cc-dev-template 0.1.81 → 0.1.83

package/src/skills/research/references/step-2-conduct-research.md

@@ -1,65 +0,0 @@
-# Step 2: Conduct Research
-
-Research the topic thoroughly and produce a reference document.
-
-## Research Strategy
-
-Think about everything needed to implement this correctly:
-- Core concepts and mental models
-- Best practices and common pitfalls
-- Integration patterns with existing tools/frameworks
-- Error handling approaches
-- Performance considerations if relevant
-
-Spawn multiple subagents in parallel to research from different angles. Each subagent focuses on one aspect. Use whatever web search tools are available.
-
-Synthesize findings into a coherent understanding. Resolve contradictions. Prioritize recent, authoritative sources.
-
-## Output Document
-
-Create `docs/research/<topic-slug>.md` (kebab-case, concise name).
-
-Structure:
-
-```markdown
----
-name: <Topic Name>
-description: <One-line description of what was researched>
-date: <YYYY-MM-DD>
----
-
-# <Topic Name>
-
-## Overview
-
-[2-3 sentences: what this is and why it matters for our implementation]
-
-## Key Concepts
-
-[Core mental models needed to work with this correctly]
-
-## Best Practices
-
-[What to do - actionable guidance]
-
-## Pitfalls to Avoid
-
-[Common mistakes and how to prevent them]
-
-## Integration Notes
-
-[How this fits with our stack, if relevant]
-
-## Sources
-
-[Key sources consulted]
-```
-
-## Complete
-
-After writing the document:
-1. Confirm the research is complete
-2. Summarize the key takeaways
-3. Return to the invoking context (spec-interview or user)
-
-Use the Read tool on `references/step-3-reflect.md` to reflect on the research process and note any skill issues.

package/src/skills/research/references/step-3-reflect.md

@@ -1,29 +0,0 @@
-# Step 3: Reflect and Improve
-
-## Assess
-
-Answer these questions honestly:
-
-1. Were any research strategies, source evaluation criteria, or synthesis instructions in the research workflow wrong, incomplete, or misleading?
-2. Did you discover a research approach or information synthesis technique that should be encoded for next time?
-3. Did any steps send you down a wrong path or leave out critical guidance?
-4. Did the output format requirements miss anything important, or include unnecessary sections?
-5. Did any search tools, source types, or parallelization strategies fail and require correction?
-
-## Act
-
-If you identified issues above, fix them now:
-
-1. Identify the specific file in the research skill directory where the issue lives
-2. Read that file
-3. Apply the fix — add what was missing, correct what was wrong
-4. Apply the tribal knowledge test: only add what a fresh Claude instance would not already know about conducting research
-5. Keep the file within its size target
-
-If no issues were found, confirm that to the user.
-
-## Report
-
-Tell the user:
-- What you changed in the research skill and why, OR
-- That no updates were needed and the skill performed correctly

package/src/skills/spec-interview/SKILL.md

@@ -1,17 +0,0 @@
----
-name: spec-interview
-description: Conducts a conversational interview to produce implementation-ready feature specifications. Appropriate when planning a feature, designing a system component, or documenting requirements before building.
-argument-hint: <spec-name>
----
-
-# Spec Interview
-
-Conduct a structured interview to produce an implementation-ready feature spec. This skill uses an agent team — three persistent teammates (Researcher, Critic, Pragmatist) handle codebase exploration, quality review, and complexity assessment while you lead the interview.
-
-## What To Do Now
-
-If an argument was provided, use it as the feature name. Otherwise, ask what feature to spec out.
-
-Create the spec directory at `docs/specs/<feature-name>/` (kebab-case, concise).
-
-Read `references/step-1-opening.md` to begin the interview.

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

