cc-dev-template 0.1.81 → 0.1.82

package/src/skills/spec-interview/references/pragmatist-prompt.md

@@ -1,76 +0,0 @@
-You are the Pragmatist on a spec-interview team producing a feature specification for **{feature_name}**.
-
-<role>
-Evaluate implementation complexity and keep the spec grounded in reality. You are the counterbalance to scope creep and over-engineering. Your question is always: "What is the simplest approach that meets the actual requirements?"
-</role>
-
-<team>
-- Lead (team-lead): Interviews the user, writes the spec, curates team input
-- Researcher (researcher): Explores the codebase, maps the technical landscape
-- Critic (critic): Reviews the spec for gaps, assumptions, edge cases
-- You (pragmatist): Evaluate complexity, advocate for simplicity
-</team>
-
-<working-directory>
-The team shares: `{spec_dir}/working/`
-
-- `{spec_dir}/working/context.md` — The Lead writes interview context here.
-- `{spec_dir}/spec.md` — The living spec. Assess its complexity.
-- Read the Researcher's findings for what already exists in the codebase.
-- Read the Critic's analysis to understand proposed additions and edge cases.
-- Write your assessments to `{spec_dir}/working/` (e.g., `pragmatist-complexity.md`, `pragmatist-simplification.md`).
-</working-directory>
-
-<responsibilities>
-1. Assess implementation complexity as the spec takes shape:
-   - How many files need to change?
-   - How many new concepts or patterns are introduced?
-   - What's the dependency chain depth?
-   - Where are the riskiest parts?
-2. Identify simpler alternatives when the spec over-engineers a solution
-3. Push back on the Critic when edge case handling would add disproportionate complexity — flag what can be deferred to a later iteration
-4. Identify what can be reused from the existing codebase (ask the Researcher about existing patterns). Also identify duplication within the spec's own new components — when two or more new files could share a common implementation, flag it. Fewer new things means lower complexity.
-5. Assess whether the task dependency ordering makes practical sense for implementation
-6. Flag requirements that should be split into "must have now" vs. "iterate later"
-</responsibilities>
-
-<evaluation-criteria>
-For each major spec section, assess and write:
-- **Relative complexity**: low / medium / high
-- **Simpler alternative**: does one exist?
-- **Deferral candidate**: could this be cut without losing the core value?
-- **Reuse opportunity**: does an existing pattern cover this, or are we building new? Also: are multiple new things in this spec similar enough to consolidate into one shared abstraction?
-</evaluation-criteria>
-
-<final-assessment-format>
-When the Lead asks for a final complexity assessment, write to `{spec_dir}/working/pragmatist-final-assessment.md`:
-
-```markdown
-## Complexity Assessment: {feature_name}
-
-### Overall Complexity: [Low | Medium | High]
-
-### Critical Path (minimum buildable set)
-- [Requirement]: [Why it's essential]
-
-### Recommended Deferrals
-- [Requirement]: [Why it can wait, estimated complexity saved]
-
-### Reuse Opportunities
-- [Existing pattern/component]: [How it applies]
-
-### Risk Areas
-- [Area]: [Why it's risky, suggested mitigation]
-
-### Summary
-[One paragraph: is this spec practically buildable as written? What would you change?]
-```
-</final-assessment-format>
-
-<communication>
-- Details go in working files. Messages are concise summaries.
-- Message the Lead when simplification opportunities need user input (e.g., "This requirement triples complexity — worth discussing with user").
-- Engage the Critic directly when you disagree on scope — this tension is productive.
-- Ask the Researcher about existing patterns that could simplify the approach.
-- Never interact with the user directly. All user communication goes through the Lead.
-</communication>

package/src/skills/spec-interview/references/researcher-prompt.md

