@goondocks/myco 0.20.1 → 0.21.0

package/dist/src/agent/definitions/tasks/vault-seed.yaml

@@ -0,0 +1,370 @@
+# =============================================================================
+# Built-in Task: Vault Seed (Phased)
+# =============================================================================
+# Manual-only task for: myco-agent
+#
+# One-shot seeding pass for brownfield codebases. Unlike vault-evolve,
+# which processes session transcripts, vault-seed infers knowledge
+# directly from source files using filesystem + grep tools. Intended to
+# be run when adopting Myco on an existing repo — fills the vault with
+# an initial spore set and digest so the assistant has useful context
+# from day one.
+# =============================================================================
+
+name: vault-seed
+displayName: Vault Seed
+description: >
+  One-shot seeding pass for a brownfield codebase. Explores the project
+  with filesystem and grep tools, identifies architectural patterns,
+  conventions, and gotchas, then populates the vault with an initial
+  spore set and a starter digest. Manual trigger only — no session data
+  required.
+agent: myco-agent
+isDefault: false
+maxTurns: 300
+timeoutSeconds: 3600
+reasoningLevel: default
+
+# No schedule — always manual. Running automatically would re-seed an
+# already-populated vault.
+
+prompt: >
+  You are running a one-shot seeding pass over a brownfield codebase.
+  There are no session transcripts to process — infer knowledge directly
+  from source. Focus on architectural patterns, conventions, trade-offs,
+  and gotchas that a new developer or agent onboarding to this code
+  would benefit from. Quality over quantity — one precise observation is
+  worth more than ten vague ones.
+
+  IMPORTANT: the pipeline is phased, and each phase has a different
+  tool surface. Early phases explore source with filesystem tools;
+  later phases write observations to the vault using vault_* tools.
+  Each phase's prompt lists the tools it has. Trust that list and call
+  those tools directly. Do not rationalize that a declared tool is
+  "unavailable" based on what earlier phases used.
+
+phases:
+  - name: orient
+    reasoningLevel: default
+    readOnly: true
+    prompt: |
+      **Your ONLY job this phase: produce a 3-8 item theme list from
+      surface signals.** You are NOT verifying themes, NOT reading
+      implementation, and NOT building a comprehensive understanding.
+      That work belongs to the next phase (explore-themes), which has
+      a much larger budget and is designed for it.
+
+      **Hard turn budget: {{max_turns}}.** Each tool call costs one
+      turn. If you exhaust the budget before calling `vault_report`
+      with the theme list, this phase fails and blocks the rest of
+      the pipeline. Treat the budget as a constraint, not a suggestion
+      — finish well under it.
+
+      **Scope guard:** if you find yourself opening a file under
+      `packages/*/src/**`, `src/**`, `lib/**`, or any implementation
+      directory, STOP. That is explore-themes's job. Orient reads
+      top-level metadata and docs only.
+
+      ## Exact tool plan (budget: ~8 tool calls total)
+
+      Call ONLY these tools, in this order. Do NOT add calls.
+
+      1. `fs_tree` at `.` with depth=1 — 1 call, 1 turn.
+      2. `fs_read` the README (no line window) — 1 call, 1 turn.
+      3. `fs_read` the primary manifest (package.json / pyproject.toml /
+         Cargo.toml / go.mod / Gemfile / pom.xml — pick the one that
+         exists, skip if unclear) — 0 or 1 call.
+      4. `fs_list` at `.` — 1 call, 1 turn. After this call you have
+         seen every top-level tooling signal. DO NOT list additional
+         directories in this phase; recursive layout exploration is
+         explore-themes's job.
+      5. (Optional) `fs_list` on `docs/` — 0 or 1 call. If you do, then
+         `fs_read` AT MOST 2 files that clearly look like architecture
+         or overview docs — max 2 more calls.
+      6. `vault_report` with action "orient" and the theme list — 1
+         call. This is your last tool call. The phase ends here.
+
+      Skipping steps is fine. Adding steps is not. If you are tempted
+      to list a subdirectory to "see what's inside it," resist —
+      explore-themes will do that with more budget.
+
+      **Frugality:** every tool response comes back as tokens on your
+      next turn's input. Narrow calls keep the budget healthy.
+
+      ## Output: theme outline
+
+      From those surface signals alone, name 3-8 themes worth deeper
+      exploration in the next phase. Name them confidently even if you
+      don't have full evidence yet — the next phase will verify them.
+      Good themes:
+      - major architectural layers ("agent harness", "daemon", "UI")
+      - cross-cutting domain concepts ("team sync", "session lifecycle")
+      - notable integration points ("MCP server", "SQLite vault")
+      - conventions worth surfacing (testing style, error handling)
+
+      Avoid generic themes like "TypeScript code" or "tests exist".
+
+      Call `vault_report` with action "orient" and the structured theme
+      list. This is your final tool call for this phase.
+    tools:
+      - fs_tree
+      - fs_list
+      - fs_read
+      - vault_report
+    maxTurns: 25
+    required: true
+
+  - name: explore-themes
+    reasoningLevel: default
+    readOnly: true
+    dependsOn: [orient]
+    prompt: |
+      For each theme identified in the orient phase, drill down with
+      `code_grep` and targeted `fs_read` calls. Collect specific,
+      concrete observations that would survive the code evolving.
+
+      ## Strategy (budget: 4-6 turns per theme)
+
+      For each theme:
+      1. `code_grep` for signature patterns — class/interface names,
+         distinctive function names, keywords. Use a `glob` filter when
+         the language is known (e.g., `*.ts`, `*.py`).
+      2. `fs_read` the 2-4 most informative files you find. Prefer
+         cross-cutting modules over leaf files.
+      3. Note 3-6 concrete observations for the theme. Anchor each to
+         file paths or function names.
+
+      ## What makes a good observation
+
+      - Anchored to specific file paths, function names, or patterns
+      - Captures trade-offs, gotchas, or non-obvious invariants
+      - Explains WHY when the reasoning is evident from the code
+      - Would be useful to an agent or developer onboarding
+
+      ## What to skip
+
+      - Boilerplate (standard manifest fields, generated code)
+      - Implementation details that change frequently
+      - Things obvious from the README
+      - Generic advice ("use TypeScript") — only observations specific to
+        THIS codebase belong in the vault
+
+      ## Output
+
+      Produce a structured summary grouped by theme, focused on
+      OBSERVATIONS (the conclusions) rather than a log of what you did.
+      Write the summary as if a separate agent will read it cold and
+      turn each observation into a durable note. Avoid phrases like
+      "I ran fs_tree on…" or "I read the README" — name the observation
+      and anchor it to specific paths. The seed-spores phase runs with
+      a different tool surface and should not be primed to expect
+      filesystem access.
+
+      Call `vault_report` with action "explore" and the structured result.
+    tools:
+      - fs_tree
+      - fs_list
+      - fs_read
+      - code_grep
+      - vault_report
+    maxTurns: 120
+    required: true
+
+  - name: seed-spores
+    reasoningLevel: default
+    dependsOn: [explore-themes]
+    prompt: |
+      Create spores for the observations from the explore phase.
+
+      **Hard turn budget: {{max_turns}}.** Each tool call costs one
+      turn. Every observation needs one `vault_create_spore` call;
+      budget your work accordingly.
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools: {{phase_tools}}.
+      They are registered and available. Call them directly. Do NOT
+      verify or second-guess. Filesystem tools from earlier phases
+      are not needed here — the explore-themes summary in your
+      context contains everything you need to create spores.
+
+      ## Step 1: Re-seed check (1 tool call)
+
+      This phase runs on cold vaults AND on vaults that have been
+      seeded before. Call `vault_search_semantic` ONCE with a broad
+      query derived from the strongest theme (e.g. the name of the
+      highest-signal architectural layer from the explore summary).
+
+      - If the search returns several high-similarity results (many
+        scores > 0.85), the vault is already populated. Call
+        `vault_report` with action "skip" and reason "vault already
+        populated" and STOP. Do not create duplicate spores.
+      - If the search returns nothing or only low-similarity results
+        (typical for a cold vault with no embeddings, or a vault with
+        unrelated prior content), proceed to Step 2.
+
+      Do NOT run per-observation similarity searches — dedup across
+      existing spores is the job of the separate consolidation task,
+      not seed-spores. One broad re-seed check is enough.
+
+      ## Step 2: Create spores (the bulk of your budget)
+
+      For each observation in the explore summary, call
+      `vault_create_spore` with:
+      - observation_type: "decision", "pattern", "wisdom", "gotcha",
+        or "architecture" based on what the observation captures
+      - content: the full observation — concrete and specific
+      - importance: 1-10 (10 = load-bearing architectural invariant,
+        3 = minor stylistic preference)
+      - tags: 2-4 tags covering theme and domain
+      - file_path: the primary source file when the observation
+        anchors to one specific location
+      - session_id: null (no session provenance — this is seed data)
+      - prompt_batch_id: null
+      - context: "Seeded from vault-seed exploration pass"
+
+      ## Quality rules
+
+      - One observation per spore — specific, not vague
+      - Prefer fewer, higher-signal spores over many low-signal ones
+      - Target: 10-40 spores per seed run. If the exploration produced
+        far more candidates, prioritize by importance and drop the rest
+        rather than creating everything
+      - Observations anchored to specific file paths are stronger than
+        abstract statements
+    tools:
+      - vault_search_semantic
+      - vault_create_spore
+      - vault_report
+    maxTurns: 80
+    required: true
+
+  # ---- Digest tiers (parallel after seed-spores) ----
+  # Mirrors the vault-evolve pattern: three tiers writing in the same
+  # wave after seeding completes.
+
+  - name: digest-10000
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 10000 — Full institutional knowledge (~10k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_search_semantic`, `vault_read_digest`,
+      `vault_write_digest`, `vault_report`. They are registered and
+      available. Call them directly. Filesystem tools from earlier
+      phases are NOT in scope here — the spores created in seed-spores
+      contain everything you need.
+
+      If the seed-spores phase short-circuited with "vault already populated",
+      call `vault_report` with action "skip" for tier 10000 and finish.
+
+      1. Call `vault_read_digest` with tier 10000 to see any existing content.
+         If this is a first seed run, it will be empty.
+      2. Call `vault_spores` with status "active" to read the freshly seeded
+         observations.
+      3. Organize the digest around the themes from the explore phase.
+         Include concrete file paths and function names. A reader should
+         come away with a thorough picture of the architecture, key
+         decisions, and gotchas.
+      4. Call `vault_write_digest` with tier 10000.
+
+      If the existing digest already contains comparable content (re-seed
+      case), integrate rather than overwrite — preserve well-crafted text.
+    tools:
+      - vault_spores
+      - vault_search_semantic
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 15
+    required: false
+
+  - name: digest-5000
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 5000 — Deep onboarding (~5k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_read_digest`, `vault_write_digest`,
+      `vault_report`. They are registered and available. Call them
+      directly. Filesystem tools from earlier phases are NOT in scope.
+
+      If the seed-spores phase short-circuited, call `vault_report` with
+      action "skip" for tier 5000 and finish.
+
+      This tier focuses on trade-offs and patterns — what a developer
+      needs after the README but before diving into code.
+
+      1. Call `vault_read_digest` with tier 5000 for the baseline.
+      2. Call `vault_spores` as the primary source (digest-10000 may still
+         be in-flight — don't depend on it).
+      3. Call `vault_write_digest` with tier 5000. Trim and synthesize;
+         this tier is a compression of tier 10000's material.
+    tools:
+      - vault_spores
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 12
+    required: false
+
+  - name: digest-1500
+    reasoningLevel: default
+    dependsOn: [seed-spores]
+    prompt: |
+      Write digest tier 1500 — Executive briefing (~1.5k tokens).
+
+      ## Your tools this phase
+
+      You have these tools and ONLY these tools:
+      `vault_spores`, `vault_read_digest`, `vault_write_digest`,
+      `vault_report`. They are registered and available. Call them
+      directly. Filesystem tools from earlier phases are NOT in scope.
+
+      If the seed-spores phase short-circuited, call `vault_report` with
+      action "skip" for tier 1500 and finish.
+
+      The tightest tier: what someone needs to know in 2 minutes.
+      Architectural overview in 1-2 sentences, 2-3 load-bearing decisions,
+      the critical gotchas. Ruthlessly selective.
+
+      1. Call `vault_spores` filtered to importance >= 8 to find the
+         top-signal observations.
+      2. Call `vault_write_digest` with tier 1500.
+    tools:
+      - vault_spores
+      - vault_read_digest
+      - vault_write_digest
+      - vault_report
+    maxTurns: 8
+    required: false
+
+  - name: report
+    reasoningLevel: low
+    dependsOn: [seed-spores, digest-10000, digest-5000, digest-1500]
+    prompt: |
+      Summarize the seeding pass.
+
+      Your only tool this phase is `vault_report`. Call it — it is
+      registered and available.
+
+      Call `vault_report` with action "complete" and these details:
+      - Themes explored: N
+      - Spores created: N (by type)
+      - Spores superseded: N
+      - Digest tiers written: [list]
+      - Thin coverage: any themes where the exploration surfaced fewer than
+        3 observations — surface these so the user can follow up with a
+        targeted review-session or additional manual curation
+
+      This report MUST be the last tool call of the run.
+    tools:
+      - vault_report
+    maxTurns: 5
+    required: true

package/dist/src/agent/prompts/agent.md

@@ -1,6 +1,6 @@
 # Myco Intelligence Agent
 
-You are the Myco intelligence agent. You process captured developer session data to build institutional knowledge. Your job is to read raw session activity, extract meaningful observations, build a knowledge graph, maintain spore lifecycle, and synthesize digest context.
+You are the Myco intelligence agent. You process captured developer session data to build institutional knowledge. Your job is to read raw session activity, extract meaningful observations, maintain spore lifecycle, and synthesize digest context.
 
 You operate on a vault database. The capture layer writes raw data (sessions, prompt batches, activities) without any intelligence. You provide the intelligence — deciding what matters, what connects, and what has changed.
 
@@ -12,17 +12,15 @@ You operate on a vault database. The capture layer writes raw data (sessions, pr
 - **vault_unprocessed** — Get prompt batches not yet processed, ordered by ID. Supports cursor-based pagination via `after_id`.
 - **vault_spores** — List existing spores with filters: `observation_type`, `status` (active/superseded/archived), `agent_id`, `session_id`, or fetch exact spores by `ids` when you need full content for a semantic shortlist.
 - **vault_sessions** — List sessions with optional `status` filter, ordered by most recent.
+- **vault_session_summary_material** — Get compact title/summary material for one session in a single read: current title/summary plus the ordered prompt-batch arc with only user prompts and assistant summaries.
 - **vault_search_fts** — Full-text search across prompt batches and activities using FTS5. Best for keyword matches and finding session content. Params: `query`, `type` (prompt_batch, activity), `limit`.
 - **vault_search_semantic** — Semantic similarity search across embedded vault content (spores, sessions, plans, artifacts). Best for finding conceptually related content and shortlist candidates before reading exact records. Params: `query`, `namespace` (spores, sessions, plans, artifacts — omit to search all), `limit`.
 - **vault_read_digest** — Read current digest extracts. Call with no params for metadata, or with a `tier` number (1500/5000/10000) to read that tier's content.
-- **vault_entities** — List knowledge graph entities with optional `type` and `name` filters. Use to check existing entities before creating new ones.
-- **vault_edges** — List graph edges with optional `source_id`, `target_id`, and `type` filters. Use to check existing relationships before creating edges.
+- **vault_edges** — List lineage edges between sessions, prompt batches, and spores. Use for provenance walks: `FROM_SESSION` (spore→session), `EXTRACTED_FROM` (spore→batch), `HAS_BATCH` (session→batch), `DERIVED_FROM` (wisdom→source spores), `SUPERSEDED_BY` (spore→spore). Filters: `source_id`, `target_id`, `type`.
 
 ### Write Tools
 
 - **vault_create_spore** — Create a new observation. Requires `observation_type` and `content`. Optional: `session_id`, `prompt_batch_id`, `importance` (1-10), `tags`, `context`, `file_path`, `properties` (JSON string, e.g., `'{"consolidated_from": ["id1", "id2"]}'`).
-- **vault_create_entity** — Create or update a knowledge graph node. Requires `type` and `name`. Upserts on (type, name). Optional: `properties` object.
-- **vault_create_edge** — Create a directed relationship between entities. Requires `source_id`, `target_id`, `type`. Optional: `session_id`, `confidence` (0-1), `valid_from`, `properties`.
 - **vault_resolve_spore** — Resolve a spore's lifecycle. Requires `spore_id` and `action` (supersede/archive/merge/split/consolidate). Optional: `new_spore_id`, `reason`, `session_id`.
 - **vault_update_session** — Set a session's `title` and/or `summary`.
 - **vault_set_state** — Store a key-value pair for your cursor and preferences.
@@ -61,37 +59,15 @@ A good spore is specific and captures insight, not activity.
 - Create vague spores like "worked on authentication" — be precise about what was discovered or decided
 - Inflate importance scores — most spores should be 3-6
 
-## Entity Types
+## Lineage Edges (read-only, daemon-created)
 
-Only create an entity when it is referenced by 3+ spores from 2+ different sessions and represents a specific, named thing. Entities are hubs in the knowledge graph — not labels for every concept mentioned.
+The daemon maintains a lineage graph automatically — you do not create edges. Use `vault_edges` to walk provenance:
 
-Good entity names: "DaemonClient", "cursor-based pagination", "Chris"
-Bad entity names: "testing phase", "technical debt", "code quality"
-
-Three types only:
-
-- **component** — A module, class, service, or significant function (e.g., "EventBuffer", "DaemonClient", "SQLite")
-- **concept** — An architectural pattern or domain concept that spans multiple sessions. Must be specific and named, not abstract categories (e.g., "idempotent writes", "cursor-based pagination")
-- **person** — A contributor or team member mentioned in sessions
-
-## Relationship Types
-
-**Semantic edges** (you create these via `vault_create_edge`):
-
-- **RELATES_TO** — General semantic relationship (spore→spore or entity→entity)
-- **SUPERSEDED_BY** — A newer observation replaces an older one (spore→spore)
-- **REFERENCES** — A spore references an entity (spore→entity)
-- **DEPENDS_ON** — Architectural dependency (entity→entity)
-- **AFFECTS** — An observation impacts a component (spore→entity)
-
-**Lineage edges** (created automatically — do NOT create these):
-
-- **FROM_SESSION** — spore → session (auto-created on spore insert)
-- **EXTRACTED_FROM** — spore → batch (auto-created on spore insert)
-- **HAS_BATCH** — session → batch (auto-created on batch insert)
-- **DERIVED_FROM** — wisdom spore → source spore (auto-created on consolidation)
-
-Set `confidence` below 1.0 when the relationship is inferred rather than explicitly stated. Include `session_id` for provenance.
+- **FROM_SESSION** — spore → session (which session produced this observation)
+- **EXTRACTED_FROM** — spore → batch (which prompt batch surfaced it)
+- **HAS_BATCH** — session → batch (structural containment)
+- **DERIVED_FROM** — wisdom spore → source spore (consolidation provenance)
+- **SUPERSEDED_BY** — spore → spore (supersession link)
 
 ## Skill Lifecycle Tools
 
@@ -130,15 +106,13 @@ When running as a single-query task (no phased executor), follow this general se
 2. **Extract** — process batches, create/supersede spores, mark processed, update cursor
 3. **Summarize** — update session titles and summaries for touched sessions
 4. **Consolidate** — search for related spores, create wisdom from 3+ clusters, supersede stale pairs
-5. **Build graph** — create entities (check `vault_entities` first), link with semantic edges (check `vault_edges` first)
-6. **Update digest** — read current tiers via `vault_read_digest`, integrate new material, write updated tiers
-7. **Report** — call `vault_report` with counts and outcomes
+5. **Update digest** — read current tiers via `vault_read_digest`, integrate new material, write updated tiers
+6. **Report** — call `vault_report` with counts and outcomes
 
 For phased tasks, follow only your assigned phase instructions. The executor controls phase sequencing.
 
 **Key rules across all modes:**
 - Supersede rather than duplicate — the vault gets sharper, not bigger
-- Check existing entities/edges before creating to avoid duplicates
 - One observation per spore, specific not vague
 - Report via `vault_report` after each significant action
 - If no work to do, report "skip" with reason and finish

package/dist/src/cli.js

@@ -2,5 +2,5 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/cli.ts
-await import("../cli-UWBAOHLL.js");
+await import("../cli-LNYSTDQM.js");
 //# sourceMappingURL=cli.js.map

package/dist/src/daemon/main.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/daemon.ts
-var { main } = await import("../../main-E7HU4QYR.js");
+var { main } = await import("../../main-5PRQNEEE.js");
 await main();
 //# sourceMappingURL=main.js.map

package/dist/src/hooks/post-tool-use.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/post-tool-use.ts
-var { main } = await import("../../post-tool-use-RYHXLCTC.js");
+var { main } = await import("../../post-tool-use-GMMSYBII.js");
 await main();
 //# sourceMappingURL=post-tool-use.js.map

package/dist/src/hooks/session-end.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/session-end.ts
-var { main } = await import("../../session-end-DQELLTGJ.js");
+var { main } = await import("../../session-end-LWJYQAXX.js");
 await main();
 //# sourceMappingURL=session-end.js.map

package/dist/src/hooks/session-start.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/session-start.ts
-var { main } = await import("../../session-start-5SUTR5GP.js");
+var { main } = await import("../../session-start-WTA6GCOQ.js");
 await main();
 //# sourceMappingURL=session-start.js.map

package/dist/src/hooks/stop.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/stop.ts
-var { main } = await import("../../stop-5AJXBKEE.js");
+var { main } = await import("../../stop-WRBTXEVT.js");
 await main();
 //# sourceMappingURL=stop.js.map

package/dist/src/hooks/user-prompt-submit.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/user-prompt-submit.ts
-var { main } = await import("../../user-prompt-submit-TTBTHBBH.js");
+var { main } = await import("../../user-prompt-submit-ME2TBKOS.js");
 await main();
 //# sourceMappingURL=user-prompt-submit.js.map

package/dist/src/mcp/server.js

@@ -1,6 +1,6 @@
 import { createRequire as __cr } from 'node:module'; const require = __cr(import.meta.url);
 
 // src/entries/mcp-server.ts
-var { main } = await import("../../server-TSYZMFFK.js");
+var { main } = await import("../../server-AHUR6CWF.js");
 await main();
 //# sourceMappingURL=server.js.map

package/dist/src/symbionts/manifests/claude-code.yaml

@@ -16,6 +16,10 @@ capture:
     # user-committed plans in the repo.
     - ~/.claude/plans/
     - .claude/plans/
+  planTags:
+    # Ultraplan sends the approved cloud plan back to the terminal by injecting
+    # it into the next user prompt as <ultraplan>...</ultraplan>.
+    - ultraplan
 registration:
   hooksTarget: .claude/settings.json
   mcpTarget: .mcp.json

package/dist/src/symbionts/manifests/pi.yaml

@@ -0,0 +1,22 @@
+name: pi
+displayName: Pi
+binary: pi
+configDir: .pi
+pluginRootEnvVar: PI_PLUGIN_ROOT
+hookFields:
+  sessionId: session_id
+  transcriptPath: transcript_path
+  lastResponse: last_assistant_message
+capture:
+  planDirs:
+    - .pi/plans/
+registration:
+  # Pi uses an extension file, not JSON hook entries
+  hooksTarget: .pi/extensions/myco/index.ts
+  hooksFormat: plugin-file
+  # package.json for the extension's deps
+  pluginPackageTarget: .pi/extensions/myco/package.json
+  # Pi has no native MCP — Myco tools are registered via pi.registerTool()
+  # mcpTarget is omitted; tools are wired in the extension itself.
+  skillsTarget: .agents/skills
+  # No instructionsFile — pi reads AGENTS.md natively via context files

package/dist/src/symbionts/templates/pi/package.json

@@ -0,0 +1,6 @@
+{
+  "dependencies": {
+    "@mariozechner/pi-coding-agent": "*",
+    "@sinclair/typebox": "*"
+  }
+}