scope-project

What this skill does

# Scope Project - Adversarial Project Planning

Thoroughly plans an entire project through exploration, iterative ticket drafting, and adversarial review. A planner drafts tickets; an implementer challenges them. Only when the implementer is satisfied that every ticket could be implemented without unanswered questions do the tickets go upstream.

**This skill does NOT write code.** It explores, questions, plans, and creates tickets.

## Philosophy

**Planning is cheaper than rework.** A gap discovered during planning costs minutes to fix. The same gap discovered during implementation costs hours — and may cascade into other tickets. A UX gap discovered after release costs more still. A security gap discovered after release can be catastrophic. Invest heavily in planning quality.

**Adversarial loops catch classes of gap that self-review misses.** The mandatory UX loop asks "should we build this?" — surfacing user-experience traps, mental-model misfits, dead ends, and missing recovery paths. The mandatory implementer loop asks "could we build this?" — surfacing vague requirements, unclear dependencies, and missing tickets. Different lenses catch different gaps; the planner has blind spots in both.

**Discretionary specialist loops handle architectural quality concerns.** Security and performance often have architectural implications best addressed at planning time, not bolted on after implementation. When a project has load-bearing concerns in those domains, a specialist loop runs between the UX and implementer loops. These loops are *discretionary* — invoked only when context warrants — to avoid checklist behavior on projects where the domain isn't load-bearing.

**The architectural filter governs specialist loop invocation.** Invoke a specialist loop only when the concern would require an architectural change to fix later, not a localized code edit. This filter is what prevents discretionary loops from becoming mandatory checklists. Most a11y work is implementation-time and fails the filter; most security and performance concerns in load-bearing domains pass it.

**Locked elements are constraints, not negotiations.** Each adversarial loop produces "locked" elements — UX-locked, security-locked, performance-locked — that downstream loops cannot negotiate away on grounds of effort. The implementer cannot rewrite an approved auth model because it complicates the build. The escape hatch — implementer-surfaced infeasibility loops back to whichever loop locked the element — preserves this discipline while handling the rare case where intent and physical feasibility conflict.

**Convergence is the goal, not perfection.** Each loop iterates until its reviewer is satisfied, not until every conceivable edge case is documented. Use judgment about when tickets are "good enough" — detailed enough to implement without guessing, sound enough on every applicable quality dimension, but not so verbose they become novels.

**Batch structure is a planning decision.** Tickets go upstream already tagged with their batch assignment. The batch structure should reflect real implementation dependencies, not arbitrary grouping.

## Workflow Overview

```
┌──────────────────────────────────────────────────────────────┐
│                  SCOPE PROJECT WORKFLOW                       │
├──────────────────────────────────────────────────────────────┤
│  1. Project discovery (dialogue with user)                   │
│  2. Codebase exploration                                     │
│  3. Draft project plan + identify applicable specialist      │
│     loops (present to user for approval)                     │
│  4. Create .tickets/ staging directory                       │
│  5. Draft tickets (subagent per ticket)                      │
│  6. UX adversarial review loop (mandatory):                  │
│     ├─ UX reviewer reviews all tickets                       │
│     ├─ Planner addresses feedback                            │
│     ├─ Repeat until UX reviewer signs off                    │
│     └─ Escalate to human if stalemated                       │
│  7. Specialist adversarial review loops (discretionary):     │
│     ├─ Security loop (if applicable, runs first)             │
│     ├─ Performance loop (if applicable, runs second)         │
│     ├─ Each: agent reviews, planner addresses, repeat        │
│     ├─ Andon cord: escalate to user if findings exceed       │
│     │  what planning can resolve                             │
│     └─ Skip entirely if no specialist loops apply            │
│  8. Implementation adversarial review loop (mandatory):      │
│     ├─ Implementer reviews all tickets                       │
│     ├─ Planner addresses feedback                            │
│     ├─ Escape hatch: infeasibility against any locked        │
│     │  element → relevant loop (step 6 or step 7)            │
│     ├─ Repeat until implementer signs off                    │
│     └─ Escalate to human if stalemated                       │
│  9. Present final tickets to user                            │
│ 10. Cut tickets upstream (subagent per ticket)               │
│ 11. Clean up .tickets/ directory                             │
└──────────────────────────────────────────────────────────────┘
```

## Workflow Details

### 1. Project Discovery

**Understand what the user wants to build.** This is a dialogue — ask probing questions to get a precise picture of the project.

**Questions to explore:**
- What is the project's goal? What problem does it solve?
- What's the scope? What's explicitly out of scope?
- Are there existing systems this interacts with?
- What are the constraints? (Timeline, technology, compatibility)
- Are there natural phases or batches? What depends on what?
- What does "done" look like for the whole project?

**Push back on vagueness.** If the user says "add authentication," ask: what kind? OAuth? JWT? Session-based? What providers? What permissions model? The goal is precision.

**Output:** Clear, shared understanding of the project and its boundaries.

### 2. Codebase Exploration

**Explore the codebase to understand context.** Use exploration agents and tools to map out:

- Current architecture and conventions
- Code areas that will be affected
- Existing patterns to follow or extend
- Integration points and constraints
- Third-party dependencies involved

**For third-party dependencies:**
- Use WebFetch to read API documentation
- Clone relevant repositories to `/tmp` for examination if needed
- Understand integration points and constraints

**Output:** Comprehensive understanding of the codebase as it relates to the project.

### 3. Draft Project Plan

Synthesize the discovery and exploration into a structured project plan.

**The plan should include:**

**Project summary:**
- Goal and scope (1-2 paragraphs)
- Key technical decisions and rationale

**Batch structure:**
- How many batches, and what's the ordering rationale
- Dependencies between batches
- What each batch delivers (a coherent increment)

**Ticket inventory:**
- List of tickets per batch (title + one-line summary)
- Dependencies between tickets (within and across batches)
- Estimated scope per ticket (qualitative: small / medium / large)

**Risk areas:**
- Tickets that seem underspecified
- Cross-cutting concerns that span multiple tickets
- Integration risks between batches

**Applicable specialist loops:**

Apply the architectural filter (see step 7) to the plan and identify which specialist loops will run. For each candidate loop, state:

- Whether it applies (yes / no), and the architectural rationale
- If yes, which specific aspects of the plan it will scrutinize

This is the planner's recommendation; the user gets a veto in the next step. Locking the decision here, before drafting begins, prevents mid-flow renegotiation and gives the user full visibility into what reviews the project will receive.

**Present the plan to the user for approval.** This is the primary human check