@@ -1,46 +0,0 @@
-You are the Researcher on a spec-interview team producing a feature specification for **{feature_name}**.
-
-<role>
-Explore the codebase and provide technical grounding for the spec. You accumulate context across the entire interview — unlike disposable subagents, you build a deepening understanding of the relevant codebase as the conversation progresses.
-</role>
-
-<team>
-- Lead (team-lead): Interviews the user, writes the spec, curates team input
-- Critic (critic): Reviews the spec for gaps, assumptions, edge cases
-- Pragmatist (pragmatist): Evaluates complexity, advocates for simplicity
-- You (researcher): Explore the codebase, map the technical landscape
-</team>
-
-<working-directory>
-The team shares: `{spec_dir}/working/`
-
-- `{spec_dir}/working/context.md` — The Lead writes interview context here. Read this to stay current on what the user has discussed. It is append-only with section headings per step.
-- `{spec_dir}/spec.md` — The living spec. Read it to understand what has been decided.
-- Write your findings to `{spec_dir}/working/` with descriptive filenames (e.g., `file-landscape.md`, `integration-points.md`, `data-model.md`, `existing-patterns.md`).
-</working-directory>
-
-<responsibilities>
-1. When you learn what feature is being built, immediately start mapping the relevant codebase areas — existing patterns, conventions, related components
-2. Map concrete file paths: files to create, files to modify, directory conventions this project follows
-3. Document how existing systems work that the feature will integrate with
-4. Draft proposed content for these spec sections: **File Landscape**, **Integration Points**, **Data Model**. Structure your working files to match the spec's section headings so the Lead can incorporate them directly.
-5. Respond to codebase questions from any teammate via SendMessage
-6. When you discover something that affects the spec, write details to a working file and message the Lead with a concise summary pointing to the file
-</responsibilities>
-
-<communication>
-- Details go in working files. Messages are summaries with a pointer to the file (e.g., "Findings on auth patterns ready — see working/integration-points.md").
-- Message the Lead when findings are ready to incorporate into the spec.
-- Message teammates directly when findings affect their analysis.
-- Read context.md and spec.md regularly to stay aligned with interview progress.
-</communication>
-
-<tools>
-Use Glob, Grep, Read, and LSP for all codebase exploration. You have full read access. For very broad searches that might flood your context, use the Task tool with an Explorer subagent to get curated results back.
-</tools>
-
-<boundaries>
-- Write only to `{spec_dir}/working/`. Never write to spec.md directly — the Lead owns the spec.
-- Never create or modify source code files. Your role is research only.
-- Never interact with the user directly. All user communication goes through the Lead.
-</boundaries>

package/src/skills/spec-interview/references/step-1-opening.md

@@ -1,78 +0,0 @@
-# Step 1: Opening
-
-Establish understanding of the feature before diving into details.
-
-## Opening Questions
-
-Use AskUserQuestion to gather information. Ask one or two questions at a time. Follow up on anything unclear.
-
-Start with:
-- What problem does this feature solve?
-- Who uses it and what is their goal?
-
-Then explore:
-- What does success look like?
-- Are there existing solutions or workarounds?
-
-## When to Move On
-
-Move on when:
-- The core problem and user goal are clear
-- Success criteria are understood at a high level
-
-## Initialize the Team
-
-You are the **Lead** — you interview the user, write the spec, and curate team input. Three persistent teammates handle research, critique, and complexity assessment.
-
-### Team Composition
-
-All teammates run on Opus:
-- **Researcher** (researcher): Continuously explores the codebase, maps file landscape, integration points, data model. Drafts technical sections.
-- **Critic** (critic): Reviews the emerging spec for gaps, bad assumptions, edge cases. Absorbs the spec-review completeness checklist and spec-sanity-check logic framework.
-- **Pragmatist** (pragmatist): Evaluates complexity, pushes back on over-engineering, identifies the simplest buildable path.
-
-### Working Directory
-
-The team shares `{spec_dir}/working/`:
-- `context.md` — You (the Lead) write interview updates here. Append-only — each update is a new section with a heading (e.g., `## Step 1: Feature Overview`). This replaces broadcasting — teammates read this file to stay current.
-- Teammates write their findings to `working/` with descriptive filenames. Read these at checkpoints.
-- `spec.md` (parent dir) — The living spec. You own this file. Teammates read it but never write to it.
-
-### Checkpoint Pattern
-
-Surface team input at step transitions, not continuously. This keeps the user conversation clean:
-- **After Step 2** (approach selected): Read all working files, curate team findings for user
-- **During Step 4** (deep dive): Read Researcher findings for each subsection, read Critic/Pragmatist feedback
-- **At Step 7** (finalize): Request final assessments from all three, compile and present to user
-
-At each checkpoint: read the working files, identify findings that are relevant and actionable, summarize them for the user as "Before we continue, my research team surfaced a few things..." Skip trivial items.
-
-### Team Lifecycle
-
-1. **Spawn** — After the opening questions (once the feature is understood), create the working directory, read the three prompt templates from `references/`, substitute `{spec_dir}` and `{feature_name}`, use TeamCreate to create a team named `spec-{feature-name}`, then spawn the three teammates via the Task tool
-2. **Communicate** — Update context.md after each step. Message teammates for specific questions. Read their working files at checkpoints.
-3. **Shutdown** — After Step 7 (user approves the spec), send shutdown requests to all three teammates, then use TeamDelete. Leave the `working/` directory in place as reference for implementation.
-
-### Spawn Steps
-
-1. Create the spec directory at `docs/specs/<feature-name>/` if not already created
-2. Create `docs/specs/<feature-name>/working/` subdirectory
-3. Read the three prompt templates:
-   - `references/researcher-prompt.md`
-   - `references/critic-prompt.md`
-   - `references/pragmatist-prompt.md`
-4. In all three templates, substitute `{spec_dir}` with the actual spec directory path (e.g., `docs/specs/my-feature`) and `{feature_name}` with the feature name
-5. Use TeamCreate to create a team named `spec-<feature-name>`
-6. Spawn three teammates in parallel using the Task tool with `subagent_type: "general-purpose"` and `model: "opus"`:
-   - Name: `researcher`, prompt: substituted researcher-prompt.md content
-   - Name: `critic`, prompt: substituted critic-prompt.md content
-   - Name: `pragmatist`, prompt: substituted pragmatist-prompt.md content
-   - Set `team_name` to the team you just created
-7. Send the Researcher an initial message via SendMessage summarizing the feature: problem, user, success criteria — so it can begin exploring immediately
-8. Write initial context to `{spec_dir}/working/context.md`:
-   ```
-   ## Step 1: Feature Overview
-   [Problem, user, success criteria as discussed with the user]
-   ```
-
-Now proceed to `references/step-2-ideation.md`.

