Add approve and ship workflow shortcuts

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "powers",
   "description": "Thin dev-workflow plugin: brainstorm-to-spec, TDD, spec-scoped subagents, and a verify gate — built on native Claude Code primitives.",
-  "version": "0.3.2",
+  "version": "0.4.0",
   "author": { "name": "corvid", "email": "claude@corvid.boo" },
   "license": "MIT"
 }

README.md

@@ -23,6 +23,12 @@ adversarial review → hard verify gate.**
   command fails.
 - **`setup` skill** — `/powers:setup` rolls a repo out: detects test/build
   commands, asks for `VERIFY_LEVEL`, generates CLAUDE.md + verify.sh, commits.
+- **`approve` shortcut** — `/powers:approve` after reviewing a brainstormed
+  spec: counts as explicit approval, commits the spec, enters plan mode.
+  User-invoked only.
+- **`ship` shortcut** — `/powers:ship` when the branch's work is done: opens
+  the PR, requests + waits for Copilot's review, fixes what's relevant, states
+  why the rest was skipped. User-invoked only.
 
 ## Install
 

skills/approve/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: approve
+description: >-
+  Shortcut for "Approved. Commit the spec, then plan the implementation."
+  Invoke after reviewing the spec a brainstorm produced. Counts as the
+  explicit spec approval the brainstorming hard-gate waits for.
+disable-model-invocation: true
+---
+
+# Spec Approved → Plan
+
+The user has read the spec file just presented and approves it as written.
+This invocation **is** the explicit approval the brainstorming hard-gate
+requires — no further confirmation needed.
+
+**Guard first.** If no spec file is awaiting approval in this conversation —
+no brainstorm happened, or the spec was already approved and committed — say
+so and stop. Approval of nothing is nothing.
+
+Then:
+
+1. **Commit the spec** on the current branch with message `spec: <slug>`,
+   per the brainstorming skill. If the spec file is already committed and
+   unchanged since, skip the commit rather than creating an empty one.
+2. **Enter plan mode** and plan the implementation of that spec. The spec is
+   the contract: plan tasks should map to its acceptance criteria, and its
+   scope boundaries bound the plan. Nothing in the plan may widen the spec —
+   if planning surfaces a scope problem, that's a spec edit (and commit)
+   first.
+
+Approval covers exactly the spec as it stands at invocation. If the user
+attached changes to this invocation, that's not approval yet — apply the
+changes, re-present the spec, and wait.

skills/brainstorming/SKILL.md

@@ -72,7 +72,8 @@ that contradict each other? A requirement readable two ways? Fix inline.
 
 Ask the user to review the spec file. When they approve, **commit it on the
 current branch** with message `spec: <slug>`. This commit must exist before
-any implementation starts.
+any implementation starts. (`/powers:approve` is the fast path: it counts as
+explicit approval and continues into commit + plan mode.)
 
 ## The Spec Is Versioned
 

skills/ship/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: ship
+description: >-
+  Shortcut for "Open the PR, wait for Copilot's review, then fix anything
+  relevant it brings up." Invoke when the body of work on the current branch
+  is done.
+disable-model-invocation: true
+---
+
+# Ship: PR → Copilot Review → Fix
+
+The work on the current branch is done. Get it into a reviewed, green PR.
+
+## 1. Preflight
+
+- Working tree clean — everything meant to ship is committed. Uncommitted
+  changes are a stop: show them and ask whether to commit or drop.
+- Verify passes (`scripts/verify.sh` or the repo's test command). Red means
+  fix first, not ship anyway.
+
+## 2. Open the PR
+
+Push the branch and open a PR against the repo's default branch. Title from
+the spec slug where one exists; body summarizes what shipped and links the
+spec file. Follow the repo's PR template if it has one. If a PR for this
+branch already exists, reuse it — push and continue.
+
+## 3. Request Copilot's review
+
+Check whether the repo auto-requests Copilot on new PRs (a pending review
+request from Copilot appears immediately). If not, request it:
+
+```
+gh api --method POST repos/{owner}/{repo}/pulls/{number}/requested_reviewers \
+  -f 'reviewers[]=copilot-pull-request-reviewer[bot]'
+```
+
+## 4. Wait for the review
+
+If the environment has a PR-watch tool (e.g. `subscribe_pr_activity`),
+subscribe and end the turn — the review arrives as an event. Otherwise poll
+(`gh pr view --json reviews` or the reviews API) roughly every minute. After
+~10 minutes with no review, report the PR URL and stop waiting — don't spin
+forever.
+
+## 5. Triage and fix
+
+Go through every comment in Copilot's review. Each one gets exactly one of:
+
+- **Fix** — it's a real issue in scope. Fix it test-first per the tdd skill
+  and push.
+- **Skip, with a stated reason** — false positive, out of scope, or contradicts
+  the spec. One line each; reply on the thread only where a reply is genuinely
+  useful.
+
+Never silently ignore a comment, and never "fix" something by weakening a
+test or the spec.
+
+## 6. Report
+
+PR URL, what was fixed (with commits), what was skipped and why, and current
+CI state.