Implement-Project - Full-Lifecycle Project Workflow
Orchestrates an entire project from tickets to release-ready code. Implements batched tickets via /implement-batch, runs smoke tests, then executes a comprehensive quality pipeline. Maximizes autonomy — the andon cord is the only planned escalation path.
Philosophy
This skill implements the autonomy discipline documented in references/autonomy.md: the five levers (altitude rule, pre-loaded options, pre-rebutted recommendation, commander's intent, risk budgets), the cascade rule, the shared handoff template, and the "log instead of escalate" pattern. Its commander's-intent schema is the four-field variant defined there (tickets, acceptance bar, constraints, non-goals).
Autonomy is the default; escalation is the exception. The goal is to complete an entire project — multiple batches of tickets, quality passes, and verification — without user intervention. When stuck, try /think-deliberate first. Only pull the andon cord when autonomous resolution has failed or is clearly futile.
The project branch is the single integration point. All work flows into the project branch. Batches merge into it, quality passes commit to it, and the user makes one decision at the end: merge or don't.
Quality is layered. Each quality pass builds on the previous one. Refactoring cleans the code so review-arch can focus on structure. Arch-review surfaces structural recommendations (advisory only — /review-arch no longer implements changes; see the "Advisory aspiration" section of references/autonomy.md) so review-test can survey coverage of the current form. Review-test surfaces ticket-shaped test work (advisory only — /review-test no longer writes tests in-skill). Tidy-docs documents what actually shipped. Release-review validates the whole.
Fresh eyes catch what familiarity misses. Each quality pass runs its full workflow, including any embedded sub-passes (e.g., /refactor runs its own /tidy-docs). Redundancy is intentional — each agent sees the project with fresh context and may catch issues that prior passes normalized.
Workflow Overview
┌──────────────────────────────────────────────────────────────┐
│ PROJECT WORKFLOW │
├──────────────────────────────────────────────────────────────┤
│ 1. Gather tickets and batching strategy │
│ 2. Discuss smoke testing procedures │
│ 3. Plan execution + elicit commander's intent │
│ 4. Create project branch │
│ 5. Per-batch loop: │
│ ├─ 5a. Create batch branch from project branch │
│ ├─ 5b. Run /implement-batch workflow (autonomous mode) │
│ ├─ 5c. Merge batch branch → project branch │
│ ├─ 5d. Post-merge verification │
│ └─ 5e. Clean up and checkpoint │
│ 6. Smoke testing │
│ 7. Quality pipeline: │
│ ├─ 7a. /refactor (MAXIMUM aggression) │
│ ├─ 7b. /review-arch (advisory; ticket proposal) │
│ ├─ 7c. /review-test (advisory; ticket proposal) │
│ ├─ 7d. /tidy-docs │
│ └─ 7e. /review-release │
│ 8. Final report │
└──────────────────────────────────────────────────────────────┘
The former conditional second /refactor (previously step 7c, which ran when /review-arch made substantive changes) is removed. /review-arch is now advisory and does not make changes; the conditional can never fire.
Available Tools
Beyond the mainline workflow, the orchestrator has access to additional workflows:
/think-deliberate: Adversarial deliberation for difficult autonomous decisions. Spawns advocates to argue options before rendering a verdict. Prefer this over gut-feel decisions when stakes are high or trade-offs are unclear./bug-fix: Coordinated bug-fixing for challenging issues encountered during any phase. Handles diagnosis, reproduction, and targeted fixes.
Andon Cord Protocol
This protocol applies throughout the entire workflow. The andon cord is the escape valve for problems that cannot be resolved autonomously.
Before pulling the andon cord:
- Attempt autonomous resolution first.
- For judgment calls, run
/think-deliberateto reason through options. - Only escalate if autonomous resolution has failed or is clearly futile.
When the andon cord is pulled:
- Stop all work immediately — do not attempt to continue with other batches or steps.
- Produce a handoff using the shared handoff template in
references/autonomy.md. The escalation must include pre-loaded options (2–3 named choices), an explicit recommendation, the one tradeoff that would flip the recommendation, and a pre-rebutted counterargument. Include the skill-specific state: current phase and step, what/think-deliberatewas already considered, current state of all branches (what's merged into the project branch, what's in-progress), and how far through the per-batch loop or quality pipeline the run is. - Wait for user guidance before resuming.
Andon cord triggers (skill-specific):
- Batch workflow pulls its own andon cord (cascades up)
- Merge conflict between batch branch and project branch
- Smoke testing reveals fundamental design issues that can't be fixed locally
- Quality pass reveals blocking issues the orchestrator can't resolve
- Project branch already exists (step 4)
- Any situation where continuing would compound errors rather than resolve them
Workflow Details
1. Gather Tickets and Batching Strategy
Ask the user:
- Which tickets belong to this project? (IDs, tags, milestones, etc.)
- How are they batched? (e.g., tagged
batch-1,batch-2; or user specifies explicit grouping) - What's the batch execution order?
If batching is unclear: Ask. Do not guess at grouping — the user has a reason for the batch structure.
Fetch all tickets using the shared tracker detection from references/trackers.md. Gather title, description, acceptance criteria, labels, and dependencies for each.
2. Discuss Smoke Testing Procedures
Ask the user: "What smoke testing should be performed after implementation? This varies by project type."
Offer examples if the user needs prompts:
- CLI tool: run the binary with representative commands, verify output
- MCP server: build the binary, send JSON-RPC commands, verify responses
- Web app: use Playwright MCP for browser testing
- Library: run integration tests, verify public API works end-to-end
- API server: hit key endpoints, verify responses
Record the procedure. It will be used for:
- Step 6 (smoke testing)
- QA instructions passed to quality passes (steps 7a-7e)
3. Plan Execution Across Batches + Elicit Commander's Intent
Analyze all tickets across all batches and produce an execution plan, and elicit the commander's-intent fields beyond the tickets themselves.
Per-batch analysis:
- Tickets in this batch and their dependencies
- Estimated scope (qualitative)
- Any concerns about ambiguous or under-specified tickets
Cross-batch analysis:
- Dependencies between batches (batch 2 might depend on batch 1's changes)
- Optimal batch ordering
- Risk areas where batches might conflict
Elicit commander's intent (the four-field schema from references/autonomy.md):
| Field | Default | Notes |