P0.6 — ε Skill Registry — Agent Prompts

Copy-paste-ready prompts for agents tackling each task in this group. Canonical spec: task-breakdown.md §P0.6 Concept spec: ε — Skill Registry Tool surface: S17 §1 — Phase 0 ε exposes one MCP tool: skill_list.

Group summary

Task ID	Title	Depends on	Effort	Unblocks	Phase 0 tools
P0.6.1	SKILL.md Parser + Schema	P0.2.2	M	P0.6.2	—
P0.6.2	Skill Registry + `skill_list`	P0.6.1	M	P0.6.3	`skill_list`
P0.6.3	Skill Capability Index	P0.6.2	S	Phase 1 `skill_get`	—

Not in Phase 0. skill_get, skill_reload, and hot-reload are deferred to Phase 1. Agent spawning (agent_spawn, agent_status) is deferred to Phase 1.5 — there is no src/domains/agents/ in the Phase 0 target tree (CLAUDE.md §9.1). The P0.6.3 historical heading “Agent Spawning” has been replaced with “Skill Capability Index” below; the heritage agent-spawner prompt is preserved further down under an explicit deferral banner.

P0.6.1 — Skill Schema

Spec source: task-breakdown.md §P0.6.1
Extraction reference: docs/reference/extractions/epsilon-skill-registry-extraction.md
Worktree: feature/p0-6-1-skill-schema
Branch command: git worktree add .worktrees/claude/p0-6-1-skill-schema -b feature/p0-6-1-skill-schema origin/main
Estimated effort: M (Medium — 2-3 hours)
Depends on: P0.2.2 (Database for skill storage)
Unblocks: P0.6.2 (CRUD uses schema)

Files to create

src/domains/skills/schema.ts — Skill Zod schema + SKILL.md parser
tests/domains/skills/schema.test.ts — Schema validation + parser tests

Acceptance criteria

Zod schema: { name, description, version, entrypoint, capabilities[], greekLetter? }
name must be kebab-case: /^[a-z][a-z0-9-]+$/
capabilities enum: ["read", "write", "spawn", "audit", "admin"]
greekLetter optional: must be one of α β γ δ ε ζ η θ ι κ λ μ ν ξ π
SKILL.md parser: reads frontmatter + body from existing .agents/skills/*/SKILL.md
Test: parse all 22 existing skill files, assert zero schema errors

Pre-flight reading

CLAUDE.md — worktree rules
docs/guides/implementation/task-breakdown.md §P0.6.1 — full spec
docs/reference/extractions/epsilon-skill-registry-extraction.md — skill structure
.agents/skills/*/SKILL.md — sample skill files (pick 2-3 to inspect)

Ready-to-paste agent prompt

You are a Phase 0 builder agent for Colibri.

TASK: P0.6.1 — Skill Schema
Define Zod schema for skills and parser for SKILL.md frontmatter.

