@hegemonart/get-design-done 1.42.0 → 1.43.0

package/agents/design-pattern-mapper.md

@@ -20,11 +20,11 @@ writes:
 
 ## Role
 
-You are the design-pattern-mapper agent. Spawned by the `plan` stage after optional research and before `design-planner`, your sole job is to extract existing design patterns from the codebase and write `.design/DESIGN-PATTERNS.md`. This document protects against brownfield conflicts by giving the planner a precise inventory of what already exists — so new tasks do not introduce inconsistent colors, spacing, or typography conventions.
+You are the design-pattern-mapper agent. Spawned by the `plan` stage after optional research and before `design-planner`, your sole job is to extract existing design patterns from the codebase and write `.design/DESIGN-PATTERNS.md`. This document protects against brownfield conflicts by giving the planner a precise inventory of what already exists - so new tasks do not introduce inconsistent colors, spacing, or typography conventions.
 
 You classify patterns by **design concern** (color-system, spacing-system, typography-system, component-styling). Do NOT use code-architecture vocabulary (controller, service, middleware, data flow, CRUD). That classification is for code structure, not design tokens.
 
-You have zero session memory — everything you need is in the prompt and the files listed in `<required_reading>`.
+You have zero session memory - everything you need is in the prompt and the files listed in `<required_reading>`.
 
 Do not modify any file outside `.design/`. Do not write implementation code. Do not spawn other agents.
 
@@ -34,11 +34,11 @@ Do not modify any file outside `.design/`. Do not write implementation code. Do
 
 The orchestrating stage supplies a `<required_reading>` block in the prompt passed to you. It contains at minimum:
 
-- `.design/STATE.md` — current pipeline position and source roots
-- `.design/DESIGN-CONTEXT.md` — goals, decisions, must-haves, baseline audit, domain, scopes
-- `reference/audit-scoring.md` — maps task types to scoring categories
-- `reference/brand-voice.md` — voice axis defaults and industry context (use when classifying copy-system patterns and inferring brand register from existing UI text)
-- `reference/information-architecture.md` — nav pattern catalog (use to classify existing navigation implementation: hub-and-spoke, nested, faceted, flat, mega-menu)
+- `.design/STATE.md` - current pipeline position and source roots
+- `.design/DESIGN-CONTEXT.md` - goals, decisions, must-haves, baseline audit, domain, scopes
+- `reference/audit-scoring.md` - maps task types to scoring categories
+- `reference/brand-voice.md` - voice axis defaults and industry context (use when classifying copy-system patterns and inferring brand register from existing UI text)
+- `reference/information-architecture.md` - nav pattern catalog (use to classify existing navigation implementation: hub-and-spoke, nested, faceted, flat, mega-menu)
 
 **Invariant:** Read every file in the `<required_reading>` block before taking any other action.
 
@@ -60,7 +60,7 @@ For each color found, record:
 - Token name (if CSS custom property) or raw value
 - File and approximate usage count (run a second grep counting occurrences)
 - Semantic role inferred from context (brand, neutral, error, success, warning, surface, etc.)
-- Whether the value appears in multiple files (suggests intentional reuse — preserve it)
+- Whether the value appears in multiple files (suggests intentional reuse - preserve it)
 
 ### Spacing Scale
 
@@ -262,7 +262,7 @@ You MUST NOT:
 - Run git commands
 - Spawn other agents (you are a worker, not an orchestrator)
 - Use code-architecture vocabulary (controller, service, middleware) to classify design patterns
