# Scope Project > 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 implem… - **Type:** Skill - **Install:** `agentstack add skill-chrisallenlane-claude-swe-workflows-scope-project` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [chrisallenlane](https://agentstack.voostack.com/s/chrisallenlane) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [chrisallenlane](https://github.com/chrisallenlane) - **Source:** https://github.com/chrisallenlane/claude-swe-workflows/tree/master/skills/scope-project ## Install ```sh agentstack add skill-chrisallenlane-claude-swe-workflows-scope-project ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 checkpoint — the user should agree with the project structure, batch grouping, ticket inventory, and applicable specialist loops before detailed ticket drafting begins. **Wait for user approval before proceeding.** The user may adjust batches, add/remove tickets, reorder, override the planner's specialist-loop selection (add a loop the planner skipped, or skip a loop the planner included), or ask questions. Iterate until approved. ### 4. Create Staging Directory Create a `.tickets/` directory in the repository root, organized by batch: ``` .tickets/ ├── batch-1/ │ ├── 01-.md │ ├── 02-.md │ └── 03-.md └── batch-2/ ├── 01-.md └── 02-.md ``` The numbering reflects execution order within each batch. The slug is derived from the ticket title. **Add `.tickets/` to `.gitignore`** to prevent accidental commits of staging artifacts. ### 5. Draft Tickets **Spawn one subagent per ticket** to draft ticket content. Each subagent receives: - The approved project plan (from step 3) - The codebase exploration findings relevant to that ticket - The ticket's position in the batch structure (what comes before it, what depends on it) **Each subagent writes a markdown file** in the `.tickets/` directory following this format: ```markdown --- title: batch: order: depends_on: [] labels: [batch-N, ] --- ## Problem Statement [What problem does this ticket solve? Why is it needed?] ## Proposed Solution [High-level approach — what to build, not how to build it line-by-line] ## Acceptance Criteria - [ ] [Specific, testable criterion] - [ ] [Another criterion] ## Technical Notes [Implementation considerations, affected components, relevant code paths] - Affected files: [list key files] - Key functions: [list functions to modify/create] - Patterns to follow: [existing patterns in the codebase] - Security considerations: [if applicable — new attack surface, input handling, auth/authz changes, trust boundary impacts] ## Implementation Notes [Guidance for the implementer — current function signatures, module boundaries, integration points. The kind of context that saves the implementer from having to rediscover what the planner already found.] ## Dependencies - Depends on: [list ticket slugs this depends on] - Blocks: [list ticket slugs that depend on this] ## Out of Scope [What explicitly will NOT be done in this ticket] ``` **Subagent coordination:** - Subagents run in parallel where possible (independent tickets) - Sequential for tickets with dependencies (later ticket needs to reference earlier ticket's content) - Each subagent writes its file and reports completion ### 6. UX Adversarial Review Loop This loop runs **before** the implementer review. UX issues become hard constraints on the implementation discussion — they are not items the implementer can negotiate away on grounds of effort. The technical loop catches "could I build this?" reliably, but never asks "should this be built this way?". That is what this loop catches: features that work but trap users, surfaces that imply a mental model the user does not share, dead ends with no recovery, expert tools that lock out novices. #### 6a. Spawn UX Reviewer **Spawn a fresh `ux-reviewer` agent** to review the entire ticket set. The reviewer reads all tickets together (not ticket-by-ticket — coherence across tickets is part of what it evaluates) and walks a fixed seven-concern spine: 1. **Coherence** — consistent mental model across tickets? 2. **Completeness** — implicit user needs unaddressed? Dead ends? 3. **Mental-model fit** — surface matches how users will think? 4. **Implicit knowledge** — what must users already know? 5. **Failure paths** — recovery legible when things go wrong? 6. **Power/novice tension** — both served, or one privileged? 7. **Orientation** — does the user know where they are and what's next? The agent auto-detects target type (CLI / MCP server / webapp / library / mixed) from project signals and adapts the *evidence it inspects* by type, but walks all seven concerns regardless. If the target type is ambiguous, it asks you to clarify. **Prompt the reviewer with:** ``` You are reviewing a draft ticket set as a UX advocate before implementation begins. Your role is adversarial: find user-experience problems while they are still cheap to fix. Review *all tickets together* — coherence across tickets is part of your evaluation. Walk the seven-concern spine systematically: 1. Coherence — consistent mental model across tickets? 2. Completeness — implicit user needs unaddressed? Dead ends? 3. Mental-model fit — surface matches how users will think? 4. Implicit knowledge — what must users already know? 5. Failure paths — recovery legible when things go wrong? 6. Power/novice tension — both served, or one privileged? 7. Orientation — does the user know where they are and what's next? Auto-detect target type (CLI / MCP / webapp / library / mixed) from project signals. If ambiguous, ask the orchestrator. Adapt the *evidence you look at* by target type, but walk all seven concerns regardless. Categorize findings: blocker / concern / suggestion. Issue verdict: APPROVED or NEEDS REVISION. Do not critique technical implementation choices — that is the implementer's lens, not yours. ``` #### 6b. Planner Addresses UX Feedback The orchestrator (you, the planner) reviews each finding and responds: - **Blockers:** Must be addressed. Revise the affected ticket(s) so the UX issue is resolved. - **Concerns:** Address them, or document explicitly why the concern is acceptable in this context. Don't silently dismiss. - **Suggestions:** Use judgment. Accept those that improve the design; decline those that over-specify. **Asking the human is normal.** If the UX reviewer surfaces a question about user populations, intended audience, or design intent that you genuinely cannot answer, ask the user. UX questions surfaced here cost minutes; the same questions surfaced after release cost rework or shipped traps. **Update the `.tickets/` files** with revisions. UX-locked elements — concept names, error semantics, command/tool names, workflow shapes the reviewer approved — become hard constraints. The downstream reviews (specialist loops in step 7, implementer in step 8) must not negotiate them away on grounds of effort. If the implementer later surfaces an infeasibility that breaks one of these, that is the escape hatch back to step 6, not a license to revise UX unilaterally. #### 6c. Re-Review **Spawn a fresh `ux-reviewer`** (clean context) to review the revised tickets. The fresh instance prevents anchoring on prior findings. **Repeat steps 6a-6c until:** - The reviewer returns `APPROVED` — the design is UX-cogent across the seven concerns - **Or** the process has stalemated — same blockers cycling without resolution **On stalemate:** Escalate to the human. UX stalemate usually means a design intent the user has not made explicit — exactly what this loop is designed to surface. Present the unresolved findings and ask for direction. **There is no hard iteration cap.** Convergence is the goal. Most projects converge in 1-2 rounds at this loop because the spine is fixed and the planner has more visibility into the design than into implementation feasibility. ### 7. Specialist Adversarial Review Loops This step runs zero or more discretionary specialist adversarial loops between the UX loop (mandatory) and the implementer loop (mandatory). Specialist loops catch architectural quality concerns — security, performance — that the design-intent and feasibility loops miss but that are catastrophic to bolt on after implementation. **If no specialist loops apply (per the architectural filter and step 3 selection), skip this step entirely.** Most projects do not need specialist loops. The discipline is in *not* invoking them when they aren't load-bearing. #### The Architectural Filter (Load-Bearing Meta-Rule) Before any specialist loop is invoked, apply this filter: > **Would this co … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [chrisallenlane](https://github.com/chrisallenlane) - **Source:** [chrisallenlane/claude-swe-workflows](https://github.com/chrisallenlane/claude-swe-workflows) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-chrisallenlane-claude-swe-workflows-scope-project - Seller: https://agentstack.voostack.com/s/chrisallenlane - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.