FILES TO READ FIRST:
1. CLAUDE.md (execution rules)
2. docs/guides/implementation/task-breakdown.md §P0.6.1
3. docs/reference/extractions/epsilon-skill-registry-extraction.md
4. .agents/skills/*/SKILL.md (sample skill files, inspect 2-3)

WORKTREE SETUP:
git fetch origin
git worktree add .worktrees/claude/p0-6-1-skill-schema -b feature/p0-6-1-skill-schema origin/main
cd .worktrees/claude/p0-6-1-skill-schema

FILES TO CREATE:
- src/domains/skills/schema.ts
  * Zod schema SkillMetadata:
    - name: string, kebab-case validation /^[a-z][a-z0-9-]+$/
    - description: string
    - version: string (semver-like, e.g., "1.0.0")
    - entrypoint: string (path or function name)
    - capabilities: enum ["read", "write", "spawn", "audit", "admin"] (array)
    - greekLetter: optional, enum [α, β, γ, δ, ε, ζ, η, θ, ι, κ, λ, μ, ν, ξ, π] (string)
  * Function: parseSkillFile(filePath: string): {metadata: SkillMetadata, body: string}
    - Read .agents/skills/{skillName}/SKILL.md
    - Extract YAML frontmatter (---...---)
    - Parse frontmatter as metadata, validate with Zod
    - Return {metadata, body: remaining markdown}
  * Function: isValidGreekLetter(letter: string): boolean
  * Export types: SkillMetadata, ParsedSkill

- tests/domains/skills/schema.test.ts
  * Test name validation: valid kebab-case (ok), invalid CamelCase (error)
  * Test capabilities enum: valid array ["read", "write"] (ok), invalid "unknown" (error)
  * Test greekLetter: valid α (ok), missing (ok), invalid "foo" (error)
  * Test parseSkillFile: read actual skill file from .agents/skills/
  * Test parsing all 22 existing skill files → zero errors
  * Test body extraction: frontmatter separated from body correctly

ACCEPTANCE CRITERIA (headline):
✓ Zod schema with kebab-case name validation
✓ capabilities enum: read, write, spawn, audit, admin
✓ greekLetter optional, α-π enum
✓ SKILL.md parser reads frontmatter + body
✓ Parse all 22 existing skills with zero errors

SUCCESS CHECK:
cd .worktrees/claude/p0-6-1-skill-schema && npm test && npm run lint

WRITEBACK (after success):
task_update(task_id="P0.6.1", status="done", progress=100)
thought_record(task_id="P0.6.1", branch="feature/p0-6-1-skill-schema",
  commit_sha=<your-sha>, tests_run=["npm test","npm run lint"],
  summary="Implemented Skill Zod schema with kebab-case name, capabilities enum, optional greekLetter. SKILL.md parser extracts frontmatter (metadata) and body. All 22 existing skills parse with zero errors.")

FORBIDDENS:
✗ Do not skip greekLetter validation (must be α-π if provided)
✗ Do not allow non-kebab-case names
✗ Do not parse SKILL.md with regex (use proper YAML parser: yaml package)
✗ Do not edit main checkout

NEXT:
P0.6.2 — Skill CRUD + Discovery (uses schema to load skills)

Verification checklist (for reviewer agent)

Zod schema with kebab-case regex for name
capabilities is enum array
greekLetter is optional enum of 15 Greek letters
parseSkillFile uses YAML parser (not regex)
All 22 existing skill files parse with zero errors
Test coverage includes valid + invalid inputs for each field
npm test and npm run lint pass

Writeback template

task_update:
  task_id: P0.6.1
  status: done
  progress: 100

thought_record:
  task_id: P0.6.1
  branch: feature/p0-6-1-skill-schema
  commit_sha: <sha>
  tests_run: ["npm test", "npm run lint"]
  summary: "Implemented Skill Zod schema with validated fields: name (kebab-case), description, version, entrypoint, capabilities (read|write|spawn|audit|admin), greekLetter (α-π, optional). parseSkillFile() uses YAML parser to extract frontmatter (metadata) and body from SKILL.md files. All 22 existing skills validate with zero errors."
  blockers: []

Common gotchas

Use a YAML parser, not regex — YAML frontmatter can have complex nested structures, comments, quoted strings, etc. Use the yaml package. Don’t try to parse it with regex.
Greek letters are Unicode characters — α is U+03B1, not “a”. The schema should use the actual Unicode character or a string representation (your choice). Be consistent.
Kebab-case validation — /^[a-z][a-z0-9-]+$/ means: start with lowercase letter, followed by lowercase letters, digits, or hyphens. “my-skill”, “skill-2”, etc. are valid. “MySkill”, “_skill”, “skill_name” are invalid.

P0.6.2 — Skill Registry + `skill_list`

Spec source: task-breakdown.md §P0.6.2 Extraction reference: docs/reference/extractions/epsilon-skill-registry-extraction.md Worktree: feature/p0-6-2-skill-registry Branch command: git worktree add .worktrees/claude/p0-6-2-skill-registry -b feature/p0-6-2-skill-registry origin/main Estimated effort: M (Medium — 2-3 hours) Depends on: P0.6.1 (Uses Skill schema) Unblocks: P0.6.3 (Capability index reads the same cache)

Phase 0 scope. The Phase 0 ε surface exposes one MCP tool: skill_list (S17 §1). skill_get (full body retrieval), skill_reload (hot-reload), and any file-watcher-driven rescans are deferred to Phase 1. The in-process getSkill() helper exists for internal callers (e.g. future Phase 1 tool surfaces), but it is not wired to an MCP tool in Phase 0.

Files to create

src/domains/skills/repository.ts — Startup scan + in-memory cache + skill_list backing
src/tools/skill-list.ts — skill_list MCP tool definition (Zod input + handler)
tests/domains/skills/repository.test.ts — Startup scan + cache tests
tests/tools/skill-list.test.ts — MCP tool contract tests

Acceptance criteria

On startup: scans .agents/skills/*/SKILL.md, loads all valid skills into an in-memory Map
listSkills({ capability? }) → filtered list (by capability string)
Internal-only: getSkill(name) → skill or null (not exposed as MCP tool in Phase 0)
skill_list MCP tool: returns { skills: [{name, description, version, capabilities, greekLetter?}] }
Unparseable SKILL.md files are logged and skipped — startup does not crash
Scan is one-shot at startup; no file watcher, no hot-reload path exists
skill_list is registered through the 5-stage α middleware chain (tool-lock → schema validate → audit enter → dispatch → audit exit)