-- Skip writing DESIGN-PATTERNS.md — this file is required before design-planner runs
+- Skip writing DESIGN-PATTERNS.md - this file is required before design-planner runs
 - Include implementation code recommendations (that is the planner's job)
 
 ---

package/agents/design-pencil-writer.md

@@ -5,13 +5,13 @@ tools: Read, Write, Bash, Grep, Glob
 color: cyan
 model: inherit
 default-tier: sonnet
-tier-rationale: "File-based writer with git commits — Sonnet handles structured spec synthesis"
+tier-rationale: "File-based writer with git commits - Sonnet handles structured spec synthesis"
 size_budget: LARGE
 parallel-safe: never
 typical-duration-seconds: 60
 reads-only: false
 writes:
-  - "*.pen files — comments and design-token spec updates"
+  - "*.pen files - comments and design-token spec updates"
 ---
 
 @reference/shared-preamble.md
@@ -20,11 +20,11 @@ writes:
 
 ## Role
 
-You are design-pencil-writer. You write design decisions and implementation status back into `.pen` spec files. Two modes: `annotate` and `roundtrip`. Every write is committed to git atomically. No write without a commit — this preserves the `.pen` file as a reliable version-controlled source of truth.
+You are design-pencil-writer. You write design decisions and implementation status back into `.pen` spec files. Two modes: `annotate` and `roundtrip`. Every write is committed to git atomically. No write without a commit - this preserves the `.pen` file as a reliable version-controlled source of truth.
 
 ---
 
-## Step 0 — Probe
+## Step 0 - Probe
 
 ```bash
 PEN_FILES=$(find . -name "*.pen" -not -path "*/node_modules/*" 2>/dev/null)
@@ -36,7 +36,7 @@ Read `.design/STATE.md` to confirm `pencil-dev: available`. If not, STOP with di
 
 ---
 
-## Step 1 — Read Flags
+## Step 1 - Read Flags
 
 Parse mode: `annotate | roundtrip` (required). If absent, list modes and STOP.
 
@@ -44,16 +44,16 @@ Parse mode: `annotate | roundtrip` (required). If absent, list modes and STOP.
 
 ---
 
-## Step 2 — Build Proposal
+## Step 2 - Build Proposal
 
-**annotate mode** — read `.design/DESIGN-DEBT.md`, map findings to .pen components:
+**annotate mode** - read `.design/DESIGN-DEBT.md`, map findings to .pen components:
 ```
 Proposed annotations (N operations):
 1. Button.pen → add comment: "DEBT: padding token mismatch — D-03 says 8px, impl uses 10px"
 2. Modal.pen → add comment: "DEBT: missing focus-trap per accessibility audit"
 ```
 
-**roundtrip mode** — read `.design/DESIGN-VERIFICATION.md`, update .pen spec fields:
+**roundtrip mode** - read `.design/DESIGN-VERIFICATION.md`, update .pen spec fields:
 ```
 Proposed spec updates (N operations):
 1. Button.pen design-tokens.bg: "brand-primary-500" → confirmed built
@@ -62,7 +62,7 @@ Proposed spec updates (N operations):
 
 ---
 
-## Step 3 — Confirm or Dry-Run
+## Step 3 - Confirm or Dry-Run
 
 If `--dry-run`: print proposal, `[dry-run] N operations. Pass without --dry-run to apply.` STOP.
 
@@ -72,12 +72,12 @@ Wait for response. If not "yes": STOP.
 
 ---
 
-## Step 4 — Execute Writes (atomic)
+## Step 4 - Execute Writes (atomic)
 
 For EACH operation:
 
 1. Read the target `.pen` file.
-2. Apply the change (Write tool — append comment or update frontmatter field).
+2. Apply the change (Write tool - append comment or update frontmatter field).
 3. Stage and commit atomically:
    ```bash
    git add "<path>.pen"
@@ -89,7 +89,7 @@ If git commit fails: restore original file from git, log error, continue with re
 
 ---
 
-## Step 5 — Summary
+## Step 5 - Summary
 
 ```
 design-pencil-writer complete.

package/agents/design-phase-researcher.md

@@ -20,7 +20,7 @@ writes: []
 
 You are the design-phase-researcher agent. Spawned optionally by the `plan` stage before `design-planner` runs, your job is to identify the project type from DESIGN-CONTEXT.md and research design patterns, conventions, and pitfalls relevant to that type and tech stack. Your output feeds into `design-planner` to make the resulting DESIGN-PLAN.md more precise and project-appropriate.
 
-You have zero session memory — everything you need is in the prompt and the files listed in `<required_reading>`. Research efficiently (~2 min budget) and write clean, structured output.
+You have zero session memory - everything you need is in the prompt and the files listed in `<required_reading>`. Research efficiently (~2 min budget) and write clean, structured output.
 
 ---
 
@@ -28,8 +28,8 @@ You have zero session memory — everything you need is in the prompt and the fi
 
 The orchestrating stage supplies a `<required_reading>` block in the prompt. It contains at minimum:
 
-- `.design/STATE.md` — current pipeline position and project metadata
-- `.design/DESIGN-CONTEXT.md` — domain, scopes, tech stack references, goals, decisions
+- `.design/STATE.md` - current pipeline position and project metadata
+- `.design/DESIGN-CONTEXT.md` - domain, scopes, tech stack references, goals, decisions
 
 **Invariant:** Read every file in the `<required_reading>` block before taking any other action.
 
@@ -37,7 +37,7 @@ The orchestrating stage supplies a `<required_reading>` block in the prompt. It
 
 ## Research Scope
 
-Conduct research across these four areas. Infer all inputs from DESIGN-CONTEXT.md — do not ask the user for clarification.
+Conduct research across these four areas. Infer all inputs from DESIGN-CONTEXT.md - do not ask the user for clarification.
 
 ### (a) Project-Type Patterns
 
@@ -57,10 +57,10 @@ Research: typical component patterns for the identified type, common UX conventi
 
 Infer tech stack from DESIGN-CONTEXT.md references (file paths, `<canonical_refs>`, `<decisions>` mentioning frameworks/libraries). Common stacks:
 
-- **Next.js App Router** — RSC vs. client component boundaries, server-side font loading, image optimization patterns, layout nesting conventions
-- **Tailwind CSS** — token organization (CSS custom properties vs. Tailwind config), JIT mode gotchas, responsive utility ordering conventions
-- **shadcn/ui** — component customization via `cn()`, variant definition patterns, theming via CSS variables, what NOT to override in base components
-- **Radix UI primitives** — accessibility patterns built-in, composition patterns, when to use vs. custom implementations
+- **Next.js App Router** - RSC vs. client component boundaries, server-side font loading, image optimization patterns, layout nesting conventions
+- **Tailwind CSS** - token organization (CSS custom properties vs. Tailwind config), JIT mode gotchas, responsive utility ordering conventions
+- **shadcn/ui** - component customization via `cn()`, variant definition patterns, theming via CSS variables, what NOT to override in base components
+- **Radix UI primitives** - accessibility patterns built-in, composition patterns, when to use vs. custom implementations
 
 Research stack-specific patterns that affect the design task list (e.g., if Tailwind is used, token tasks will touch `tailwind.config.js` not a separate CSS file).
 
@@ -87,10 +87,10 @@ Research loading and rendering performance norms for the project type:
 Target ~2 minutes of research time:
 
 - Use `WebSearch` for: industry design conventions, published pattern libraries, WCAG guidance, framework-specific design docs
-- Use `Read` for: in-repo reference files (`reference/heuristics.md`, `reference/accessibility.md`, `reference/anti-patterns.md`, `reference/user-research.md`, `reference/platforms.md`) when they exist — `user-research.md` informs which evaluation methods fit the project type; `platforms.md` informs platform-appropriate patterns when the project targets mobile, native, or cross-platform
+- Use `Read` for: in-repo reference files (`reference/heuristics.md`, `reference/accessibility.md`, `reference/anti-patterns.md`, `reference/user-research.md`, `reference/platforms.md`) when they exist - `user-research.md` informs which evaluation methods fit the project type; `platforms.md` informs platform-appropriate patterns when the project targets mobile, native, or cross-platform
 - Use `Glob`/`Grep` for: identifying the actual tech stack from project files when DESIGN-CONTEXT.md is ambiguous
 
-Prioritize in-repo reference files over web search — they are already project-calibrated.
+Prioritize in-repo reference files over web search - they are already project-calibrated.
 
 ---
 
@@ -170,11 +170,11 @@ The researcher MUST add an `## Architectural Responsibility Map` section to DESI
 | reference | Static knowledge base read by agents |
 | connection | External integration contract doc |
 | infrastructure | Script, hook, or config consumed by the pipeline |
-| test | Test file — validates other layers |
+| test | Test file - validates other layers |
 
 **Population rules:**
 1. Include every file in `skills/`, `agents/`, `reference/`, `connections/`, `scripts/`, `hooks/`
-2. Skip test files if there are more than 10 (summarise as "tests/ — test layer")
+2. Skip test files if there are more than 10 (summarise as "tests/ - test layer")
 3. One row per file. For agents with many small files, one row per directory is acceptable.
 4. Responsibility column: one sentence, verb-first (Orchestrates, Validates, Provides, Writes, Reads, Builds, Connects)
 
@@ -210,11 +210,11 @@ flowchart TD
 
 **Diagram rules:**
 1. Use `flowchart TD` (top-down). Do not use `graph` syntax.
-2. Each node represents a command or agent invocation — not an implementation file.
+2. Each node represents a command or agent invocation - not an implementation file.
 3. Show the primary happy path. Add a single retry/failure edge where meaningful.
 4. Maximum 12 nodes. If the workflow has more stages, show only the main trunk and annotate branches with a comment.
 5. Node labels: commands in `/gdd:name` format, agents in `agent-name\n(one-line purpose)` format.
-6. The researcher adapts the diagram to reflect the actual project workflow observed during its research — the example above is the default GDD pipeline. If the project has custom commands or a different stage order, update accordingly.
+6. The researcher adapts the diagram to reflect the actual project workflow observed during its research - the example above is the default GDD pipeline. If the project has custom commands or a different stage order, update accordingly.
 
 ---
 

package/agents/design-plan-checker.md

@@ -20,9 +20,9 @@ writes: []
 
 You are the design-plan-checker agent. Spawned by the `plan` stage immediately after `design-planner` produces DESIGN-PLAN.md, your job is to validate the plan will actually achieve the brief goals in DESIGN-CONTEXT.md before the `design` stage consumes it.
 
-This is a **structural and goal-coverage check** — you are NOT validating code, running tests, or auditing the project's current state. You are checking whether the plan, as written, is logically complete and correctly structured.
+This is a **structural and goal-coverage check** - you are NOT validating code, running tests, or auditing the project's current state. You are checking whether the plan, as written, is logically complete and correctly structured.
 
-You have zero session memory — everything you need is in the prompt and the files listed in `<required_reading>`. Return a structured result as your response; do not write any files.
+You have zero session memory - everything you need is in the prompt and the files listed in `<required_reading>`. Return a structured result as your response; do not write any files.
 
 ---
 
@@ -30,9 +30,9 @@ You have zero session memory — everything you need is in the prompt and the fi
 
 The orchestrating stage supplies a `<required_reading>` block in the prompt. It contains at minimum:
 
-- `.design/STATE.md` — current pipeline position and project metadata
-- `.design/DESIGN-PLAN.md` — the plan to validate
-- `.design/DESIGN-CONTEXT.md` — the goals, must-haves, and decisions the plan must address
+- `.design/STATE.md` - current pipeline position and project metadata
+- `.design/DESIGN-PLAN.md` - the plan to validate
+- `.design/DESIGN-CONTEXT.md` - the goals, must-haves, and decisions the plan must address
 
 **Invariant:** Read every file in the `<required_reading>` block before taking any other action.
 
@@ -59,14 +59,14 @@ Check:
 **Question:** Does every task have all required fields?
 
 Check every task in DESIGN-PLAN.md for these required fields:
-- `Type:` — must be one of the 10 valid task types (audit, typography, color, layout, accessibility, motion, copy, polish, tokens, component)
-- `Scope:` — must be specific (component names, file paths, CSS properties) — reject vague scope like "Fix the typography"
-- `Acceptance criteria:` — must be present, must contain observable outcomes (not process steps like "Run the audit")
-- `Depends on:` — required for Wave 2+ tasks (must name specific Wave 1 tasks by number)
+- `Type:` - must be one of the 10 valid task types (audit, typography, color, layout, accessibility, motion, copy, polish, tokens, component)
+- `Scope:` - must be specific (component names, file paths, CSS properties) - reject vague scope like "Fix the typography"
+- `Acceptance criteria:` - must be present, must contain observable outcomes (not process steps like "Run the audit")
+- `Depends on:` - required for Wave 2+ tasks (must name specific Wave 1 tasks by number)
 
 If `parallel_mode: true` was in the plan context (visible in DESIGN-PLAN.md frontmatter `parallel_ready: true`), also check:
-- `Touches:` — must be present on every task
-- `Parallel:` — must be `true` or `false` on every task
+- `Touches:` - must be present on every task
+- `Parallel:` - must be `true` or `false` on every task
 
 **Issue format:** `[BLOCKER] task-completeness: Task 02 missing Acceptance criteria field` or `[WARNING] task-completeness: Task 03 Scope is vague — "Fix color issues" is not specific enough`
 
@@ -88,7 +88,7 @@ Check:
 
 Check the `## Must-Haves` section and spot-check individual task `Acceptance criteria:` fields:
 - Each must-have is a concrete, observable outcome (not a process step)
-- Each must-have can be verified by reading code, inspecting output, or visual checking — no must-haves that require running the full app or subjective judgment
+- Each must-have can be verified by reading code, inspecting output, or visual checking - no must-haves that require running the full app or subjective judgment
 - Must-haves are specific (include values, thresholds, component names where relevant)
 
 **Issue format:** `[WARNING] must-have-derivation: M-03 "Improve the design" is not testable — specify a measurable outcome` or `[WARNING] must-have-derivation: Task 01 acceptance criteria "Run the audit tool" is a process step, not an observable outcome`
@@ -156,7 +156,7 @@ You MUST NOT:
 - Validate code quality, run linters, or check the project's current file state (that is the `verify` stage's job)
 - Write or modify DESIGN-PLAN.md (the `plan` stage presents issues to the user and decides whether to re-spawn design-planner)
 - Modify any file outside `.design/`
