const e={ask:{description:`Quick research question — find answer using AI Kit + web search`,agent:`Researcher-Alpha`,tools:[`search`,`web_search`,`web_fetch`,`compact`,`file_summary`,`knowledge`,`present`],content:`## Quick Research

1. **AI Kit Recall** — Search the AI Kit index for existing answers
2. **Web Search** — If AI Kit has no relevant results, search the web
3. **Synthesize** — Combine findings into a clear, concise answer
4. **Remember** — If the answer is broadly useful, persist it with \`knowledge({ action: "remember", ... })\`

**Always cite sources** — AI Kit entries, file paths, or URLs.`},debug:{description:`Systematic error diagnosis: reproduce → trace → diagnose → fix → verify`,agent:`Debugger`,tools:[`search`,`symbol`,`trace`,`blast_radius`,`check`,`test_run`,`parse_output`,`compact`,`knowledge`,`present`],content:'## Debug Workflow\n\n1. **Parse Error** — Use `parse_output` on the error message/stack trace\n2. **AI Kit Recall** — Search for known issues matching this pattern\n3. **Reproduce** — Run the failing command/test to confirm\n4. **Trace** — Use `symbol` and `trace` to follow the call chain\n5. **Diagnose** — Form hypothesis, gather evidence\n6. **Fix** — Implement minimal fix\n7. **Verify** — `check` + `test_run` to confirm fix and no regressions\n8. **Remember** — Persist the fix with `knowledge({ action: "remember", category: "troubleshooting", ... })`'},implement:{description:`Full lifecycle implementation: plan → build → review → commit`,agent:`Orchestrator`,tools:[`search`,`scope_map`,`forge_ground`,`check`,`test_run`,`blast_radius`,`knowledge`,`audit`,`present`],content:`## Implementation Pipeline

Follow the Orchestrator's full workflow:

1. **Phase 0: Design Gate** — Orchestrator checks if design is needed. Creative/additive work triggers brainstorming first. Use \`/design\` if you want to start with design explicitly.
2. **Phase 1: Planning** — Research, draft plan, present to user for approval
3. **Phase 2: Implementation** — Execute phases in parallel batches
4. **Phase 3: Completion** — Final review, docs, persist learnings

**🛑 MANDATORY STOPS** — After plan, after each batch, after completion.

Refer to the Orchestrator agent's full instructions for the detailed workflow.`},plan:{description:`Create a detailed TDD implementation plan without executing it`,agent:`Planner`,tools:[`search`,`scope_map`,`forge_ground`,`forge_classify`,`file_summary`,`analyze`,`knowledge`,`present`],content:`## Planning Workflow

1. **AI Kit Recall** — Search for past plans, architecture decisions
2. **FORGE Ground** — Classify tier, scope map, seed unknowns
3. **Research** — Explore codebase, understand subsystems
4. **Draft Plan** — 3-10 phases with agent assignments, TDD steps
5. **Dependency Graph** — Group into parallel batches
6. **Present** — Show plan with open questions

**🛑 MANDATORY STOP** — Wait for user approval. Do NOT implement.`},design:{description:`Collaborative design session — explore ideas, refine requirements, produce a design spec`,agent:`Orchestrator`,tools:[`search`,`scope_map`,`file_summary`,`compact`,`knowledge`,`forge_classify`,`present`],content:`## Design Session

Enter Phase 0 (Design Gate) directly — the user is requesting a design session.

1. **Invoke the brainstorming skill** — interactive design dialogue with user
2. Follow the skill's full process (auto-selects Simple or Advanced mode)
3. If Advanced Mode, use the full Multi-Model Decision Protocol (3-phase: research → peer review → verdict, defined in Orchestrator instructions) for unresolved technical choices
4. Terminal state: brainstorming skill invokes writing-plans skill

**🛑 HARD GATE** — Do NOT skip brainstorming. Do NOT write code. Design first.`},review:{description:`Dual-model code + architecture review pipeline`,agent:`Orchestrator`,tools:[`search`,`blast_radius`,`check`,`test_run`,`analyze`,`knowledge`,`present`],content:`## Review Pipeline

### Step 1: Scope
Identify changed files and their blast radius.

### Step 2: Code Review (parallel)
Launch Code-Reviewer-Alpha and Code-Reviewer-Beta on the same changeset.

### Step 3: Architecture Review (if needed)
If changes cross service boundaries or modify interfaces, launch Architect-Reviewer-Alpha and Architect-Reviewer-Beta.

### Step 4: Synthesis
Merge findings from both reviewers:
- **Agreements**: Both found same issue → HIGH confidence
- **Unique findings**: One found, other didn't → verify
- **Disagreements**: Contradicting verdicts → present both to user

### Step 5: Report
Present unified review with: verdict, findings by severity, recommended actions.`},"flow-add":{description:`Install a new flow from a git URL or local path — with interactive error recovery`,agent:`Orchestrator`,tools:[`flow`,`search`,`compact`,`file_summary`,`present`],content:`## Flow Installation Assistant

Install a development flow from a git repository or local directory.

### Usage
Provide a git URL or local path:
- \`https://github.com/org/my-flow.git\`
- \`git@github.com:org/my-flow.git\`
- \`./path/to/local/flow\`
- \`C:\\Users\\name\\flows\\my-flow\`

### Workflow

1. **Attempt Install** — Call \`flow({ action: 'add', source })\` with the provided source
2. **On Success** — Show installed flow info with \`flow({ action: 'info', name })\`, present summary to user
3. **On Failure** — Classify the error and enter the appropriate recovery path:

### Error Recovery Paths

#### Git Authentication Failure
If the error mentions authentication, credentials, 401, 403, permission denied, or SAML:

1. Present the error clearly to the user
2. Ask which auth method they prefer:
   - **SSH key**: Walk through \`ssh-keygen -t ed25519\`, adding the public key to their git host, and retrying with the SSH URL
   - **Personal Access Token (PAT)**: Guide them to create a PAT in their git host settings, configure \`git credential.helper store\`, and retry
   - **Git Credential Manager**: Check if GCM is installed, help install if needed, then retry (GCM opens a browser for auth)
3. After credentials are configured, retry \`flow({ action: 'add', source })\`

#### Network / Connectivity Failure
If the error mentions timeout, host not found, SSL, or proxy:

1. Present diagnostics: Is VPN needed? Is the URL correct? Is there a proxy?
2. Guide the user through resolution
3. Retry after the issue is resolved

#### Format Not Recognized
If \`flow({ action: 'add', source })\` succeeds cloning but returns a format/structure error:

1. Explain that the source was fetched but doesn't match any supported format
2. List the 3 supported formats:
   - **Native**: Has a \`flow.json\` manifest in the root
   - **Claude Plugin**: Has \`.claude-plugin/plugin.json\` with skills as steps
   - **Copilot Agents**: Has \`.github/agents/\` with agent .md files as steps
3. Analyze the source structure to understand what's there
4. Offer to help migrate:
   - If it has README files or markdown docs → propose creating a \`flow.json\` that maps them as steps
   - If it has a different workflow format → propose conversion
   - If it's missing key parts → guide user to fill them in
5. Create the missing \`flow.json\` manifest and step structure
6. Retry \`flow({ action: 'add', source })\` with the fixed source

### Native flow.json Format Reference
\`\`\`json
{
  "name": "my-flow",
  "version": "1.0.0",
  "description": "Description of the flow",
  "steps": [
    {
      "id": "step-id",
      "name": "Step Name",
      "instruction": "steps/step-id/README.md",
      "produces": ["output.md"],
      "requires": [],
      "agents": [],
      "description": "What this step does"
    }
  ],
  "agents": [],
  "artifacts_dir": ".spec",
  "install": []
}
\`\`\`

### Post-Install
After successful installation:
- Show the flow name, steps, and description via \`present\`
- Remind user they can start it with \`flow({ action: 'start', name, topic })\``},"flow-manage":{description:`List, inspect, update, and remove installed flows`,agent:`Orchestrator`,tools:[`flow`,`present`],content:`## Flow Management

Manage your installed development flows.

### Available Actions

1. **List flows** — \`flow({ action: 'list' })\` to see all installed flows with status
2. **Inspect a flow** — \`flow({ action: 'info', name })\` to see detailed steps, agents, and artifacts
3. **Check status** — \`flow({ action: 'status' })\` to see the active flow and current step
4. **Update a flow** — \`flow({ action: 'update', name })\` to pull latest changes for git-installed flows
5. **Remove a flow** — \`flow({ action: 'remove', name })\` to uninstall (builtin flows cannot be removed)
6. **Start a flow** — \`flow({ action: 'start', name, topic })\` to begin executing a flow
7. **Reset active flow** — \`flow({ action: 'reset' })\` to clear active flow state

### Workflow
1. If no specific action requested, start with \`flow({ action: 'list' })\` and present overview
2. Use \`present\` to display flow information in a clear table/card format
3. For updates, warn if there's an active flow that might be affected
4. For removals, confirm with user before proceeding`},"flow-create":{description:`Create a new flow from scratch or migrate an existing workflow to aikit format`,agent:`Orchestrator`,tools:[`flow`,`search`,`compact`,`file_summary`,`present`],content:`## Flow Creation Assistant

Create a new development flow or migrate an existing workflow to the aikit flow format.

### Mode 1: Create from Scratch

Guide the user through building a complete flow:

1. **Define the workflow** — Ask what the flow should accomplish (e.g., "TDD workflow", "documentation pipeline", "migration process")
2. **Design steps** — Break the workflow into sequential steps (3-8 is ideal)
3. **For each step**:
   - Define the step id, name, and description
   - Write the instruction (README.md content — what the agent should do)
   - Identify what it produces (output artifacts)
   - Identify what it requires (which previous steps must complete first)
   - Optionally assign preferred agents
4. **Generate flow.json** — Create the manifest with all steps
5. **Write step READMEs** — Create instruction files for each step
6. **Install** — Use \`flow({ action: 'add', source })\` to install from the local directory

### Mode 2: Migrate Existing Workflow

If the user has an existing workflow (scripts, docs, runbooks) that they want to convert:

1. **Analyze the source** — Read the existing workflow files to understand the process
2. **Map to steps** — Identify discrete steps with clear inputs/outputs
3. **Identify gaps** — What's missing for a complete flow? (instructions? ordering? agents?)
4. **Fill gaps with user** — Ask user to clarify any ambiguous parts
5. **Generate the flow** — Create flow.json + step READMEs
6. **Install and validate** — Use \`flow({ action: 'add', source })\` and \`flow({ action: 'info', name })\` to verify

### Flow Structure

\`\`\`
my-flow/
  flow.json              — Flow manifest (name, version, steps, agents)
  steps/
    step-1/
      README.md          — Step instructions (what the agent should do)
    step-2/
      README.md
      references/        — Optional reference files for the step
    ...
\`\`\`

### flow.json Format
\`\`\`json
{
  "name": "my-flow",
  "version": "1.0.0",
  "description": "What this flow does",
  "steps": [
    {
      "id": "step-id",
      "name": "Human-readable Step Name",
      "instruction": "steps/step-id/README.md",
      "produces": ["artifact-name.md"],
      "requires": [],
      "agents": ["Preferred-Agent"],
      "description": "Brief description of this step"
    }
  ],
  "agents": [],
  "artifacts_dir": ".spec",
  "install": []
}
\`\`\`

### Step README Format
Each step README should include:
- **Goal** — What this step accomplishes
- **Inputs** — What context/artifacts from prior steps are needed
- **Instructions** — Detailed steps for the agent to follow
- **Output** — What artifact(s) to produce and where to save them
- **Acceptance criteria** — How to know the step is complete`},docs:{description:`Deep codebase understanding — analyze, learn, document, and visualize the entire project as an interactive knowledge graph`,agent:`Orchestrator`,tools:[`onboard`,`analyze`,`audit`,`produce_knowledge`,`graph`,`measure`,`blast_radius`,`search`,`symbol`,`trace`,`dead_symbols`,`file_summary`,`compact`,`digest`,`knowledge`,`present`,`check`,`test_run`,`git_context`],content:`## Understand & Document — Full Codebase Intelligence

Turn this codebase into a deeply understood, richly documented, and visually explorable project.
"Understand Anything" philosophy: **graphs that teach > graphs that impress.**

This is NOT just documentation generation — it is a full **analyze → understand → learn → document → present** pipeline.

### Phase 1: Deep Scan (parallel analysis)

Run all analysis tools in parallel to build a comprehensive baseline:

1. **Onboard** — \`onboard({ path: "." })\` if not already done (check \`status()\` first)
2. **Structure** — \`analyze({ aspect: "structure", path: "." })\`
3. **Dependencies** — \`analyze({ aspect: "dependencies", path: "." })\`
4. **Symbols** — \`analyze({ aspect: "symbols", path: "." })\`
5. **Patterns** — \`analyze({ aspect: "patterns", path: "." })\`
6. **Entry Points** — \`analyze({ aspect: "entry_points", path: "." })\`
7. **Diagrams** — \`analyze({ aspect: "diagram", path: "." })\`
8. **Health Audit** — \`audit({ path: "." })\`
9. **Complexity** — \`measure({ path: "." })\`
10. **Git Context** — \`git_context({ include_diff: true })\`
11. **Dead Symbols** — \`dead_symbols({ path: "." })\`

Stash all results for later phases.

### Phase 2: Knowledge Graph Construction

Build a navigable knowledge graph of the codebase:

1. **Discover modules** — \`graph({ action: 'find_nodes' })\` to get all indexed modules
2. **Map relationships** — For key modules, \`graph({ action: 'neighbors', node_id, direction: 'both' })\`
3. **Trace critical paths** — Use \`trace({ start: "<entry-point>", direction: "forward" })\` on each entry point
4. **Identify layers** — Classify modules into architectural layers (API, Service, Domain, Data, Infrastructure, UI, Utility, Config)
5. **Detect communities** — \`graph({ action: 'detect_communities' })\` to find natural module clusters
6. **Symbol deep-dive** — For each public API/export, \`symbol({ name })\` to understand usage

Persist the graph structure and layer classification.

### Phase 3: Multi-Agent Understanding (parallel dispatch)

Dispatch Researcher agents **in parallel** to deeply understand different aspects:

**Researcher-Alpha** — Architecture & Design Patterns:
- What architectural style is used? (layered, hexagonal, microservice, monolith)
- What design patterns appear? (repository, factory, strategy, observer, etc.)
- How is data flow organized? (request lifecycle, event pipeline, etc.)

**Researcher-Beta** — Business Logic & Domain:
- What are the core business domains/bounded contexts?
- What are the key business flows and processes?
- What domain entities and value objects exist?
- How is business logic separated from infrastructure?

**Researcher-Gamma** — Integration & Infrastructure:
- What external services, APIs, databases are used?
- How is authentication/authorization handled?
- What is the deployment topology?
- What monitoring, logging, observability exists?

**Researcher-Delta** — Quality & Concerns:
- What is the test coverage strategy?
- What tech debt or code smells exist?
- What security concerns should be noted?
- What performance bottlenecks are visible?
- What are the highest-complexity files?

### Phase 4: Document Everything

Load the \`docs\` skill and generate comprehensive documentation:

1. **Project Knowledge** (7 architecture docs):
   - \`docs/architecture/stack.md\` — Language, runtime, frameworks, all dependencies
   - \`docs/architecture/structure.md\` — Directory layout, entry points, key files
   - \`docs/architecture/design.md\` — Layers, patterns, data flow, component boundaries
   - \`docs/architecture/conventions.md\` — Naming, formatting, error handling, imports
   - \`docs/architecture/integrations.md\` — External APIs, databases, auth, monitoring
   - \`docs/architecture/testing.md\` — Test frameworks, file organization, mocking
   - \`docs/architecture/concerns.md\` — Tech debt, security risks, performance issues

2. **Component Docs** — For each major module/component:
   - \`docs/architecture/components/{name}.md\` — Purpose, API, design decisions, data flow

3. **Reference Docs**:
   - \`docs/reference/api.md\` — API surface, endpoints, schemas
   - \`docs/reference/configuration.md\` — Config options, environment variables

4. **Guides**:
   - \`docs/guides/onboarding.md\` — Guided tour for new developers (dependency-ordered walkthrough)
   - \`docs/guides/architecture-tour.md\` — Visual architecture walkthrough

5. **Project Overview**:
   - \`docs/README.md\` — Index linking all docs, project summary

6. **Persist Knowledge** — \`produce_knowledge({ path: "." })\` + \`knowledge({ action: "remember", ... })\` for key findings

7. **AGENTS.md** — Generate an agent-friendly project context file at the repo root:
   - Project overview, architecture style, key modules
   - Build/test/run commands
   - Coding conventions and patterns in use
   - Key entry points and data flows
   - Known concerns and tech debt

> **Interactive HTML viewers** (C4 diagrams, code tour walkthroughs) are generated by the \`/aikit-docs-site\` command. Use it after this command to produce interactive explorable documentation.

### Phase 5: Interactive Presentation

Present the understanding as a rich interactive dashboard using \`present\`:

1. **Architecture Overview** — Mermaid diagram of system layers and component relationships
2. **Dependency Graph** — Module dependency visualization
3. **Metrics Dashboard** — File count, complexity distribution, test coverage, health score
4. **Knowledge Map** — Key modules with descriptions, organized by architectural layer
5. **Guided Tour** — Recommended reading order for codebase onboarding
6. **Concerns Board** — Tech debt, dead code, security risks as a status board
7. **Business Domain Map** — Domain entities and their relationships

Use the \`c4-architecture\` skill for generating proper C4 architecture diagrams (Context, Container, Component levels).

### Output Summary

After all phases complete, present a final summary to the user:
- Total files analyzed, modules discovered, patterns detected
- Architecture style and key design decisions identified
- Number of docs generated and their locations
- Top concerns and recommendations
- Links to the interactive dashboard

### Rules

- **Every claim must be traceable** to source files or tool output
- **Never infer or assume** — only document what is verifiable
- **Mark unknowns** with \`[TODO]\` and intent-dependent decisions with \`[ASK USER]\`
- **Delegate to specialists**: architecture diagrams → \`c4-architecture\` skill, ADRs → \`adr-skill\`
- **Compress between phases** — use \`digest\` and \`stash\` to manage context
- **🛑 STOP after Phase 5** — present results and ask user for feedback before any follow-up work`},"docs-site":{description:`Generate interactive HTML documentation — C4 architecture viewers and code tour walkthroughs with browser verification`,agent:`Orchestrator`,tools:[`onboard`,`analyze`,`produce_knowledge`,`graph`,`search`,`symbol`,`trace`,`file_summary`,`compact`,`digest`,`knowledge`,`browser`,`present`,`check`,`git_context`,`measure`],content:`## Generate Interactive Documentation Viewers

Create interactive HTML documentation using C4 architecture viewers and code tour walkthroughs.

> **Prerequisite:** Run \`/aikit-docs\` first to generate the base markdown documentation and AGENTS.md.

### Phase 1: Analyze Project

\`\`\`
onboard({ path: "." })                           # If not done (check status() first)
analyze({ aspect: "structure", path: "." })      # Directory layout
analyze({ aspect: "dependencies", path: "." })   # Module graph
analyze({ aspect: "entry_points", path: "." })   # API surface
analyze({ aspect: "diagram", path: "." })        # Architecture diagram data
graph({ action: "find_nodes" })                  # Module graph for C4 mapping
graph({ action: "detect_communities" })          # Natural module clusters
\`\`\`

Stash results for use in subsequent phases.

### Phase 2: Generate C4 Architecture Data

Create C4 JSON data files for each architectural level. Save to \`docs/architecture/interactive/\`.

**Required schema — MUST match exactly:**

\`\`\`json
{
  "title": "Project Name - C4 Level",
  "description": "What this diagram shows",
  "layout": { "direction": "DOWN", "spacing": 80, "layerSpacing": 120 },
  "nodes": [
    {
      "id": "unique-string-id",
      "type": "person|system|container|component|database|queue|external",
      "label": "Display Name",
      "description": "What this element does",
      "technology": "Language/framework",
      "parentId": "optional-boundary-id"
    }
  ],
  "edges": [
    {
      "id": "unique-edge-id",
      "source": "source-node-id",
      "target": "target-node-id",
      "label": "Relationship description",
      "technology": "Protocol/transport"
    }
  ]
}
\`\`\`

**C4 levels to generate:**
1. \`system-context.json\` — External actors + the system as a black box
2. \`containers.json\` — Major deployable units (services, databases, frontends)
3. \`{component-name}-components.json\` — Internal structure of key containers

**Critical rules:**
- Top-level keys are \`nodes\` and \`edges\` (NOT \`elements\`/\`relationships\`)
- Every edge MUST have a unique \`id\` field (ELK crashes without it)
- Node \`type\` MUST be one of: person, system, container, component, database, queue, external
- \`layout.direction\` MUST be: DOWN, UP, LEFT, or RIGHT
- \`parentId\` references must point to existing node IDs (or omit entirely)

### Phase 3: Generate Tour Data

Create code tour JSON files. Save to \`docs/tours/interactive/\`.

**Required schema — MUST match exactly:**

\`\`\`json
{
  "title": "Tour Title",
  "description": "What this tour teaches",
  "estimatedTime": "15 min",
  "steps": [
    {
      "stepNumber": 1,
      "id": "kebab-case-step-id",
      "title": "Step Title",
      "file": "relative/path/to/file.ts",
      "line": 42,
      "explanation": "What this code does and why it matters",
      "learnsConcept": "Concept name",
      "duration": "2 min",
      "notes": "Optional additional context"
    }
  ],
  "dependencies": [
    { "source": "step-id-1", "target": "step-id-2" }
  ]
}
\`\`\`

**Tours to generate:**
1. \`architecture-overview.json\` — High-level system walkthrough (entry points → core logic → outputs)
2. \`onboarding.json\` — New developer guided tour (most important files in dependency order)
3. Additional tours for complex subsystems with >5 modules

**Critical rules:**
- Step content field is \`explanation\` (NOT \`description\`)
- Every step needs \`id\` (kebab-case) and \`stepNumber\` (integer, 1-based)
- \`learnsConcept\` is the concept tag (NOT \`highlights\`)
- \`dependencies\` array uses step \`id\` values in \`{source, target}\` objects
- Root MUST have \`title\`, \`description\`, \`estimatedTime\`

### Phase 4: Inject Data into HTML Templates

Use PowerShell to inject JSON data into the viewer template HTML files.

**Template locations:**
- C4 viewer: \`C:\\Users\\AnVPX\\.copilot\\skills\\c4-architecture\\assets\\c4-viewer.html\` (tag: \`id="diagram-data"\`)
- Tour viewer: \`C:\\Users\\AnVPX\\.copilot\\skills\\docs\\assets\\tour-viewer.html\` (tag: \`id="tour-data"\`)

**Injection procedure (for EACH JSON file):**

\`\`\`powershell
$template = [System.IO.File]::ReadAllText("TEMPLATE_PATH")
$startTag = '<script type="application/json" id="TARGET_ID">'
$startIdx = $template.IndexOf($startTag)
if ($startIdx -lt 0) { throw "Tag not found" }
$contentStart = $startIdx + $startTag.Length
$endIdx = $template.IndexOf('<\/script>', $contentStart)

$before = $template.Substring(0, $contentStart)
$after = $template.Substring($endIdx)
$data = Get-Content "JSON_PATH" -Raw

$output = $before + [char]10 + $data + [char]10 + $after
[System.IO.File]::WriteAllText("OUTPUT_PATH", $output, [System.Text.Encoding]::UTF8)
\`\`\`

**Output file layout:**
\`\`\`
docs/
  architecture/interactive/
    system-context.json        # Data
    system-context.html        # Injected viewer (from c4-viewer.html)
    containers.json
    containers.html
  tours/interactive/
    architecture-overview.json # Data
    architecture-overview.html # Injected viewer (from tour-viewer.html)
    onboarding.json
    onboarding.html
\`\`\`

**Rules:**
- JSON + HTML MUST be siblings in the same \`interactive/\` directory
- NEVER use \`inject-viewer.mjs\` — use the PowerShell procedure above
- Verify \`$startIdx -ge 0\` before proceeding

### Phase 5: Browser Verification (MANDATORY)

**Every generated HTML file MUST be tested before presenting to user.**

\`\`\`
# 1. Serve the docs folder
run_in_terminal("npx -y serve docs -l 4000 --no-clipboard", mode: "async")

# 2. Open each viewer
browser({ action: 'open', url: 'http://localhost:4000/architecture/interactive/system-context.html', mode: 'ui', waitUntil: 'networkidle' })

# 3. Read accessibility snapshot
browser({ action: 'read', pageId: '<id>', readMode: 'snapshot' })

# 4. Verify content renders:
#    C4: nodes with labels, edges, Zoom In/Out/Fit buttons, Mini Map
#    Tour: step numbers + titles, Prev/Next buttons, explanation text, file paths

# 5. If blank or errors → fix JSON schema → re-inject → re-test

# 6. Clean up
browser({ action: 'session', sessionAction: 'close', pageId: '<id>' })
kill_terminal(<serve-terminal-id>)
\`\`\`

**Verification checklist:**

| Viewer | Must see in snapshot | Failure indicator |
|--------|---------------------|-------------------|
| C4 | Node labels, edge groups, Zoom/Fit buttons, Mini Map | Empty page, "Error", no nodes |
| Tour | Step numbers + titles, Prev/Next, explanation text | Blank panel, "undefined", no steps |

### Phase 6: Present Results

After ALL viewers pass verification:

1. List all generated files (JSON + HTML) with descriptions
2. Provide the serve command: \`npx -y serve docs -l 4000 --no-clipboard\`
3. List all viewer URLs (e.g., \`http://localhost:4000/architecture/interactive/system-context.html\`)
4. Note any issues found during verification

### Critical Rules

1. **NEVER skip browser verification** — a valid JSON can still produce a broken viewer
2. **NEVER use \`file:///\` URLs** — CORS blocks ES modules; always serve via HTTP
3. **NEVER use \`inject-viewer.mjs\`** — use the PowerShell injection procedure
4. **NEVER use \`elements\`/\`relationships\`** — the ReactFlow viewer uses \`nodes\`/\`edges\`
5. **NEVER omit \`id\` on edges** — ELK layout throws null errors
6. **NEVER use \`description\` in tour steps** — template reads \`explanation\`
7. **ALWAYS use \`npx -y\`** — without \`-y\` the command hangs on install prompt
8. **ALWAYS include \`layout\` object in C4 JSON** — ELK crashes without direction/spacing
9. **ALWAYS verify \`$startIdx -ge 0\`** before injection — missing tag = wrong template
10. **All data must come from AI Kit analysis tools** — never fabricate architecture`}};export{e as PROMPTS};