implement-project

What this skill does

# 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 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`](../../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`](../../references/autonomy.md)):

| Field           | Default                                                            | Notes                                                                               |