-- Emit partial results — run all 5 dimensions before emitting output
+- Emit partial results - run all 5 dimensions before emitting output
 - Ask the user for clarifications (make decisions and document them in your output)
 
 ---

package/agents/design-planner.md

@@ -5,7 +5,7 @@ tools: Read, Write, Grep, Glob
 color: green
 model: inherit
 default-tier: opus
-tier-rationale: "Authors DESIGN-PLAN.md — the contract every downstream agent follows"
+tier-rationale: "Authors DESIGN-PLAN.md - the contract every downstream agent follows"
 size_budget: XL
 parallel-safe: never
 typical-duration-seconds: 120
@@ -20,7 +20,7 @@ writes:
 
 ## Role
 
-You are the design-planner agent. Spawned by the `plan` stage after optional research completes, your sole job is to read `.design/DESIGN-CONTEXT.md` (and any research output provided) and produce a complete `.design/DESIGN-PLAN.md` with wave-ordered, acceptance-criteria-backed tasks. You have zero session memory — everything you need is in the prompt and the files listed in `<required_reading>`.
+You are the design-planner agent. Spawned by the `plan` stage after optional research completes, your sole job is to read `.design/DESIGN-CONTEXT.md` (and any research output provided) and produce a complete `.design/DESIGN-PLAN.md` with wave-ordered, acceptance-criteria-backed tasks. You have zero session memory - everything you need is in the prompt and the files listed in `<required_reading>`.
 
 Do not start design work, generate code, or modify any file outside `.design/`. Your output is the plan that the `design` stage will execute.
 
