Split /spec-submit into /verify-submit and /create-runbook

.claude-plugin/marketplace.json

@@ -17,8 +17,8 @@
     {
       "name": "aviator",
       "source": "./aviator",
-      "description": "Runbooks and workflow automation with Aviator MCP",
-      "version": "1.1.8"
+      "description": "Verify and Runbooks workflow automation with Aviator MCP",
+      "version": "1.2.0"
     }
   ]
 }

README.md

@@ -72,20 +72,24 @@ run `av pr --all` to create PRs for the entire stack.
 
 ### aviator
 
-Connects Claude Code to [Aviator Runbooks](https://aviator.co/runbooks) via MCP for workflow automation.
+Connects Claude Code to Aviator via MCP for spec submission to [Runbooks](https://aviator.co/runbooks) and Verify, to automate development workflows.
 
-**What are Runbooks?** Aviator Runbooks let you capture and replay complex development workflows. Create a runbook from your Claude session to save your exploration, decisions, and implementation approach for future use or to share with your team.
+**Verify vs Runbooks.** Aviator has two ways to hand a spec off from your Claude session:
+
+- **Verify** — *you* write the code and Aviator verifies it against your intent. You submit an intent, a free-form spec of the key decisions, and acceptance criteria; Aviator checks the PR you open against those criteria.
+- **Runbooks** — *Aviator's agent* writes the code from your spec. The spec carries full implementation detail so the runbook can capture and replay the workflow.
 
 **What this plugin does:**
 
-- Connects to the Aviator MCP server for runbook operations
-- Creates runbooks from your current Claude session context
+- Connects to the Aviator MCP server for spec submission and runbook operations
+- Submits Verify specs and creates runbooks from your current Claude session context
 - Handles OAuth authentication automatically
 - Provides access to Aviator's workflow automation tools
 
 **Usage:**
 
-Use `/spec-submit` to submit a spec and create a runbook from your current session.
+- `/verify-submit` — submit a Verify spec (intent + acceptance criteria) for code you're writing yourself.
+- `/create-runbook` — have Aviator's agent write the code from a spec with provided implementation detail.
 
 **Requirements:**
 

aviator/.claude-plugin/plugin.json

@@ -1,12 +1,12 @@
 {
   "name": "aviator",
-  "description": "Create Aviator Runbooks from Claude Code sessions to capture and relay development workflows",
+  "description": "Submit specs to Aviator from Claude Code sessions — Verify (intent + acceptance criteria over your own code) and Runbooks (agentic code generation)",
   "author": {
     "name": "Aviator",
     "email": "support@aviator.co"
   },
   "homepage": "https://aviator.co",
   "repository": "https://github.com/aviator-co/agent-plugins",
   "license": "MIT",
-  "keywords": ["runbooks", "aviator", "spec-driven", "spec-driven-development"]
+  "keywords": ["verify", "runbooks", "aviator", "spec-driven", "behavior-driven-development"]
 }

aviator/commands/create-runbook.md

@@ -0,0 +1,60 @@
+---
+description: Create an Aviator Runbook — Aviator's agent writes the code from your spec
+---
+
+# Create a Runbook
+
+Create an Aviator Runbook from the current Claude Code session context. **Aviator's agent writes the code** from the spec you submit, so this flow carries full implementation detail — intent, scope, ordered steps, and acceptance criteria — and includes an implementation discussion with you before kicking off.
+
+> Writing the code yourself and just want Aviator to verify it against intent + acceptance criteria? Use `/verify-submit` instead — it captures intent and AC with no implementation steps.
+
+**Load the `spec-submission` skill** (Skill tool → `aviator:spec-submission`) before you start — it carries the shared mechanics this flow relies on: how the message reads, the Acceptance Criteria review loop, the `specSubmit` call, and the PR directive. This command file only covers what's specific to a Runbook.
+
+## Arguments
+
+$ARGUMENTS - Optional additional context or instructions for the runbook.
+
+## Step 1: Generate Message + Spec
+
+Write the message per the `spec-submission` skill, and the Acceptance Criteria per the `acceptance-criteria` skill — **AC are the primary output of this step.** What's specific to a Runbook is that the spec **carries implementation detail** — the agent uses it to write the code.
+
+### Spec file
+
+The spec provides the supporting context the AC needs to be unambiguous, plus the implementation detail the agent works from. Don't pad.
+
+If a plan file exists from plan mode (check the plan file path mentioned in the system prompt), read it and check whether its content is relevant to the user's current intent. If it is, use it as-is — do not restructure, reformat, or rewrite it. Pass its content through directly as the spec. If the plan file is unrelated to the current task, ignore it and generate a new spec instead.
+
+Similarly, if a spec file already exists in the conversation — one the user wrote, one generated earlier, or one provided via `$ARGUMENTS` — use it as-is. Do not restructure, reformat, or rewrite an existing spec. When the spec comes from a file, preserve the original filename.
+
+If no existing spec is available, generate one. Keep it **free-form** — there's no required structure or fixed set of sections. Write whatever best conveys the change to the agent that will implement it: the intent and the implementation approach or steps, shaped to the task rather than forced into headings. (The acceptance criteria are passed separately as the `acceptance_criteria` argument — you don't hand-embed them; the backend folds them into the spec the agent works from.)
+
+## Step 2: Review with the user
+
+Before submitting, show the user three things and get their sign-off:
+
+1. **The intent** — the short intent message, for grounding.
+2. **The Acceptance Criteria** — run the review loop from the `spec-submission` skill, iterating until the user explicitly confirms.
+3. **Any pertinent questions or callouts** — while writing the free-form spec, notice anything the user should weigh in on before submitting: a consequential choice (a new dependency, a data migration, a public API change, an area to leave untouched), an ambiguity in the approach, or a decision you made that they haven't seen. Raise only what's genuinely open — if the approach was already settled earlier in this session, don't re-litigate it.
+
+A simple "yes" or "go ahead" is enough to submit.
+
+## Step 3: Create Runbook
+
+Submit via the `specSubmit` call described in the `spec-submission` skill. For a Runbook:
+
+- `submission_type`: **`"runbook"`** — the agent writes the code from the spec. This is the default, but pass it explicitly.
+- `acceptance_criteria`: the confirmed AC as a JSON array of strings (optional but recommended — they're folded into the spec the agent works from).
+- `spec_files`: include only if a spec was generated; always a single file.
+- `target_branch`: **optional** — the base branch the runbook builds on and checks out; the generated PR opens against it. Omit for the repo default (trunk). (Runbook mode generates its own PR, so there's no `working_branch` to connect here.)
+
+Then return the Runbook URL and set the PR directive, both per the `spec-submission` skill. The expected PR body shape:
+
+```
+Runbook: <runbook-url>
+
+## Summary
+…
+
+## Test plan
+…
+```