/scope-project

name: scope-project
description: Adversarial project planning workflow. Explores the problem space, drafts tickets in batches, then runs sequential adversarial loops — a mandatory UX loop ("should we build this?"), zero or more discretionary specialist loops (security, performance) for projects with architectural implications in those domains, and a mandatory implementer loop ("could we build this?") — to find gaps before implementation. Creates well-specified, batch-tagged tickets upstream only after every applicable loop signs off.
model: opus

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