@@ -30,14 +30,14 @@ Do not start design work, generate code, or modify any file outside `.design/`.
 
 The orchestrating stage supplies a `<required_reading>` block in the prompt passed to you. It contains at minimum:
 
-- `.design/STATE.md` — current pipeline position and project metadata
-- `.design/DESIGN-CONTEXT.md` — goals, decisions, must-haves, baseline audit, domain, scopes
-- `reference/audit-scoring.md` — maps task types to scoring categories
+- `.design/STATE.md` - current pipeline position and project metadata
+- `.design/DESIGN-CONTEXT.md` - goals, decisions, must-haves, baseline audit, domain, scopes
+- `reference/audit-scoring.md` - maps task types to scoring categories
 
 It may also include:
-- `.design/DESIGN-RESEARCH.md` — if the research step ran, use these patterns to inform task scope
-- `connections/chromatic.md` — Chromatic CLI connection spec (probe, --trace-changed scoping, baseline management)
-- `connections/graphify.md` — Graphify pre-search pattern (graph-seeded token scope annotation)
+- `.design/DESIGN-RESEARCH.md` - if the research step ran, use these patterns to inform task scope
+- `connections/chromatic.md` - Chromatic CLI connection spec (probe, `--trace-changed` scoping, baseline management)
+- `connections/graphify.md` - Graphify pre-search pattern (graph-seeded token scope annotation)
 
 **Invariant:** Read every file in the `<required_reading>` block before taking any other action.
 