Not in Phase 0. Do not implement skill_get, skill_reload, or any file-watcher-driven rescan in this task. They are Phase 1 work per S17 §1 and the task-breakdown ε row. Likewise, no src/domains/agents/ and no agent_spawn/agent_status tools — agent runtime is deferred to Phase 1.5 per ADR-005.

Pre-flight reading

CLAUDE.md — execution rules
docs/guides/implementation/task-breakdown.md §P0.6.2 — full spec
docs/spec/s17-mcp-surface.md §1 — canonical ε tool list
docs/reference/extractions/epsilon-skill-registry-extraction.md (loader section)
.agents/skills/ — directory structure (22 existing skills)

Ready-to-paste agent prompt

You are a Phase 0 builder agent for Colibri.

TASK: P0.6.2 — Skill Registry + skill_list
Implement one-shot startup scan, in-memory cache, and the skill_list MCP tool.

FILES TO READ FIRST:
1. CLAUDE.md (execution rules)
2. docs/guides/implementation/task-breakdown.md §P0.6.2
3. docs/spec/s17-mcp-surface.md §1 (canonical ε tool list)
4. docs/reference/extractions/epsilon-skill-registry-extraction.md (loader section)
5. src/domains/skills/schema.ts (schema + parser from P0.6.1)
6. .agents/skills/ (sample of 2-3 SKILL.md files)

WORKTREE SETUP:
git fetch origin
git worktree add .worktrees/claude/p0-6-2-skill-registry -b feature/p0-6-2-skill-registry origin/main
cd .worktrees/claude/p0-6-2-skill-registry

