scope-project

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 checkp