|
| 1 | +--- |
| 2 | +name: autoship |
| 3 | +description: Use when the user wants fully autonomous delivery in this repo from the next ready bd issue through implementation, verification, review, and PR follow-through. |
| 4 | +--- |
| 5 | + |
| 6 | +# Autoship |
| 7 | + |
| 8 | +Run an end-to-end autonomous ship cycle for `dubstack`. Do not pause for confirmation unless blocked. |
| 9 | + |
| 10 | +## Non-Negotiables |
| 11 | + |
| 12 | +- Operate autonomously and avoid routine follow-up questions; make reasonable assumptions and record them. |
| 13 | +- Keep issue tracking in `bd` only. |
| 14 | +- Start with `bd ready --json`, pick work deterministically, and claim it. |
| 15 | +- Run two `review-council` passes: |
| 16 | + - Plan pass: `Architect` persona, prefer `claude`. |
| 17 | + - Code pass: `Staff Engineer` persona, prefer `claude` + `codex` + `gemini`. |
| 18 | +- Run repository quality gates twice (before and after council-driven fixes). |
| 19 | +- Require zero failures and zero warnings. |
| 20 | +- Run quality checks strictly sequentially (never parallel). |
| 21 | +- Use this repository's required quality-gate sequence: |
| 22 | + - `pnpm checks` |
| 23 | + - `pnpm typecheck` |
| 24 | + - `pnpm test` |
| 25 | +- If AI metadata or prompt generation changed, also run `pnpm evals`. |
| 26 | +- Maintain autonomy for git/PR operations: branch, commit, push, submit PR, and update the branch without waiting for extra confirmation. |
| 27 | +- Work only in the current checkout (no git worktrees). |
| 28 | +- Produce a written summary report for the user. |
| 29 | + |
| 30 | +## Workflow |
| 31 | + |
| 32 | +1. Select and claim work: |
| 33 | + - Run `bd ready --json`. |
| 34 | + - Pick the highest-priority unblocked issue (tie-breaker: oldest issue). |
| 35 | + - Run `bd update <id> --claim --json`. |
| 36 | + - Run `bd show <id> --json` and capture acceptance criteria. |
| 37 | + |
| 38 | +2. Build an implementation plan: |
| 39 | + - Ensure plan directory exists: `mkdir -p .dispatch`. |
| 40 | + - Write a plan file at `.dispatch/<id>-implementation-plan.md`. |
| 41 | + - Include: scope, assumptions, risks, step-by-step tasks, test strategy, and rollback notes. |
| 42 | + |
| 43 | +3. Plan review council (round 1): |
| 44 | + - Use the `review-council` skill. |
| 45 | + - Persona: `Architect`. |
| 46 | + - Prefer `claude`; if unavailable, use the best available reviewer and note the limitation. |
| 47 | + - Revise the plan based on feedback and save changes. |
| 48 | + |
| 49 | +4. Implement: |
| 50 | + - Execute plan steps in order. |
| 51 | + - Maintain existing repo patterns and code standards. |
| 52 | + - Add/update tests for changed behavior near the edited code. |
| 53 | + - If new follow-up work is discovered, create linked bead issues using |
| 54 | + `--deps discovered-from:<current-id>`. |
| 55 | + |
| 56 | +5. Quality gates (pass 1): |
| 57 | + - Run checks strictly one at a time. Start the next check only after the |
| 58 | + current check fully exits. |
| 59 | + - Never run multiple quality checks concurrently. |
| 60 | + - If a check is slow, keep waiting. Do not interrupt or spawn extra checks. |
| 61 | + - Execute this exact verification sequence, one command at a time: |
| 62 | + - `pnpm checks` |
| 63 | + - `pnpm typecheck` |
| 64 | + - `pnpm test` |
| 65 | + - If AI metadata or prompt generation changed: |
| 66 | + - `pnpm evals` |
| 67 | + - If repository policy requires wrappers/sub-agents for checks, still run the |
| 68 | + same checks in this exact order, sequentially. |
| 69 | + - Treat any warning as a failure. |
| 70 | + |
| 71 | +6. Code review council (round 2): |
| 72 | + - Use the `review-council` skill. |
| 73 | + - Persona: `Staff Engineer` with strict review tone ("hard-ass staff engineer"). |
| 74 | + - Prefer council members: `claude`, `codex`, and `gemini`. |
| 75 | + - If one member is unavailable, continue with available reviewers and record the gap. |
| 76 | + - Apply all valid fixes and document any rejected feedback with rationale. |
| 77 | + |
| 78 | +7. Quality gates (pass 2): |
| 79 | + - Re-run the exact same full verification set from step 5. |
| 80 | + - Do not proceed until every check passes with zero warnings. |
| 81 | + |
| 82 | +8. Create stacked PR: |
| 83 | + - Use a non-interactive autonomous `dub-flow` path for branch + commit + submit (for example: `dub flow --ai -a -y`). |
| 84 | + - Ensure PR description includes scope, test evidence, and bead reference(s). |
| 85 | + - If `dub-flow` is unavailable, fall back to direct non-interactive commands (`dub create ...` + `dub ss`) and record why. |
| 86 | + |
| 87 | +9. Post-PR CI watch and fix loop: |
| 88 | + - Run `gh pr checks --watch` and wait for completion. |
| 89 | + - If any check fails or reports issues: |
| 90 | + - Fix the issues in code. |
| 91 | + - Re-run the full local verification set sequentially (same commands as |
| 92 | + step 5/7). |
| 93 | + - Update the PR branch. |
| 94 | + - Run `gh pr checks --watch` again. |
| 95 | + - Repeat until all PR checks complete successfully. |
| 96 | + |
| 97 | +10. Copilot review comments: |
| 98 | + - Ensure a Copilot review exists on the PR. |
| 99 | + - After CI is green, review Copilot comments and resolve all valid feedback. |
| 100 | + - Use the `review-pr-comments` skill in autonomous mode (do not pause for |
| 101 | + user confirmation) to process unresolved review threads. |
| 102 | + - For rejected comments, provide technical rationale in-thread before |
| 103 | + resolving. |
| 104 | + - If code changes were made while addressing comments, re-run local quality |
| 105 | + checks sequentially and run `gh pr checks --watch` again. |
| 106 | + |
| 107 | +11. Produce final report: |
| 108 | + - Ensure report directory exists: `mkdir -p docs/reports`. |
| 109 | + - Create `docs/reports/<date>-<id>-autoship-report.md` using |
| 110 | + [report-template.md](references/report-template.md). |
| 111 | + - Include: selected bead, plan changes from council, implementation summary, |
| 112 | + quality gate evidence (both passes), review-council findings + resolutions, |
| 113 | + CI watch cycles, Copilot review comment resolutions, PR link, and any |
| 114 | + follow-up beads. |
| 115 | + - Share a concise handoff summary with the user. |
| 116 | + |
| 117 | +## Failure Handling |
| 118 | + |
| 119 | +- If blocked by missing credentials, missing CLI tools, or infrastructure failure, |
| 120 | + stop and provide a blocker report with exact failing command, error, and next action. |
| 121 | +- Do not skip required steps, quality gates, or council rounds. |
0 commit comments