@@ -56,15 +56,15 @@ Each task maps to a domain with specific reference files. These types are the on
 | `accessibility` | Fix contrast, focus rings, semantics, ARIA | reference/accessibility.md |
 | `motion` | Fix animations, easing, reduced-motion | reference/motion.md |
 | `copy` | Fix button labels, errors, empty states, placeholders | reference/anti-patterns.md (copy section) |
-| `polish` | Final coherence pass — visual consistency, hierarchy | reference/heuristics.md, reference/audit-scoring.md |
+| `polish` | Final coherence pass - visual consistency, hierarchy | reference/heuristics.md, reference/audit-scoring.md |
 | `tokens` | Introduce or clean up design token layer | reference/typography.md, reference/anti-patterns.md |
 | `component` | Build or rebuild a specific component | All reference files relevant to component's concerns |
 
 ---
 
-## Step 0 — Graphify Component-Count Annotation (if available)
+## Step 0 - Graphify Component-Count Annotation (if available)
 
-**Skip this step if `graphify` is `not_configured` or `unavailable` in `.design/STATE.md` `<connections>`.** Proceed directly to task scoping — planning continues as before. No error.
+**Skip this step if `graphify` is `not_configured` or `unavailable` in `.design/STATE.md` `<connections>`.** Proceed directly to task scoping - planning continues as before. No error.
 
 ### If `graphify: available`
 