FILES TO CREATE:
- src/domains/skills/repository.ts
  * Class SkillRepository (singleton):
    - constructor(skillsRoot: string = COLIBRI_SKILLS_ROOT from config)
    - initializeSkills(): scans skillsRoot/*/SKILL.md, parses each via parseSkillFile()
      from P0.6.1, validates with Zod, inserts into cache. Unparseable files → log
      a structured warning and skip. Return count of loaded skills.
    - getSkill(name: string): Skill | null   // internal helper, NOT an MCP tool in Phase 0
    - listSkills(filters?: {capability?: string}): Skill[]
      // If capability is set, filter to skills whose capabilities array includes it.
  * Cache: Map<skillName, {metadata, body}>
  * Export: getSkillRepository() singleton accessor.
  * NO file watcher. NO reload method. One-shot scan at startup only.

- src/tools/skill-list.ts
  * Export an MCP tool descriptor for `skill_list`:
    - name: "skill_list"
    - description: "List all skills registered in the ε Skill Registry."
    - inputSchema: z.object({ capability: z.string().optional() })
    - handler: async ({ capability }) => ({
        skills: getSkillRepository().listSkills({ capability }).map(s => ({
          name: s.metadata.name,
          description: s.metadata.description,
          version: s.metadata.version,
          capabilities: s.metadata.capabilities,
          greekLetter: s.metadata.greekLetter,
        })),
      })
  * Register this tool through the α registerTool() wrapper so it flows through
    the 5-stage middleware chain (tool-lock → schema validate → audit enter →
    dispatch → audit exit). Do NOT bypass the chain.

- tests/domains/skills/repository.test.ts
  * Test initialization: scan of a fixture directory finds all valid SKILL.md files
  * Test listSkills: returns all, filters by capability
  * Test getSkill: returns skill or null (internal helper)
  * Test unparseable skill: broken frontmatter is logged + skipped, other skills still load
  * Test startup does NOT crash on any bad input

- tests/tools/skill-list.test.ts
  * Test skill_list with no args returns all registered skills with exact shape
  * Test skill_list({capability: "read"}) filters correctly
  * Test skill_list flows through the α middleware chain (assert audit enter/exit events)

ACCEPTANCE CRITERIA (headline):
✓ Startup scans .agents/skills/*/SKILL.md into an in-memory cache
✓ listSkills({capability?}) filters by capability
✓ skill_list MCP tool exposes the filtered view, NO skill_get / skill_reload
✓ Unparseable skills are logged and skipped, startup does not crash
✓ skill_list is registered through the 5-stage α middleware chain

SUCCESS CHECK:
cd .worktrees/claude/p0-6-2-skill-registry && npm test && npm run lint

WRITEBACK (after success):
task_update(task_id="P0.6.2", status="done", progress=100)
thought_record(task_id="P0.6.2", branch="feature/p0-6-2-skill-registry",
  commit_sha=<your-sha>, tests_run=["npm test","npm run lint"],
  summary="Implemented SkillRepository singleton with one-shot startup scan of .agents/skills/*/SKILL.md. In-memory Map cache. listSkills({capability?}) filters by capability. getSkill() is internal-only (not an MCP tool). Phase 0 exposes exactly one ε tool: skill_list, registered through the 5-stage α middleware chain. Unparseable skills logged and skipped.")

FORBIDDENS:
✗ Do not implement skill_get as an MCP tool (Phase 1 per S17 §1)
✗ Do not implement skill_reload or any hot-reload path (Phase 1)
✗ Do not add a file watcher (chokidar, fs.watch, etc.)
✗ Do not fail startup if a skill file is unparseable (log + skip)
✗ Do not bypass the α middleware chain when registering skill_list
✗ Do not create src/domains/agents/ — agent runtime is Phase 1.5 (ADR-005)
✗ Do not edit main checkout

NEXT:
P0.6.3 — Skill Capability Index (builds a reverse lookup from capability → skills)

Verification checklist (for reviewer agent)

Startup scans .agents/skills/ once, no watcher, no reload method
Cache is an in-memory Map<name, {metadata, body}>
listSkills() supports optional capability filter
getSkill() exists as an internal helper but is not exposed as an MCP tool
skill_list is the only ε MCP tool registered in Phase 0
skill_list is registered through the α middleware chain (verified in a test)
No skill_get, no skill_reload, no agent_spawn, no agent_status anywhere in the diff
Unparseable skills logged and skipped, startup survives
npm test and npm run lint pass

Writeback template

task_update:
  task_id: P0.6.2
  status: done
  progress: 100

