API or Git-based workflow to promote Bugbot learned rules into repository rules

Ideas Feature Requests
,
1

Feature request for product/service

BugBot

Describe the request

We use Bugbot alongside repository-managed AI rules.

Our repository rules are versioned under a single source of truth and referenced by both Cursor Agents and .cursor/BUGBOT.md. This gives us code review, ownership and conflict resolution through pull requests.

The issue is Bugbot’s learned rules: they live only in the Cursor dashboard. This creates a second, non-versioned rule store that can become redundant or conflict with repository rules.

Our ideal workflow would be:

Bugbot learns or proposes a rule.
We retrieve its full content and metadata.
An agent compares it against our repository rules for duplicates, overlaps and contradictions.
A human validates the proposal through a pull request.
Once merged, the dashboard learned rule is disabled or marked as promoted.
Today, GitHub comments expose the learned rule ID, title and dashboard URL, but not necessarily its full content, scope or status. Scraping an authenticated dashboard or relying on internal APIs would be too fragile.

Are any of the following available or planned?

A supported API to list, read, update and disable learned rules.
An export format such as JSON or Markdown.
Webhooks when a learned rule is created, promoted, updated or disabled.
A Git-backed mode where learned rules are proposed as pull requests.
An approval mode preventing learned rules from becoming active before human validation.
Metadata linking a learned rule to the PR comments and feedback that produced it.
The goal is not to disable learning, but to keep one auditable and version-controlled ruleset without requiring developers to manually copy rules from the dashboard.

5

A middle path that has worked well: keep Bugbot as the authoring surface and mirror the learned rules into the repo with a small CI script that regenerates the rules file on every push. Git keeps the versioning, the agent keeps the authoring, and nothing is hand-copied. Whether the API route also allows scoping which rules get promoted per branch seems worth asking for, since staging usually wants a looser set than main.

8

Thanks — this sounds close to what we need. Could you share how your CI script retrieves the learned rules?

In particular:

  • Which API or endpoint do you use?
  • How is authentication handled?
  • Does it expose the full rule content, scope, status and stable ID?
  • Is this a supported API or an internal dashboard endpoint?

We would likely mirror rules into a candidate file first, then promote them into our canonical rules through a human-reviewed PR, rather than automatically enforcing every dashboard change.

If you can share a minimal example of the script or API response, that would be extremely helpful.