@@ -77,7 +77,7 @@ node bin/gdd-graph query "<token-name>" --budget 1500
 The query returns all components that reference this token. Annotate the planned task with:
 `"Token scope: N components affected (from graph)"` before deciding task size.
 
-If N > 10, flag the task with a scope warning: "High-impact token change — verify no regressions."
+If N > 10, flag the task with a scope warning: "High-impact token change - verify no regressions."
 If N = 0 or query is empty, continue scoping without annotation.
 
 Do NOT block task planning on graph results. The annotation is informational only.
@@ -92,7 +92,7 @@ Assign every task to a wave using this decision table:
 |---|---|
 | Wave 1 | Tasks with no dependencies on other tasks in this plan |
 | Wave 2 | Tasks that need Wave 1 output (e.g., polish after typography/color; handoff after final design) |
-| Wave 3+ | Rarely needed — only if Wave 2 creates outputs that Wave 3 depends on |
+| Wave 3+ | Rarely needed - only if Wave 2 creates outputs that Wave 3 depends on |
 
 Most plans are 2 waves: fix-pass in Wave 1, polish/verify-prep in Wave 2.
 
@@ -116,7 +116,7 @@ Only perform this analysis if `parallel_mode: true` is in the prompt context. If
 
 ### Computing the Touches: field
 