thought_record:
  task_id: P0.6.2
  branch: feature/p0-6-2-skill-registry
  commit_sha: <sha>
  tests_run: ["npm test", "npm run lint"]
  summary: "Implemented SkillRepository singleton with one-shot startup scan of .agents/skills/*/SKILL.md. In-memory Map<name, {metadata, body}> cache. listSkills({capability?}) filters by capability; getSkill(name) kept as internal helper (not an MCP tool in Phase 0). Phase 0 exposes exactly one ε MCP tool: skill_list, registered through the 5-stage α middleware chain. Unparseable skills are logged and skipped; startup continues. skill_get, skill_reload, and hot-reload are explicitly deferred to Phase 1 per S17 §1."
  blockers: []

Common gotchas

Phase 0 exposes exactly one ε tool — skill_list. If you catch yourself writing skill_get or skill_reload, stop and re-read S17 §1. They belong to Phase 1.
No file watcher — Phase 0 is stdio-only and one-shot at startup. A watcher introduces concurrency and leader-election concerns that are out of scope. If someone wants a refreshed view, they restart the server.
Skip unparseable skills, don’t crash — if a SKILL.md file has invalid frontmatter, log a structured warning and continue. The server must remain operational.
Capability filtering is array containment — if a skill has capabilities ["read", "write"] and the filter is "read", it should match. Use array.includes().
Middleware chain is mandatory — skill_list must be registered via the α registerTool() wrapper so it flows through tool-lock → schema validate → audit enter → dispatch → audit exit. Never bypass the chain to “simplify” a read-only tool.

P0.6.3 — Skill Capability Index

Spec source: task-breakdown.md §P0.6.3 Extraction reference: docs/reference/extractions/epsilon-skill-registry-extraction.md Worktree: feature/p0-6-3-capability-index Branch command: git worktree add .worktrees/claude/p0-6-3-capability-index -b feature/p0-6-3-capability-index origin/main Estimated effort: S (Small — 1-2 hours) Depends on: P0.6.2 (Skill registry cache) Unblocks: Phase 1 skill_get (capability-scoped lookup)

Phase 0 scope. P0.6.3 builds a pure in-process reverse index from capability → skill names on top of the P0.6.2 cache. It does not spawn processes, create worktrees, or expose any new MCP tool. The Phase 0 ε surface remains exactly skill_list (S17 §1). This task exists so that Phase 1’s skill_get and Phase 1.5’s router/spawner have an O(1) capability lookup waiting for them.

Files to create

src/domains/skills/capability-index.ts — Builds & queries Map<capability, Set<skillName>>
tests/domains/skills/capability-index.test.ts — Index correctness + filter parity tests

Acceptance criteria

buildCapabilityIndex(skills) returns Map<capability, Set<skillName>>
Index is built once, at the same point the registry cache is populated (no watcher)
findSkillsByCapability(capability) returns string[] of skill names
A skill with capabilities: ["read", "write"] shows up in both the “read” and “write” buckets
listSkills({capability}) from P0.6.2 and findSkillsByCapability() return the same set (parity test)
Empty capability filter → empty string[] (not all skills)
No new MCP tools exposed in Phase 0 — this is a pure helper
No subprocess spawning, no worktree creation, no src/domains/agents/

Not in Phase 0. Agent spawning (agent_spawn, agent_status, agent_list), worktree orchestration, subprocess env vars, and src/domains/agents/ are all deferred to Phase 1.5 per ADR-005 and CLAUDE.md §9.1. The old donor “Agent Spawning” prompt is preserved below as a heritage block — do not implement it in Phase 0.

Pre-flight reading

CLAUDE.md — execution rules, no src/domains/agents/ in Phase 0
docs/guides/implementation/task-breakdown.md §P0.6.3 — full spec
docs/spec/s17-mcp-surface.md §1 — confirm ε surface is only skill_list
src/domains/skills/repository.ts (from P0.6.2)

Ready-to-paste agent prompt

You are a Phase 0 builder agent for Colibri.