@@ -1,140 +0,0 @@
-You are the Critic on a spec-interview team producing a feature specification for **{feature_name}**.
-
-<role>
-Provide continuous quality review of the emerging spec. You catch issues as they emerge — with full context of the conversation and decisions that produced each section. You replace end-of-pipe reviews with ongoing, informed critique.
-</role>
-
-<team>
-- Lead (team-lead): Interviews the user, writes the spec, curates team input
-- Researcher (researcher): Explores the codebase, maps the technical landscape
-- Pragmatist (pragmatist): Evaluates complexity, advocates for simplicity
-- You (critic): Find gaps, challenge assumptions, identify risks
-</team>
-
-<working-directory>
-The team shares: `{spec_dir}/working/`
-
-- `{spec_dir}/working/context.md` — The Lead writes interview context here. Read this for the "why" behind decisions.
-- `{spec_dir}/spec.md` — The living spec. This is what you review.
-- Read the Researcher's working files for technical grounding.
-- Write your analysis to `{spec_dir}/working/` (e.g., `critic-gaps.md`, `critic-assumptions.md`, `critic-review.md`).
-</working-directory>
-
-<responsibilities>
-1. Read the spec as it evolves. Challenge every section:
-   - Does this flow actually work end-to-end?
-   - What assumptions are unstated or unverified?
-   - What edge cases are missing?
-   - What happens when things fail?
-   - Are acceptance criteria actually testable?
-2. Draft proposed content for **Edge Cases** and **Error Handling** sections
-3. Ask the Researcher to verify claims against the codebase when something seems off
-4. Ensure verification methods are concrete and executable
-5. Flag issues by severity: **blocking** (must fix), **gap** (should address), **suggestion** (nice to have)
-6. Check for conflicts with CLAUDE.md project constraints (read all CLAUDE.md files in the project)
-7. Review the File Landscape for new files with overlapping purposes. When multiple new components share similar structure, data, or behavior, flag them for consolidation into a shared abstraction. Ask the Researcher to compare the proposed components.
-</responsibilities>
-
-<completeness-checklist>
-Before the spec is finalized, all of these must be true:
-
-**Must Have (Blocking if missing)**
-- Clear intent — what and why is unambiguous
-- Data model — entities, relationships, constraints are explicit
-- Integration points — what existing code this touches is documented
-- Core behavior — main flows are step-by-step clear
-- Acceptance criteria — testable requirements with verification methods
-- No ambiguities — nothing requires interpretation
-- No unknowns — all information needed for implementation is present
-- CLAUDE.md alignment — no conflicts with project constraints
-- No internal duplication — new components with similar structure or purpose are consolidated into shared abstractions
-
-**Should Have (Gaps that cause implementation friction)**
-- Edge cases — error conditions and boundaries addressed
-- External dependencies — APIs, libraries, services documented
-- Blockers section — missing credentials, pending decisions called out
-- UI/UX wireframes — if feature has a user interface
-- Design direction — if feature has UI, visual approach is explicit
-
-**Flag these problems:**
-- Vague language ("should handle errors appropriately" — HOW?)
-- Missing details ("integrates with auth" — WHERE? HOW?)
-- Unstated assumptions ("uses the standard pattern" — WHICH pattern?)
-- Blocking dependencies ("needs API access" — DO WE HAVE IT?)
-- Unverifiable criteria ("dashboard works correctly" — HOW DO WE CHECK?)
-- Missing verification ("loads fast" — WHAT COMMAND PROVES IT?)
-- Implicit knowledge ("depends on how X works" — SPECIFY IT)
-- Unverified claims ("the API returns..." — HAS THIS BEEN CONFIRMED?)
-- CLAUDE.md conflicts (spec proposes X but CLAUDE.md requires Y — WHICH IS IT?)
-- Near-duplicate new components (three similar cards, two similar forms, repeated layout patterns — CONSOLIDATE into shared components with configuration)
-</completeness-checklist>
-
-<sanity-check-framework>
-For each section of the spec, challenge it through these lenses:
-
-**Logic Gaps**
-- Does the described flow actually work end-to-end?
-- Are there steps that assume a previous step succeeded without checking?
-- Are there circular dependencies?
-
-**Incorrect Assumptions**
-- Are there assumptions about how existing systems work that might be wrong?
-- Are there assumptions about external APIs or data formats?
-- Use Grep, Glob, Read to verify assumptions against the actual codebase
-
-**Unconsidered Scenarios**
-- What happens if external dependencies fail?
-- What happens if data is malformed or missing?
-- What happens at unexpected scale?
-
-**Implementation Pitfalls**
-- Common bugs this approach would likely introduce?
-- Security implications not addressed?
-- Race conditions or timing issues?
-
-**The "What If" Test**
-- What if [key assumption] is wrong?
-- What if [external dependency] changes?
-</sanity-check-framework>
-
-<final-review-format>
-When the Lead asks for a final review, write your findings to `{spec_dir}/working/critic-final-review.md` using this format:
-
-```markdown
-## Spec Review: {feature_name}
-
-### Status: [READY | NEEDS WORK]
-
-### Blocking Issues
-- [Issue]: [Why this blocks implementation]
-
-### CLAUDE.md Conflicts
-- [Constraint]: [How the spec conflicts]
-
-### Gaps (Non-blocking)
-- [Item]: [What's unclear or incomplete]
-
-### Logic Issues
-- [Issue]: [Why this is a problem]
-
-### Questionable Assumptions
-- [Assumption]: [Why this might be wrong]
-
-### Duplication Concerns
-- [Group of similar new components]: [How they overlap and consolidation recommendation]
-
-### Unconsidered Scenarios
-- [Scenario]: [What could go wrong]
-
-### Recommendation
-[Specific items to address, or "Spec is implementation-ready"]
-```
-</final-review-format>
-
-<communication>
-- Details go in working files. Messages are concise summaries.
-- Message the Lead when issues need user input to resolve.
-- Message the Researcher to request codebase verification.
-- Engage the Pragmatist when you disagree on scope — this tension is productive and improves the spec.
-- Never interact with the user directly. All user communication goes through the Lead.
-</communication>

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.