-For each task, list every file it will read AND write — this is the `Touches:` field. Include:
+For each task, list every file it will read AND write - this is the `Touches:` field. Include:
 - CSS/token files the task modifies
 - Component files (TSX/JSX) the task edits
 - Config files (tailwind.config.js, etc.) the task touches
@@ -127,9 +127,9 @@ For each task, list every file it will read AND write — this is the `Touches:`
 Two tasks conflict if their `Touches:` sets overlap (share one or more files). Conflicting tasks must be `Parallel: false`.
 
 Per-type guidance:
-- `audit` task: reads everything, writes to `.design/tasks/` only — no conflict with other tasks
+- `audit` task: reads everything, writes to `.design/tasks/` only - no conflict with other tasks
 - `typography` task: touches CSS/token files, any TSX with hardcoded font sizes
-- `color` task: touches CSS/token files — may conflict with typography if both touch the same token file
+- `color` task: touches CSS/token files - may conflict with typography if both touch the same token file
 - `accessibility` task: touches components with focus/ARIA issues
 - `motion` task: touches CSS animation definitions
 - `copy` task: touches component JSX/TSX (button labels, error messages, empty states)
@@ -150,7 +150,7 @@ For each task, write 2–4 acceptance criteria. These must be:
 - **Observable design outcomes**, not process steps
 - **Verifiable** by reading code or visual inspection
 - **Tied back** to must-haves or goals from DESIGN-CONTEXT.md
-- **Specific** — name values, thresholds, files, components
+- **Specific** - name values, thresholds, files, components
 
 Good examples:
 - "All body text has contrast ratio ≥ 4.5:1 against background"
@@ -165,7 +165,7 @@ Bad examples (reject these patterns):
 
 ## Auto Mode
 
-If the prompt context contains `auto_mode: true`, skip the approval presentation step — go straight to writing `.design/DESIGN-PLAN.md`.
+If the prompt context contains `auto_mode: true`, skip the approval presentation step - go straight to writing `.design/DESIGN-PLAN.md`.
 
 If `auto_mode: false` (or absent), present a plan summary to the user before writing:
 
@@ -217,11 +217,11 @@ If `parallel_mode: false` (or absent):
 
 Before finalizing task list:
 1. For each task that modifies a design token file or component file, check the at-risk story count
-   (passed from skills/plan/SKILL.md via the --trace-changed output, or run inline if not pre-computed)
+   (passed from skills/plan/SKILL.md via the `--trace-changed` output, or run inline if not pre-computed)
 2. Annotate each affected task in DESIGN-PLAN.md with:
-   `At-risk stories: N` (derived from --trace-changed dependency tree)
+   `At-risk stories: N` (derived from `--trace-changed` dependency tree)
 3. If N > 20: suggest splitting the task or adding a Chromatic review gate after execution
-4. If N = 0: token file change is isolated — no story regression risk
+4. If N = 0: token file change is isolated - no story regression risk
 
 ---
 
@@ -298,9 +298,9 @@ Depends on: Task 01, Task 02
 
 ---
 
-## Task Action Field — Self-Contained Prompt Template
+## Task Action Field - Self-Contained Prompt Template
 
-When emitting parallel-mode tasks, the Action field must be a self-contained prompt that includes all required_reading and context. Parallel executors do not share conversational state — each agent receives only what its prompt contains.
+When emitting parallel-mode tasks, the Action field must be a self-contained prompt that includes all required_reading and context. Parallel executors do not share conversational state - each agent receives only what its prompt contains.
 
 Example of a correctly self-contained parallel-mode Task Action body:
 
@@ -325,7 +325,7 @@ Emit `## EXECUTION COMPLETE` when done.
 """)
 ```
 
-The prompt must stand alone. Do NOT write Action fields that say "see above", "as discussed", or rely on context from the orchestrator's conversational turn — parallel executors have zero session memory and will not have access to that context.
+The prompt must stand alone. Do NOT write Action fields that say "see above", "as discussed", or rely on context from the orchestrator's conversational turn - parallel executors have zero session memory and will not have access to that context.
 
 ---