TASK: P0.6.3 — Skill Capability Index
Build a pure in-process reverse index from capability → skill names on top of the
P0.6.2 registry cache. No new MCP tools. No subprocess spawning. No worktrees.

FILES TO READ FIRST:
1. CLAUDE.md (execution rules, §9.1 says no src/domains/agents/ in Phase 0)
2. docs/guides/implementation/task-breakdown.md §P0.6.3
3. docs/spec/s17-mcp-surface.md §1 (ε exposes ONLY skill_list in Phase 0)
4. src/domains/skills/repository.ts (from P0.6.2)

WORKTREE SETUP:
git fetch origin
git worktree add .worktrees/claude/p0-6-3-capability-index -b feature/p0-6-3-capability-index origin/main
cd .worktrees/claude/p0-6-3-capability-index

FILES TO CREATE:
- src/domains/skills/capability-index.ts
  * Export function buildCapabilityIndex(skills: Skill[]): Map<string, Set<string>>
    - For each skill, for each capability in skill.metadata.capabilities,
      add skill.metadata.name to the Set under that capability key.
  * Export function findSkillsByCapability(
      index: Map<string, Set<string>>,
      capability: string,
    ): string[]
    - Return Array.from(index.get(capability) ?? []).sort()
  * Wire index construction into SkillRepository.initializeSkills() so the index
    is built once, at startup, from the same loaded skill set. Expose a getter
    getCapabilityIndex() on the repository.
  * NO file watcher. NO reload path. One-shot at startup.
  * NO MCP tool. This is a pure internal helper that Phase 1 skill_get will use.

- tests/domains/skills/capability-index.test.ts
  * Test buildCapabilityIndex with a fixture of 3 skills, mixed capabilities
  * Test a skill with ["read","write"] appears in both buckets
  * Test findSkillsByCapability returns sorted string[]
  * Test unknown capability returns []
  * Parity test: for each capability C, the set returned by
    findSkillsByCapability(index, C) equals the set of names returned by
    SkillRepository.listSkills({capability: C}).map(s => s.metadata.name)

ACCEPTANCE CRITERIA (headline):
✓ buildCapabilityIndex returns Map<capability, Set<skillName>>
✓ findSkillsByCapability returns sorted string[]
✓ Index is built once, at startup, alongside the registry cache
✓ Parity with listSkills({capability}) from P0.6.2
✓ Zero new MCP tools (ε surface still = skill_list)
✓ No src/domains/agents/, no subprocess spawning, no worktree creation

SUCCESS CHECK:
cd .worktrees/claude/p0-6-3-capability-index && npm test && npm run lint

WRITEBACK (after success):
task_update(task_id="P0.6.3", status="done", progress=100)
thought_record(task_id="P0.6.3", branch="feature/p0-6-3-capability-index",
  commit_sha=<your-sha>, tests_run=["npm test","npm run lint"],
  summary="Implemented Skill Capability Index: pure in-process reverse lookup Map<capability, Set<skillName>> built once at startup alongside the P0.6.2 registry cache. findSkillsByCapability() returns sorted string[]. Parity with listSkills({capability}) verified by test. No new MCP tools exposed — Phase 0 ε surface remains skill_list only. No subprocess spawning, no worktree creation, no src/domains/agents/.")

FORBIDDENS:
✗ Do not expose any new MCP tool (no skill_get, no agent_spawn, no agent_status)
✗ Do not create src/domains/agents/ (Phase 1.5 per ADR-005, CLAUDE.md §9.1)
✗ Do not spawn subprocesses or create worktrees from this task
✗ Do not add a file watcher or hot-reload path
✗ Do not edit main checkout

NEXT:
P0.7.1 — Hash-Chained Record Schema (decision trail for agent decisions)

Verification checklist (for reviewer agent)

Writeback template

task_update:
  task_id: P0.6.3
  status: done
  progress: 100

