opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "ADR-reviewer": {
      "description": "Reviews Architecture Decision Records for completeness, structural validity, and cross-reference integrity. Validates status transitions (proposed \u2192 accepted \u2192 superseded \u2192 deprecated). Checks that code changes comply with accepted ADRs and flags when new ADRs should be written. Backs the /hex-ADR-review skill.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_adr_list, mcp__hex__hex_adr_search, mcp__hex__hex_adr_status instead of Bash."
    },
    "adversarial-reviewer": {
      "description": "Adversarial codebase reviewer that hunts for breakage after migrations, refactors, and multi-phase feature work. Assumes nothing works until proven otherwise. Traces every deleted/modified artifact to all its consumers across the entire workspace (ADR-2026-04-05-0900).\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. Use mcp__hex__hex_git_log, mcp__hex__hex_git_diff, mcp__hex__hex_analyze for investigation. Adversarial review must grep ENTIRE workspace \u2014 not just the immediate directory \u2014 before claiming a refactor/deletion is safe."
    },
    "behavioral-spec-writer": {
      "description": "Writes behavioral specifications BEFORE code generation starts. Takes a problem description, applies domain knowledge, and outputs BehavioralSpec[] that become acceptance criteria for the validation judge. Specs describe user-facing behavior only \u2014 no implementation details, no function names, no internal state references.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_adr_search not `hex adr search` via Bash.\nSpecs must be understandable by someone who has never seen the code\nSpecs must be testable against any correct implementation"
    },
    "dead-code-analyzer": {
      "description": "Identifies dead code, unused exports, orphaned adapters, and dependency direction violations in hexagonal architecture projects. Validates that the port-adapter boundary is clean and no cross-adapter imports exist. Uses tree-sitter L1 summaries to build the full dependency graph without reading every file at L3.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze not `hex analyze` via Bash.\nOnly analyze project source files (exclude node_modules, dist, tests)\nTests may import from anywhere (no hex validation on test files)"
    },
    "dependency-analyst": {
      "description": "Analyzes problem requirements to recommend optimal language/library combinations, cross-language communication patterns, and dependency graphs. Runs before the planner to inform technology selection for each adapter boundary.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze, mcp__hex__hex_adr_search instead of Bash.\nNever recommend unmaintained libraries (no commit in 12+ months)\nPrefer libraries with TypeScript types / Go interfaces / Rust traits"
    },
    "dev-tracker": {
      "description": "Session-persistent development tracker backed by HexFlo. On every session start, reconciles HexFlo task state against git history. Identifies completed, in-progress, blocked, and next tasks. Spawns agents for the next work items. Converts validation findings into HexFlo tasks automatically.\n",
      "mode": "all",
      "model": "opus",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze, mcp__hex__hex_hexflo_task_list, mcp__hex__hex_status instead of Bash.\nNever write application code directly (delegate to hex-coder agents)\nAll task state lives in HexFlo \u2014 never create local tracking JSON files"
    },
    "feature-developer": {
      "description": "Orchestrates the complete lifecycle of a feature in a hexagonal architecture project. Unlike vertical-slice feature development, hex features decompose across layers: domain \u2192 ports \u2192 usecases \u2192 adapters (parallel) \u2192 composition root \u2192 integration tests. Each adapter boundary gets its own git worktree for isolation.\n",
      "mode": "all",
      "model": "opus",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze not `hex analyze` via Bash, mcp__hex__hex_hexflo_swarm_init not `hex swarm init`.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP all work, save feature state to HexFlo memory, acknowledge via hex inbox ack, and inform the user. This overrides all other work.\nNever write application code directly (delegate to hex-coder agents)"
    },
    "hex-coder": {
      "description": "Generates production code within a single hexagonal adapter boundary. Uses TDD (London school, mock-first) with a compile-lint-test feedback loop. Never crosses adapter boundaries. Operates in an isolated git worktree.\n",
      "mode": "all",
      "model": "openai/gpt-4o-mini",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze not `hex analyze` via Bash, mcp__hex__hex_adr_search not `hex adr search`.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP coding, commit any in-progress work, acknowledge via hex inbox ack, and inform the coordinator. This overrides all other work.\nNever import from other adapters (only from core/ports and core/domain)"
    },
    "hex-fixer": {
      "description": "Fixes specific compile, lint, and test errors in generated code. Uses fast OpenRouter models for iterative fixes with Sonnet escalation for hard cases.\n",
      "mode": "all",
      "model": "deepseek-chat",
      "prompt": ""
    },
    "hex-reviewer": {
      "description": "Reviews code for quality, hex boundary compliance, and patterns. Uses local Ollama model for fast offline review.\n",
      "mode": "all",
      "model": "qwen3.5:9b",
      "prompt": ""
    },
    "hex-tester": {
      "description": "Generates London-school tests for a single source file. Uses local Ollama model for fast, offline test generation.\n",
      "mode": "all",
      "model": "qwen-coder",
      "prompt": ""
    },
    "integrator": {
      "description": "Handles the integration phase after parallel adapter coding is complete. Merges git worktrees back to the target branch, resolves merge conflicts, runs cross-adapter integration tests, and ensures the full system works together.\n",
      "mode": "all",
      "model": "opus",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_hexflo_task_complete not `hex task complete` via Bash.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP merge operations, save integration state, acknowledge via hex inbox ack, and inform the coordinator. This overrides all other work.\nNever modify adapter internals during merge (only resolve conflicts)"
    },
    "planner": {
      "description": "Decomposes high-level requirements into a task graph of adapter-bounded work units. Each task maps to exactly one adapter boundary and one git worktree. Produces a dependency-ordered workplan that the swarm coordinator uses for agent assignment.\n",
      "mode": "all",
      "model": "opus",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze not `hex analyze` via Bash, mcp__hex__hex_adr_list not `hex adr list`.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP planning, save workplan state, acknowledge via hex inbox ack, and inform the user. This overrides all other work.\nEvery task must map to exactly one adapter boundary"
    },
    "rust-refactorer": {
      "description": "Autonomous Rust codebase refactoring agent with worktree isolation",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": ""
    },
    "scaffold-validator": {
      "description": "Validates that every generated project is immediately runnable. Checks for README.md, start scripts, .env.example, and actually attempts to execute the dev/test commands. Runs AFTER code generation to ensure the \"last mile\" from code to running app is complete.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze, mcp__hex__hex_status instead of Bash.\nEvery project MUST have a README.md \u2014 no exceptions\nREADME MUST contain exact commands to install, run, and test"
    },
    "status-monitor": {
      "description": "A passive monitoring agent that subscribes to the domain event bus and provides real-time formatted progress updates. Detects anomalies such as stalls, quality regressions, and resource exhaustion. Runs alongside coding agents without interfering with their work.\n",
      "mode": "all",
      "model": "anthropic/claude-haiku-4-5-20251001",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_hexflo_swarm_status, mcp__hex__hex_hexflo_memory_retrieve instead of Bash.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP monitoring, acknowledge via hex inbox ack, and relay the notification to the user. This overrides all other work.\nNever modify source code or tests (read-only access to codebase)"
    },
    "swarm-coordinator": {
      "description": "Top-level orchestrator for the hex development workflow. Initializes the HexFlo swarm, assigns tasks from the planner's workplan to hex-coder agents in parallel worktrees, monitors progress, handles failures, and triggers integration when all adapter tasks complete.\n",
      "mode": "all",
      "model": "opus",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_hexflo_swarm_init, mcp__hex__hex_hexflo_task_list, mcp__hex__hex_analyze instead of Bash.\nADR-060 PRIORITY: If a critical notification (priority 2) appears in hook output, STOP all coordination, save swarm state to HexFlo memory, acknowledge via hex inbox ack, and inform the user. This overrides all other work.\nNever write application code directly (delegate to hex-coder agents)"
    },
    "validation-judge": {
      "description": "Post-build validation judge. Runs AFTER all code generation and unit tests pass. Catches semantic bugs that compile-lint-test pipelines miss \u2014 the kind where \"tests pass but app doesn't work.\" Produces a PASS/FAIL verdict with specific reasons. If FAIL, code generation must iterate.\n",
      "mode": "all",
      "model": "anthropic/claude-sonnet-4-6",
      "prompt": "TOOL PREFERENCE: Always use mcp__hex__* MCP tools before falling back to Bash. e.g. use mcp__hex__hex_analyze not `hex analyze` via Bash.\nBehavioral specs must be INDEPENDENT of implementation (no function names)\nProperty tests must use PRODUCTION config values, never test-only fixtures"
    }
  },
  "autoupdate": false,
  "command": {
    "hex-ADR-create": {
      "description": "Create a new Architecture Decision Record with timestamp-based ID (YYMMDDHHMM)",
      "template": "# Create New ADR\n\n## Steps\n\n1. Get the next available ADR ID and schema by running:\n   ```bash\n   hex adr schema\n   ```\n   This returns a timestamp-based ID (YYMMDDHHMM format), the template, valid statuses, and required sections.\n\n2. Ask the user for:\n   - Title (required)\n   - Brief context description\n   - Drivers (what triggered this decision)\n\n3. Create `docs/adrs/ADR-{YYMMDDHHMM}-{kebab-slug}.md` using the template from `hex adr schema`\n\n4. Fill in all required sections:\n   - Title: `# ADR-{YYMMDDHHMM}: {Title}`\n   - Status: `**Status:** Proposed`\n   - Date: today's date (YYYY-MM-DD)\n   - Drivers: from user input\n   - Context: describe the problem, forces, constraints, alternatives\n   - Decision: clear imperative language (\"We will...\", \"The system shall...\")\n   - Consequences: positive, negative, mitigations\n   - Implementation: phased table with status\n   - References: related ADRs, issues, documents\n\n## ID Format\n\nADR IDs use **YYMMDDHHMM** (timestamp) format \u2014 e.g., `ADR-2026-03-22-1500` means 2026-03-22 at 15:00.\nThis eliminates race conditions from sequential numbering. No reservation needed.\n\nLegacy ADRs (ADR-001 through ADR-066) keep their original sequential IDs.\n\n## Schema Reference\n\nValid statuses: `Proposed | Accepted | Deprecated | Superseded | Abandoned`\n\nRequired frontmatter:\n- `**Status:**` \u2014 one of valid statuses\n- `**Date:**` \u2014 YYYY-MM-DD\n- `**Drivers:**` \u2014 what triggered this decision\n- `**Supersedes:**` \u2014 (optional) ADR-YYMMDDHHMM if replacing\n\nRequired sections: Context, Decision, Consequences, Implementation, References\n\n## Example\n\nUser: `/hex-ADR-create`\nAssistant: runs `hex adr schema` to get timestamp ID (e.g., ADR-2026-03-22-1500)\nAssistant: \"What architectural decision needs to be recorded?\"\nUser: \"We should use WebSockets instead of polling for real-time updates\"\n-> Creates `docs/adrs/ADR-2026-03-22-1500-websocket-realtime.md` with all sections filled"
    },
    "hex-ADR-review": {
      "description": "Review code changes against existing Architecture Decision Records",
      "template": "# Review Code Against ADRs\n\n## Steps\n\n1. Get the current git diff: `git diff --cached` or `git diff HEAD`\n\n2. Read all ADR files from `docs/adrs/` to understand architectural decisions\n\n3. For each changed file, check:\n   - Does it violate any boundary rules from ADRs?\n   - Does it contradict any accepted decisions?\n   - Should a new ADR be written for this change?\n\n4. Report findings:\n   - **Compliant**: changes align with existing ADRs\n   - **Warning**: changes touch areas covered by ADRs but may not violate them\n   - **Violation**: changes directly contradict an accepted ADR\n   - **New ADR needed**: significant architectural change without an ADR\n\n## Key ADRs to Check\n- ADR-001: Hexagonal architecture boundaries\n- ADR-014: Dependency injection (no mock.module)\n- ADR-025: SpacetimeDB as state backend\n- ADR-042: SpacetimeDB single source of truth"
    },
    "hex-ADR-search": {
      "description": "Search Architecture Decision Records by keyword, status, or date",
      "template": "# Search ADRs\n\n## Steps\n\n1. Ask the user what to search for (keyword, status, or date range)\n\n2. Search methods:\n   - **By keyword**: `grep -ril \"{keyword}\" docs/adrs/`\n   - **By status**: `grep -rl \"Status.*{status}\" docs/adrs/`\n   - **By date**: `grep -rl \"Date.*2026\" docs/adrs/`\n   - **Via CLI**: `hex adr search {keyword}`\n   - **Via API**: `GET /api/adrs` then filter results\n\n3. Display matching ADRs with:\n   - ADR number and title\n   - Status badge\n   - Matching context snippet\n\n4. Offer to open any result for full reading\n\n## Example\n\nUser: `/hex-ADR-search spacetimedb`\n-> Shows ADR-025, ADR-032, ADR-042 with relevant snippets"
    },
    "hex-ADR-status": {
      "description": "Check ADR lifecycle -- find stale, abandoned, or conflicting decisions",
      "template": "# ADR Status Report\n\n## Steps\n\n1. Read all ADR files from `docs/adrs/`\n\n2. Parse status, date, and references from each\n\n3. Check for issues:\n   - **Stale**: Proposed ADRs older than 30 days without resolution\n   - **Abandoned**: ADRs with no related code changes in the last 90 days\n   - **Conflicting**: Multiple accepted ADRs that contradict each other\n   - **Missing references**: ADRs that mention other ADRs that don't exist\n   - **Numbering gaps**: Missing numbers in the sequence\n   - **Duplicate numbers**: Same number used twice\n\n4. Generate report:\n   ```\n   ADR Health Report\n   -----------------\n   Total: 45 ADRs\n   Accepted: 38 | Proposed: 4 | Superseded: 2 | Deprecated: 1\n\n   Issues Found:\n   - ADR-032 has duplicate numbers (two different files)\n   - ADR-041 has duplicate numbers (review agent + spacetimedb)\n   - 3 proposed ADRs older than 30 days\n   ```\n\n5. Offer to fix issues (renumber duplicates, update statuses)\n\n## CLI Shortcut\n\nThe `hex adr` subcommands can assist:\n- `hex adr list` -- list all ADRs with status\n- `hex adr status <id>` -- show detail for one ADR\n- `hex adr abandoned` -- detect stale/abandoned ADRs"
    },
    "hex-analyze-arch": {
      "description": "Check hexagonal architecture health, find dead code, and validate boundary rules. Automatically creates tasks and spawns fix agents for violations found. Use when the user asks to \"check architecture\", \"find dead code\", \"validate hex boundaries\", \"architecture health\", \"detect circular dependencies\", or \"hex analyze\".",
      "template": "# Hex Analyze Arch \u2014 Architecture Health Check with Auto-Fix\n\nRuns a full hexagonal architecture analysis. When violations are found, automatically creates HexFlo tasks and spawns a fix swarm \u2014 no manual triage needed.\n\n## Parameters\n\n- **rootPath** (optional, default: \".\"): Root directory to analyze\n- **autoFix** (implicit: true when critical/high issues found): Spawn agents to fix violations\n- **reportOnly** (optional, default: false): Skip auto-fix, just report\n\n## Execution Steps\n\n### 1. Run Architecture Analysis\n\nCall the hex_analyze MCP tool:\n\n```\nmcp__hex__hex_analyze({ path: rootPath })\n```\n\nThis returns the formatted HEXAGONAL ARCHITECTURE HEALTH REPORT with:\n- Summary table (files, exports, violations, circular deps, dead exports, repo hygiene)\n- Error rates with thresholds\n- Layer breakdown\n- Boundary violations grouped by severity (CRITICAL/WARNING)\n- Circular dependencies\n- Dead exports grouped by file\n- Unused ports & adapters\n- **Repo hygiene (anti-slop)**: uncommitted files, staged-not-committed, orphan worktrees, embedded git repos, untracked build artifacts, runtime state dirs\n- Health score and grade (A-F)\n\nDisplay the full report to the user.\n\n### 2. Extract Action Items\n\nUse the action item extractor from the domain layer to convert findings into structured tasks:\n\n```typescript\nimport { buildActionItemReport, formatActionItems } from 'src/core/domain/action-items.ts';\n\nconst actionReport = buildActionItemReport(archResult);\nconst formatted = formatActionItems(actionReport);\n```\n\nDisplay the ACTION ITEMS report showing:\n- MUST FIX: Critical and high-priority items with suggested fixes\n- SHOULD FIX: Medium and low-priority items\n\n### 3. Register Tasks in HexFlo\n\nFor each action item with priority `critical` or `high`, create a HexFlo task:\n\n```\nmcp__hex__hex_hexflo_task_create({\n  title: item.title,\n  metadata: {\n    category: item.category,        // bug, violation, circular-dep\n    priority: item.priority,        // critical, high\n    file: item.file,                // affected file path\n    layer: item.layer,              // hex layer name\n    suggestedFix: item.suggestedFix,\n    source: \"hex-analyze-arch\",\n    autoFixable: item.autoFixable\n  }\n})\n```\n\nStore the full report in HexFlo memory:\n```\nmcp__hex__hex_hexflo_memory_store(\"devtracker/validation-actions\", JSON.stringify(actionReport))\n```\n\n### 4. Auto-Fix Decision\n\nIf `reportOnly` is true, stop here with the report.\n\nOtherwise, evaluate whether to auto-fix:\n\n| Condition | Action |\n|-----------|--------|\n| Critical violations (cross-adapter, domain leak) | Spawn fix agent immediately |\n| Circular dependencies | Spawn fix agent immediately |\n| High-priority violations only | Spawn fix agent |\n| Medium/low only (dead exports, unused ports) | Report only, do not auto-fix |\n| Score >= 90 (Grade A) | No action needed |\n\n### 5. Spawn Fix Swarm\n\nFor each fixable issue, spawn a targeted agent in a worktree:\n\n```\nAgent tool: {\n  subagent_type: \"general-purpose\",\n  mode: \"bypassPermissions\",\n  run_in_background: true,\n  isolation: \"worktree\",\n  prompt: <fix prompt with full context>\n}\n```\n\n#### Fix Prompts by Category\n\n**Boundary Violation** (adapter imports from wrong layer):\n```\nFix hex boundary violation in {file}.\nCurrent: imports {names} from {wrongLayer}\nRequired: import through ports layer only.\n\nCheck if the types are already re-exported through a port file.\nIf yes: change the import path to use the port.\nIf no: add re-exports to the appropriate port file, then update the import.\n\nRules:\n- adapters/ may only import from ports/\n- domain/ may only import from domain/\n- usecases/ may only import from domain/ and ports/\n\nAfter fixing, run: bun test\n```\n\n**Circular Dependency**:\n```\nBreak circular dependency: {cycle}\n\nStrategies (pick the simplest):\n1. Extract shared types to a common domain file both can import\n2. Introduce a port interface to break the direct dependency\n3. Use event-based decoupling if the cycle is behavioral\n\nAfter fixing, run: bun test\n```\n\n**Domain Leak** (domain imports non-domain):\n```\nFix domain purity violation in {file}.\nDomain layer must have zero external dependencies.\nMove the imported types to domain/ or inject via port interface.\n\nAfter fixing, run: bun test\n```\n\n### 6. Monitor Fix Results\n\nAfter spawning fix agents:\n\n1. Wait for agent completion notifications\n2. For each completed fix:\n   - Run `mcp__hex__hex_validate_boundaries(\".\")` to verify the fix\n   - If violation resolved: `mcp__hex__hex_hexflo_task_complete(taskId, commitHash)`\n   - If still broken: report failure, do NOT retry automatically\n3. Run final `mcp__hex__hex_analyze(\".\")` to get updated health score\n\n### 7. Write Report\n\nWrite the full analysis + action items + fix results to `docs/analysis/arch-report.md`:\n\n```markdown\n# Architecture Health Report \u2014 {date}\n\n## Score: {score}/100 ({grade})\n\n## Summary\n{summary table}\n\n## Error Rates\n{error rates table}\n\n## Violations Found\n{violations table with severity}\n\n## Action Items Created\n{list of HexFlo tasks created}\n\n## Fixes Applied\n{list of auto-fixed issues with commit hashes}\n\n## Remaining Issues\n{items that need manual attention}\n```\n\n### 8. Final Status\n\nDisplay to the user:\n- Before/after health score comparison\n- Number of issues auto-fixed vs remaining\n- Any items that need manual attention\n- Link to the full report\n\n## Exclude Patterns\n\nThe analyzer excludes these by default:\n- `node_modules`, `dist`, `examples`\n- `*.test.ts`, `*.spec.ts`, `*_test.go`, `*.test.rs`\n- `/tests/`\n- `**/target/**` (Rust/Cargo build artifacts)\n\n## Output\n\n- Full health report displayed inline\n- Action items report displayed inline\n- Ruflo tasks created for critical/high issues\n- Fix agents spawned for violations (unless reportOnly)\n- Report written to `docs/analysis/arch-report.md`"
    },
    "hex-analyze-deps": {
      "description": "Analyze dependencies and recommend optimal tech stack for a hexagonal project. Use when the user asks to \"analyze dependencies\", \"what libraries should I use\", \"recommend tech stack\", \"language selection\", or \"how should components communicate\".",
      "template": "# Hex Analyze Deps \u2014 Dependency Analysis and Tech Stack Recommendation\n\nAnalyzes a problem statement to recommend optimal language/library combinations and cross-language communication patterns for hexagonal architecture projects.\n\n## Parameters\n\nAsk the user for:\n- **problem** (required): Problem statement or feature description\n- **languages** (optional, default: \"typescript,go,rust\"): Comma-separated target languages to consider\n\n## Execution Steps\n\n### 1. Decompose the Problem\n\nBreak the problem statement into architectural components:\n- **UI/Presentation layer** \u2014 user-facing interfaces\n- **Business logic** \u2014 core domain rules and use cases\n- **Data layer** \u2014 persistence, caching, state management\n- **IO layer** \u2014 external services, APIs, file system, network\n\nFor each component, identify key requirements: performance, concurrency, type safety, ecosystem maturity.\n\n### 2. Research Package Registries\n\nFor each component domain and each candidate language, search for:\n- Mature, well-maintained libraries\n- Community adoption (stars, downloads, recent activity)\n- Type safety and API ergonomics\n- License compatibility\n\nSources: npm registry, pkg.go.dev, crates.io, and general web search.\n\n### 3. Score Language x Library Combinations\n\nEvaluate each combination against criteria:\n- **Fitness**: How well does the language suit this component?\n- **Ecosystem**: Quality and breadth of available libraries?\n- **Performance**: Does it meet latency/throughput requirements?\n- **Team familiarity**: Reasonable learning curve?\n- **Interop**: Can it communicate with other components cleanly?\n\n### 4. Recommend Communication Pattern\n\nBased on the component decomposition, recommend how components should communicate:\n- **In-process**: Direct function calls (single-language projects)\n- **FFI/WASM**: For performance-critical cross-language calls\n- **gRPC/Protobuf**: For service-to-service communication\n- **Message queue**: For async, decoupled components\n- **REST/HTTP**: For external-facing APIs\n\n### 5. Generate Report\n\nWrite a structured recommendation to `docs/analysis/{problem-slug}-deps.md` containing:\n- Component breakdown with assigned languages\n- Library recommendations per component with rationale\n- Dependency graph showing inter-component relationships\n- Communication pattern diagram\n- Risk assessment and migration path\n\n## Output\n\nReport the recommendation summary and the path to the full analysis document."
    },
    "hex-dashboard": {
      "description": "Start the hex monitoring dashboard. Use when the user asks to \"start dashboard\", \"open dashboard\", \"monitor project\", \"hex dashboard\", or \"show swarm status\".",
      "template": "# Hex Dashboard \u2014 Project Monitoring\n\nStart the hex dashboard for the **current project directory**.\n\nThe `hex dashboard` command auto-registers with the project registry at `~/.hex/registry.json` and gets an assigned port (3848-3947). Port 3847 is reserved for the multi-project hub.\n\n## Steps\n\n1. **Check the registry** for an existing registration using the Read tool (NOT bash):\n\nUse the Read tool to read `~/.hex/registry.json`. Look for an entry whose `rootPath` matches the current working directory. If found, note the assigned `port`.\n\n2. **If registered, check if already running** on the assigned port:\n\n```bash\nlsof -ti :<assigned-port>\n```\n\nIf a PID is returned, the dashboard is already running \u2014 report the URL `http://localhost:<assigned-port>` and stop.\n\n3. **Start the dashboard** using the Bash tool with `run_in_background: true`:\n\n**CRITICAL**: Do NOT use `&`, `|`, `$(...)`, or any shell operators. Use ONLY the Bash tool's `run_in_background` parameter.\n\n```\nBash(command: \"hex dashboard\", run_in_background: true)\n```\n\nThis will:\n- Register the project in `~/.hex/registry.json` (if not already)\n- Get an assigned port from the registry (3848-3947)\n- Write `.hex/project.json` with the project's registry ID\n- Start the HTTP server on the assigned port\n\n4. **Wait and verify**:\n\n```bash\nsleep 3\n```\n\nThen read `.hex/project.json` with the Read tool to confirm the registration.\n\nReport: `http://localhost:<assigned-port>`\n\n## CRITICAL RULES\n\n- **Use Read tool** to read registry \u2014 NOT `cat` or `grep` via Bash\n- **Use `run_in_background: true`** \u2014 NOT the `&` shell operator\n- **Do NOT use pipes, command substitution, or shell operators** in any Bash commands\n- **Do NOT manually pick ports** \u2014 the registry assigns them\n- **Do NOT scan ports with lsof in a loop** \u2014 read the registry\n\n## What It Shows\n\n- **Architecture Health** \u2014 files scanned, violations, dead exports, circular deps\n- **Token Efficiency** \u2014 AST summary compression ratios (L0-L3)\n- **Swarm Status** \u2014 active agents, tasks, topology (live from ruflo daemon)\n- **Dependency Graph** \u2014 interactive import visualization\n- **Event Log** \u2014 real-time SSE notifications\n\n## Notes\n\n- The dashboard runs as a background process \u2014 it stays alive until killed\n- SSE stream connects automatically when the page loads\n- To stop: find PID with `lsof -ti :<port>` then `kill <PID>`\n- Unregister: remove the entry from `~/.hex/registry.json`"
    },
    "hex-dev-rebuild": {
      "description": "Rebuild and deploy hex-nexus binary after Rust code or asset changes",
      "template": "# hex-dev-rebuild \u2014 Rebuild and Deploy hex-nexus\n\n**Use this skill when**: You've made changes to hex-nexus Rust code or dashboard assets and need to rebuild and deploy.\n\n## What This Does\n\n1. Stops running hex-nexus daemon\n2. Rebuilds hex-nexus in release mode\n3. Copies new binary to `~/.hex/bin/hex-nexus`\n4. Removes stale lock files\n5. Starts daemon with new binary\n6. Verifies deployment\n\n## Workflow\n\n### Step 1: Stop Daemon\n\n```bash\npkill -9 hex-nexus\nsleep 2\nrm -f /Users/gary/.hex/daemon/hub.lock\nrm -f /Users/gary/.hex/daemon/hub.state\n```\n\n### Step 2: Rebuild hex-nexus\n\n```bash\ncd hex-nexus\ncargo build --release 2>&1 | grep -E \"(Compiling|Finished|error|warning)\"\n```\n\nIf build fails, STOP and report error.\n\n### Step 3: Copy Binary\n\n```bash\ncp hex-nexus/target/release/hex-nexus ~/.hex/bin/hex-nexus\nchmod +x ~/.hex/bin/hex-nexus\n```\n\n### Step 4: Verify Binary\n\n```bash\nls -lh ~/.hex/bin/hex-nexus\nstrings ~/.hex/bin/hex-nexus | grep -c \"cleanup\" || echo \"Binary verification failed\"\n```\n\n### Step 5: Start Daemon\n\n```bash\nbun run hex daemon start\n```\n\nIf this times out with \"Daemon failed to start within 5s\", IGNORE IT and check if process is running:\n\n```bash\nps aux | grep hex-nexus | grep -v grep\ncat ~/.hex/daemon/hub.lock | jq '.'\n```\n\nIf process exists and lock file has a PID, daemon IS running despite the error message.\n\n### Step 6: Verify Deployment\n\n```bash\nsleep 2\nlsof -i :5555 | grep hex-nexus\ncat ~/.hex/daemon/hub.lock | jq -r '.version, .startedAt'\n```\n\nDashboard should be available at: http://localhost:5555\n\n## Success Criteria\n\n- \u2705 hex-nexus process running (check with `ps`)\n- \u2705 Lock file exists with valid PID\n- \u2705 Port 5555 is bound to hex-nexus\n- \u2705 Dashboard loads in browser\n\n## Common Issues\n\n### Issue: \"Address already in use\"\n**Fix**: Go back to Step 1, ensure all processes killed\n\n### Issue: \"Daemon failed to start within 5s\"\n**Fix**: This is a false alarm if the process is actually running. Check `ps aux | grep hex-nexus`\n\n### Issue: Binary file is \"No such file or directory\"\n**Fix**: Build output is in `hex-nexus/target/release/hex-nexus` (relative to project root)\n\n### Issue: Dashboard shows old version\n**Fix**: Hard refresh browser (Cmd+Shift+R) \u2014 assets are compile-time embedded\n\n## Why This is Needed\n\nhex-nexus uses `rust-embed` to bake `hex-nexus/assets/*` (HTML, CSS, JS) into the Rust binary at **compile time**. This means:\n\n1. Editing `hex-nexus/assets/index.html` requires **rebuilding the Rust binary**\n2. The new binary must be **copied** to `~/.hex/bin/hex-nexus` (not automatic)\n3. The daemon must be **restarted** to load the new binary\n4. Browser must **hard-refresh** to bypass cache\n\nThis is different from typical web dev where HTML changes are live-reloaded.\n\n## ARGUMENTS\n\nNo arguments required. Run with: `/hex-dev-rebuild`"
    },
    "hex-feature-dev": {
      "description": "Start feature development with hex decomposition and worktree isolation. Use when the user asks to \"develop a feature\", \"new feature\", \"implement feature\", \"feature dev\", \"start feature\", or \"add feature\".",
      "template": "# Hex Feature Dev \u2014 Develop a Feature Across Hexagonal Boundaries\n\nCRITICAL: Do NOT enter plan mode (EnterPlanMode). Proceed directly with execution.\n\n## How Hex Treats Features\n\nIn hexagonal architecture, a \"feature\" is NOT a single vertical slice. It decomposes inside-out across layers:\n\n```\nDomain types \u2192 Port contracts \u2192 Use cases \u2192 Adapters (parallel) \u2192 Composition root \u2192 Integration tests\n```\n\nEach adapter gets its own git worktree. Port/domain changes merge first, then adapters fan out in parallel, then integration merges last. This is enforced by the planner agent's dependency ordering.\n\n## Phase 0: Initialize HexFlo Swarm\n\nCRITICAL: Before any work begins, initialize the HexFlo swarm for tracking.\n\n```tool\nmcp__hex__hex_hexflo_swarm_init({\n  topology: \"hierarchical\",\n  maxAgents: 8,\n  strategy: \"specialized\"\n})\n```\n\nThen reconcile any prior state:\n\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\nCross-reference task list against `git log --oneline -10`. If commits exist for tasks, mark them complete:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"...\",\n  result: \"feat(adapter): summary \u2014 commit abc1234\"\n})\n```\n\n## Phase 1: Feature Discovery\n\nUse AskUserQuestion to understand the feature scope.\n\n```tool\nAskUserQuestion({\n  questions: [\n    {\n      question: \"Describe the feature you want to build\",\n      header: \"Feature Description\",\n      multiSelect: false,\n      options: [\n        { label: \"Free-form description\", description: \"I'll describe what the feature should do\" }\n      ]\n    },\n    {\n      question: \"Which layers does this feature touch?\",\n      header: \"Affected Layers\",\n      multiSelect: true,\n      options: [\n        { label: \"Domain (new types/entities)\", description: \"New value objects, entities, or domain events\" },\n        { label: \"Ports (new/modified interfaces)\", description: \"New port contracts or changes to existing ones\" },\n        { label: \"Use cases (new orchestration)\", description: \"New application logic composing ports\" },\n        { label: \"Primary adapters (CLI, HTTP, MCP)\", description: \"New ways to drive the application\" },\n        { label: \"Secondary adapters (DB, API, FS)\", description: \"New infrastructure integrations\" },\n        { label: \"Not sure \u2014 let the planner decide\", description: \"The planner agent will analyze and decompose\" }\n      ]\n    },\n    {\n      question: \"How should this feature be developed?\",\n      header: \"Development Mode\",\n      multiSelect: false,\n      options: [\n        { label: \"Swarm (recommended)\", description: \"Multi-agent parallel development with worktree isolation. Best for features spanning 2+ adapters.\" },\n        { label: \"Interactive\", description: \"Step-by-step with human review at each phase. Best for learning or critical features.\" },\n        { label: \"Single-agent\", description: \"One agent handles everything sequentially. Best for small, single-adapter features.\" }\n      ]\n    }\n  ]\n})\n```\n\nAfter discovery, store the feature context in HexFlo memory:\n\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/{{feature-name}}/context\",\n  value: {\n    name: \"{{feature-name}}\",\n    description: \"{{feature_description}}\",\n    layers: [\"{{selected_layers}}\"],\n    mode: \"{{development_mode}}\",\n    started_at: \"{{ISO timestamp}}\"\n  }\n})\n```\n\n## Phase 2: Behavioral Specs (MANDATORY)\n\nBefore ANY code is written, create behavioral specs. This prevents the \"tests mirror bugs\" problem.\n\n### Register specs task with HexFlo:\n\n```tool\nmcp__hex__hex_hexflo_task_create({\n  title: \"Write behavioral specs for {{feature-name}}\",\n  assignee: \"behavioral-spec-writer\",\n  metadata: { phase: \"specs\", feature: \"{{feature-name}}\", tier: 0 }\n})\n```\n\n### Spawn the behavioral-spec-writer agent:\n\n```\nAgent({\n  subagent_type: \"general-purpose\",\n  mode: \"bypassPermissions\",\n  prompt: `You are the behavioral-spec-writer agent for a hex project.\n\nFeature: {{feature_description}}\nProject root: {{cwd}}\n\nInstructions:\n1. Read src/core/ports/index.ts to understand existing contracts\n2. Read src/core/domain/ to understand existing types\n3. Write behavioral specs in Given/When/Then format\n4. Include negative specs (what should NOT happen)\n5. Document any coordinate systems, sign conventions, or domain conventions\n6. Save specs to docs/specs/{{feature-name}}.json\n\nSpec format per entry:\n{\n  \"category\": \"string\",\n  \"description\": \"human-readable description\",\n  \"given\": \"precondition\",\n  \"when\": \"action or event\",\n  \"then\": \"expected outcome\",\n  \"negative_spec\": false,\n  \"domain_conventions\": {}\n}\n\nWrite at least 5 specs covering: happy path, error cases, edge cases, and at least 1 negative spec.`\n})\n```\n\nWait for specs to complete. Then mark task done:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"{{specs_task_id}}\",\n  result: \"Wrote {{N}} behavioral specs to docs/specs/{{feature-name}}.json\"\n})\n```\n\n**IMPORTANT**: `feature-workflow.sh setup` now **enforces** spec existence. The setup command will exit with an error if `docs/specs/<feature>.json` does not exist. This is intentional -- specs must be written before worktrees are created. For emergency hotfixes only, pass `--skip-specs` to bypass this check:\n\n```bash\n./scripts/feature-workflow.sh setup {{feature-name}} --skip-specs\n```\n\n## Phase 3: Planning \u2014 Decompose into Adapter-Bounded Tasks\n\n### Register planning task with HexFlo:\n\n```tool\nmcp__hex__hex_hexflo_task_create({\n  title: \"Decompose {{feature-name}} into adapter-bounded tasks\",\n  assignee: \"planner\",\n  metadata: { phase: \"plan\", feature: \"{{feature-name}}\", tier: 0 }\n})\n```\n\n### Spawn the planner agent:\n\n```\nAgent({\n  subagent_type: \"general-purpose\",\n  mode: \"bypassPermissions\",\n  prompt: `You are the planner agent for a hex project.\n\nFeature: {{feature_description}}\nBehavioral specs: docs/specs/{{feature-name}}.json\nProject root: {{cwd}}\n\nInstructions:\n1. Read the behavioral specs\n2. Read src/core/ports/index.ts for existing port interfaces\n3. Read src/core/domain/ for existing domain types\n4. Decompose the feature into adapter-bounded tasks\n5. Each task maps to exactly one adapter boundary\n6. Order tasks by dependency:\n   - Domain/port changes FIRST (other tasks depend on these)\n   - Secondary adapters NEXT\n   - Primary adapters NEXT\n   - Integration tests LAST\n7. Max 8 parallel tasks\n8. Write workplan to docs/workplans/feat-{{feature-name}}.json\n\nWorkplan schema:\n{\n  \"id\": \"feat-{{feature-name}}\",\n  \"title\": \"Feature: {{feature_description}}\",\n  \"specs\": \"docs/specs/{{feature-name}}.json\",\n  \"steps\": [\n    {\n      \"id\": \"step-1\",\n      \"description\": \"what to do\",\n      \"layer\": \"domain|ports|usecases|adapters/primary|adapters/secondary\",\n      \"adapter\": \"adapter-name (if applicable)\",\n      \"port\": \"IPortName (if applicable)\",\n      \"dependencies\": [],\n      \"worktree_branch\": \"feat/{{feature-name}}/{{adapter-name}}\",\n      \"done_condition\": \"compile + lint + test pass\"\n    }\n  ]\n}`\n})\n```\n\nWait for workplan. Then mark task done and register all coding tasks:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"{{plan_task_id}}\",\n  result: \"Workplan with {{N}} steps written to docs/workplans/feat-{{feature-name}}.json\"\n})\n```\n\n### Register each workplan step as a HexFlo task:\n\nFor EACH step in the workplan:\n\n```tool\nmcp__hex__hex_hexflo_task_create({\n  title: \"{{step.description}}\",\n  assignee: \"hex-coder\",\n  metadata: {\n    phase: \"code\",\n    feature: \"{{feature-name}}\",\n    step_id: \"{{step.id}}\",\n    adapter: \"{{step.adapter}}\",\n    port: \"{{step.port}}\",\n    layer: \"{{step.layer}}\",\n    tier: {{tier_number}},\n    worktree_branch: \"{{step.worktree_branch}}\",\n    dependencies: [\"{{step.dependencies}}\"]\n  }\n})\n```\n\nStore workplan reference in HexFlo memory:\n\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/{{feature-name}}/workplan\",\n  value: {\n    workplan_path: \"docs/workplans/feat-{{feature-name}}.json\",\n    task_ids: { \"step-1\": \"hexflo-task-id-1\", \"step-2\": \"hexflo-task-id-2\" },\n    total_steps: {{N}},\n    completed_steps: 0\n  }\n})\n```\n\n## Phase 4: Worktree Setup and Parallel Coding\n\n### 4a. Create worktrees for each task\n\nRun `scripts/feature-workflow.sh setup {{feature-name}}` to create worktrees from the workplan.\n\nIf the script doesn't exist yet, create worktrees manually:\n\n```bash\n# For each step in the workplan:\ngit worktree add ../hex-feat-{{feature-name}}-{{adapter}} feat/{{feature-name}}/{{adapter}}\n```\n\n### 4b. Spawn hex-coder agents in parallel\n\nCRITICAL: Spawn ALL independent agents in a SINGLE message (parallel tool calls).\nCRITICAL: Use mode=bypassPermissions for background agents that write files.\n\nFor each task that has no unfinished dependencies, spawn a hex-coder:\n\n```\nAgent({\n  subagent_type: \"coder\",\n  mode: \"bypassPermissions\",\n  run_in_background: true,\n  prompt: `You are a hex-coder agent.\n\nFeature: {{feature_description}}\nTask: {{step.description}}\nAdapter: {{step.adapter}}\nPort: {{step.port}}\nWorktree: ../hex-feat-{{feature-name}}-{{step.adapter}}\nBehavioral specs: docs/specs/{{feature-name}}.json\nHexFlo task ID: {{hexflo_task_id}}\n\nInstructions:\n1. cd to the worktree directory\n2. Read the port interface from src/core/ports/index.ts\n3. Read the behavioral specs relevant to your adapter\n4. TDD Red: Write failing tests in tests/unit/{{adapter}}.test.ts\n5. TDD Green: Implement adapter in src/adapters/{{layer}}/{{adapter}}.ts\n6. TDD Refactor: Clean up, extract helpers if needed\n7. Run: bun run check && bun test && bun run lint\n8. Commit changes with message: feat({{adapter}}): implement {{port}} for {{feature-name}}\n9. Report the commit hash in your response\n\nConstraints:\n- NEVER import from other adapters\n- ONLY import from core/ports and core/domain\n- Use .js extensions in all relative imports\n- Max 500 lines per file`\n})\n```\n\n### 4c. On agent completion \u2014 mark HexFlo task done\n\nWhen each hex-coder agent completes, immediately mark its HexFlo task:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"{{hexflo_task_id}}\",\n  result: \"feat({{adapter}}): implement {{port}} \u2014 commit {{hash}}\"\n})\n```\n\nUpdate progress in HexFlo memory:\n\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/{{feature-name}}/progress\",\n  value: {\n    completed: [\"step-1\", \"step-3\"],\n    in_progress: [\"step-2\"],\n    pending: [\"step-4\", \"step-5\"],\n    current_tier: 1,\n    last_updated: \"{{ISO timestamp}}\"\n  }\n})\n```\n\n### 4d. Handle dependency tiers\n\nTasks execute in tiers based on dependencies:\n- **Tier 0**: Domain + port changes (no dependencies)\n- **Tier 1**: Secondary adapters (depend on ports)\n- **Tier 2**: Primary adapters (depend on ports)\n- **Tier 3**: Use case changes (depend on ports)\n- **Tier 4**: Composition root wiring\n- **Tier 5**: Integration tests (depend on everything)\n\nAfter all agents in a tier complete, check HexFlo task list for next tier:\n\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\nSpawn agents for the next tier's pending tasks.\n\n## Phase 5: Validation (BLOCKING GATE)\n\nRegister validation task:\n\n```tool\nmcp__hex__hex_hexflo_task_create({\n  title: \"Validate {{feature-name}} against behavioral specs\",\n  assignee: \"validation-judge\",\n  metadata: { phase: \"validate\", feature: \"{{feature-name}}\", blocking: true }\n})\n```\n\nSpawn the validation judge:\n\n```\nAgent({\n  subagent_type: \"general-purpose\",\n  mode: \"bypassPermissions\",\n  prompt: `You are the validation-judge agent.\n\nFeature: {{feature_description}}\nBehavioral specs: docs/specs/{{feature-name}}.json\nProject root: {{cwd}}\n\nInstructions:\n1. Read the behavioral specs\n2. For EACH spec, verify the implementation satisfies it\n3. Run: bun run build\n4. Run: bun test\n5. Run: bunx hex analyze . (architecture boundary check)\n6. Generate property-based tests for critical invariants\n7. Check that the app is actually runnable (not just \"tests pass\")\n\nOutput a verdict:\n{\n  \"verdict\": \"PASS\" | \"FAIL\",\n  \"specs_checked\": number,\n  \"specs_passed\": number,\n  \"specs_failed\": [{ \"spec\": \"...\", \"reason\": \"...\" }],\n  \"architecture_violations\": [],\n  \"recommendations\": []\n}\n\nIf FAIL: list exactly what needs to change for each failing spec.`\n})\n```\n\nMark validation result:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"{{validate_task_id}}\",\n  result: \"Verdict: {{PASS|FAIL}} \u2014 {{specs_passed}}/{{specs_checked}} specs passed\"\n})\n```\n\nIf verdict is FAIL, iterate: fix the issues and re-validate (max 2 retries).\nIf verdict is PASS, proceed to Phase 6.\n\n## Phase 6: Integration and Merge\n\nRegister integration task:\n\n```tool\nmcp__hex__hex_hexflo_task_create({\n  title: \"Merge and integrate {{feature-name}} worktrees\",\n  assignee: \"integrator\",\n  metadata: { phase: \"integrate\", feature: \"{{feature-name}}\" }\n})\n```\n\n### 6a. Merge worktrees in dependency order\n\n```bash\n# Run the feature-workflow script:\n./scripts/feature-workflow.sh merge {{feature-name}}\n\n# Or manually in dependency order:\ngit merge feat/{{feature-name}}/domain --no-ff\ngit merge feat/{{feature-name}}/ports --no-ff\ngit merge feat/{{feature-name}}/{{secondary-adapter}} --no-ff\ngit merge feat/{{feature-name}}/{{primary-adapter}} --no-ff\ngit merge feat/{{feature-name}}/integration --no-ff\n```\n\n### 6b. Run full test suite on merged result\n\n```bash\nbun run check && bun test && bun run lint && bunx hex analyze .\n```\n\n### 6c. Clean up worktrees\n\n```bash\n./scripts/feature-workflow.sh cleanup {{feature-name}}\n```\n\nMark integration done:\n\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"{{integrate_task_id}}\",\n  result: \"Feature {{feature-name}} merged to main \u2014 commit {{final_hash}}\"\n})\n```\n\n## Phase 7: Finalize\n\n1. Update composition-root.ts if new adapters need wiring\n2. Run final `bun run build` to verify clean build\n3. Commit with: `feat: {{feature-name}} \u2014 {{one-line summary}}`\n\nStore final report in HexFlo memory:\n\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/{{feature-name}}/report\",\n  value: {\n    status: \"complete\",\n    verdict: \"PASS\",\n    specs_file: \"docs/specs/{{feature-name}}.json\",\n    workplan_file: \"docs/workplans/feat-{{feature-name}}.json\",\n    tasks_completed: {{N}},\n    files_changed: [\"...\"],\n    tests_added: {{N}},\n    integration_commit: \"{{hash}}\",\n    completed_at: \"{{ISO timestamp}}\"\n  }\n})\n```\n\nReport completion with summary of files changed, tests added, specs validated.\n\n## Quick Reference\n\n| Phase | Agent | HexFlo Action | Gate |\n|-------|-------|-------------|------|\n| Init | \u2014 | `swarm_init` + `task_list` (reconcile) | Swarm active |\n| Specs | behavioral-spec-writer | `task_create` \u2192 `task_complete` | Specs exist |\n| Plan | planner | `task_create` \u2192 `task_complete` + register all steps | Workplan valid |\n| Code | hex-coder (x N) | `task_complete` per agent + `memory_store` progress | compile + lint + test |\n| Validate | validation-judge | `task_create` \u2192 `task_complete` with verdict | PASS verdict |\n| Integrate | integrator | `task_create` \u2192 `task_complete` with commit hash | Full suite passes |\n| Finalize | \u2014 | `memory_store` final report | Build clean |\n\n## Worktree Branch Naming\n\n```\nfeat/{{feature-name}}/domain          # Domain type changes\nfeat/{{feature-name}}/ports           # Port interface changes\nfeat/{{feature-name}}/{{adapter}}     # Per-adapter work\nfeat/{{feature-name}}/integration     # Integration tests\n```\n\n## Session Continuity\n\nIf a session ends mid-feature, the next session can resume by:\n\n```tool\nmcp__hex__hex_hexflo_memory_retrieve({ key: \"feature/{{feature-name}}/progress\" })\nmcp__hex__hex_hexflo_task_list()\n```\n\nCross-reference HexFlo task status against `git log --oneline -10` to reconcile completed work. Resume from the next incomplete tier."
    },
    "hex-generate": {
      "description": "Generate code within a hexagonal adapter boundary. Use when the user asks to \"generate adapter\", \"implement port\", \"create adapter\", \"code adapter\", or \"implement interface\".",
      "template": "# Hex Generate \u2014 Implement an Adapter for a Port Interface\n\n## Parameters\n\nAsk the user for:\n- **adapter** (required): Target adapter path relative to `src/adapters/` (e.g., \"secondary/git-adapter\", \"primary/cli-adapter\")\n- **port** (optional): Specific port interface to implement (e.g., \"IGitPort\"). If omitted, infer from adapter name.\n- **language** (optional, default: typescript): One of `typescript`, `go`, or `rust`\n- **test_style** (optional, default: london): `london` (mock-first) or `chicago` (state-based)\n- **max_iterations** (optional, default: 5): Max feedback loop iterations\n\n## Step 1: Resolve Port\n\nIf port is not specified, infer from adapter path:\n- `secondary/git-adapter` -> IGitPort + IWorktreePort\n- `secondary/llm-adapter` -> ILLMPort\n- `secondary/build-adapter` -> IBuildPort\n- `secondary/fs-adapter` -> IFileSystemPort\n- `secondary/ast-adapter` -> IASTPort\n- `primary/cli-adapter` -> ICodeGenerationPort + IWorkplanPort\n- `primary/http-adapter` -> ICodeGenerationPort + ISummaryPort\n- `primary/agent-adapter` -> ICodeGenerationPort + IWorkplanPort + ISummaryPort\n\n## Step 2: Load Context\n\nLoad AST summaries at appropriate levels:\n- **L1** of all `src/core/ports/**` \u2014 skeleton of all port interfaces for contract awareness\n- **L2** of the specific port file \u2014 full method signatures being implemented\n- **L2** of existing adapter code in `src/adapters/{adapter}/**` \u2014 current state\n- **L1** of `src/core/domain/**` \u2014 domain entity skeletons for type references\n- **L3** of the specific file being edited (on-demand)\n\nStay within token budget: ~100K total, reserve 20K for response.\n\n## Step 3: Write Failing Tests First (TDD Red)\n\nCreate unit tests in `tests/unit/{adapter_name}.test.{ext}`:\n- Test every method defined in the port interface\n- Mock all dependencies (other ports) using London-school style\n- Include happy path, error cases, and edge cases (empty input, null, timeout)\n- Assert return types match the port contract\n\nRun tests to confirm they FAIL before implementation exists.\n\n## Step 4: Implement the Adapter (TDD Green)\n\nGenerate the adapter in `src/adapters/{adapter}/index.{ext}`:\n- Implement every method from the resolved port interface\n- Use dependency injection for all external dependencies\n- Include proper error handling with domain-specific error types\n- Add JSDoc/godoc/rustdoc for all public methods\n- Keep file under 500 lines; split if needed\n\n## Step 5: Feedback Loop (Compile -> Lint -> Test -> Refine)\n\nRun quality gates in order, up to max_iterations:\n\n1. **Compile**: `npx tsc --noEmit` / `go build ./...` / `cargo check`\n2. **Lint**: `npx eslint src/adapters/{adapter}/ --ext .ts` / equivalent\n3. **Unit Test**: `npx vitest run tests/unit/{adapter_name}.test.ts` / equivalent\n4. **AST Diff** (optional): `npx hex summarize --file src/adapters/{adapter}/index.ts --level L2`\n\nOn failure:\n1. Parse structured error output from the failing gate\n2. Load L3 context of the failing file\n3. Apply targeted fix using Edit tool (not full rewrite)\n4. Re-run only the failing gate before full cycle\n\nIf all gates fail after max_iterations, report the errors and escalate for human review.\n\n## Step 6: Refactor (TDD Refactor)\n\nAfter all gates pass, clean up:\n- Eliminate code duplication (DRY)\n- Ensure single responsibility per function\n- Verify consistent naming with project conventions\n- Check error messages are descriptive\n- Confirm all public API has documentation\n\nRe-run quality gates after refactoring to confirm nothing broke.\n\n## Step 7: Run Architecture Analysis\n\nRun `hex analyze .` to verify the new adapter does not introduce boundary violations or circular dependencies.\n\n## Output\n\nReport: adapter name, port implemented, quality gate results (compile/lint/test), iteration count, files created/modified."
    },
    "hex-inference": {
      "description": "Manage inference providers (Ollama, vLLM, OpenAI-compatible) and map local models to hex agent tiers. Use when the user asks to \"add ollama\", \"use local model\", \"configure inference\", \"qwen\", \"minimax\", \"ollama setup\", \"model mapping\", or \"inference provider\".",
      "template": "# Hex Inference \u2014 Local & Remote Model Management\n\nhex is model-agnostic. It works with frontier models (Anthropic, OpenAI), self-hosted models (Ollama, vLLM), and free models. This skill guides inference provider setup, model-to-agent tier mapping, and capability-aware agent assignment.\n\n## Quick Start\n\n```bash\n# Discover Ollama instances on your network\nhex inference discover\n\n# Register a provider\nhex inference add ollama http://localhost:11434 --model qwen3:32b\n\n# Test connectivity + latency\nhex inference test http://localhost:11434\n\n# List all providers\nhex inference list\n```\n\n## Provider Types\n\n| Type | Protocol | Auth | Use Case |\n|------|----------|------|----------|\n| `ollama` | Ollama API + OpenAI-compat `/v1/` | None | Local/LAN self-hosted |\n| `vllm` | OpenAI-compat `/v1/` | Optional API key | GPU server, high throughput |\n| `openai-compat` | OpenAI `/v1/` | API key | Any OpenAI-compatible endpoint |\n\n## Environment Variables\n\n| Variable | Purpose | Example |\n|----------|---------|---------|\n| `HEX_OLLAMA_HOST` | Ollama base URL | `http://bazzite.local:11434` |\n| `HEX_OLLAMA_MODEL` | Default Ollama model | `qwen3:32b` |\n| `HEX_VLLM_HOST` | vLLM base URL | `http://gpu-server:8000` |\n| `HEX_VLLM_MODEL` | Default vLLM model | `Qwen/Qwen3-32B` |\n| `HEX_INFERENCE_URL` | Generic inference URL | `http://host:8080` |\n| `HEX_INFERENCE_MODEL` | Generic model name | `default` |\n| `ANTHROPIC_API_KEY` | Anthropic API (frontier) | `sk-ant-...` |\n\n## Model-to-Agent Tier Mapping\n\nhex agents have a `model_tier` field (1-3) that determines which model class they need. When using local models, map tiers to your available models:\n\n### Tier Definitions\n\n| Tier | Capability Needed | Frontier Model | Minimum Local Model |\n|------|-------------------|----------------|---------------------|\n| **1** (fast) | Simple lookups, status checks, formatting | Haiku | Any 1B-7B (qwen3:4b, phi4-mini) |\n| **2** (balanced) | Code generation, review, analysis | Sonnet | 14B-32B (qwen3:32b, qwen3.5:27b, minimax-m1:80b) |\n| **3** (deep) | Planning, architectural reasoning, validation | Opus | 70B+ (qwen3:235b, deepseek-r1:70b) or use frontier |\n\n### Agent \u2192 Tier Mapping\n\n| Agent | Tier | Why | Can Run Local? |\n|-------|------|-----|----------------|\n| status-monitor | 1 | Simple status aggregation | Yes \u2014 any model |\n| dev-tracker | 1 | Progress tracking | Yes \u2014 any model |\n| scaffold-validator | 1 | File existence checks | Yes \u2014 any model |\n| hex-coder | 2 | Code generation within one adapter | Yes \u2014 14B+ recommended |\n| dead-code-analyzer | 2 | Pattern matching + grep | Yes \u2014 14B+ |\n| ADR-reviewer | 2 | Template validation | Yes \u2014 14B+ |\n| dependency-analyst | 2 | Dependency analysis | Yes \u2014 14B+ |\n| rust-refactorer | 2 | Rust-specific refactoring | Yes \u2014 32B+ recommended |\n| integrator | 2 | Merge + test orchestration | Yes \u2014 14B+ |\n| behavioral-spec-writer | 3 | Domain reasoning for specs | Risky \u2014 needs frontier or 70B+ |\n| planner | 3 | Architectural decomposition | Risky \u2014 needs frontier or 70B+ |\n| validation-judge | 3 | Deep semantic validation | Risky \u2014 needs frontier or 70B+ |\n| swarm-coordinator | 3 | Multi-agent orchestration | Risky \u2014 needs frontier or 70B+ |\n| feature-developer | 3 | Full lifecycle orchestration | Risky \u2014 needs frontier or 70B+ |\n\n### Recommended Model Configurations\n\n#### Budget: Ollama Only (No API Keys)\n\n```bash\n# Use a capable open model for coding\nhex inference add ollama http://localhost:11434 --model qwen3:32b\n\n# Agent mapping\n# Tier 1-2: qwen3:32b (handles most coding tasks)\n# Tier 3: qwen3:32b with /think mode, or qwen3:235b if you have 128GB+ RAM\n```\n\n**Limitations**:\n- Tier 3 agents (planner, validation-judge) will produce lower-quality plans\n- Behavioral specs may miss edge cases\n- Swarm coordination may be less reliable\n- Workplans may have dependency errors\n\n**Mitigations**:\n- Use **Interactive mode** instead of Swarm mode (human reviews each phase)\n- Run `hex analyze .` after each coding step (catches boundary violations)\n- Review behavioral specs manually before workplan creation\n- Use `hex plan validate` to catch workplan structural issues\n\n#### Hybrid: Ollama + Frontier API\n\n```bash\n# Local model for coding (tier 1-2)\nhex inference add ollama http://localhost:11434 --model qwen3:32b\n\n# Frontier for planning/validation (tier 3)\n# Set ANTHROPIC_API_KEY in environment\n```\n\n**Best of both worlds**:\n- Tier 1-2 agents run locally (free, fast, private)\n- Tier 3 agents use Anthropic API (high quality planning/validation)\n- Token cost reduced by ~70% vs. all-frontier\n\n#### Full Frontier (Anthropic API)\n\n```bash\n# All agents use Claude models\n# Set ANTHROPIC_API_KEY in environment\n# No hex inference setup needed \u2014 uses Anthropic directly\n```\n\n### MiniMax Models\n\nMiniMax models (minimax-m1) are available through Ollama:\n\n```bash\n# Pull MiniMax model\nollama pull minimax-m1:80b\n\n# Register with hex\nhex inference add ollama http://localhost:11434 --model minimax-m1:80b\n```\n\n**MiniMax tier mapping**:\n- `minimax-m1:80b` \u2192 Tier 2-3 (strong reasoning, competitive with frontier for coding)\n- Good for: hex-coder, planner, behavioral-spec-writer\n- Caveat: Context window may be smaller than frontier \u2014 reduce `token_budget.max` in agent definitions\n\n### Qwen Models\n\n```bash\n# Qwen 3 (recommended for hex)\nollama pull qwen3:32b        # Tier 2 \u2014 best balance of speed/quality\nollama pull qwen3:4b          # Tier 1 \u2014 fast, status checks only\nollama pull qwen3:235b        # Tier 3 \u2014 if you have the VRAM/RAM\n\n# Qwen 3.5 (latest)\nollama pull qwen3.5:27b       # Tier 2 \u2014 newer, potentially better coding\n\n# Register the primary model\nhex inference add ollama http://localhost:11434 --model qwen3:32b\n```\n\n## Configuring hex-agent for Local Models\n\nWhen running hex-agent with local inference:\n\n```bash\n# Set the Ollama endpoint\nexport HEX_OLLAMA_HOST=http://localhost:11434\nexport HEX_OLLAMA_MODEL=qwen3:32b\n\n# Run hex-agent\nhex-agent --project-dir .\n```\n\n### Context Window Adjustments\n\nLocal models typically have smaller context windows. Adjust agent token budgets:\n\n| Model | Context Window | Recommended `token_budget.max` |\n|-------|---------------|-------------------------------|\n| qwen3:4b | 32K | 20000 |\n| qwen3:32b | 128K | 60000 |\n| qwen3:235b | 128K | 80000 |\n| minimax-m1:80b | 128K | 60000 |\n| Claude Sonnet | 200K | 80000 |\n| Claude Opus | 200K+ | 120000 |\n\nWhen using a local model with a smaller context window:\n- Use L0/L1 summaries instead of L2 (less context consumed)\n- Break features into smaller steps\n- Reduce the number of parallel agents (fewer concurrent context windows)\n\n## Inference Routing\n\nhex-nexus routes inference requests based on provider priority:\n\n1. **Registered providers** (via `hex inference add`) \u2014 checked first\n2. **Environment variables** (`HEX_OLLAMA_HOST`, etc.) \u2014 fallback\n3. **Anthropic API** (`ANTHROPIC_API_KEY`) \u2014 final fallback\n\nWhen SpacetimeDB is running, the `inference-gateway` WASM module handles routing. The module stores request/response state; hex-nexus performs the actual HTTP calls (WASM can't make network requests).\n\n## Troubleshooting\n\n| Issue | Fix |\n|-------|-----|\n| \"Connection refused\" | Ensure Ollama is running: `ollama serve` |\n| \"Connection timeout\" | Ollama may be bound to localhost. Fix: `OLLAMA_HOST=0.0.0.0 ollama serve` |\n| Slow inference | Check GPU utilization. Ollama defaults to CPU if no GPU detected |\n| Out of memory | Use a smaller model or enable partial offloading |\n| Model not found | Pull it first: `ollama pull qwen3:32b` |\n\n## Quick Reference\n\n| Command | What it does |\n|---------|-------------|\n| `hex inference discover` | Auto-discover Ollama instances on LAN |\n| `hex inference add ollama <url> --model <model>` | Register Ollama provider |\n| `hex inference add vllm <url> --model <model>` | Register vLLM provider |\n| `hex inference list` | List all registered providers |\n| `hex inference test <url>` | Test connectivity + run inference probe |\n| `hex inference remove <id>` | Remove a provider |"
    },
    "hex-project-output": {
      "description": "Every hex project created by an agent must include README.md and a startup script. Defines the required output structure for scaffold-validator. Use when creating new projects, examples, or applications.",
      "template": "# Project Output Requirements\n\nWhen creating a new project, application, or multi-file codebase, you MUST include these files alongside the code:\n\n## Required Files\n\n### 1. README.md\n\nEvery project directory must contain a `README.md` with:\n\n```markdown\n# {Project Name}\n\n{One-line description}\n\n## What This Does\n\n{2-3 sentences explaining the project purpose and key features}\n\n## Prerequisites\n\n- {runtime} (e.g., Python 3.10+, Node.js 18+, Rust 1.75+)\n- {any dependencies or system requirements}\n\n## Quick Start\n\n```bash\n./start.sh\n```\n\n## Usage\n\n{Show the main commands/API with examples}\n\n## File Structure\n\n```\nproject/\n  file1.py    \u2014 {purpose}\n  file2.py    \u2014 {purpose}\n  start.sh    \u2014 startup script\n  README.md   \u2014 this file\n```\n\n## How It Works\n\n{Brief architecture explanation \u2014 what talks to what}\n```\n\n### 2. start.sh (or run.sh)\n\nAn executable startup script that:\n- Installs dependencies if needed (pip install, npm install, etc.)\n- Sets up any required directories or config\n- Runs the application\n- Is idempotent (safe to run multiple times)\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\n# Install deps (if needed)\npip install -r requirements.txt 2>/dev/null || true\n\n# Run\npython3 main.py \"$@\"\n```\n\nMake it executable: `chmod +x start.sh`\n\n## File Creation Order\n\nWhen building a multi-file project, create files in this order:\n\n1. **Directory structure** \u2014 `mkdir -p` the project directory\n2. **Domain/model files** \u2014 data structures, types\n3. **Library/backend files** \u2014 business logic, storage\n4. **Main/CLI files** \u2014 entry point, argument parsing\n5. **start.sh** \u2014 startup script\n6. **README.md** \u2014 documentation (write LAST so it accurately reflects what was built)\n\n## Verification\n\nAfter creating all files, ALWAYS:\n1. Run `start.sh` or the main entry point to verify it works\n2. Show the output to confirm correctness\n3. If it fails, fix the issue and re-run\n\n## Examples\n\n### Python CLI App\n```\ntodo-app/\n  models.py     \u2014 TodoItem dataclass\n  storage.py    \u2014 JSON file storage backend\n  todo.py       \u2014 CLI entry point (argparse)\n  start.sh      \u2014 #!/bin/bash \u2014 python3 todo.py \"$@\"\n  README.md     \u2014 usage docs\n```\n\n### Node.js Web App\n```\nweb-app/\n  src/\n    server.js   \u2014 Express server\n    routes.js   \u2014 API routes\n  package.json  \u2014 dependencies\n  start.sh      \u2014 npm install && node src/server.js\n  README.md     \u2014 API docs\n```\n\n### Rust Binary\n```\nmy-tool/\n  src/\n    main.rs     \u2014 entry point\n    lib.rs      \u2014 core logic\n  Cargo.toml    \u2014 dependencies\n  start.sh      \u2014 cargo run --release -- \"$@\"\n  README.md     \u2014 usage docs\n```"
    },
    "hex-publish-module": {
      "description": "Publish a SpacetimeDB WASM module with the full pipeline \u2014 publish, regen bindings, bump schema version, rebuild, restart",
      "template": "# SpacetimeDB Module Publish Pipeline\n\nWhen a SpacetimeDB WASM module schema changes (fields added/removed, reducer signatures changed), follow this exact pipeline:\n\n## Steps\n\n1. **Publish the module** (from its directory):\n```bash\ncd spacetime-modules/<MODULE_NAME>\necho \"y\" | spacetime publish <MODULE_NAME> --clear-database\n```\n\n2. **Regenerate TypeScript bindings**:\n```bash\ncd /Volumes/ExtendedStorage/PARA/01-Projects/hex-intf\nspacetime generate --lang typescript \\\n  --out-dir hex-nexus/assets/src/spacetimedb/<MODULE_NAME> \\\n  --module-path spacetime-modules/<MODULE_NAME>\n```\n\n3. **Bump SCHEMA_VERSION** in `hex-nexus/assets/src/stores/connection.ts`:\n   - Find `const SCHEMA_VERSION = \"N\"` and increment N\n   - This forces browser localStorage token clearing on next load\n\n4. **Rebuild hex-nexus + hex-cli**:\n```bash\ncargo build -p hex-nexus -p hex-cli --release\n```\n\n5. **Restart nexus**:\n```bash\ncargo run -p hex-cli --release -- nexus stop\nsleep 1\ncargo run -p hex-cli --release -- nexus start\n```\n\n6. **Re-register project + agent** (data was cleared):\n```bash\n# Register project\ntarget/release/hex dashboard register /Volumes/ExtendedStorage/PARA/01-Projects/hex-intf\n\n# Register agent\nCLAUDE_PROJECT_DIR=\"/Volumes/ExtendedStorage/PARA/01-Projects/hex-intf\" \\\nCLAUDE_SESSION_ID=\"session-$(date +%s)\" \\\nCLAUDE_MODEL=\"claude-opus-4-6\" \\\nnode .claude/helpers/agent-register.cjs register\n```\n\n## Available modules\n\n| Module | Directory | Tables |\n|--------|-----------|--------|\n| hexflo-coordination | spacetime-modules/hexflo-coordination | swarm, swarm_task, swarm_agent, project, etc |\n| agent-registry | spacetime-modules/agent-registry | agent, agent_heartbeat |\n| inference-gateway | spacetime-modules/inference-gateway | inference_provider, inference_request, etc |\n| fleet-state | spacetime-modules/fleet-state | compute_node |\n\n## Critical notes\n\n- **Never publish from workspace root** \u2014 `uuid` compile error. Always `cd` into the module directory first.\n- **Always bump SCHEMA_VERSION** \u2014 stale SDK tokens cause `DataView` deserialization crashes.\n- **`--clear-database` destroys all data** \u2014 re-registration of project and agents is required.\n- **Rebuild is required** \u2014 the Rust binary embeds the reducer call signatures; stale binary \u2192 \"invalid arguments\" errors."
    },
    "hex-scaffold": {
      "description": "Scaffold a new hexagonal architecture project. Use when the user asks to \"create hex project\", \"scaffold hexagonal\", \"new ports and adapters project\", \"hex init\", or \"init hexagonal project\".",
      "template": "# Hex Scaffold \u2014 Create a Hexagonal Architecture Project\n\nCRITICAL: Do NOT enter plan mode (EnterPlanMode). Proceed directly with execution.\n\nIf the `--yes` or `-y` flag was passed (check `ctx.autoConfirm`), skip Phase 1 entirely and use these defaults:\n- Interface: CLI\n- Storage: JSON file\n- Entities: inferred from project name or user description\n- Style: Minimal MVP\nThen go straight to Phase 2: Scaffold.\n\nOtherwise, use AskUserQuestion for an interactive wizard experience.\n\n## Phase 1: Interactive Discovery Wizard (skipped with --yes)\n\nUse the AskUserQuestion tool to gather requirements interactively. Ask in batches of 3-4 questions max.\n\n### Wizard Step 1 (3 questions)\n\n```tool\nAskUserQuestion({\n  questions: [\n    {\n      question: \"How will users interact with this application?\",\n      header: \"Interface\",\n      multiSelect: true,\n      options: [\n        { label: \"CLI (Recommended)\", description: \"Terminal commands like `myapp add \\\"task\\\"`. Fastest to scaffold, works everywhere.\" },\n        { label: \"Web UI\", description: \"Browser-based interface with local server. Great for visual apps.\" },\n        { label: \"REST API\", description: \"JSON API for other services. Good for backends and microservices.\" },\n        { label: \"Library\", description: \"Imported as npm package. No runtime interface, just typed exports.\" }\n      ]\n    },\n    {\n      question: \"Where should this app store its data?\",\n      header: \"Storage\",\n      multiSelect: false,\n      options: [\n        { label: \"JSON file (Recommended)\", description: \"Simple file persistence. Perfect for CLIs and small tools.\" },\n        { label: \"SQLite\", description: \"Embedded database. Good for queries and local apps.\" },\n        { label: \"In-memory only\", description: \"No persistence. Good for stream processors and libraries.\" },\n        { label: \"External API\", description: \"Delegates storage to another service via HTTP/gRPC.\" }\n      ]\n    },\n    {\n      question: \"What are the main domain entities? (the core nouns)\",\n      header: \"Entities\",\n      multiSelect: false,\n      options: [\n        { label: \"Todo, TodoList\", description: \"Task management domain\" },\n        { label: \"User, Session\", description: \"Authentication domain\" },\n        { label: \"Event, Handler\", description: \"Event processing domain\" },\n        { label: \"Custom\", description: \"I'll describe my own entities\" }\n      ]\n    }\n  ]\n})\n```\n\n### Wizard Step 2 (1-2 questions, based on Step 1 answers)\n\nUse AskUserQuestion with preview to show the proposed architecture:\n\n```tool\nAskUserQuestion({\n  questions: [\n    {\n      question: \"Here's the architecture plan. Which style fits your project?\",\n      header: \"Style\",\n      multiSelect: false,\n      options: [\n        {\n          label: \"Minimal MVP\",\n          description: \"Just the core CRUD operations. Ship fast, add later.\",\n          preview: \"src/\\n  core/\\n    domain/entities.ts     # 1 entity\\n    ports/index.ts         # 3 interfaces\\n    usecases/service.ts    # CRUD logic\\n  adapters/\\n    primary/cli.ts         # 5 commands\\n    secondary/storage.ts   # JSON file\\n  composition-root.ts\\ntests/\\n  unit/service.test.ts\\n\\n~8 files, ~600 lines\"\n        },\n        {\n          label: \"Full Featured\",\n          description: \"CRUD + filtering + stats + validation + events.\",\n          preview: \"src/\\n  core/\\n    domain/\\n      value-objects.ts    # IDs, statuses, types\\n      entities.ts         # Entities + events\\n    ports/index.ts         # 5 interfaces (CQRS)\\n    usecases/service.ts    # Full orchestration\\n  adapters/\\n    primary/cli.ts         # 8+ commands\\n    secondary/storage.ts   # Atomic writes\\n  composition-root.ts\\ntests/\\n  unit/\\n    entities.test.ts\\n    service.test.ts\\n\\n~12 files, ~1200 lines\"\n        },\n        {\n          label: \"Production\",\n          description: \"Full featured + error handling + logging + health checks.\",\n          preview: \"src/\\n  core/\\n    domain/\\n      value-objects.ts\\n      entities.ts\\n      errors.ts          # Domain error types\\n    ports/\\n      commands.ts         # Write operations\\n      queries.ts          # Read operations\\n      storage.ts          # Persistence\\n    usecases/service.ts\\n  adapters/\\n    primary/\\n      cli.ts\\n      http.ts            # REST + health\\n    secondary/\\n      storage.ts\\n      logger.ts\\n  composition-root.ts\\ntests/\\n  unit/ (3 files)\\n  integration/ (1 file)\\n\\n~16 files, ~1800 lines\"\n        }\n      ]\n    }\n  ]\n})\n```\n\n## Phase 2: Scaffold Based on Answers\n\nAfter the wizard completes, generate ONLY the files that match the user's choices.\n\n### Map answers to adapters:\n\n| User chose | Primary adapter to create |\n|-----------|--------------------------|\n| CLI | `src/adapters/primary/cli-adapter.ts` with arg parsing |\n| Web UI | `src/adapters/primary/http-adapter.ts` serving HTML |\n| REST API | `src/adapters/primary/http-adapter.ts` JSON-only |\n| Library | Just `src/index.ts` with type exports |\n\n| User chose | Secondary adapter to create |\n|-----------|---------------------------|\n| JSON file | `src/adapters/secondary/json-storage.ts` |\n| SQLite | `src/adapters/secondary/sqlite-storage.ts` |\n| In-memory | `src/adapters/secondary/memory-storage.ts` |\n| External API | `src/adapters/secondary/api-storage.ts` |\n\n### Generate in order:\n\n1. `mkdir -p` for directory structure\n2. Domain layer (value-objects.ts, entities.ts) \u2014 zero external imports\n3. Ports (index.ts) \u2014 imports only domain types\n4. Use cases (service.ts) \u2014 imports domain + ports\n5. Selected primary adapter(s) \u2014 imports ports only\n6. Selected secondary adapter \u2014 imports ports only\n7. composition-root.ts \u2014 the ONLY cross-boundary file\n8. Entry point (cli.ts or index.ts)\n9. Tests (London-school mocks)\n10. package.json, tsconfig.json, README.md\n\n### Verify:\n\nRun `bun test` and verify the app works end-to-end via the chosen primary adapter.\n\n## Rules\n\n- Domain imports NOTHING external\n- Ports import only from domain\n- Adapters import only from ports\n- composition-root.ts is the ONLY cross-boundary file\n- All imports use `.js` extensions\n- Every file under 150 lines\n- The app MUST actually work after scaffolding\n- NEVER scaffold adapters the user didn't ask for"
    },
    "hex-spacetime": {
      "description": "Guide SpacetimeDB WASM module development for hex. Use when the user asks to \"create module\", \"spacetimedb\", \"wasm module\", \"new reducer\", \"spacetime table\", \"add spacetime module\", or works in spacetime-modules/.",
      "template": "# Hex SpacetimeDB \u2014 WASM Module Development Guide\n\nSpacetimeDB is hex's coordination backbone \u2014 18+ WASM modules provide transactional state management for swarms, agents, inference, chat, architecture enforcement, and more. All clients (web dashboard, CLI, desktop) connect via WebSocket for real-time synchronization.\n\n## Critical Constraints\n\nSpacetimeDB WASM modules run in a **sandboxed environment**. Understanding these constraints is essential:\n\n| Capability | Allowed? | Workaround |\n|-----------|----------|------------|\n| Read/write files | NO | Delegate to hex-nexus REST API |\n| Network requests | NO | Delegate to hex-nexus (inference-bridge pattern) |\n| Spawn processes | NO | Delegate to hex-nexus |\n| Access env vars | NO | Pass config via reducer arguments |\n| Persistent state | YES | SpacetimeDB tables (automatic persistence) |\n| WebSocket push | YES | Client subscriptions (automatic) |\n| Cross-module calls | LIMITED | Via shared tables, not direct function calls |\n\n**Key implication**: Any operation requiring filesystem, network, or process access must go through hex-nexus as a bridge. The WASM module stores intent/state, and hex-nexus reads that state via WebSocket subscription and performs the actual I/O.\n\n## Module Structure\n\nEvery SpacetimeDB module follows this pattern:\n\n```\nspacetime-modules/<module-name>/\n  Cargo.toml          # Depends on spacetimedb crate\n  src/\n    lib.rs            # Tables + reducers\n```\n\n### Cargo.toml Template\n\n```toml\n[package]\nname = \"<module-name>\"\nversion = \"0.1.0\"\nedition = \"2021\"\n\n[lib]\ncrate-type = [\"cdylib\"]\n\n[dependencies]\nspacetimedb = \"1.0\"\nlog = \"0.4\"\n\n[profile.release]\nopt-level = \"s\"       # Optimize for size (WASM binary)\nlto = true\n```\n\n### lib.rs Template\n\n```rust\nuse spacetimedb::{table, reducer, Table, ReducerContext, Identity, Timestamp};\n\n// \u2500\u2500 Tables \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// Tables are automatically persisted and subscribable via WebSocket.\n\n#[table(name = my_entity, public)]\npub struct MyEntity {\n    #[primary_key]\n    #[auto_inc]\n    pub id: u64,\n    pub name: String,\n    pub status: String,\n    pub created_at: Timestamp,\n    pub owner: Identity,\n}\n\n// \u2500\u2500 Reducers \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// Reducers are transactional functions callable by clients.\n// They run atomically \u2014 if they panic, the transaction is rolled back.\n\n#[reducer]\npub fn create_entity(ctx: &ReducerContext, name: String) -> Result<(), String> {\n    let entity = MyEntity {\n        id: 0,  // auto_inc fills this\n        name,\n        status: \"active\".to_string(),\n        created_at: ctx.timestamp,\n        owner: ctx.sender,\n    };\n    ctx.db.my_entity().insert(entity);\n    Ok(())\n}\n\n#[reducer]\npub fn update_entity_status(ctx: &ReducerContext, id: u64, status: String) -> Result<(), String> {\n    let entity = ctx.db.my_entity()\n        .id()\n        .find(id)\n        .ok_or_else(|| format!(\"Entity {} not found\", id))?;\n\n    ctx.db.my_entity().id().delete(id);\n    ctx.db.my_entity().insert(MyEntity { status, ..entity });\n    Ok(())\n}\n\n// \u2500\u2500 Init reducer \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// Called once when the module is first published.\n\n#[reducer(init)]\npub fn init(ctx: &ReducerContext) {\n    log::info!(\"Module initialized at {:?}\", ctx.timestamp);\n}\n```\n\n## Existing Modules Reference\n\n| Module | Purpose | Key Tables |\n|--------|---------|------------|\n| `hexflo-coordination` | Core swarm/task/agent/memory/project/config state | swarm, swarm_task, swarm_agent, hexflo_memory |\n| `agent-registry` | Agent lifecycle + heartbeats | agent, agent_heartbeat |\n| `inference-gateway` | LLM request routing | inference_request, inference_response |\n| `workplan-state` | Task status + phase tracking | workplan, workplan_step |\n| `chat-relay` | Message routing between agents/users | chat_message, chat_channel |\n| `fleet-state` | Compute node registry | fleet_node, node_capability |\n| `architecture-enforcer` | Server-side boundary validation | boundary_rule, violation_record |\n\n## Creating a New Module\n\n### Step 1: Scaffold\n\n```bash\nmkdir -p spacetime-modules/<module-name>/src\n```\n\nCreate `Cargo.toml` and `src/lib.rs` using the templates above.\n\n### Step 2: Add to Workspace\n\nEdit the root `Cargo.toml` to add the new module:\n```toml\n[workspace]\nmembers = [\n    # ... existing members ...\n    \"spacetime-modules/<module-name>\",\n]\n```\n\n### Step 3: Build\n\n```bash\ncargo build -p <module-name> --target wasm32-unknown-unknown --release\n```\n\nThe WASM binary will be at:\n```\ntarget/wasm32-unknown-unknown/release/<module_name>.wasm\n```\n\n### Step 4: Publish to SpacetimeDB\n\n```bash\nspacetime publish <module-name> \\\n  --project-path spacetime-modules/<module-name> \\\n  --clear-database  # Only on first publish or schema changes\n```\n\n### Step 5: Generate Client Bindings\n\nFor the dashboard (TypeScript):\n```bash\nspacetime generate --lang typescript \\\n  --out-dir hex-nexus/assets/src/spacetimedb/<module-name> \\\n  --project-path spacetime-modules/<module-name>\n```\n\nFor hex-nexus (Rust):\n```bash\n# hex-nexus connects via the spacetimedb-sdk crate\n# Add the module's types to hex-nexus/src/adapters/spacetimedb/\n```\n\n## Design Patterns\n\n### Bridge Pattern (for I/O operations)\n\nWhen a WASM module needs to trigger filesystem or network operations:\n\n```\n1. Client calls reducer \u2192 stores \"intent\" in a table\n2. hex-nexus subscribes to that table via WebSocket\n3. hex-nexus sees new row \u2192 performs the I/O\n4. hex-nexus calls another reducer to store the result\n5. Original client sees the result via subscription\n```\n\nExample: Inference requests\n```\nClient \u2192 inference_gateway.request_inference(prompt)\n  \u2192 Inserts row in inference_request table (status: \"pending\")\n\nhex-nexus subscription fires \u2192 sees pending request\n  \u2192 Makes HTTP call to LLM API\n  \u2192 Calls inference_gateway.complete_inference(id, response)\n    \u2192 Updates inference_request status to \"completed\"\n\nClient subscription fires \u2192 sees completed request \u2192 reads response\n```\n\n### Shared Table Pattern (for cross-module communication)\n\nModules cannot call each other's reducers directly. Instead, they share state via tables:\n\n```\nModule A writes to shared_events table\nModule B subscribes to shared_events table\nModule B reads new events and acts on them\n```\n\n### Identity-Scoped Access\n\nUse `ctx.sender` (Identity) to scope data access:\n\n```rust\n#[reducer]\npub fn get_my_tasks(ctx: &ReducerContext) -> Result<(), String> {\n    let tasks: Vec<_> = ctx.db.swarm_task()\n        .iter()\n        .filter(|t| t.assignee == ctx.sender)\n        .collect();\n    // Tasks are returned via subscription, not return value\n    Ok(())\n}\n```\n\n## Testing\n\nSpacetimeDB modules are tested via integration tests that publish to a local instance:\n\n```bash\n# Start local SpacetimeDB\nspacetime start\n\n# Publish and test\nspacetime publish <module> --project-path spacetime-modules/<module>\n\n# Run integration tests\ncargo test -p <module> --test integration\n```\n\nUnit tests for pure logic can run normally:\n```rust\n#[cfg(test)]\nmod tests {\n    use super::*;\n\n    #[test]\n    fn test_status_transition() {\n        assert!(is_valid_transition(\"pending\", \"active\"));\n        assert!(!is_valid_transition(\"completed\", \"pending\"));\n    }\n}\n```\n\n## Common Mistakes\n\n| Mistake | Why it fails | Fix |\n|---------|-------------|-----|\n| `std::fs::read()` in reducer | WASM sandbox blocks filesystem | Use bridge pattern via hex-nexus |\n| `reqwest::get()` in reducer | WASM sandbox blocks network | Use bridge pattern via hex-nexus |\n| `std::env::var()` in reducer | No env vars in WASM | Pass config via reducer arguments |\n| Large WASM binary | Slow publish, memory limits | Use `opt-level = \"s\"` and `lto = true` |\n| Direct cross-module calls | Not supported | Use shared table pattern |\n| Returning data from reducer | Reducers don't return data to caller | Use table subscriptions |\n\n## Quick Reference\n\n| Task | Command |\n|------|---------|\n| Build module | `cargo build -p <module> --target wasm32-unknown-unknown --release` |\n| Publish module | `spacetime publish <module> --project-path spacetime-modules/<module>` |\n| Generate TS bindings | `spacetime generate --lang typescript --out-dir hex-nexus/assets/src/spacetimedb/<module>` |\n| View logs | `spacetime logs <module>` |\n| List tables | `spacetime sql <module> \"SELECT name FROM st_table\"` |\n| Query table | `spacetime sql <module> \"SELECT * FROM <table>\"` |"
    },
    "hex-summarize": {
      "description": "Generate token-efficient AST summaries of source files. Use when the user asks to \"summarize project\", \"ast summary\", \"token context\", \"generate context\", \"project overview\", or \"what does this project do\".",
      "template": "# Hex Summarize \u2014 Tree-Sitter AST Summaries for LLM Context\n\nGenerates tree-sitter AST summaries at configurable detail levels, compressing source files to ~10% token count while preserving structural information needed for code generation and navigation.\n\n## Parameters\n\nAsk the user for:\n- **target** (optional, default: \".\"): File or directory path to summarize\n- **level** (optional, default: L1): Summary detail level (L0, L1, L2, or L3)\n- **format** (optional, default: text): Output format \u2014 `text`, `json`, or `markdown`\n- **filter** (optional): Glob pattern to filter files (e.g., `**/*.ts`, `src/adapters/**`)\n- **max_tokens** (optional, default: 50000): Maximum total tokens for output\n- **include_tests** (optional, default: false): Whether to include test files\n\n## Summary Levels Explained\n\n| Level | Name | Tokens/File | What It Captures |\n|-------|------|-------------|------------------|\n| L0 | Index | ~5 | Filename, language, line count |\n| L1 | Skeleton | ~50 | Exports, imports, dependencies |\n| L2 | Signatures | ~200 | Full type signatures, params, return types |\n| L3 | Full | ~2000 | Complete source code (use sparingly) |\n\n## Execution\n\n### 1. Discover Files\n\nFind all source files (`.ts`, `.go`, `.rs`) in the target path, excluding `node_modules`, `dist`, `target`, and optionally test files.\n\n### 2. Run hex summarize\n\nFor a single file:\n```bash\nnpx hex summarize <file> --level <L0|L1|L2|L3>\n```\n\nFor a directory:\n```bash\nnpx hex summarize <directory> --level <L0|L1|L2|L3>\n```\n\nIf a filter is specified, apply it to limit which files are summarized.\n\n### 3. Token Budget Management\n\nEstimate tokens using `word_count * 1.3` heuristic. If total exceeds max_tokens:\n1. Drop L2 files to L1\n2. Drop L1 files to L0\n3. Prioritize: ports > domain > adapters > infrastructure\n\n### 4. Format Output\n\n- **text**: Plain text with `---` separators between files\n- **json**: Structured JSON with filePath, language, level, exports, imports, dependencies, lineCount, tokenEstimate per file\n- **markdown**: Table format with file, language, lines, tokens, exports columns\n\n### 5. Write Output\n\nDisplay the summary to the user. If json or markdown format, also write to `docs/context/{level}-summary.{ext}`.\n\n## Output\n\nReport: level used, number of files summarized, estimated token count, and compression ratio (original tokens vs summary tokens)."
    },
    "hex-swarm": {
      "description": "Manage HexFlo swarm coordination for multi-agent development. Use when the user asks to \"start swarm\", \"swarm status\", \"coordinate agents\", \"multi-agent\", \"parallel agents\", \"hexflo\", or \"swarm cleanup\".",
      "template": "# Hex Swarm \u2014 HexFlo Multi-Agent Coordination\n\nHexFlo is hex's native Rust swarm coordination layer (ADR-027). It manages task tracking, agent lifecycle, memory persistence, and heartbeat monitoring for multi-agent feature development. State lives in SpacetimeDB with SQLite fallback.\n\n## When to Use Swarm Mode\n\n| Scenario | Mode | Why |\n|----------|------|-----|\n| Feature spans 2+ adapters | **Swarm** | Parallel worktrees, multiple hex-coder agents |\n| Single adapter change | Single-agent | Overhead not justified |\n| Critical/learning feature | Interactive | Human review at each phase |\n\n## Parameters\n\nAsk the user for:\n- **action** (required): One of: init, status, monitor, cleanup, recover\n- **name** (required for init): Swarm name (usually the feature name)\n- **topology** (optional, default: hierarchical): hierarchical, mesh, or pipeline\n\n## Action: init\n\nInitialize a new HexFlo swarm for a feature.\n\n### Steps\n\n1. Initialize the swarm:\n```tool\nmcp__hex__hex_hexflo_swarm_init({\n  topology: \"hierarchical\",\n  maxAgents: 8,\n  strategy: \"specialized\"\n})\n```\n\n2. Reconcile any prior state from previous sessions:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n3. Cross-reference against git history:\n```bash\ngit log --oneline -10\n```\n\n4. Mark any completed tasks:\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"...\",\n  result: \"feat(adapter): summary \u2014 commit abc1234\"\n})\n```\n\n5. Store swarm metadata:\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"swarm/<name>/config\",\n  value: {\n    name: \"<name>\",\n    topology: \"hierarchical\",\n    max_agents: 8,\n    started_at: \"ISO timestamp\",\n    feature: \"<feature-name>\"\n  }\n})\n```\n\n### Topology Options\n\n- **hierarchical** (default): Coordinator \u2192 planner \u2192 hex-coders \u2192 integrator. Best for features with clear dependency tiers.\n- **mesh**: All agents peer-to-peer. Best for independent tasks with minimal coordination.\n- **pipeline**: Sequential handoff. Best for linear workflows (spec \u2192 plan \u2192 code \u2192 validate).\n\n## Action: status\n\nShow the current swarm state.\n\n### Steps\n\n1. Get swarm status:\n```tool\nmcp__hex__hex_hexflo_swarm_status()\n```\n\n2. Get all tasks:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n3. Report:\n   - Active swarm name and topology\n   - Tasks by status: pending, in_progress, completed, failed\n   - Agent assignments and heartbeat status\n   - Current tier being executed\n   - Estimated completion (tasks remaining / rate)\n\n## Action: monitor\n\nContinuous monitoring of swarm progress. Use during active multi-agent execution.\n\n### Steps\n\n1. Check task list for newly completed agents:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n2. For each newly completed task:\n   - Verify the commit exists: `git log --oneline -1 <hash>`\n   - Mark task complete in HexFlo\n   - Check if next-tier tasks are unblocked\n\n3. For stale agents (no heartbeat in 45s):\n   - Flag as potentially stuck\n   - After 120s, reclaim tasks and reassign\n\n4. When all tasks in a tier complete:\n   - Update progress in HexFlo memory\n   - Spawn agents for the next tier\n   - Report tier completion to user\n\n5. Retrieve progress:\n```tool\nmcp__hex__hex_hexflo_memory_retrieve({\n  key: \"feature/<feature>/progress\"\n})\n```\n\n## Action: cleanup\n\nTear down a completed or abandoned swarm.\n\n### Steps\n\n1. Get final task status:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n2. Verify all tasks are completed or explicitly abandoned\n\n3. Store final report:\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"swarm/<name>/final-report\",\n  value: {\n    status: \"completed\",\n    tasks_total: N,\n    tasks_completed: N,\n    tasks_failed: N,\n    duration_minutes: N,\n    completed_at: \"ISO timestamp\"\n  }\n})\n```\n\n4. Clean up stale agent registrations:\n```bash\nhex swarm cleanup\n```\n\n## Action: recover\n\nResume a swarm from a previous session.\n\n### Steps\n\n1. Retrieve swarm config:\n```tool\nmcp__hex__hex_hexflo_memory_retrieve({\n  key: \"swarm/<name>/config\"\n})\n```\n\n2. Retrieve progress:\n```tool\nmcp__hex__hex_hexflo_memory_retrieve({\n  key: \"feature/<feature>/progress\"\n})\n```\n\n3. Get current task list and reconcile against git log:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n4. For tasks marked in_progress but with commits:\n```tool\nmcp__hex__hex_hexflo_task_complete({\n  task_id: \"...\",\n  result: \"Recovered from previous session \u2014 commit <hash>\"\n})\n```\n\n5. Resume spawning agents for the next incomplete tier\n\n## Agent Spawning Rules\n\n**CRITICAL**: Background agents that write files MUST use `mode: \"bypassPermissions\"`.\n\n```\nAgent({\n  subagent_type: \"coder\",\n  mode: \"bypassPermissions\",        # REQUIRED for background file writes\n  run_in_background: true,\n  prompt: \"...\"\n})\n```\n\n**WRONG** \u2014 silently blocks all file writes:\n```\nAgent({ mode: \"acceptEdits\", run_in_background: true })\n```\n\n### Parallel Spawning\n\nSpawn ALL independent agents in a SINGLE message with multiple tool calls:\n```\n# Tier 1: secondary adapters (all independent)\nAgent({ prompt: \"git-adapter task...\", run_in_background: true })\nAgent({ prompt: \"fs-adapter task...\", run_in_background: true })\nAgent({ prompt: \"llm-adapter task...\", run_in_background: true })\n```\n\n## Heartbeat Protocol\n\n| Event | Timeout | Action |\n|-------|---------|--------|\n| Heartbeat sent | Every 15s | Agent alive |\n| No heartbeat | 45s | Mark agent stale |\n| No heartbeat | 120s | Mark agent dead, reclaim tasks |\n\n## HexFlo Memory Scopes\n\n| Scope | Key Pattern | Use |\n|-------|-------------|-----|\n| Global | `swarm/<name>/*` | Swarm-level config and reports |\n| Feature | `feature/<name>/*` | Feature progress, worktrees, workplan |\n| Agent | `agent/<id>/*` | Per-agent state (rare) |\n\n## Quick Reference\n\n| Command | What it does |\n|---------|-------------|\n| `/hex-swarm init <name>` | Initialize a new HexFlo swarm |\n| `/hex-swarm status` | Show swarm state and task progress |\n| `/hex-swarm monitor` | Monitor active multi-agent execution |\n| `/hex-swarm cleanup` | Tear down completed swarm |\n| `/hex-swarm recover` | Resume swarm from previous session |"
    },
    "hex-validate": {
      "description": "Run post-build semantic validation with behavioral specs and property tests. Use when the user asks to \"validate app\", \"post-build check\", \"judge the build\", \"semantic validation\", or \"run validation judge\".",
      "template": "# Hex Validate \u2014 Post-Build Semantic Validation\n\nRuns the post-build validation judge to catch semantic bugs that compile-lint-test pipelines miss. Produces a PASS/FAIL verdict with behavioral spec results, property test results, smoke test results, and sign convention audit.\n\n## Parameters\n\nAsk the user for:\n- **problem_statement** (required): Original user prompt describing what they want built. Used to derive behavioral specs and expected behavior.\n- **domain_path** (required): Path to generated domain code (e.g., \"src/core\")\n- **test_path** (optional, default: \"tests/\"): Path to generated test files\n- **output_dir** (optional, default: \"docs/analysis\"): Where to write the verdict report\n- **fix_on_fail** (optional, default: false): If true, automatically iterate on FAIL verdict\n\n## Execution Steps\n\n### 1. Derive Behavioral Specs\n\nFrom the problem_statement, derive expected behaviors:\n- List the key user-facing behaviors the system must exhibit\n- For each behavior, define a testable assertion (given/when/then format)\n- Identify edge cases and invariants\n\n### 2. Run Behavioral Spec Validation\n\nFor each derived behavioral spec:\n- Check if a corresponding test exists in test_path\n- Run the test and verify it passes\n- If no test exists, flag as \"untested behavior\"\n\nReport: specs tested, specs passing, specs failing, specs with no test coverage.\n\n### 3. Run Property Tests\n\nIdentify properties that should hold for all inputs:\n- Idempotency: calling an operation twice yields the same result\n- Commutativity: order-independent operations produce same output\n- Round-trip: serialize then deserialize returns original\n- Invariants: domain rules that must always hold\n\nRun property-based tests (if available) or flag missing property tests.\n\n### 4. Run Smoke Tests\n\nExecute basic end-to-end smoke tests:\n- Can the application start without errors?\n- Do the primary adapters respond to basic requests?\n- Does the happy path work end-to-end?\n\n### 5. Sign Convention Audit\n\nVerify consistency of:\n- Error codes and error message patterns\n- Return type conventions (Result vs throw vs null)\n- Naming conventions across the codebase\n- Port contract compliance (do adapters match port signatures exactly?)\n\n### 6. Compute Verdict\n\nScore each category (0-100):\n- Behavioral specs: weight 40%\n- Property tests: weight 20%\n- Smoke tests: weight 25%\n- Sign conventions: weight 15%\n\nOverall score = weighted average. Verdict:\n- **PASS**: score >= 80\n- **WARN**: score 60-79\n- **FAIL**: score < 60\n\n### 7. Write Verdict Report\n\nWrite to `{output_dir}/validation-verdict.md`:\n- Overall verdict (PASS/WARN/FAIL) and score\n- Behavioral spec results table\n- Property test results\n- Smoke test results\n- Sign convention audit findings\n- Fix instructions (if FAIL)\n\n### 8. Auto-Fix on Failure (Optional)\n\nIf fix_on_fail is true and verdict is FAIL:\n1. Extract fix instructions from the verdict\n2. Invoke the hex-generate skill with fix instructions\n3. Re-run validation\n4. Repeat up to 3 times\n\n## Output\n\nReport the verdict (PASS/WARN/FAIL), overall score, category breakdowns, and path to the verdict report."
    },
    "hex-workplan": {
      "description": "Create, validate, and manage hex workplans and behavioral specs. Use when the user asks to \"create workplan\", \"write a plan\", \"plan this feature\", \"workplan format\", \"spec format\", \"behavioral specs\", or \"decompose into tasks\".",
      "template": "# Hex Workplan \u2014 Feature Planning and Spec Authoring\n\nWorkplans are the structured task graphs that drive hex feature development. They decompose features into adapter-bounded steps with dependency ordering, tier assignment, and spec traceability. HexFlo executes workplans by dispatching agents per step.\n\n## Two Artifacts, One Pipeline\n\nEvery hex feature requires **two** JSON artifacts before code begins:\n\n1. **Behavioral Specs** \u2192 `docs/specs/<feature>.json`\n2. **Workplan** \u2192 `docs/workplans/feat-<feature>.json`\n\nSpecs come first (enforced by the hex-specs-required hook). The workplan references specs by ID so every coding task is traceable to a behavioral expectation.\n\n---\n\n## Behavioral Spec Format\n\nLocation: `docs/specs/<feature-name>.json`\n\n```json\n{\n  \"feature\": \"<feature-name>\",\n  \"description\": \"One-line summary of what this feature does\",\n  \"specs\": [\n    {\n      \"id\": \"S01\",\n      \"category\": \"CategoryName\",\n      \"description\": \"Human-readable description of the expected behavior\",\n      \"given\": \"Precondition \u2014 the state of the system before the action\",\n      \"when\": \"Action or event that triggers the behavior\",\n      \"then\": \"Expected outcome \u2014 the observable result\",\n      \"negative_spec\": false,\n      \"domain_conventions\": {\n        \"key\": \"Optional domain-specific conventions (encryption, coordinate systems, etc.)\"\n      }\n    }\n  ]\n}\n```\n\n### Spec Rules\n\n- **Minimum 3 specs** per feature (happy path, error case, edge case)\n- **At least 1 negative spec** (`negative_spec: true`) \u2014 what should NOT happen\n- **IDs are sequential**: S01, S02, S03...\n- **Categories group related behaviors**: e.g., \"LocalVaultAdapter\", \"CachingLayer\", \"CLI\"\n- **`given/when/then` must be implementation-agnostic** \u2014 describe behavior, not code\n- **`domain_conventions`** captures sign conventions, encryption params, coordinate systems, or any domain knowledge the coder needs\n\n### Spec Categories\n\nUse these standard categories where applicable:\n\n| Category | For |\n|----------|-----|\n| HappyPath | Normal successful operations |\n| ErrorHandling | Expected error conditions |\n| EdgeCase | Boundary values, empty inputs, limits |\n| Security | Auth, encryption, injection prevention |\n| Performance | Latency, throughput, resource constraints |\n| Integration | Cross-adapter interaction behavior |\n\n### Example Behavioral Spec\n\n```json\n{\n  \"feature\": \"user-auth\",\n  \"description\": \"JWT-based user authentication with refresh tokens\",\n  \"specs\": [\n    {\n      \"id\": \"S01\",\n      \"category\": \"HappyPath\",\n      \"description\": \"Valid credentials return a JWT token pair\",\n      \"given\": \"A registered user with email 'test@example.com' and valid password\",\n      \"when\": \"authenticate(email, password) is called\",\n      \"then\": \"Returns { accessToken: <JWT>, refreshToken: <UUID>, expiresIn: 3600 }\",\n      \"negative_spec\": false,\n      \"domain_conventions\": { \"jwt_algo\": \"HS256\", \"access_ttl_seconds\": 3600 }\n    },\n    {\n      \"id\": \"S02\",\n      \"category\": \"Security\",\n      \"description\": \"Invalid password is rejected without leaking which field failed\",\n      \"given\": \"A registered user with email 'test@example.com'\",\n      \"when\": \"authenticate(email, 'wrong-password') is called\",\n      \"then\": \"Returns error 'Invalid credentials' (no mention of 'password' specifically)\",\n      \"negative_spec\": true,\n      \"domain_conventions\": { \"security\": \"Uniform error message prevents username enumeration\" }\n    },\n    {\n      \"id\": \"S03\",\n      \"category\": \"EdgeCase\",\n      \"description\": \"Expired refresh token cannot generate new access token\",\n      \"given\": \"A refresh token that was issued 31 days ago (TTL is 30 days)\",\n      \"when\": \"refreshAccessToken(expiredToken) is called\",\n      \"then\": \"Returns error 'Refresh token expired' and does not issue new tokens\",\n      \"negative_spec\": true\n    }\n  ]\n}\n```\n\n---\n\n## Workplan Format\n\nLocation: `docs/workplans/feat-<feature-name>.json`\n\n```json\n{\n  \"id\": \"feat-<feature-name>\",\n  \"title\": \"Feature: <one-line description>\",\n  \"specs\": \"docs/specs/<feature-name>.json\",\n  \"adr\": \"ADR-NNN\",\n  \"created\": \"YYYY-MM-DD\",\n  \"status\": \"planned | in_progress | complete\",\n  \"topology\": \"hierarchical | mesh | pipeline\",\n  \"budget\": \"~NNNNN tokens\",\n  \"prior_work\": {\n    \"done\": [\n      \"List of files/components already completed (optional)\"\n    ]\n  },\n  \"steps\": [\n    {\n      \"id\": \"step-1\",\n      \"description\": \"What to implement in this step\",\n      \"layer\": \"domain|ports|usecases|adapters/primary|adapters/secondary|integration\",\n      \"adapter\": \"adapter-name (if applicable)\",\n      \"port\": \"IPortName (if applicable)\",\n      \"dependencies\": [],\n      \"tier\": 0,\n      \"specs\": [\"S01\", \"S02\"],\n      \"worktree_branch\": \"feat/<feature>/<adapter>\",\n      \"done_condition\": \"compile + specific test criteria\"\n    }\n  ],\n  \"dependencies\": {\n    \"cargo\": [\n      { \"name\": \"crate-name\", \"version\": \"1.0\", \"purpose\": \"why needed\" }\n    ],\n    \"npm\": [\n      { \"name\": \"package\", \"version\": \"^1.0\", \"purpose\": \"why needed\" }\n    ]\n  },\n  \"mergeOrder\": [\n    \"step-1 \u2192 step-2 (domain then ports)\",\n    \"step-3, step-4 parallel \u2192 step-5 last\"\n  ],\n  \"riskRegister\": [\n    { \"risk\": \"Description of what could go wrong\", \"impact\": \"high|medium|low\", \"mitigation\": \"How to handle it\" }\n  ],\n  \"successCriteria\": [\n    \"Observable outcome that proves the feature works end-to-end\"\n  ]\n}\n```\n\n### Workplan Fields\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| `id` | string | yes | Unique ID, format: `feat-<feature-name>` |\n| `title` | string | yes | Human-readable feature title |\n| `specs` | string | yes | Path to behavioral specs file |\n| `adr` | string | no | Related ADR (e.g., ADR-027) |\n| `created` | string | no | Creation date (YYYY-MM-DD) |\n| `status` | string | no | Runtime status: planned, in_progress, complete |\n| `topology` | string | no | Swarm topology: hierarchical, mesh, pipeline |\n| `budget` | string | no | Estimated token budget |\n| `prior_work` | object | no | Already-completed work from previous sessions |\n| `prior_work.done` | string[] | no | List of completed files/components |\n| `dependencies` | object | no | External dependencies needed (cargo crates, npm packages) |\n| `mergeOrder` | string[] | no | Explicit merge ordering instructions |\n| `riskRegister` | object[] | no | Risks with impact levels and mitigations |\n| `successCriteria` | string[] | no | Observable outcomes that prove the feature works |\n| `steps` | array | yes | Ordered list of adapter-bounded tasks |\n\n### Step Fields\n\n| Field | Type | Required | Description |\n|-------|------|----------|-------------|\n| `id` | string | yes | Unique step ID: `step-1`, `step-2`, ... |\n| `description` | string | yes | What to implement \u2014 specific enough for a hex-coder agent |\n| `layer` | string | yes | Hexagonal layer this step targets |\n| `adapter` | string | yes* | Adapter name (required for adapter-layer steps) |\n| `port` | string | no | Port interface being implemented |\n| `dependencies` | string[] | yes | Step IDs that must complete before this one |\n| `tier` | integer | yes | Execution tier (0-5), determines parallelism |\n| `specs` | string[] | yes | Behavioral spec IDs this step satisfies |\n| `worktree_branch` | string | no | Git worktree branch name |\n| `done_condition` | string | yes | Specific criteria for marking step complete |\n| `status` | string | no | Runtime status: pending, in_progress, completed, failed |\n| `commit_hash` | string | no | Git commit hash when completed |\n\n### Tier Ordering\n\nTiers determine which steps can run in parallel. Lower tiers must complete before higher tiers start:\n\n| Tier | Layer | Depends On | Parallelism |\n|------|-------|------------|-------------|\n| 0 | Domain types + Port interfaces | Nothing | Sequential (foundational) |\n| 1 | Secondary adapters | Tier 0 | Parallel within tier |\n| 2 | Primary adapters | Tier 0 | Parallel within tier |\n| 3 | Use cases | Tiers 0-2 | Sequential (orchestrates adapters) |\n| 4 | Composition root | Tiers 0-3 | Sequential (wiring) |\n| 5 | Integration tests | Everything | Sequential (validates all) |\n\n### Dependency Rules\n\n- Every step must list its dependencies explicitly (no implicit ordering)\n- Dependencies must respect tier ordering (a tier-1 step cannot depend on tier-3)\n- Port interface changes (tier 0) are implicit dependencies for all adapter steps\n- Integration tests (tier 5) depend on all steps they exercise\n- Maximum 8 parallel steps per tier (matches worktree limit)\n\n---\n\n## Creating a Workplan\n\n### Step 1: Write Behavioral Specs First\n\n```tool\nAgent({\n  subagent_type: \"general-purpose\",\n  mode: \"bypassPermissions\",\n  prompt: \"You are the behavioral-spec-writer agent. Feature: <description>. Write specs to docs/specs/<feature>.json\"\n})\n```\n\n### Step 2: Decompose into Steps\n\nFor each behavioral spec:\n1. Identify which adapter boundary it touches\n2. Group specs by adapter \u2192 each group becomes a step\n3. Assign tiers based on layer hierarchy\n4. Set dependencies based on which steps need outputs from others\n\n### Step 3: Write the Workplan\n\nSave to `docs/workplans/feat-<feature>.json`\n\n### Step 4: Register with HexFlo\n\nFor each step, create a HexFlo task:\n```tool\nmcp__hex__hex_hexflo_task_create({\n  swarm_id: \"<swarm-id>\",\n  title: \"<step.description>\",\n  assignee: \"hex-coder\",\n  metadata: {\n    phase: \"code\",\n    feature: \"<feature>\",\n    step_id: \"<step.id>\",\n    tier: <step.tier>,\n    adapter: \"<step.adapter>\",\n    port: \"<step.port>\"\n  }\n})\n```\n\n### Step 5: Store Workplan Reference in Memory\n\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/<feature>/workplan\",\n  value: JSON.stringify({\n    workplan_path: \"docs/workplans/feat-<feature>.json\",\n    total_steps: N,\n    completed_steps: 0\n  })\n})\n```\n\n---\n\n## Validating a Workplan\n\nBefore execution, validate:\n\n1. **Spec traceability**: Every step references at least one spec ID\n2. **Spec coverage**: Every spec ID is referenced by at least one step\n3. **Tier consistency**: Dependencies respect tier ordering\n4. **No cycles**: Dependency graph is a DAG\n5. **Layer correctness**: Each step's `layer` matches the adapter it targets\n6. **Done conditions**: Every step has a testable done_condition\n\n```bash\n# Validate workplan structure\nhex plan status feat-<feature>.json\n```\n\n---\n\n## Workplan Execution Flow\n\n```\nhex plan execute docs/workplans/feat-<feature>.json\n  \u2502\n  \u251c\u2500 Tier 0: domain + ports (sequential)\n  \u2502   \u2514\u2500 Wait for completion \u2192 verify compile\n  \u2502\n  \u251c\u2500 Tier 1: secondary adapters (parallel)\n  \u2502   \u251c\u2500 hex-coder \u2192 git-adapter worktree\n  \u2502   \u251c\u2500 hex-coder \u2192 fs-adapter worktree\n  \u2502   \u2514\u2500 hex-coder \u2192 llm-adapter worktree\n  \u2502       \u2514\u2500 Wait for all \u2192 verify tests\n  \u2502\n  \u251c\u2500 Tier 2: primary adapters (parallel)\n  \u2502   \u251c\u2500 hex-coder \u2192 cli-adapter worktree\n  \u2502   \u2514\u2500 hex-coder \u2192 http-adapter worktree\n  \u2502       \u2514\u2500 Wait for all \u2192 verify tests\n  \u2502\n  \u251c\u2500 Tier 3: usecases (sequential)\n  \u2502   \u2514\u2500 Wait \u2192 verify compile + tests\n  \u2502\n  \u251c\u2500 Tier 4: composition root (sequential)\n  \u2502   \u2514\u2500 Wait \u2192 verify full build\n  \u2502\n  \u2514\u2500 Tier 5: integration tests\n      \u2514\u2500 validation-judge \u2192 PASS/FAIL verdict\n```\n\n---\n\n## Workplan Lifecycle Commands\n\n| Command | What it does |\n|---------|-------------|\n| `/hex-workplan create <feature>` | Create workplan from behavioral specs |\n| `/hex-workplan validate <file>` | Validate workplan structure and traceability |\n| `hex plan list` | List all workplans with progress |\n| `hex plan status <file>` | Show detailed workplan status |\n| `hex plan execute <file>` | Start workplan execution via HexFlo |\n| `hex plan pause` | Pause active execution |\n| `hex plan resume` | Resume paused execution |\n| `hex plan report <id>` | Execution report with agent performance |\n| `hex plan history` | All past executions |"
    },
    "hex-worktree": {
      "description": "Manage git worktree lifecycle for hex feature development. Use when the user asks to \"create worktrees\", \"setup worktrees\", \"merge worktrees\", \"cleanup worktrees\", \"list worktrees\", \"worktree status\", or \"feature branches\".",
      "template": "# Hex Worktree \u2014 Git Worktree Lifecycle for Hex Features\n\nIn hex architecture, each adapter boundary gets its own git worktree during feature development. This skill manages the full worktree lifecycle: creation, status tracking, merge ordering, and cleanup.\n\n## Why Worktrees?\n\nHexagonal architecture enforces strict import boundaries between layers. By giving each adapter its own worktree, hex ensures:\n- Adapters cannot accidentally import each other (they're in separate directories)\n- Parallel development \u2014 multiple agents can code different adapters simultaneously\n- Clean merge ordering \u2014 domain/ports merge first, then adapters, then integration\n\n## Parameters\n\nAsk the user for:\n- **action** (required): One of: setup, status, merge, cleanup, list, stale\n- **feature_name** (required for setup/status/merge/cleanup): The feature identifier\n- **skip_specs** (optional, default: false): Bypass specs requirement (emergency hotfixes only)\n\n## Action: setup\n\nCreate worktrees from an existing workplan.\n\n### Prerequisites\n1. Behavioral specs must exist at `docs/specs/<feature-name>.json` (enforced by hex-specs-required hook)\n2. Workplan must exist at `docs/workplans/feat-<feature-name>.json`\n\n### Steps\n\n1. Read the workplan:\n```bash\ncat docs/workplans/feat-<feature-name>.json\n```\n\n2. For each step in the workplan, create a worktree:\n```bash\n# Domain/ports changes (Tier 0)\ngit worktree add ../hex-feat-<feature>-domain feat/<feature>/domain\ngit worktree add ../hex-feat-<feature>-ports feat/<feature>/ports\n\n# Secondary adapters (Tier 1)\ngit worktree add ../hex-feat-<feature>-<adapter> feat/<feature>/<adapter>\n\n# Primary adapters (Tier 2)\ngit worktree add ../hex-feat-<feature>-<adapter> feat/<feature>/<adapter>\n\n# Integration (Tier 5)\ngit worktree add ../hex-feat-<feature>-integration feat/<feature>/integration\n```\n\n3. Register worktrees in HexFlo memory:\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/<feature>/worktrees\",\n  value: {\n    feature: \"<feature>\",\n    worktrees: [\n      { branch: \"feat/<feature>/domain\", path: \"../hex-feat-<feature>-domain\", tier: 0, status: \"active\" },\n      ...\n    ],\n    created_at: \"ISO timestamp\"\n  }\n})\n```\n\n4. If `scripts/feature-workflow.sh` exists, prefer using it:\n```bash\n./scripts/feature-workflow.sh setup <feature-name>\n```\n\n## Action: status\n\nShow the current state of all worktrees for a feature.\n\n### Steps\n\n1. List all worktrees:\n```bash\ngit worktree list\n```\n\n2. Filter to the feature's worktrees (branches matching `feat/<feature>/`)\n\n3. For each worktree, report:\n   - Branch name and path\n   - Tier (from workplan)\n   - Commits ahead of main: `git log main..feat/<feature>/<adapter> --oneline`\n   - Test status: run `bun test` in the worktree (if requested)\n   - Merge readiness: all lower-tier worktrees merged?\n\n4. Cross-reference with HexFlo task status:\n```tool\nmcp__hex__hex_hexflo_task_list()\n```\n\n## Action: merge\n\nMerge worktrees in dependency order.\n\n### Merge Order (ENFORCED)\n\n```\nTier 0: domain \u2192 ports\nTier 1: secondary adapters (parallel within tier)\nTier 2: primary adapters (parallel within tier)\nTier 3: usecases\nTier 4: composition root\nTier 5: integration tests\n```\n\n### Steps\n\n1. Verify merge preconditions for each worktree (hex-merge-validation hook):\n   - Tests pass in the worktree\n   - All lower-tier worktrees already merged\n   - No cross-adapter imports\n   - Commit conventions followed\n\n2. Merge in order:\n```bash\ngit checkout main\ngit merge feat/<feature>/domain --no-ff -m \"feat(domain): <feature> domain types\"\ngit merge feat/<feature>/ports --no-ff -m \"feat(ports): <feature> port contracts\"\n# ... secondary adapters ...\n# ... primary adapters ...\ngit merge feat/<feature>/integration --no-ff -m \"test(<feature>): integration tests\"\n```\n\n3. After each merge, run the test suite:\n```bash\nbun run check && bun test\n```\n\n4. If conflicts arise:\n   - Resolve manually (adapters should not conflict with each other)\n   - Port/domain conflicts indicate a planning error \u2014 escalate to planner agent\n\n5. If `scripts/feature-workflow.sh` exists:\n```bash\n./scripts/feature-workflow.sh merge <feature-name>\n```\n\n## Action: cleanup\n\nRemove worktrees and branches after successful merge.\n\n### Steps\n\n1. Verify all worktrees are merged:\n```bash\ngit branch --merged main | grep \"feat/<feature>/\"\n```\n\n2. Remove worktrees:\n```bash\ngit worktree remove ../hex-feat-<feature>-domain\ngit worktree remove ../hex-feat-<feature>-ports\n# ... all worktrees ...\n```\n\n3. Delete branches:\n```bash\ngit branch -d feat/<feature>/domain\ngit branch -d feat/<feature>/ports\n# ... all branches ...\n```\n\n4. Clean up HexFlo memory:\n```tool\nmcp__hex__hex_hexflo_memory_store({\n  key: \"feature/<feature>/worktrees\",\n  value: { status: \"cleaned\", cleaned_at: \"ISO timestamp\" }\n})\n```\n\n5. If `scripts/feature-workflow.sh` exists:\n```bash\n./scripts/feature-workflow.sh cleanup <feature-name>\n```\n\n## Action: list\n\nList all active feature worktrees across all features.\n\n```bash\ngit worktree list\n```\n\nGroup by feature name and show tier/status for each.\n\n## Action: stale\n\nFind abandoned worktrees (older than 24h with no new commits).\n\n```bash\n# List worktrees and check last commit date\nfor wt in $(git worktree list --porcelain | grep \"^worktree\" | cut -d' ' -f2); do\n  last_commit=$(git -C \"$wt\" log -1 --format=\"%ci\" 2>/dev/null)\n  echo \"$wt: $last_commit\"\ndone\n```\n\nFlag worktrees with no commits in 24+ hours. Recommend cleanup or reassignment.\n\n## Worktree Limits\n\n- **Maximum 8 concurrent worktrees** per feature (matches max parallel agents)\n- Worktrees are created in the parent directory of the project root (../hex-feat-*)\n- Each worktree gets a full copy of the repo \u2014 disk space scales linearly\n\n## Quick Reference\n\n| Command | What it does |\n|---------|-------------|\n| `/hex-worktree setup <feature>` | Create worktrees from workplan |\n| `/hex-worktree status <feature>` | Show worktree status and merge readiness |\n| `/hex-worktree merge <feature>` | Merge worktrees in dependency order |\n| `/hex-worktree cleanup <feature>` | Remove worktrees and branches |\n| `/hex-worktree list` | List all active worktrees |\n| `/hex-worktree stale` | Find abandoned worktrees |"
    }
  },
  "instructions": [
    "You are an AI assistant embedded in the hex development environment.\n\nProject: unknown (unknown)\nActive swarms/workplans: unknown\nRecent ADRs:\n  ADR-001 [Accepted] Hexagonal Architecture as Foundational Pattern\n  ADR-002 [Accepted] Tree-Sitter for Token-Efficient LLM Communication\n  ADR-003 [Accepted] Multi-Language Support \u2014 TypeScript, Go, Rust\n  ADR-004 [Accepted] Git Worktrees for Parallel Agent Isolation\n  ADR-005 [Accepted] Compile-Lint-Test Feedback Loop with Quality Gates\n  ADR-006 [Accepted] Skills, Agent Definitions, and npm Packaging\n  ADR-007 [Accepted] Multi-Channel Notification System\n  ADR-008 [Accepted] Dogfooding \u2014 hex Built with Hexagonal Architecture\nInference providers: none registered\n\nhex MCP tools are available \u2014 use them for ADR search, workplan status, architecture analysis, git log, and hex command execution.\nType /help in the chat for available slash commands."
  ],
  "mcp": {
    "hex": {
      "command": [
        "hex",
        "mcp"
      ],
      "environment": {
        "HEX_PROJECT_ROOT": "."
      },
      "type": "local"
    }
  },
  "permission": {
    "bash": "allow",
    "doom_loop": "allow",
    "edit": "allow",
    "external_directory": "allow",
    "webfetch": "allow",
    "websearch": "allow"
  },
  "plugin": [
    "./.opencode/plugins/hex-sidebar.tsx"
  ],
  "provider": {
    "hex": {
      "api": "openai",
      "name": "hex-nexus inference router",
      "options": {
        "baseURL": "http://127.0.0.1:5555/v1"
      }
    }
  }
}