/implement-project

name: implement-project
description: Full-lifecycle project workflow. Takes batched tickets, implements via /implement-batch, runs smoke tests, then executes a comprehensive quality pipeline (refactor, review-arch, review-test, tidy-docs, review-release). Maximizes autonomy with andon cord escape.
model: opus

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`](../../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`](../../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:** 1. Attempt autonomous resolution first. 2. For judgment calls, run `/think-deliberate` to reason through options. 3. Only escalate if autonomous resolution has failed or is clearly futile.

**When the andon cord is pulled:** 1. **Stop all work immediately** — do not attempt to continue with other batches or steps. 2. Produce a handoff using the **shared handoff template** in [`references/autonomy.md`](../../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-deliberate` was 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. 3. 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 f