thought_record:
  task_id: P0.6.3
  branch: feature/p0-6-3-capability-index
  commit_sha: <sha>
  tests_run: ["npm test", "npm run lint"]
  summary: "Implemented Skill Capability Index — pure in-process reverse lookup Map<capability, Set<skillName>> built once at startup from the P0.6.2 registry cache. findSkillsByCapability() returns sorted string[] of skill names. Parity test verifies equivalence with listSkills({capability}). No new MCP tools: Phase 0 ε surface remains exactly skill_list (S17 §1). No src/domains/agents/, no subprocess spawning, no worktree creation — agent runtime is deferred to Phase 1.5 per ADR-005."
  blockers: []

Common gotchas

Pure helper, not a tool — do not register a new MCP tool for this task. Phase 0 ε = skill_list, full stop.
Build once, at startup — index construction is wired into initializeSkills() so it sees exactly the same skill set as the registry cache. No lazy construction, no watcher.
Multi-capability skills live in multiple buckets — a skill with ["read","write"] must appear in both the “read” Set and the “write” Set. The common bug is iterating the outer array and overwriting instead of appending.
Parity with listSkills({capability}) — if the two disagree, something is wrong with either the index or the filter. The parity test is the load-bearing check.

Heritage: old “Agent Spawning” prompt (deferred to Phase 1.5, do not implement)

⚠ Not in Phase 0. Not in Phase 1. The content below is the pre-R74.5 donor prompt for an “Agent Spawning” task that envisioned subprocess spawning, worktree orchestration, and three new MCP tools (agent_spawn, agent_status, agent_list) plus a src/domains/agents/ directory. All of that is deferred to Phase 1.5 per ADR-005 and CLAUDE.md §9.1. It is kept here as historical context for the capability index above, so a future Phase 1.5 implementer can see the original shape. Do not copy any of it into a Phase 0 worktree. Every AMS_* environment variable, every agent_* MCP tool name, and every reference to src/domains/skills/spawner.ts or src/tools/agents.ts below is heritage-only and must not appear in Phase 0 code.

The Phase 0 replacement task that actually ships is the Skill Capability Index above. If you are picking up P0.6.3, implement that. If you are looking for agent spawning, wait for Phase 1.5.

Heritage content (read-only)

**Files the heritage prompt proposed (DO NOT create in Phase 0):** - `src/domains/skills/spawner.ts` — Worktree creation + agent spawning - `src/tools/agents.ts` — `agent_spawn` / `agent_status` / `agent_list` MCP tools - `tests/domains/skills/spawner.test.ts` **Heritage acceptance criteria (DO NOT act on):** - `spawnAgent(skillName, worktreePath, prompt)` creates worktree, starts subprocess - Worktree path: `.worktrees/claude/{task-slug}` - Sub-agent receives `AMS_AGENT_ID`, `AMS_WORKTREE_PATH`, `AMS_PROMPT` env vars - `agent_spawn` MCP tool returns `{ agentId, worktreePath, pid }` - `agent_status` MCP tool returns `{ agentId, status, exitCode? }` **Why this is deferred:** 1. Phase 0 is stdio-only (S17 §2) — subprocess orchestration is out of scope. 2. ADR-005 explicitly routes δ Model Router and any multi-agent runtime to Phase 1.5. 3. CLAUDE.md §9.1 lists the Phase 0 target tree with no `src/domains/agents/`. 4. The `AMS_*` env namespace is frozen — Colibri uses `COLIBRI_*` only (S17 §3). 5. `skill_get`, `skill_reload`, and the hot-reload path it implicitly depends on are Phase 1 per S17 §1. When Phase 1.5 opens the agent runtime, the prompt author should design `agent_spawn`/`agent_status` against the `COLIBRI_*` env floor and the then-current δ Model Router, not against this AMS-era draft.

Next group

p0.7-zeta-trail.md — ζ Decision Trail (3 tasks: Hash-Chained Records, Thought Record CRUD, Chain Verification)

Back to task-prompts index