Skip to content

Rework aviator plugin to submit through the aviator CLI - #30

Open
simsinght wants to merge 5 commits into
split-verify-and-runbook-commandsfrom
cli-forward-commands
Open

Rework aviator plugin to submit through the aviator CLI#30
simsinght wants to merge 5 commits into
split-verify-and-runbook-commandsfrom
cli-forward-commands

Conversation

@simsinght

Copy link
Copy Markdown
Contributor

Replace the MCP mechanics in the aviator plugin with aviator CLI invocations: aviator verify / aviator runbook for submission, and aviator verify get / aviator verify edit for the acceptance-criteria freshness loop. The flows themselves (AC review loop, intent guidance, PR directive) are unchanged.

  • Drop .mcp.json — the plugin no longer wires the MCP server.
  • spec-submission skill: CLI preflight (install + API token), repo derivation from the git remote, spec-to-file for --spec, --criteria-file guidance, and result parsing from the CLI's stdout.
  • README and marketplace entry updated; aviator plugin bumped to 2.0.0 since it now requires the aviator CLI binary and an API token instead of the MCP server.

Replace the MCP mechanics (specSubmit / getRunbook / editRunbook and
the auto-wired MCP server) with aviator CLI invocations: aviator
verify / aviator runbook for submission, aviator verify get / edit
for the AC freshness loop. Flows, AC review loop, and PR directive
are unchanged. Drops .mcp.json; README and marketplace entry updated,
version bumped to 2.0.0 since the plugin now requires the CLI.
@simsinght
simsinght marked this pull request as ready for review July 23, 2026 20:47
Simrandeep Singh added 4 commits July 27, 2026 13:26
The noun-scoped subcommands (aviator verify get/edit) never shipped;
the CLI settled on generic top-level verbs over typed ids. The AC
freshness loop now reads the version via 'aviator results r/<n> --json'
and replaces criteria via 'aviator edit r/<n> --expected-version'.
Also teach the r/<n> id form, fix the example URL shape, and note that
the backend rejects a spec that embeds its own Acceptance Criteria
section when --criteria is also passed.
Findings from driving both flows end-to-end with subagents against a
local backend (verify r/220, runbook r/219):

- Repo derivation: don't assume origin — pick the remote the PR will
  target; a wrong-but-well-formed owner/repo is accepted silently.
- Preflight: check the runbook command actually has --spec/
  --criteria-file (older binaries only have them on verify).
- Realistic submit output example; note the URL host is the app URL,
  not AVIATOR_API_HOST; note show's 400 right after a runbook submit
  means generation is still running.
- Verify: point Step 3 at the non-interactive provision, reconcile
  --working-branch required-vs-optional, and trigger the AC freshness
  loop on any meaningful change, not just pushes.
- Runbook: document --title (backend otherwise truncates the prompt).
Both commands now take --intent; a runbook's implementation detail
travels in the spec, and the intent is stored verbatim on the session
and displayed in Aviator, so the quality bar on its wording carries
real weight.
…am check

The e2e smoke run showed the previous procedure fails the normal case:
a fresh working branch has no upstream, so the @{u} check never works,
and local tracking config can point at a stale repo name. Worse, two
remote URLs can be one renamed repo — GitHub redirects silently while
Aviator records the stale and current names as different repos. Derive
from where PRs actually target, then canonicalize via
'gh api repos/<o>/<r> --jq .full_name'. Also fix /verify-submit Step 1
still suggesting 'git remote get-url origin'.
@simsinght
simsinght requested a review from tulioz July 29, 2026 00:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant