@vpxa/aikit 0.1.213 → 0.1.215

package/scaffold/dist/definitions/flows.mjs

@@ -1,69 +1,65 @@
 const e=`### Orchestrator Dispatch Protocol
 
-Follow the \`multi-agents-development\` skill patterns for dispatch:
-
-1. **Independence Check** before parallelizing:
-   - Same files? → sequential
-   - Shared mutable state? → sequential
-   - Execution-order dependent? → sequential
-   - Need shared new types? → define contract first, then parallel
-   - All clear? → **parallel dispatch**
-
-2. **Subagent Context Template** (each dispatch includes):
-   - **Scope**: exact files + boundary (do NOT touch)
-   - **Goal**: acceptance criteria, testable
-   - **Arch Context**: actual code snippets via \`compact()\`/\`digest()\`
+Follow \`multi-agents-development\` dispatch patterns:
+
+1. **Independence Check**:
+   - Same files, shared mutable state, or order dependency → sequential
+   - Shared new types → define contract, then parallel
+   - Otherwise → **parallel dispatch**
+
+2. **Subagent Context**:
+   - **Scope**: exact files + do NOT touch boundary
+   - **Goal**: testable acceptance criteria
+   - **Arch Context**: code via \`compact()\`/\`digest()\`
    - **Constraints**: patterns, conventions, anti-patterns
-   - **Self-Review**: checklist before declaring DONE
+   - **Self-Review**: checklist before DONE
 
-3. **Status Protocol**: \`DONE\` | \`DONE_WITH_CONCERNS\` | \`NEEDS_CONTEXT\` | \`BLOCKED\`
-4. **Max 2 retries** per task — then escalate to user`,t=`### FORGE Quality Gate
+3. **Status**: \`DONE\` | \`DONE_WITH_CONCERNS\` | \`NEEDS_CONTEXT\` | \`BLOCKED\`
+4. **Max 2 retries** per task → escalate`,t=`### FORGE Quality Gate
 
-After all reviews complete:
-1. \`evidence_map({ action: "gate", task_id: "<slug>" })\` → returns YIELD/HOLD/HARD_BLOCK
-2. YIELD → approved, proceed to commit
-3. HOLD → minor issues, fix then re-gate (max 3 rounds)
-4. HARD_BLOCK → critical issues, escalate to user`;function n(e,t=``,n=``){return`## Foundation Integration
+After reviews complete:
+1. \`evidence_map({ action: "gate", task_id: "<slug>" })\` → YIELD/HOLD/HARD_BLOCK
+2. YIELD → approved, proceed
+3. HOLD → fix, re-gate (max 3 rounds)
+4. HARD_BLOCK → escalate`;function n(e,t=``,n=``){return`## Foundation Integration
 
 Load these skills BEFORE executing this step:
 
 | Skill | Purpose | When |
 |-------|---------|------|
-| \`aikit\` | Core MCP tools — search, analyze, ${e}, validate | Always (auto-loaded) |
-| \`present\` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
-| \`multi-agents-development\` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
-| \`brainstorming\` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |${t?`\n${t}`:``}
+| \`aikit\` | Core MCP tools — search, analyze, ${e}, validate | Always |
+| \`present\` | Rich rendering for structured output | Any output that benefits from rich rendering |
+| \`multi-agents-development\` | Dispatch templates, task decomposition, review patterns | Before dispatching any subagent |
+| \`brainstorming\` | Structured ideation for design decisions | Before design choice or feature exploration |${t?`\n${t}`:``}
 
 ### Presentation Rules
-- Use \`present\` for **any output** that benefits from rich rendering — not limited to dashboards
-- Assessments, reports, comparisons, reviews, status boards → \`present({ schemaVersion: 1, title: "Assessment", blocks: [...] })\`
-- Use \`table\` blocks for comparisons, \`kv\` for status/scores, \`list\` for findings, and \`metrics\` for numeric health indicators. NEVER \`code\` blocks for structured data.
-- Tables, charts, progress tracking, code review findings → always present
-- Use \`metrics\` for numeric indicators, \`checklist\` for task status, \`kv\` for summary, and \`table\` for review findings. NEVER \`code\` blocks for structured data.
-- Artifact content and summaries → present with structured layout; use \`markdown\` for prose sections.
-- Only use plain text for brief confirmations and simple questions${n?`\n\n${n}`:``}`}const r=e=>`## Knowledge Capture
+- Use \`present\` for any output that benefits from rich rendering
+- Assessments, reports, comparisons, reviews, status boards, tables, charts, progress, findings → \`present({ schemaVersion: 1, title: "Assessment", blocks: [...] })\`
+- Use \`table\` for comparisons/findings, \`kv\` for status/summary, \`list\` for findings/tasks, \`metrics\` for numeric health, \`checklist\` for task status, \`markdown\` for prose
+- NEVER use \`code\` blocks for structured data
+- Plain text only for brief confirmations and simple questions${n?`\n\n${n}`:``}`}const r=e=>`## Knowledge Capture
 
-Before completing this step, persist important findings using \`knowledge({ action: "remember", ... })\`:
+Before completing this step, persist important findings with \`knowledge({ action: "remember", ... })\`:
 
 ${e}
 
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`knowledge({ action: "remember", ... })\` now.`,i={_epilogue:[{file:`steps/docs-sync/README.md`,content:`# Epilogue: Documentation Sync
+If this step produced reusable knowledge, store it now.`,i={_epilogue:[{file:`steps/docs-sync/README.md`,content:`# Epilogue: Documentation Sync
 
-> **This is a mandatory epilogue step.** It runs automatically after every flow completes to keep project documentation synchronized with code changes.
+> **This is a mandatory epilogue step.** Runs after every flow to keep project documentation synced with code changes.
 
 ## Objective
 
-Review the changes made during this flow and update the \`docs/\` folder using AI Kit analysis tools — never write docs from scratch when a tool can generate the foundation.
+Review flow changes and update \`docs/\` with AI Kit analysis tools. Never write docs from scratch when a tool can generate the base.
 
 ## Prerequisites
 
-Load the \`docs\` skill before proceeding — it contains the full documentation convention, templates, architecture blueprint workflow, and change-to-doc mapping rules.
+Load the \`docs\` skill before proceeding.
 
 ## Instructions
 
 ### 0. Gather Flow Artifacts
 
-Read all artifacts produced during this flow — they contain design decisions, requirements, and verification results that are the most valuable documentation input.
+Read all flow artifacts.
 
 \`\`\`
 flow({ action: 'status' })                             # Get artifactsPath
@@ -75,7 +71,7 @@ digest({ sources: [                                     # Compress artifacts for
 ]})
 \`\`\`
 
-Map each discovered artifact to documentation actions using the artifact-to-doc mapping from the \`docs\` skill. Different flows produce different artifacts — read everything \`find()\` returns and focus on content that contains decisions, requirements, and verification results.
+Map each artifact to doc actions with the \`docs\` skill mapping. Focus on decisions, requirements, and verification.
 
 If no artifacts exist, proceed to Step 1 in source-only mode.
 
@@ -86,7 +82,7 @@ git_context({})                                         # What changed in this f
 blast_radius({ path: ".", files: ["<changed-files>"] }) # Impact analysis — which modules affected
 \`\`\`
 
-Use the output to classify changes:
+Classify changes from tool output:
 
 | Change Signal | Documentation Action |
 |---------------|---------------------|
@@ -98,7 +94,7 @@ Use the output to classify changes:
 
 ### 2. Apply the Change-to-Doc Mapping
 
-Follow the decision tree from the \`docs\` skill to determine which documentation actions are needed.
+Follow the \`docs\` skill decision tree.
 
 ### 3. Bootstrap \`docs/\` If Needed (full tool-driven workflow)
 
@@ -127,7 +123,7 @@ docs/
    └── api.md             ← From analyze(entry_points)
 \`\`\`
 
-Use the Architecture Blueprint sections from the \`docs\` skill as the template for each document.
+Use the \`docs\` skill Architecture Blueprint sections as the template.
 
 ### 4. Update Existing Docs (tool-assisted)
 
@@ -138,8 +134,8 @@ compact({ path: "docs/architecture/overview.md", query: "section to update" })
 blast_radius({ path: ".", files: ["<files>"] })                                # What's affected
 \`\`\`
 
-- **Don't rewrite** — update the relevant sections of existing docs
-- **Don't duplicate** — if the information is in code comments or READMEs, reference it
+- **Don't rewrite** — update relevant sections only
+- **Don't duplicate** — reference code comments or READMEs when they already contain it
 - Use \`compact\` to read existing doc sections before editing
 - Use \`blast_radius\` output to determine which sections need updating
 
@@ -147,27 +143,27 @@ blast_radius({ path: ".", files: ["<files>"] })                                #
 
 - Architecture decisions → \`adr-skill\` → \`docs/decisions/\`
 - Architecture diagrams → \`c4-architecture\` skill → \`docs/architecture/\`
-- Full architecture refresh → Run the Architecture Blueprint Workflow from \`docs\` skill
+- Full architecture refresh → run the \`docs\` skill Architecture Blueprint Workflow
 
 ### 6. Update Index
 
-If documents were added, removed, or renamed, update \`docs/README.md\` to reflect the current structure.
+If docs were added, removed, or renamed, update \`docs/README.md\`.
 
 ### 6b. Update HTML Documentation Site (if exists)
 
 If \`docs/site/\` exists with a manifest:
 
-1. **Detect staleness** — Compare source changes from \`git_context\` against the manifest's page data
-2. **Identify affected pages** — Use \`blast_radius\` output to determine which pages' source data changed
-3. **Regenerate affected pages only** — Update the manifest JSON with fresh data for changed pages
+1. **Detect staleness** — compare source changes from \`git_context\` against manifest page data
+2. **Identify affected pages** — use \`blast_radius\` to find pages whose source data changed
+3. **Regenerate affected pages only** — update manifest JSON with fresh data for changed pages
 4. **Rebuild** — Run \`inject-viewer.mjs --manifest\` with the updated manifest
 5. **Regenerate hub** — If pages were added or removed, regenerate the docs-hub page
 
-If \`docs/site/\` doesn't exist but the flow produced architecture diagrams or process flows, suggest running \`/docs-site\` to generate a full HTML documentation site.
+If \`docs/site/\` doesn't exist but the flow produced architecture diagrams or process flows, suggest \`/docs-site\`.
 
 ### 7. Skip If Nothing Changed
 
-If the flow's changes don't warrant doc updates (e.g., pure bug fix with no revelations), report:
+If changes don't warrant doc updates, report:
 - "No documentation updates needed"
 - Reason: (brief explanation)
 
@@ -180,7 +176,7 @@ If the flow's changes don't warrant doc updates (e.g., pure bug fix with no reve
 - [ ] Stale HTML pages regenerated from fresh analysis data
 - [ ] Relevant docs created or updated (or skipped with reason)
 - [ ] \`docs/README.md\` index is current
-- [ ] No placeholder/empty docs created — all content tool-generated or hand-written with purpose`},{file:`steps/lesson-learned/README.md`,content:`---
+- [ ] No placeholder/empty docs created — all content tool-generated or written with purpose`},{file:`steps/lesson-learned/README.md`,content:`---
 name: _lesson-learned
 description: Extract engineering principles from the completed flow
 skills: [lesson-learned]
@@ -190,30 +186,30 @@ skills: [lesson-learned]
 
 ## Condition Check (MUST evaluate first)
 
-Before extracting lessons, check if this flow produced learnable outcomes:
+Before extracting lessons, check whether this flow produced learnable outcomes:
 
-**Skip this step (advance with 'skip') when ALL of these are true:**
+**Skip this step (advance with 'skip') when ALL are true:**
 - Flow was Floor-tier (trivial change)
 - blast_radius ≤ 2 for all changes
 - Flow completed in a single batch with no iteration
 - No agent returned BLOCKED or DONE_WITH_CONCERNS
 - evidence_map never reached HOLD state
 
-**Proceed when ANY of these are true:**
+**Proceed when ANY are true:**
 - An agent returned BLOCKED or DONE_WITH_CONCERNS during the flow
 - evidence_map had HOLD before reaching YIELD (required iteration to pass)
-- Multi-model decision protocol was invoked (architectural learning)
+- Multi-model decision protocol was invoked
 - blast_radius > 5 (complex change with systemic implications)
 - A novel pattern or anti-pattern was discovered
 - A debugging session revealed non-obvious root cause
 
-If skip condition met → \`flow({ action: 'step', advance: 'skip' })\` with note: "No lesson signals detected."
+If skip condition is met → \`flow({ action: 'step', advance: 'skip' })\` with note: "No lesson signals detected."
 
 ## Extraction Protocol
 
-1. **Load the \`lesson-learned\` skill** — follow its full protocol
-2. Run \`git_context({ include_diff: true, commit_count: 10 })\` to see what changed
-3. Review flow artifacts in \`{{artifacts_path}}\` for decisions made
+1. **Load the \`lesson-learned\` skill**
+2. Run \`git_context({ include_diff: true, commit_count: 10 })\`
+3. Review flow artifacts in \`{{artifacts_path}}\`
 4. Extract 1-3 principles using the skill's framework:
    - What went wrong → What we learned → What we'll do differently
    - OR: What went right → Why it worked → How to replicate
@@ -222,21 +218,91 @@ If skip condition met → \`flow({ action: 'step', advance: 'skip' })\` with not
 ## Quality Bar
 
 A good lesson:
-- Is **generalizable** (applies beyond this specific task)
-- Has **evidence** (references specific files, errors, or decisions)
+- Is **generalizable** (applies beyond this task)
+- Has **evidence** (references files, errors, or decisions)
 - Is **actionable** (tells future agents what to do or avoid)
 
-A bad lesson (skip these):
-- Restates what was done without insight
-- Is too specific to be reusable ("file X had a typo on line 42")
+Skip lessons that:
+- Restate what was done without insight
+- Is too specific to reuse ("file X had a typo on line 42")
 - Captures a convention already documented elsewhere
-`}],"aikit-advanced":[{file:`README.md`,content:"# aikit:advanced — Full Development Flow\n\nFull development flow for **new features, API design, and architecture changes**.\n\n## Steps\n\n| # | Step | Skill | Produces | Requires | Agents |\n|---|------|-------|----------|----------|--------|\n| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |\n| 2 | **Specification** | `steps/spec/README.md` | `spec.md` | `design-decisions.md` | Researcher-Alpha |\n| 3 | **Planning** | `steps/plan/README.md` | `plan.md` | `spec.md` | Planner, Explorer |\n| 4 | **Task Breakdown** | `steps/task/README.md` | `tasks.md` | `plan.md` | Planner, Architect-Reviewer-Alpha |\n| 5 | **Execution** | `steps/execute/README.md` | `progress.md` | `tasks.md` | Orchestrator, Implementer, Frontend, Refactor |\n| 6 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta, Security |\n\n## How It Works\n\nEach step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow({ action: 'read' })` and delegates work accordingly.\n\n### Step 1: Design Gate\n- Full brainstorming session for new features and architectural changes\n- FORGE classification (`forge_classify`) + grounding (`forge_ground`) for complex tasks\n- Full 3-phase multi-model decision protocol for non-trivial technical decisions (see Orchestrator's inlined Multi-Model Decision Protocol)\n- ADR generation for critical-tier tasks\n- **Mandatory user stop** before proceeding — design decisions must be approved\n- Read `steps/design/README.md` for the full protocol\n\n### Step 2: Specification\n- Elicit requirements from the user, clarify scope\n- Define acceptance criteria and constraints\n- Build on design decisions from the previous step\n\n### Step 3: Planning\n- Deep codebase analysis using `search`, `scope_map`, `trace`, `analyze_*`\n- Design architecture based on spec and design decisions\n- Create comprehensive implementation plan with file-level changes\n\n### Step 4: Task Breakdown\n- Break the plan into ordered, atomic implementation tasks\n- Define dependencies between tasks\n- Identify parallel batches for multi-agent execution\n- Architecture review of the task structure\n\n### Step 5: Execution\n- Orchestrator dispatches agents in parallel batches per the task breakdown\n- Each agent gets a scoped task (1-3 files) with clear acceptance criteria\n- TDD: write tests first, then implement\n- Per-batch review cycle: Code Review (dual) → Arch Review → Security → Evidence Gate\n\n### Step 6: Verification\n- Dual code review (Code-Reviewer-Alpha + Beta)\n- Architecture review (Architect-Reviewer-Alpha + Beta)\n- Security review\n- Run `check({})` + `test_run({})` + `blast_radius({})`\n- `evidence_map({ action: \"gate\" })` for final quality gate\n\n## Using Skills Inside Steps\n\nWhen the Orchestrator activates a step:\n\n1. **Read the instruction first** — `flow({ action: 'read' })` returns the README.md for the current step\n2. **Follow step instructions** — the README.md is the primary guide for what to do\n3. **Delegate to listed agents** — each step lists which agents are appropriate\n4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory\n5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist\n6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator\n\n## Artifacts\n\nAll artifacts are stored in the run directory under `.flows/{topic}/`. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.\n"},{file:`steps/design/README.md`,content:`# Design Gate — Advanced Flow
+`}],"aikit-advanced":[{file:`README.md`,content:`# aikit:advanced — Full Development Flow
+
+Full development flow for **new features, API design, and architecture changes**.
+
+## Steps
+
+| # | Step | Skill | Produces | Requires | Agents |
+|---|------|-------|----------|----------|--------|
+| 1 | **Design Gate** | \`steps/design/README.md\` | \`design-decisions.md\` | — | Researcher-Alpha/Beta/Gamma/Delta |
+| 2 | **Specification** | \`steps/spec/README.md\` | \`spec.md\` | \`design-decisions.md\` | Researcher-Alpha |
+| 3 | **Planning** | \`steps/plan/README.md\` | \`plan.md\` | \`spec.md\` | Planner, Explorer |
+| 4 | **Task Breakdown** | \`steps/task/README.md\` | \`tasks.md\` | \`plan.md\` | Planner, Architect-Reviewer-Alpha |
+| 5 | **Execution** | \`steps/execute/README.md\` | \`progress.md\` | \`tasks.md\` | Orchestrator, Implementer, Frontend, Refactor |
+| 6 | **Verification** | \`steps/verify/README.md\` | \`verify-report.md\` | \`progress.md\` | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta, Security |
+
+## How It Works
+
+Each step has a **README.md**. Orchestrator reads it via \`flow({ action: 'read' })\` and delegates work.
+
+### Step 1: Design Gate
+- Brainstorming for new features and arch changes
+- FORGE classification + grounding for complex tasks
+- 3-phase decision protocol for non-trivial technical decisions
+- ADRs for critical-tier tasks
+- **Mandatory user stop** before proceeding — design decisions must be approved
+- Read \`steps/design/README.md\` for the full protocol
+
+### Step 2: Specification
+- Elicit requirements, clarify scope
+- Define acceptance criteria and constraints
+- Build on design decisions
+
+### Step 3: Planning
+- Analyze codebase with \`search\`, \`scope_map\`, \`trace\`, \`analyze_*\`
+- Design architecture from spec and design decisions
+- Create implementation plan with file-level changes
+
+### Step 4: Task Breakdown
+- Break plan into ordered, atomic tasks
+- Define task deps
+- Identify parallel batches
+- Review task structure
+
+### Step 5: Execution
+- Orchestrator dispatches agents in parallel batches per the task breakdown
+- Each agent gets a scoped task (1-3 files) with clear acceptance criteria
+- TDD: write tests first, then implement
+- Per-batch review cycle: Code Review → Arch Review → Security → Evidence Gate
+
+### Step 6: Verification
+- Dual code review (Code-Reviewer-Alpha + Beta)
+- Architecture review (Architect-Reviewer-Alpha + Beta)
+- Security review
+- Run \`check({})\` + \`test_run({})\` + \`blast_radius({})\`
+- \`evidence_map({ action: "gate" })\` for final quality gate
+
+## Using Skills Inside Steps
+
+When the Orchestrator activates a step:
+
+1. **Read the instruction first** — \`flow({ action: 'read' })\` returns the current step README.md
+2. **Follow step instructions** — primary guide
+3. **Delegate to listed agents** — each step lists which agents are appropriate
+4. **Produce the required artifact** — the step's \`produces\` field specifies the artifact file
+5. **Check dependencies** — required prior artifacts must exist
+6. **Report status** — agents report \`DONE\` | \`DONE_WITH_CONCERNS\` | \`NEEDS_CONTEXT\` | \`BLOCKED\` to the Orchestrator
+
+## Artifacts
+
+Artifacts are stored under \`.flows/{topic}/\`. \`{{artifacts_path}}\` resolves at runtime.
+`},{file:`steps/design/README.md`,content:`# Design Gate — Advanced Flow
 
 Full design gate for new features, API design, and architecture changes. Runs brainstorming, decision protocol, and FORGE classification before specification begins.
 
 ## When This Step Runs
 
-This is the **first step** of the \`aikit:advanced\` flow. It runs before specification.
+First step of \`aikit:advanced\`. Runs before specification.
 
 ## Instructions
 
@@ -252,7 +318,7 @@ Classify the task:
 
 ### 2. FORGE Classification
 
-Run \`forge_classify({ task: "<task description>", files: [<relevant files>], root_path: "." })\` to determine the complexity tier.
+Run \`forge_classify({ task: "<task description>", files: [<relevant files>], root_path: "." })\` to determine tier.
 
 | Tier | Meaning | Design Depth |
 |------|---------|-------------|
@@ -262,10 +328,10 @@ Run \`forge_classify({ task: "<task description>", files: [<relevant files>], ro
 
 ### 3. Brainstorming Session
 
-Load the \`brainstorming\` skill and conduct a structured brainstorming session:
+Load \`brainstorming\` and run:
 
 1. **Intent Discovery** — What is the user trying to achieve? What problem does this solve?
-2. **Constraint Mapping** — Technical constraints, time constraints, compatibility requirements
+2. **Constraint Mapping** — Technical, time, compatibility constraints
 3. **Approach Exploration** — Generate 2-4 possible approaches
 4. **Trade-off Analysis** — Compare approaches on: complexity, maintainability, performance, risk
 
@@ -279,30 +345,30 @@ For **Critical** tier tasks, also explore:
 
 When technical decisions need resolution, follow the **3-phase multi-model decision protocol**:
 
-1. **Identify decisions** — List each decision point with 2+ viable options
+1. **Identify decisions** — list each decision point with 2+ viable options
 2. **Phase 1 — Independent Research** — Launch ALL 4 Researcher variants in parallel:
    - Researcher-Alpha (Contrarian): Deep analysis, actively seeks fatal flaws
    - Researcher-Beta (First Principles): Trade-offs and edge cases, strips assumptions
    - Researcher-Gamma (Expansionist): Cross-domain patterns, undervalued opportunities
    - Researcher-Delta (Executor): Feasibility, performance, fastest implementation path
-3. **Phase 2 — Peer Review** — Anonymize outputs as Perspective A/B/C/D, launch 4 reviewers in parallel asking: strongest argument, biggest blind spot, consensus gap, verdict
-4. **Phase 3 — Structured Verdict** — Synthesize into: Where Agrees / Where Clashes / Blind Spots Caught / Recommendation (with confidence) / First Step
-5. **Present & Record** — Render verdict with \`present({ schemaVersion: 1, title: "Decision Verdict", blocks: [...] })\`; use \`table\` for multi-perspective comparisons, \`list\` for blind spots and recommendations, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data. Produce ADR via \`adr-skill\`
+3. **Phase 2 — Peer Review** — anonymize outputs as Perspective A/B/C/D, launch 4 reviewers in parallel asking: strongest argument, biggest blind spot, consensus gap, verdict
+4. **Phase 3 — Structured Verdict** — synthesize into: Where Agrees / Where Clashes / Blind Spots Caught / Recommendation (with confidence) / First Step
+5. **Present & Record** — Render verdict with \`present({ schemaVersion: 1, title: "Decision Verdict", blocks: [...] })\`; use \`table\` for multi-perspective comparisons, \`list\` for blind spots/recommendations, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data. Produce ADR via \`adr-skill\`
 
 **Floor tier shortcut**: Skip Phase 2 (peer review), go straight from research to verdict.
 
 ### 5. FORGE Ground (Standard & Critical tiers)
 
 Run \`forge_ground({ task, files: [<relevant files>], root_path: "." })\` to:
-- Scope the affected files and modules
+- Scope affected files and modules
 - Identify unknowns and risks
 - Load existing constraints and conventions
 
-**Auto-upgrade check**: If \`forge_ground\` reveals contract-type unknowns or security concerns not caught by initial \`forge_classify\`, recommend tier upgrade.
+**Auto-upgrade check**: If \`forge_ground\` reveals contract-type unknowns or security concerns missed by \`forge_classify\`, recommend a tier upgrade.
 
 ### 6. Write \`{{artifacts_path}}/design-decisions.md\` to disk
 
-**You MUST create this file on disk** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+**You MUST create this file on disk** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 \`\`\`markdown
 ## Design Decisions
@@ -348,7 +414,7 @@ Use \`present({ schemaVersion: 1, title: "Design Review", blocks: [...] })\` to
 - Key trade-offs
 - Open questions requiring user input
 
-Use \`kv\` for FORGE tier and rationale, \`list\` for trade-offs and open questions, \`table\` for decision comparisons, and \`markdown\` for narrative summary. NEVER \`code\` blocks for structured data. Add \`actions\` only when you need browser transport for user choices.
+Use \`kv\` for FORGE tier/rationale, \`list\` for trade-offs/open questions, \`table\` for decision comparisons, \`markdown\` for narrative summary. NEVER \`code\` blocks for structured data. Add \`actions\` only for browser transport.
 
 **🛑 MANDATORY STOP** — Wait for user approval of design decisions before proceeding.
 
@@ -363,7 +429,7 @@ After user approves:
 
 ## Outputs
 
-Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
+Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 ## Produces
 
@@ -371,27 +437,27 @@ Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this
 
 ## Agents
 
-- \`Researcher-Alpha\` — Deep analysis of primary approach
-- \`Researcher-Beta\` — Trade-offs and edge cases
+- \`Researcher-Alpha\` — Primary approach
+- \`Researcher-Beta\` — Trade-offs
 - \`Researcher-Gamma\` — Cross-domain patterns
-- \`Researcher-Delta\` — Feasibility and performance
+- \`Researcher-Delta\` — Feasibility
 
-${n(`knowledge`,"| `c4-architecture` | C4 model diagrams showing system structure changes | When visualizing proposed architecture |\n| `adr-skill` | Architecture Decision Records for non-trivial decisions | Critical tier — document architecture decisions |")}
+${n(`knowledge`,"| `c4-architecture` | C4 diagrams for system structure changes | When visualizing architecture |\n| `adr-skill` | ADRs for non-trivial decisions | Critical tier — document architecture decisions |")}
 
 ## Completion Criteria
 
 - [ ] \`{{artifacts_path}}/design-decisions.md\` written to disk (NOT just presented in chat)
 - [ ] FORGE tier determined and documented
-- [ ] Brainstorming session completed (for Standard+ tier)
+- [ ] Brainstorming completed (for Standard+ tier)
 - [ ] Key design decisions documented with rationale
 - [ ] User approval received (🛑 MANDATORY STOP)
 
-${r(`- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries`)}
+${r(`- **Design decisions**: Chosen approach and rejected alternatives
+- **Architecture patterns**: New patterns or patterns that must be followed
+- **Constraints discovered**: Technical, compatibility, performance limits`)}
 `},{file:`steps/execute/README.md`,content:`---
 name: execute
-description: Implement all tasks from the task breakdown, dispatching agents in parallel where possible.
+description: Implement tasks from the task breakdown, dispatching agents in parallel where possible.
 ---
 
 # Execution
@@ -406,26 +472,26 @@ If prerequisites are NOT met -> **backtrack to task step** (\`flow({ action: 'st
 
 ## Purpose
 
-Execute all tasks from the breakdown, dispatching implementation agents in batches for maximum parallelism while maintaining correctness.
+Execute tasks from the breakdown in batches, maximizing parallelism without losing correctness.
 
 ## Inputs
 
-- \`{{artifacts_path}}/tasks.md\` — the atomic task list with dependencies and agent assignments
+- \`{{artifacts_path}}/tasks.md\` — task list with deps and agents
 
 ## Process
 
-1. **Load tasks** — Read task graph, dependencies, and parallelism map
+1. **Load tasks** — read task graph, deps, parallelism map
 2. **Execute by batch** — For each batch in the parallelism map:
    a. Dispatch assigned agents in parallel (different files = safe parallelism)
-   b. Each agent receives: task scope, affected files, acceptance criteria, relevant code context via \`compact()\`/\`digest()\`
+   b. Each agent receives: task scope, affected files, acceptance criteria, code context via \`compact()\`/\`digest()\`
    c. Wait for all agents in batch to complete
    d. Run \`check({})\` + \`test_run({})\` after each batch
    e. Fix any failures before proceeding to next batch
-3. **Track progress** — Update task checkboxes as each completes
+3. **Track progress** — update task checkboxes
 4. **Handle failures** — If an agent reports \`BLOCKED\` or \`NEEDS_CONTEXT\`:
    - Max 2 retries per task with refined context
    - If still blocked, escalate to user
-5. **Final validation** — After all batches: \`check({})\` + \`test_run({})\` must pass
+5. **Final validation** — after all batches: \`check({})\` + \`test_run({})\` must pass
 
 ## DAG Task Decomposition
 
@@ -437,11 +503,11 @@ queue({ action: 'push', name: 'execute-tasks', title: 'Task A', id: 'a' })
 queue({ action: 'push', name: 'execute-tasks', title: 'Task B', id: 'b', dependsOn: ['a'] })
 \`\`\`
 
-Tasks with \`dependsOn\` are blocked until their dependencies complete. This ensures correct execution order for dependent changes.
+Tasks with \`dependsOn\` stay blocked until deps complete. This preserves execution order.
 
 ## Outputs
 
-Write \`{{artifacts_path}}/progress.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/progress.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -479,17 +545,17 @@ Template:
 
 | Agent | Role |
 |-------|------|
-| **Orchestrator** | Coordinates batch execution, handles failures and retries |
-| **Implementer** | Primary code writer for backend, logic, and infrastructure tasks |
-| **Frontend** | UI/UX implementation for React components, styling, responsive design |
-| **Refactor** | Code cleanup, restructuring, and pattern alignment tasks |
+| **Orchestrator** | Batches, failures, retries |
+| **Implementer** | Backend, logic, infra |
+| **Frontend** | React, styling, responsive |
+| **Refactor** | Cleanup, restructuring |
 
 **Parallelism rules**:
 - Read-only agents: unlimited parallelism
-- File-modifying agents: parallel ONLY on completely different files
+- File-modifying agents: parallel ONLY on different files
 - Max 4 concurrent file-modifying agents
 
-${n(`knowledge`,"| `session-handoff` | Context preservation for long-running execution phases | When execution spans multiple sessions or context is filling |",e)}
+${n(`knowledge`,"| `session-handoff` | Context preservation for long-running execution | When execution spans sessions or context is filling |",e)}
 
 ## Completion Criteria
 
@@ -499,12 +565,12 @@ ${n(`knowledge`,"| `session-handoff` | Context preservation for long-running exe
 - [ ] No blocked items remaining
 - [ ] \`{{artifacts_path}}/progress.md\` written
 
-${r(`- **Implementation decisions**: Why specific approaches were chosen over alternatives
-- **Patterns established**: New conventions or patterns that future code should follow
-- **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during execution`)}
+${r(`- **Implementation decisions**: Why specific approaches were chosen
+- **Patterns established**: New conventions or patterns to follow
+- **Gotchas encountered**: Edge cases, workarounds, non-obvious behaviors`)}
 `},{file:`steps/plan/README.md`,content:`---
 name: plan
-description: Analyze the codebase, design the architecture, and create a detailed implementation plan.
+description: Analyze the codebase, design the architecture, and create an implementation plan.
 ---
 
 # Planning
@@ -519,22 +585,22 @@ If prerequisites are NOT met → **backtrack to spec step** (\`flow({ action: 's
 
 ## Purpose
 
-Translate the specification into a concrete, phased implementation plan with architecture decisions, file-level scope, and dependency ordering.
+Translate the spec into a phased implementation plan with architecture decisions, file scope, and dependency order.
 
 ## Inputs
 
-- \`{{artifacts_path}}/spec.md\` — the validated specification
+- \`{{artifacts_path}}/spec.md\` — validated spec
 
 ## Requirements Alignment
 
 Before implementation, verify alignment with requirements:
 - Read \`{{artifacts_path}}/requirements.md\` if it exists
-- Ensure all acceptance criteria from requirements are covered by the implementation plan
+- Ensure all acceptance criteria from requirements are covered by the plan
 - Flag any requirement that cannot be met and explain why
 
 ## Process
 
-1. **Load spec** — Read and internalize all requirements and acceptance criteria
+1. **Load spec** — read requirements and acceptance criteria
 2. **Codebase analysis** — \`scope_map({ task: "<feature>" })\` to identify affected subsystems
 3. **Deep dive** — \`file_summary()\` + \`compact()\` on each affected module
 4. **Architecture design** — Decide on:
@@ -542,14 +608,14 @@ Before implementation, verify alignment with requirements:
    - API surface changes
    - Data model changes
    - Integration patterns
-5. **ADR for non-trivial decisions** — Use \`adr-skill\` for decisions that affect future development
-6. **Phase decomposition** — Break work into 3–10 ordered phases, each independently testable
-7. **Dependency graph** — Map which phases depend on others and which can parallelize
+5. **ADR for non-trivial decisions** — use \`adr-skill\` for decisions that affect future development
+6. **Phase decomposition** — break work into 3–10 ordered phases, each independently testable
+7. **Dependency graph** — map which phases depend on others and which can parallelize
 8. **Risk assessment** — Identify implementation risks per phase
 
 ## Outputs
 
-Write \`{{artifacts_path}}/plan.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/plan.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -588,16 +654,16 @@ Template:
 
 | Agent | Role |
 |-------|------|
-| **Planner** | Creates comprehensive TDD implementation plans with phase decomposition |
-| **Explorer** | Rapid codebase exploration for discovery of affected files and dependencies |
+| **Planner** | TDD implementation plans |
+| **Explorer** | Codebase exploration for files and deps |
 
 **Dispatch via \`runSubagent\` — never \`switchAgent\`:**
 1. \`runSubagent({ agent: "Explorer", ... })\` — initial breadth: file discovery, dependency tracing
 2. \`runSubagent({ agent: "Planner", ... })\` — depth: phase design, ordering, plan artifact creation
 
-The Planner agent (\`Planner.agent.md\`) owns the \`{{artifacts_path}}/plan.md\` artifact. Pass it the spec content, Explorer findings, and artifacts path as context.
+The Planner agent (\`Planner.agent.md\`) owns the \`{{artifacts_path}}/plan.md\` artifact. Pass spec content, Explorer findings, and artifacts path as context.
 
-${n(`knowledge`,"| `adr-skill` | Architecture Decision Records for non-trivial technical decisions | When plan involves architecture choices that need documentation |\n| `c4-architecture` | C4 model diagrams showing system structure changes | When plan modifies system architecture |")}
+${n(`knowledge`,"| `adr-skill` | ADRs for non-trivial technical decisions | When plan involves architecture choices that need documentation |\n| `c4-architecture` | C4 diagrams for system structure changes | When plan modifies system architecture |")}
 
 ## Completion Criteria
 
@@ -608,12 +674,12 @@ ${n(`knowledge`,"| `adr-skill` | Architecture Decision Records for non-trivial t
 - [ ] Risks identified with mitigations
 - [ ] \`{{artifacts_path}}/plan.md\` written
 
-${r(`- **Task dependencies**: Critical ordering constraints and parallel opportunities
-- **Risk assessment**: Identified risks and mitigation strategies
-- **Resource decisions**: File ownership, module boundaries, and integration points`)}
+${r(`- **Task dependencies**: Ordering constraints and parallel opportunities
+- **Risk assessment**: Risks and mitigations
+- **Resource decisions**: File ownership, module boundaries, integration points`)}
 `},{file:`steps/spec/README.md`,content:`---
 name: spec
-description: Elicit requirements, clarify scope, and define acceptance criteria through structured dialogue.
+description: Elicit requirements, clarify scope, and define acceptance criteria through dialogue.
 ---
 
 # Specification
@@ -628,43 +694,43 @@ If prerequisites are NOT met -> **backtrack to design step** (\`flow({ action: '
 
 ## Purpose
 
-Transform a vague or broad feature request into a precise, testable specification through requirements elicitation and stakeholder dialogue.
+Transform a vague or broad feature request into a precise, testable specification.
 
 ## Inputs
 
 - User's feature request, issue, or idea
-- Codebase context (accessed via aikit MCP tools)
+- Codebase context (via aikit MCP tools)
 
 ### Input Artifacts
 
 Read these from \`{{artifacts_path}}/\` before writing the spec:
-1. \`requirements.md\` — Requirements clarity output (score, criteria, constraints). **If this file exists, the spec MUST address all requirements and acceptance criteria listed in it.**
+1. \`requirements.md\` — Requirements clarity output (score, criteria, constraints). **If this file exists, the spec MUST address all listed requirements and acceptance criteria.**
 2. \`design-decisions.md\` — Design decisions from the design step
 
 If \`requirements.md\` is not found in artifacts, check flow-scoped knowledge:
 \`\`\`
 knowledge({ action: "withdraw", scope: "flow", profile: "implementer", budget: 4000 })
 \`\`\`
-Look for a "Requirements:" entry in the withdrawn context.
+Look for a "Requirements:" entry in withdrawn context.
 
 ## Process
 
-1. **Understand intent** — Parse what the user wants and why
-2. **Search for context** — \`search()\` for related prior decisions, existing patterns, and similar features
+1. **Understand intent** — parse what the user wants and why
+2. **Search for context** — \`search()\` for related decisions, patterns, similar features
 3. **Elicit requirements** — Ask structured questions to clarify:
    - **Functional**: What must the system do?
    - **Non-functional**: Performance, security, accessibility constraints
    - **Scope boundaries**: What is explicitly out of scope?
    - **Acceptance criteria**: How do we know it's done?
-4. **Score clarity** — Use the \`requirements-clarity\` skill to score 0–100. Iterate questions until ≥ 90.
-5. **Draft specification** — Write formal spec with all requirements resolved
+4. **Score clarity** — use the \`requirements-clarity\` skill to score 0–100. Iterate until ≥ 90.
+5. **Draft specification** — write formal spec with all requirements resolved
 
 ## Requirements Clarity Gate (MANDATORY)
 
 Before producing any spec.md or design document:
 
 1. **Load the \`requirements-clarity\` skill**
-2. **Score the current requirements** using the skill's 0-100 rubric
+2. **Score current requirements** using the skill's 0-100 rubric
 3. **If score < 90:** Ask clarifying questions, iterate with user until ≥ 90
 4. **If score ≥ 90:** Proceed to spec writing
 
@@ -678,11 +744,11 @@ Key Clarifications:
    - [question asked → answer received]
 \`\`\`
 
-This gate ensures we don't design solutions for misunderstood problems.
+This gate prevents designing for misunderstood problems.
 
 ## Outputs
 
-Write \`{{artifacts_path}}/spec.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/spec.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -728,11 +794,11 @@ Key Clarifications:
 
 | Agent | Role |
 |-------|------|
-| **Researcher-Alpha** | Deep analysis of existing codebase patterns, prior decisions, and technical constraints |
+| **Researcher-Alpha** | Patterns, prior decisions, technical constraints |
 
-Use the \`brainstorming\` skill for creative/design exploration before formalizing requirements. Use \`requirements-clarity\` skill to score and iterate until the spec is unambiguous.
+Use \`brainstorming\` for creative/design exploration before formalizing requirements. Use \`requirements-clarity\` to score and iterate until the spec is unambiguous.
 
-${n(`remember`,"| `requirements-clarity` | Score requirements 0-100, iterate until ≥90 before proceeding | Before writing spec — ensures requirements are clear enough |")}
+${n(`remember`,"| `requirements-clarity` | Score requirements 0-100, iterate until ≥90 | Before writing spec — ensures requirements are clear enough |")}
 
 ## Completion Criteria
 
@@ -743,11 +809,11 @@ ${n(`remember`,"| `requirements-clarity` | Score requirements 0-100, iterate unt
 - [ ] \`{{artifacts_path}}/spec.md\` written
 
 ${r(`- **Requirements clarified**: Ambiguities resolved and assumptions validated
-- **Scope boundaries**: What the spec covers and explicit exclusions
+- **Scope boundaries**: What the spec covers and excludes
 - **Acceptance criteria**: Key testable conditions that define "done"`)}
 `},{file:`steps/task/README.md`,content:`---
 name: task
-description: Break the implementation plan into ordered, atomic tasks with dependencies and agent assignments.
+description: Break the implementation plan into ordered, atomic tasks with deps and agent assignments.
 ---
 
 # Task Breakdown
@@ -762,27 +828,27 @@ If prerequisites are NOT met → **backtrack to plan step** (\`flow({ action: 's
 
 ## Purpose
 
-Decompose the implementation plan into small, atomic tasks that agents can execute independently, with clear dependency ordering and acceptance criteria per task.
+Decompose the implementation plan into small, atomic tasks with clear dependency order and acceptance criteria.
 
 ## Inputs
 
-- \`{{artifacts_path}}/plan.md\` — the phased implementation plan
+- \`{{artifacts_path}}/plan.md\` — phased implementation plan
 
 ## Process
 
-1. **Load plan** — Read phases, file scope, and dependency graph
+1. **Load plan** — read phases, file scope, dependency graph
 2. **Decompose phases into tasks** — Each task should:
    - Touch 1–3 files maximum
    - Have a single, testable outcome
-   - Take one agent one focused session
+   - Fit one focused agent session
 3. **Define dependencies** — Map task-to-task dependencies (not just phase-to-phase)
-4. **Assign agents** — Match each task to the best-fit agent based on scope
+4. **Assign agents** — match each task to the best-fit agent
 5. **Identify parallelism** — Mark which tasks can run simultaneously
-6. **Architecture review** — Have Architect-Reviewer validate task ordering won't create integration issues
+6. **Architecture review** — have Architect-Reviewer validate task ordering won't create integration issues
 
 ## Outputs
 
-Write \`{{artifacts_path}}/tasks.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/tasks.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -821,7 +887,7 @@ Template:
 
 ## Visualization
 
-After writing \`tasks.md\`, present the task plan visually to the user for approval:
+After writing \`tasks.md\`, present the task plan visually for approval:
 
 \`\`\`
 present({ schemaVersion: 1, title: "Task Plan: <feature>", template: "task-plan@1", data: {
@@ -830,18 +896,18 @@ present({ schemaVersion: 1, title: "Task Plan: <feature>", template: "task-plan@
 } })
 \`\`\`
 
-This renders an interactive dependency graph showing phases, parallel batches, and agent assignments. The user can visualize the execution order before approving.
+This renders an interactive dependency graph showing phases, parallel batches, and agent assignments.
 
-Use the template-driven graph for the dependency view; if you add supporting summary content, use \`kv\` for approval metadata, \`list\` for task notes, and NEVER \`code\` blocks for structured data.
+Use the template-driven graph for the dependency view; if you add summary content, use \`kv\` for approval metadata, \`list\` for task notes, and NEVER \`code\` blocks for structured data.
 
 ## Agents
 
 | Agent | Role |
 |-------|------|
-| **Planner** | Decomposes plan phases into atomic tasks with dependency ordering |
-| **Architect-Reviewer-Alpha** | Validates task decomposition won't cause integration issues |
+| **Planner** | Atomic task decomposition |
+| **Architect-Reviewer-Alpha** | Validates task graph |
 
-Planner does the decomposition, then Architect-Reviewer validates the task graph.
+Planner does the decomposition; Architect-Reviewer validates the task graph.
 
 ${n(`remember`)}
 
@@ -854,12 +920,12 @@ ${n(`remember`)}
 - [ ] Architect review confirms no integration risks
 - [ ] \`{{artifacts_path}}/tasks.md\` written
 
-${r(`- **Task decomposition rationale**: Why tasks were split this way and what each accomplishes
-- **Interface contracts**: APIs, types, or data shapes that tasks depend on
+${r(`- **Task decomposition rationale**: Why tasks were split this way
+- **Interface contracts**: APIs, types, or data shapes tasks depend on
 - **Coordination points**: Where tasks interact and handoff requirements`)}
 `},{file:`steps/verify/README.md`,content:`---
 name: verify
-description: Dual code review, architecture review, security review, and comprehensive test validation.
+description: Dual code review, architecture review, security review, and test validation.
 ---
 
 # Verification (Advanced)
@@ -875,7 +941,7 @@ If prerequisites are NOT met → **backtrack to execute step** (\`flow({ action:
 
 ## Purpose
 
-Perform thorough multi-perspective validation of all changes through parallel dual code review, architecture review, and security analysis.
+Perform multi-perspective validation through dual code review, architecture review, and security analysis.
 
 ## Inputs
 
@@ -886,20 +952,20 @@ Perform thorough multi-perspective validation of all changes through parallel du
 
 ## Process
 
-1. **Load all artifacts** — Read spec, plan, tasks, and progress
+1. **Load all artifacts** — read spec, plan, tasks, progress
 2. **Dual code review** (parallel):
-   - Code-Reviewer-Alpha: focus on correctness, conventions, quality
-   - Code-Reviewer-Beta: focus on edge cases, error handling, maintainability
+   - Code-Reviewer-Alpha: correctness, conventions, quality
+   - Code-Reviewer-Beta: edge cases, error handling, maintainability
 3. **Architecture review** (parallel with code review):
-   - Architect-Reviewer-Alpha: validate changes align with plan and ADRs
-   - Architect-Reviewer-Beta: assess long-term maintainability and evolution
+   - Architect-Reviewer-Alpha: alignment with plan and ADRs
+   - Architect-Reviewer-Beta: long-term maintainability and evolution
 4. **Security review**:
    - Security agent: OWASP Top 10, auth/authz, input validation, secrets
 5. **Quality gates** — \`check({})\` + \`test_run({})\` must pass
 6. **Blast radius** — \`blast_radius({ path: ".", files: [...] })\` on all modified files
 7. **Acceptance criteria** — Verify each spec acceptance criterion is met
 8. **FORGE gate** — \`evidence_map({ action: "gate" })\` for final quality assessment
-9. **Synthesize report** — Merge all reviewer findings into unified verdict
+9. **Synthesize report** — merge reviewer findings into a unified verdict
 
 ## Evidence Map Gate Detail
 
@@ -909,11 +975,11 @@ After the process steps above, the FORGE gate must return YIELD:
 - **HOLD** → Fix unresolved claims, re-gate (max 2 retries)
 - **HARD_BLOCK** → Contract-type unknowns detected, escalate to user
 
-Never declare verification complete without a YIELD gate result.
+Never declare verification complete without YIELD.
 
 ## Outputs
 
-Write \`{{artifacts_path}}/verify-report.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/verify-report.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -956,15 +1022,15 @@ APPROVE | REQUEST CHANGES
 
 | Agent | Role |
 |-------|------|
-| **Code-Reviewer-Alpha** | Primary code review — correctness, quality, conventions |
-| **Code-Reviewer-Beta** | Secondary code review — edge cases, error handling, maintainability |
-| **Architect-Reviewer-Alpha** | Primary architecture review — alignment with plan and ADRs |
-| **Architect-Reviewer-Beta** | Secondary architecture review — long-term evolution |
-| **Security** | Security analysis — OWASP, auth, input validation |
+| **Code-Reviewer-Alpha** | Correctness, quality, conventions |
+| **Code-Reviewer-Beta** | Edge cases, error handling, maintainability |
+| **Architect-Reviewer-Alpha** | Alignment with plan and ADRs |
+| **Architect-Reviewer-Beta** | Long-term evolution |
+| **Security** | OWASP, auth, input validation |
 
-**Parallelism**: All 5 reviewers can run in parallel — they are read-only.
+**Parallelism**: All 5 reviewers can run in parallel — read-only.
 
-${n(`remember`,"| `lesson-learned` | Extract engineering principles from completed work | After verification — capture lessons from the implementation |\n| `session-handoff` | Context preservation for session continuity | When verification spans sessions or for final handoff documentation |",t)}
+${n(`remember`,"| `lesson-learned` | Extract engineering principles from completed work | After verification — capture lessons from the implementation |\n| `session-handoff` | Context preservation for session continuity | When verification spans sessions or for final handoff |",t)}
 
 ## Completion Criteria
 
@@ -979,22 +1045,22 @@ ${n(`remember`,"| `lesson-learned` | Extract engineering principles from complet
 
 ${r(`- **Test coverage gaps**: Areas that couldn't be fully tested and why
 - **Quality findings**: Issues found during verification and their resolutions
-- **Session checkpoint**: Summarize what was accomplished, decisions made, and any remaining work`)}
-`}],"aikit-basic":[{file:`README.md`,content:"# aikit:basic — Quick Development Flow\n\nQuick development flow for **bug fixes, small features, and refactoring**.\n\n## Steps\n\n| # | Step | Skill | Produces | Requires | Agents |\n|---|------|-------|----------|----------|--------|\n| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |\n| 2 | **Assessment** | `steps/assess/README.md` | `assessment.md` | `design-decisions.md` | Explorer, Researcher-Alpha |\n| 3 | **Implementation** | `steps/implement/README.md` | `progress.md` | `assessment.md` | Implementer, Frontend |\n| 4 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha, Security |\n\n## How It Works\n\nEach step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow({ action: 'read' })` and delegates work accordingly.\n\n### Step 1: Design Gate\n- **Auto-skips** for bug fixes and refactors (produces a minimal `design-decisions.md` noting it was skipped)\n- For small features: runs quick brainstorming, FORGE classification, and optional decision protocol (see Orchestrator's inlined Multi-Model Decision Protocol for the full 3-phase process)\n- Read `steps/design/README.md` for the full decision tree\n\n### Step 2: Assessment\n- Explore the codebase to understand scope and impact\n- Use `search`, `scope_map`, `file_summary`, `compact` to gather context\n- Identify the approach and produce `assessment.md`\n\n### Step 3: Implementation\n- Write code following the assessment plan\n- The Orchestrator dispatches Implementer/Frontend agents with specific file scopes\n- Follow TDD practices where applicable\n\n### Step 4: Verification\n- Code review, test execution, security check\n- Run `check({})` + `test_run({})` + `blast_radius({})`\n- Produce `verify-report.md` with findings\n\n## Using Skills Inside Steps\n\nWhen the Orchestrator activates a step:\n\n1. **Read the instruction first** — `flow({ action: 'read' })` returns the README.md for the current step\n2. **Follow step instructions** — the README.md is the primary guide for what to do\n3. **Delegate to listed agents** — each step lists which agents are appropriate\n4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory\n5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist\n6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator\n\n## Artifacts\n\nAll artifacts are stored in the run directory under `.flows/{topic}/`. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.\n"},{file:`steps/assess/README.md`,content:`---
+- **Session checkpoint**: What was accomplished, decisions made, remaining work`)}
+`}],"aikit-basic":[{file:`README.md`,content:"# aikit:basic — Quick Development Flow\n\nQuick development flow for **bug fixes, small features, and refactoring**.\n\n## Steps\n\n| # | Step | Skill | Produces | Requires | Agents |\n|---|------|-------|----------|----------|--------|\n| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |\n| 2 | **Assessment** | `steps/assess/README.md` | `assessment.md` | `design-decisions.md` | Explorer, Researcher-Alpha |\n| 3 | **Implementation** | `steps/implement/README.md` | `progress.md` | `assessment.md` | Implementer, Frontend |\n| 4 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha, Security |\n\n## How It Works\n\nEach step has a **README.md**. Orchestrator reads it via `flow({ action: 'read' })` and delegates work.\n\n### Step 1: Design Gate\n- **Auto-skips** for bug fixes and refactors (produces minimal `design-decisions.md` noting the skip)\n- For small features: runs quick brainstorming, FORGE classification, and optional decision protocol\n- Read `steps/design/README.md` for the full decision tree\n\n### Step 2: Assessment\n- Explore the codebase to understand scope and impact\n- Use `search`, `scope_map`, `file_summary`, `compact` to gather context\n- Identify the approach and produce `assessment.md`\n\n### Step 3: Implementation\n- Write code following the assessment plan\n- The Orchestrator dispatches Implementer/Frontend agents with specific file scopes\n- Follow TDD practices where applicable\n\n### Step 4: Verification\n- Code review, test execution, security check\n- Run `check({})` + `test_run({})` + `blast_radius({})`\n- Produce `verify-report.md` with findings\n\n## Using Skills Inside Steps\n\nWhen the Orchestrator activates a step:\n\n1. **Read the instruction first** — `flow({ action: 'read' })` returns the current step README.md\n2. **Follow step instructions** — primary guide\n3. **Delegate to listed agents** — each step lists which agents are appropriate\n4. **Produce the required artifact** — the step's `produces` field specifies the artifact file\n5. **Check dependencies** — required prior artifacts must exist\n6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator\n\n## Artifacts\n\nArtifacts are stored under `.flows/{topic}/`. `{{artifacts_path}}` resolves at runtime.\n"},{file:`steps/assess/README.md`,content:`---
 name: assess
-description: Understand scope, analyze the codebase, and identify the implementation approach.
+description: Understand scope, analyze the codebase, and identify the approach.
 ---
 
 # Assessment
 
 ## Purpose
 
-Analyze the task requirements and codebase to produce a clear, actionable assessment before any code changes begin.
+Analyze task requirements and codebase to produce a clear, actionable assessment before code changes begin.
 
 ## Inputs
 
 - User's task description or issue reference
-- Codebase (accessed via aikit MCP tools)
+- Codebase (via aikit MCP tools)
 
 ## Prerequisites Check
 
@@ -1004,10 +1070,10 @@ Before executing this step, verify:
 - [ ] FORGE classification determined (tier assigned)
 - [ ] If brainstorming was done, session outcomes are recorded
 
-If any prerequisites are missing or incomplete:
+If prerequisites are missing or incomplete:
 1. Inform the Orchestrator with specifics about what's missing
 2. Recommend \`flow({ action: 'step', advance: 'redo' })\` on the **design** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
+3. Do NOT proceed with partial inputs
 
 ### Requirements Input (if available)
 
@@ -1020,16 +1086,16 @@ If no requirements.md exists (Design Gate was auto-skipped for bug fix/refactor)
 
 ## Process
 
-1. **Parse the goal** — Extract what needs to change, success criteria, and constraints
-2. **Search for prior work** — \`search({ query: "<task keywords>" })\` to check for existing decisions or related code
+1. **Parse the goal** — extract what needs to change, success criteria, constraints
+2. **Search for prior work** — \`search({ query: "<task keywords>" })\` for existing decisions or related code
 3. **Map affected scope** — \`scope_map({ task: "<description>" })\` to identify files and modules involved
 4. **Analyze structure** — \`file_summary()\` on each affected file; \`compact()\` for deeper sections
-5. **Identify risks** — Note dependencies, breaking change potential, test coverage gaps
-6. **Draft approach** — Outline the implementation strategy in 3–7 steps
+5. **Identify risks** — note deps, breaking-change potential, test gaps
+6. **Draft approach** — outline implementation strategy in 3–7 steps
 
 ## Outputs
 
-Write \`{{artifacts_path}}/assessment.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/assessment.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -1056,12 +1122,12 @@ Template:
 
 | Agent | Role |
 |-------|------|
-| **Explorer** | Rapid file discovery, dependency tracing, structural context |
-| **Researcher-Alpha** | Deep analysis of complex logic, prior decisions, architectural implications |
+| **Explorer** | File discovery, dependency tracing, structural context |
+| **Researcher-Alpha** | Complex logic, prior decisions, architecture |
 
-Use Explorer first for breadth, then Researcher-Alpha for depth on complex areas.
+Use Explorer first for breadth, then Researcher-Alpha for depth.
 
-${n(`remember`,"| `c4-architecture` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during assessment |\n| `adr-skill` | Architecture Decision Records — create, review, maintain ADRs | When assessment reveals non-trivial design decisions |")}
+${n(`remember`,"| `c4-architecture` | C4 diagrams — system context, container, component, deployment | When visualizing system structure during assessment |\n| `adr-skill` | ADRs — create, review, maintain | When assessment reveals non-trivial design decisions |")}
 
 ## Completion Criteria
 
@@ -1071,22 +1137,22 @@ ${n(`remember`,"| `c4-architecture` | C4 model architecture diagrams — system
 - [ ] No unresolved open questions that block implementation
 - [ ] \`{{artifacts_path}}/assessment.md\` written
 
-${r(`- **Codebase discoveries**: File locations, architecture patterns, or dependency relationships found during assessment
-- **Problem diagnosis**: Root cause analysis, contributing factors, and affected components
-- **Scope decisions**: What's in scope, what's explicitly excluded, and why`)}
+${r(`- **Codebase discoveries**: File locations, patterns, or dependency relationships found during assessment
+- **Problem diagnosis**: Root cause, contributing factors, affected components
+- **Scope decisions**: What's in scope, what's excluded, and why`)}
 `},{file:`steps/design/README.md`,content:`# Design Gate — Basic Flow
 
-Lightweight design gate for bug fixes, small features, and refactoring. Evaluates the task type and determines whether design work is needed before proceeding.
+Lightweight design gate for bug fixes, small features, and refactoring. Evaluates task type and whether design work is needed.
 
 ## When This Step Runs
 
-This is the **first step** of the \`aikit:basic\` flow. It runs before assessment.
+First step of \`aikit:basic\`. Runs before assessment.
 
 ## Instructions
 
 ### 1. Task Classification
 
-Classify the task into one of these categories:
+Classify the task:
 
 | Category | Indicators | Action |
 |----------|-----------|--------|
@@ -1101,8 +1167,8 @@ Classify the task into one of these categories:
 - **Design gate**: Auto-skipped — no design work needed
 - **Proceed to**: Assessment
 \`\`\`
-**You MUST create this file on disk** at the exact \`{{artifacts_path}}/design-decisions.md\` path — do not just present the content in chat.
-Then report \`DONE\` to the Orchestrator so the flow advances.
+**You MUST create this file on disk** at the exact \`{{artifacts_path}}/design-decisions.md\` path — do not only present the content in chat.
+Then report \`DONE\` to the Orchestrator.
 
 ### 2. Quick Design (Small Features Only)
 
@@ -1110,15 +1176,15 @@ For small features that need minimal design:
 
 #### For Small Features (requires design):
 
-1. **If requirements are unclear** (ambiguous scope, multiple possible interpretations, or cross-component):
+1. **If requirements are unclear** (ambiguous scope, multiple interpretations, or cross-component):
    - Load \`requirements-clarity\` skill
    - Score requirements, iterate until ≥ 90
    - Output: \`{{artifacts_path}}/requirements.md\`
 2. **If requirements are clear** (single concern, obvious scope, clear acceptance):
    - Skip requirements-clarity, proceed to Quick Design directly
 
-1. **FORGE Classify** — Run \`forge_classify({ task: "<task description>", files: [<relevant files>], root_path: "." })\` to determine complexity tier
-2. **Brainstorming** (if tier ≥ Standard) — Load the \`brainstorming\` skill and run a focused brainstorming session:
+1. **FORGE Classify** — Run \`forge_classify({ task: "<task description>", files: [<relevant files>], root_path: "." })\` to determine tier
+2. **Brainstorming** (if tier ≥ Standard) — Load \`brainstorming\` and run a focused session:
    - What is the user trying to achieve?
    - What are the constraints?
    - What is the simplest approach?
@@ -1126,7 +1192,7 @@ For small features that need minimal design:
    - **Phase 1**: Launch ALL 4 Researcher variants in parallel (Alpha/Beta/Gamma/Delta)
    - **Phase 2**: Anonymize outputs as A/B/C/D, run peer review round (4 reviewers in parallel)
    - **Phase 3**: Synthesize into structured verdict (Agrees / Clashes / Blind Spots / Recommendation / First Step)
-   - Present verdict visually using \`present({ schemaVersion: 1, title: "Decision Verdict", blocks: [...] })\`; use \`table\` for multi-approach comparisons, \`list\` for recommendations and blind spots, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data. Produce ADR for Standard+ tiers
+   - Present verdict visually using \`present({ schemaVersion: 1, title: "Decision Verdict", blocks: [...] })\`; use \`table\` for multi-approach comparisons, \`list\` for recommendations/blind spots, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data. Produce ADR for Standard+ tiers
 4. **Write \`{{artifacts_path}}/design-decisions.md\`** to disk:
 
 \`\`\`markdown
@@ -1150,13 +1216,13 @@ For small features that need minimal design:
 
 When complete, report status:
 - \`DONE\` — design decisions captured, ready for assessment
-- \`DONE_WITH_CONCERNS\` — design captured but open questions remain (list them)
+- \`DONE_WITH_CONCERNS\` — design captured but open questions remain
 
 **Do NOT call \`flow({ action: 'step', advance: 'next' })\`** — let the Orchestrator advance the flow.
 
 ## Outputs
 
-Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
+Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat. This file is a prerequisite for the next step.
 
 ## Produces
 
@@ -1164,9 +1230,9 @@ Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this
 
 ## Agents
 
-- \`Researcher-Alpha\`, \`Researcher-Beta\`, \`Researcher-Gamma\`, \`Researcher-Delta\` — for parallel research during decision protocol
+- \`Researcher-Alpha\`, \`Researcher-Beta\`, \`Researcher-Gamma\`, \`Researcher-Delta\` — parallel research during decision protocol
 
-${n(`remember`,"| `c4-architecture` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during design |\n| `adr-skill` | Architecture Decision Records — create, review, maintain ADRs | When making non-trivial design or technology decisions |")}
+${n(`remember`,"| `c4-architecture` | C4 diagrams — system context, container, component, deployment | When visualizing system structure during design |\n| `adr-skill` | ADRs — create, review, maintain | When making non-trivial design or technology decisions |")}
 
 ## Completion Criteria
 
@@ -1174,23 +1240,23 @@ ${n(`remember`,"| `c4-architecture` | C4 model architecture diagrams — system
 - [ ] FORGE tier determined (for small features)
 - [ ] Key design decisions documented
 
-${r(`- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries`)}
+${r(`- **Design decisions**: Chosen approach and rejected alternatives
+- **Architecture patterns**: New patterns or patterns that must be followed
+- **Constraints discovered**: Technical, compatibility, performance limits`)}
 `},{file:`steps/implement/README.md`,content:`---
 name: implement
-description: Write code following the assessment plan, using TDD practices where applicable.
+description: Write code following the assessment plan, using TDD where applicable.
 ---
 
 # Implementation
 
 ## Purpose
 
-Execute the implementation plan from the assessment, writing production code and tests.
+Execute the implementation plan from assessment, writing production code and tests.
 
 ## Inputs
 
-- \`{{artifacts_path}}/assessment.md\` — the approach, affected files, and risks
+- \`{{artifacts_path}}/assessment.md\` — approach, affected files, risks
 
 ## Prerequisites Check
 
@@ -1200,21 +1266,21 @@ Before executing this step, verify:
 - [ ] Files-to-modify list is clear and bounded
 - [ ] \`check({})\` baseline captured (know what currently passes)
 
-If any prerequisites are missing or incomplete:
+If prerequisites are missing or incomplete:
 1. Inform the Orchestrator with specifics about what's missing
 2. Recommend \`flow({ action: 'step', advance: 'redo' })\` on the **assess** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
+3. Do NOT proceed with partial inputs
 
 ## Process
 
-1. **Read assessment** — Load \`{{artifacts_path}}/assessment.md\` and internalize the approach
-2. **Set up tests first** — Where applicable, write failing tests that define success
-3. **Implement changes** — Follow the approach steps sequentially
-   - One logical change per commit-worthy chunk
-   - Stay within the assessed file scope — do not expand without re-assessment
+1. **Read assessment** — load \`{{artifacts_path}}/assessment.md\` and internalize the approach
+2. **Set up tests first** — where applicable, write failing tests that define success
+3. **Implement changes** — follow approach steps sequentially
+   - One logical change per chunk
+   - Stay within assessed file scope — do not expand without re-assessment
 4. **Run validation** — \`check({})\` for type/lint errors, \`test_run({})\` for test results
 5. **Fix issues** — Iterate until \`check\` and \`test_run\` pass (max 3 rounds)
-6. **Document progress** — Write progress artifact with what was done and any deviations
+6. **Document progress** — write progress artifact with what was done and deviations
 
 ## Validation Boundary (MANDATORY)
 
@@ -1232,7 +1298,7 @@ If either fails:
 
 ## Outputs
 
-Write \`{{artifacts_path}}/progress.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/progress.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -1260,12 +1326,12 @@ Template:
 
 | Agent | Role |
 |-------|------|
-| **Implementer** | Primary code writer — follows TDD, writes production code and tests |
-| **Frontend** | UI/UX specialist — use when changes involve React components, styling, or responsive design |
+| **Implementer** | TDD, production code, tests |
+| **Frontend** | React, styling, responsive design |
 
-Dispatch Implementer for backend/logic changes, Frontend for UI changes. Both can run in parallel if working on different files.
+Dispatch Implementer for backend/logic changes, Frontend for UI changes. They can run in parallel on different files.
 
-${n(`remember`,"| `session-handoff` | Context preservation for session transfers | When implementation is long-running and context may fill up |",e)}
+${n(`remember`,"| `session-handoff` | Context preservation for session transfers | When implementation is long-running or context may fill up |",e)}
 
 ## Completion Criteria
 
@@ -1275,9 +1341,9 @@ ${n(`remember`,"| `session-handoff` | Context preservation for session transfers
 - [ ] No files modified outside assessed scope
 - [ ] \`{{artifacts_path}}/progress.md\` written
 
-${r(`- **Implementation decisions**: Why specific approaches were chosen over alternatives
-- **Patterns established**: New conventions or patterns that future code should follow
-- **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during implementation`)}
+${r(`- **Implementation decisions**: Why specific approaches were chosen
+- **Patterns established**: New conventions or patterns to follow
+- **Gotchas encountered**: Edge cases, workarounds, non-obvious behaviors`)}
 `},{file:`steps/verify/README.md`,content:`---
 name: verify
 description: Review code changes, run tests, validate correctness and quality.
@@ -1287,12 +1353,12 @@ description: Review code changes, run tests, validate correctness and quality.
 
 ## Purpose
 
-Validate that the implementation meets the original requirements, passes all quality gates, and introduces no regressions.
+Validate that implementation meets requirements, passes quality gates, and introduces no regressions.
 
 ## Inputs
 
 - \`{{artifacts_path}}/assessment.md\` — original requirements and approach
-- \`{{artifacts_path}}/progress.md\` — what was implemented and any deviations
+- \`{{artifacts_path}}/progress.md\` — implemented changes and deviations
 
 ## Prerequisites Check
 
@@ -1302,27 +1368,27 @@ Before executing this step, verify:
 - [ ] \`check({})\` + \`test_run({})\` pass at baseline
 - [ ] Changed files list is available for blast radius analysis
 
-If any prerequisites are missing or incomplete:
+If prerequisites are missing or incomplete:
 1. Inform the Orchestrator with specifics about what's missing
 2. Recommend \`flow({ action: 'step', advance: 'redo' })\` on the **implement** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
+3. Do NOT proceed with partial inputs
 
 ## Process
 
-1. **Load context** — Read assessment and progress artifacts
-2. **Code review** — Review all changed files for:
+1. **Load context** — read assessment and progress artifacts
+2. **Code review** — review changed files for:
    - Correctness against requirements
-   - Code quality and adherence to project conventions
+   - Code quality and project conventions
    - Error handling and edge cases
    - No unnecessary changes (scope creep)
 3. **Run quality gates** — \`check({})\` + \`test_run({})\` must pass
 4. **Blast radius** — \`blast_radius({ path: ".", files: [...] })\` to assess impact
 5. **Security scan** — Check for OWASP Top 10 issues in changed code
-6. **Write report** — Document findings with PASS/FAIL verdict
+6. **Write report** — document findings with PASS/FAIL verdict
 
 ## Outputs
 
-Write \`{{artifacts_path}}/verify-report.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not just present content in chat.
+Write \`{{artifacts_path}}/verify-report.md\` to disk. **You MUST create this file** using the IDE's native file creation capability or equivalent — do not only present content in chat.
 
 Template:
 
@@ -1350,12 +1416,12 @@ Template:
 
 | Agent | Role |
 |-------|------|
-| **Code-Reviewer-Alpha** | Primary code reviewer — correctness, quality, conventions |
-| **Security** | Security specialist — vulnerability analysis, OWASP compliance |
+| **Code-Reviewer-Alpha** | Correctness, quality, conventions |
+| **Security** | Vulnerability analysis, OWASP compliance |
 
 Run both in parallel — they review different aspects of the same changes.
 
-${n(`remember`,"| `lesson-learned` | Extract engineering lessons from completed work via git history | After verification completes — capture principles from what was built |\n| `session-handoff` | Context preservation for session transfers | When verification is the final step and session context should be saved |",t)}
+${n(`remember`,"| `lesson-learned` | Extract engineering lessons from completed work via git history | After verification completes — capture principles from what was built |\n| `session-handoff` | Context preservation for session transfers | When verification is final step and session context should be saved |",t)}
 
 ## Completion Criteria
 
@@ -1368,5 +1434,5 @@ ${n(`remember`,"| `lesson-learned` | Extract engineering lessons from completed
 
 ${r(`- **Test coverage gaps**: Areas that couldn't be fully tested and why
 - **Quality findings**: Issues found during verification and their resolutions
-- **Session checkpoint**: Summarize what was accomplished, decisions made, and any remaining work`)}
+- **Session checkpoint**: What was accomplished, decisions made, remaining work`)}
 `}]};export{i as FLOWS};