package/src/skills/spec-interview/references/step-2-ideation.md

@@ -1,73 +0,0 @@
-# Step 2: Ideation
-
-Before designing a solution, explore the solution space. This step prevents premature convergence on the first idea that comes to mind.
-
-## Determine Mode
-
-Use AskUserQuestion to ask:
-
-> "Do you already have a clear approach in mind, or would you like to explore different options first?"
-
-**Options:**
-- **I know my approach** → Skip to `references/step-3-ui-ux.md` (or step-4-deep-dive.md if no UI)
-- **Let's explore options** → Continue with brainstorming below
-
-## Hybrid Brainstorming
-
-Get human ideas first, before AI suggestions anchor their thinking.
-
-### 1. Collect User Ideas First
-
-Use AskUserQuestion:
-
-> "Before I suggest anything - what approaches have you been considering? Even rough or half-formed ideas are valuable."
-
-Capture ideas without evaluating. The goal is to capture their independent thinking before AI ideas influence it.
-
-### 2. Generate AI Alternatives
-
-Now generate 3-4 different approaches to the same problem. These should:
-- Include options the user didn't mention
-- Vary meaningfully in architecture, complexity, or tradeoffs
-- Not just be variations on the user's ideas
-
-Frame it as: "Let me add some alternatives you might not have considered..."
-
-### 3. Diversity Check
-
-Review all ideas (user's and yours). Ask yourself:
-- Are these actually different, or variations of the same approach?
-- What's the boldest option here?
-- Can any ideas be combined into something better?
-
-If the options feel too similar, push for a more divergent alternative.
-
-### 4. Select or Combine
-
-Present all approaches with tradeoffs. Use AskUserQuestion:
-
-> "Looking at these together, which direction feels right? Or should we combine elements from multiple approaches?"
-
-Document the chosen approach and why before proceeding.
-
-## When to Move On
-
-Proceed when:
-- An approach has been selected (or user chose to skip brainstorming)
-- The rationale for the choice is understood
-
-## Team Checkpoint: Post-Ideation
-
-Before proceeding to the next step:
-
-1. Update `{spec_dir}/working/context.md` — append:
-   ```
-   ## Step 2: Approach Selected
-   [Chosen approach, rationale, alternatives considered]
-   ```
-2. Message all three teammates individually (not broadcast) informing them of the chosen approach: "We chose [approach] because [rationale]. Read context.md for full details."
-3. Read all files in `{spec_dir}/working/` to see what the team has found so far
-4. Curate findings for the user — summarize anything noteworthy from the Researcher's codebase exploration, the Critic's early concerns, or the Pragmatist's complexity notes. Present as: "Before we go deeper, my research team surfaced a few things..." Only surface findings that are relevant and actionable. Skip trivial items.
-5. If team findings raise concerns that affect the approach, discuss with the user via AskUserQuestion before proceeding
-
-If the feature has no user interface, skip to `references/step-4-deep-dive.md`. Otherwise proceed to `references/step-3-ui-ux.md`.

package/src/skills/spec-interview/references/step-3-ui-ux.md

@@ -1,83 +0,0 @@
-# Step 3: UI/UX Design
-
-If the feature has no user interface, skip to `references/step-4-deep-dive.md`.
-
-## Determine Design Direction
-
-Before any wireframes, establish the visual approach. Use AskUserQuestion to confirm:
-
-**Product context:**
-- What does this product need to feel like?
-- Who uses it? (Power users want density, occasional users want guidance)
-- What's the emotional job? (Trust, efficiency, delight, focus)
-
-**Design direction options:**
-- Precision & Density — tight spacing, monochrome, information-forward (Linear, Raycast)
-- Warmth & Approachability — generous spacing, soft shadows, friendly (Notion, Coda)
-- Sophistication & Trust — cool tones, layered depth, financial gravitas (Stripe, Mercury)
-- Boldness & Clarity — high contrast, dramatic negative space (Vercel)
-- Utility & Function — muted palette, functional density (GitHub)
-
-**Color foundation:**
-- Warm (creams, warm grays) — approachable, human
-- Cool (slate, blue-gray) — professional, serious
-- Pure neutrals (true grays) — minimal, technical
-
-**Layout approach:**
-- Dense grids for scanning/comparing
-- Generous spacing for focused tasks
-- Sidebar navigation for multi-section apps
-- Split panels for list-detail patterns
-
-Use AskUserQuestion to present 2-3 options and get the user's preference.
-
-## Create ASCII Wireframes
-
-Sketch the interface in ASCII. Keep it rough—this is for alignment, not pixel precision.
-
-```
-Example:
-┌─────────────────────────────────────────┐
-│  Page Title                [Action ▾]   │
-├──────────┬──────────────────────────────┤
-│ Nav Item │  Content Area                │
-│ Nav Item │  ┌─────────────────────────┐ │
-│ Nav Item │  │ Component               │ │
-│          │  └─────────────────────────┘ │
-└──────────┴──────────────────────────────┘
-```
-
-Create wireframes for:
-- Primary screen(s) the user will interact with
-- Key states (empty, loading, error, populated)
-- Any modals or secondary views
-
-Present each wireframe to the user. Use AskUserQuestion to confirm or iterate.
-
-## Map User Flows
-
-For each primary action, document the interaction sequence:
-
-1. Where does the user start?
-2. What do they click/type?
-3. What feedback do they see?
-4. Where do they end up?
-
-Format as simple numbered steps under each flow name.
-
-## When to Move On
-
-Proceed to `references/step-4-deep-dive.md` when:
-- Design direction is agreed upon
-- Wireframes exist for primary screens
-- User has confirmed the layout approach
-
-## Update Team Context
-
-After design decisions are confirmed, update `{spec_dir}/working/context.md` — append:
-```
-## Step 3: Design Decisions
-[Design direction chosen, layout approach, key wireframe descriptions, user flow summaries]
-```
-
-No team checkpoint at this step — design is user-driven. Teammates will read the updated context.md on their own.

package/src/skills/spec-interview/references/step-4-deep-dive.md

@@ -1,137 +0,0 @@
-# Step 4: Deep Dive
-
-Cover all specification areas through conversation. Update `docs/specs/<name>/spec.md` incrementally as information emerges.
-
-Use AskUserQuestion whenever requirements are ambiguous or multiple approaches exist. Present options with tradeoffs and get explicit decisions.
-
-## Areas to Cover
-
-### Intent & Goals
-- Primary goal and business/user value
-- Success metrics and how to verify it works
-
-### Integration Points
-- Existing system components this touches
-- External services, APIs, or libraries
-- Data flows in and out
-
-The Researcher has been exploring the codebase since Step 1. Read the Researcher's working files (especially any `integration-points.md` or related files). If the Researcher has already mapped integration points, incorporate them into the spec.
-
-If specific questions remain, message the Researcher via SendMessage with targeted questions like "How does authentication work in this codebase?" or "What middleware handles protected routes?" and wait for a response.
-
-No assumptions. If something is unclear, ask the Researcher to investigate.
-
-### File Landscape
-
-Read the Researcher's `file-landscape.md` working file. The Researcher should have identified concrete file paths by now. If the file landscape is incomplete, message the Researcher: "To implement [this feature], what files would need to be created or modified? Give me concrete file paths."
-
-Capture:
-- **Files to create**: New files with full paths (e.g., `src/models/notification.ts`)
-- **Files to modify**: Existing files that need changes (e.g., `src/routes/index.ts`)
-- **Directory conventions**: Where each type of code lives in this project
-
-This becomes the File Landscape section of the spec, which spec-to-tasks uses directly.
-
-### Data Model
-- Entities and relationships
-- Constraints (required fields, validations, limits)
-- Extending existing models vs creating new ones
-
-### Behavior & Flows
-- Main user flows, step by step
-- Triggers and resulting actions
-- Different modes or variations
-
-### Constraints
-- What is explicitly out of scope (features, users, flows to NOT build)
-- Technology boundaries (must use X, must not introduce Y)
-- Performance requirements (latency, throughput, resource limits)
-- Security requirements (auth, PII handling, logging restrictions)
-- Compatibility requirements (browsers, platforms, API versions)
-
-Constraints that aren't written down don't exist during implementation. If the spec doesn't say "don't introduce a new ORM" or "must stay under 200ms," those boundaries won't be respected downstream.
-
-### Edge Cases & Error Handling
-- Failure modes and how to handle them
-- Invalid input handling
-- Boundary conditions
-- Partial failure recovery
-
-### Blockers & Dependencies
-- External dependencies (APIs, services, libraries)
-- Credentials or access needed
-- Decisions that must be made before implementation
-
-## Spec Structure
-
-Write to `docs/specs/<name>/spec.md` with this structure:
-
-```markdown
-# [Feature Name]
-
-## Overview
-[2-3 sentences: what and why]
-
-## Goals
-- [Primary goal]
-- [Secondary goals]
-
-## Approach
-[Chosen approach and rationale. What alternatives were considered and why this one was selected.]
-
-## Constraints
-- **Out of scope:** [What this feature explicitly does NOT do]
-- **Technology:** [Must use / must not introduce]
-- **Performance:** [Latency, throughput, resource limits]
-- **Security:** [Auth, PII, logging restrictions]
-
-## Integration Points
-- Touches: [existing components]
-- External: [APIs, services, libraries]
-- Data flows: [in/out]
-
-## File Landscape
-
-### Files to Create
-- [path/to/new-file.ts]: [purpose]
-
-### Files to Modify
-- [path/to/existing-file.ts]: [what changes]
-
-## Data Model
-[Entities, relationships, constraints]
-
-## Behavior
-### [Flow 1]
-[Step by step]
-
-## Edge Cases
-- [Case]: [handling]
-
-## Acceptance Criteria
-- [ ] [Testable requirement]
-  **Verify:** [verification method]
-
-## Blockers
-- [ ] [Blocker]: [what's needed]
-```
-
-## Team Checkpoint: Deep Dive
-
-After completing all deep dive subsections:
-
-1. Update `{spec_dir}/working/context.md` — append:
-   ```
-   ## Step 4: Deep Dive Complete
-   [Summary of what was covered: integration points, file landscape, data model, behaviors, edge cases, blockers]
-   ```
-2. Read all working files from the Critic and Pragmatist
-3. Present curated findings to the user:
-   - Critic's identified gaps, bad assumptions, or logic issues
-   - Pragmatist's complexity assessment and simplification suggestions
-4. Use AskUserQuestion to discuss significant findings. If the Critic found gaps, address them. If the Pragmatist suggests simplifications, let the user decide.
-5. Update spec.md with any changes from this discussion
-
-## When to Move On
-
-Move to `references/step-5-research-needs.md` when all areas have been covered, team findings have been addressed, and the spec document is substantially complete.

package/src/skills/spec-interview/references/step-5-research-needs.md

@@ -1,53 +0,0 @@
-# Step 5: Identify Research Needs
-
-Before finalizing, determine if implementation requires unfamiliar paradigms.
-
-## The Question
-
-For each major component in the spec, ask: **Does working code using this exact pattern already exist in this codebase?**
-
-This is not about whether Claude knows how to do something in general. It's about whether this specific project has proven, working examples of the same approach.
-
-## Evaluate Each Component
-
-Review the spec's integration points, data model, and behavior sections.
-
-The Researcher has been exploring the codebase throughout the interview and already knows what patterns exist. For each significant implementation element, message the Researcher: "Does this codebase have an existing example of [pattern]? If yes, where and how does it work?"
-
-You can ask about multiple patterns in a single message. The Researcher will respond based on accumulated knowledge — faster and more informed than spawning fresh subagents.
-
-Based on Researcher findings:
-- If pattern exists → paradigm is established, no research needed
-- If not found → this is a new paradigm requiring research
-
-Examples of "new paradigm" triggers:
-- Using a library not yet in the project
-- A UI pattern not implemented elsewhere in the app
-- An integration with an external service not previously connected
-- A data structure or flow unlike existing code
-
-## If Research Needed
-
-For each new paradigm identified:
-1. State what needs research and why (no existing example found)
-2. Use AskUserQuestion to ask if they want to proceed with research, or if they have existing knowledge to share
-3. If proceeding, invoke the `research` skill for that topic
-
-Wait for research to complete before continuing. The research output goes to `docs/research/` and informs implementation.
-
-## If No Research Needed
-
-State that all paradigms have existing examples in the codebase. Proceed to `references/step-6-verification.md`.
-
-## When to Move On
-
-Proceed to `references/step-6-verification.md` when:
-- All new paradigms have been researched, OR
-- User confirmed no research is needed, OR
-- All patterns have existing codebase examples
-
-Update `{spec_dir}/working/context.md` — append:
-```
-## Step 5: Research Needs
-[Which paradigms are established, which required research, research outcomes]
-```

package/src/skills/spec-interview/references/step-6-verification.md

@@ -1,89 +0,0 @@
-# Step 6: Verification Planning
-
-Every acceptance criterion needs a specific, executable verification method. The goal: autonomous implementation with zero ambiguity about whether something works.
-
-## Verification Methods
-
-### UI Verification: agent-browser
-
-For any criterion involving visual output or user interaction, use Vercel's agent-browser CLI:
-
-```
-agent-browser open <url>              # Navigate to page
-agent-browser snapshot                # Get accessibility tree with refs
-agent-browser click @ref              # Click element by ref
-agent-browser fill @ref "value"       # Fill input by ref
-agent-browser get text @ref           # Read text content
-agent-browser screenshot file.png     # Capture visual state
-agent-browser close                   # Close browser
-```
-
-Example verification for "Dashboard shows signup count":
-1. `agent-browser open /admin`
-2. `agent-browser snapshot`
-3. `agent-browser get text @signup-count`
-4. Assert returned value is a number
-
-### Automated Tests
-
-For logic, data, and API behavior, specify the exact test:
-- Unit tests for pure functions
-- Integration tests for API endpoints
-- End-to-end tests for critical flows
-
-Include the test file path: `pnpm test src/convex/featureFlags.test.ts`
-
-### Database/State Verification
-
-For data persistence criteria:
-1. Perform the action
-2. Query the database directly
-3. Assert expected state
-
-### Manual Verification (Fallback)
-
-If no automated method exists, document exactly what to check. Flag these as candidates for future automation.
-
-## Update Each Acceptance Criterion
-
-Review every acceptance criterion in the spec. Add a verification method using this format:
-
-```markdown
-## Acceptance Criteria
-
-- [ ] Dashboard loads in under 2s
-  **Verify:** `agent-browser open /admin`, measure time to snapshot ready
-
-- [ ] Flag toggles persist across refresh
-  **Verify:** `pnpm test src/convex/featureFlags.test.ts` (toggle persistence test)
-
-- [ ] Signup chart shows accurate counts
-  **Verify:** `agent-browser get text @chart-total`, compare to `npx convex run users:count`
-```
-
-## Confirm With User
-
-Use AskUserQuestion to review verification methods with the user:
-- "For [criterion], I'll verify by [method]. Does that prove it works?"
-- Flag any criteria where verification seems insufficient
-
-The standard: if the agent executes the verification and it passes, the feature is done. No human checking required.
-
-## Team Validation
-
-After defining verification methods and before confirming with the user:
-
-1. Message the Critic: "Review the verification methods in spec.md. Are they concrete and executable? Will each one actually prove its criterion works?"
-2. Message the Pragmatist: "Review the verification methods in spec.md. Are any over-complex? Could simpler verification achieve the same confidence?"
-3. Read their responses (via working files or SendMessage)
-4. Adjust verification methods based on valid feedback before presenting to the user
-
-## When to Move On
-
-Proceed to `references/step-7-finalize.md` when every acceptance criterion has a verification method and the user agrees each method proves the criterion works.
-
-Update `{spec_dir}/working/context.md` — append:
-```
-## Step 6: Verification Methods Defined
-[Summary of verification approach and any team feedback incorporated]
-```