pi-crew 0.1.49 → 0.2.0

package/skills/systematic-debugging/SKILL.md

@@ -1,67 +1,67 @@
----
-name: systematic-debugging
-description: Use when encountering a bug, test failure, blocked run, provider error, stale state, crash, or unexpected behavior before proposing fixes.
----
-
-# systematic-debugging
-
-Core principle: no fixes without root-cause investigation first. Symptom patches create new bugs and hide the real failure.
-
-Distilled from detailed reads of systematic-debugging, root-cause tracing, TDD, and error-analysis skill patterns.
-
-## Four Phases
-
-### 1. Root Cause Investigation
-
-Before any fix:
-
-- read error messages, stack traces, failing assertions, task status, and logs completely;
-- reproduce narrowly and record the exact command/steps;
-- check recent diffs, commits, config changes, dependency changes, and environment differences;
-- trace data/control flow across component boundaries;
-- add temporary diagnostics only when they answer a specific question.
-
-For pi-crew, trace:
-
-```text
-user/tool params → config resolution → team/workflow/agent discovery → model/runtime routing → child args/env → state/events/artifacts → status/UI
-```
-
-### 2. Pattern Analysis
-
-- Find a similar working path in the codebase.
-- Compare working vs broken behavior field-by-field.
-- Identify dependencies: config home, project root markers, env vars, locks, stale caches, provider model capabilities.
-- Do not assume small differences are irrelevant.
-
-### 3. Hypothesis and Test
-
-- State one hypothesis: “I think X is the root cause because Y.”
-- Test one variable at a time with the smallest read-only probe or targeted test.
-- If wrong, discard the hypothesis instead of piling on fixes.
-- After three failed fixes, question architecture or assumptions before continuing.
-
-### 4. Implementation
-
-- Add or identify a failing regression test when practical.
-- Fix the root cause, not the symptom.
-- Avoid “while I’m here” refactors.
-- Verify targeted behavior, then broader gates.
-
-## Evidence to Collect
-
-- failing command and exit code;
-- relevant manifest/tasks/events/mailbox files;
-- effective config paths and redacted config;
-- child Pi args/env after redaction;
-- git diff and recent commits;
-- provider/model/thinking resolution;
-- async timing/race indicators.
-
-## Anti-patterns
-
-- Fixing before reproducing.
-- Assuming real user global config cannot pollute tests.
-- Treating provider errors as only transient network failures.
-- Removing guards because they reveal a blocked state.
-- Editing unrelated layers before checking the hypothesis.
+---
+name: systematic-debugging
+description: Use when encountering a bug, test failure, blocked run, provider error, stale state, crash, or unexpected behavior before proposing fixes.
+---
+
+# systematic-debugging
+
+Core principle: no fixes without root-cause investigation first. Symptom patches create new bugs and hide the real failure.
+
+Distilled from detailed reads of systematic-debugging, root-cause tracing, TDD, and error-analysis skill patterns.
+
+## Four Phases
+
+### 1. Root Cause Investigation
+
+Before any fix:
+
+- read error messages, stack traces, failing assertions, task status, and logs completely;
+- reproduce narrowly and record the exact command/steps;
+- check recent diffs, commits, config changes, dependency changes, and environment differences;
+- trace data/control flow across component boundaries;
+- add temporary diagnostics only when they answer a specific question.
+
+For pi-crew, trace:
+
+```text
+user/tool params → config resolution → team/workflow/agent discovery → model/runtime routing → child args/env → state/events/artifacts → status/UI
+```
+
+### 2. Pattern Analysis
+
+- Find a similar working path in the codebase.
+- Compare working vs broken behavior field-by-field.
+- Identify dependencies: config home, project root markers, env vars, locks, stale caches, provider model capabilities.
+- Do not assume small differences are irrelevant.
+
+### 3. Hypothesis and Test
+
+- State one hypothesis: “I think X is the root cause because Y.”
+- Test one variable at a time with the smallest read-only probe or targeted test.
+- If wrong, discard the hypothesis instead of piling on fixes.
+- After three failed fixes, question architecture or assumptions before continuing.
+
+### 4. Implementation
+
+- Add or identify a failing regression test when practical.
+- Fix the root cause, not the symptom.
+- Avoid “while I’m here” refactors.
+- Verify targeted behavior, then broader gates.
+
+## Evidence to Collect
+
+- failing command and exit code;
+- relevant manifest/tasks/events/mailbox files;
+- effective config paths and redacted config;
+- child Pi args/env after redaction;
+- git diff and recent commits;
+- provider/model/thinking resolution;
+- async timing/race indicators.
+
+## Anti-patterns
+
+- Fixing before reproducing.
+- Assuming real user global config cannot pollute tests.
+- Treating provider errors as only transient network failures.
+- Removing guards because they reveal a blocked state.
+- Editing unrelated layers before checking the hypothesis.

package/skills/ui-render-performance/SKILL.md

@@ -1,39 +1,39 @@
----
-name: ui-render-performance
-description: Non-blocking Pi TUI render workflow. Use when changing widgets, powerbar/statusbar segments, dashboard panes, overlays, snapshot caches, or live UI refresh behavior.
----
-
-# ui-render-performance
-
-Use this skill for Pi/pi-crew TUI work.
-
-## Source patterns distilled
-
-- Pi TUI is synchronous immediate-mode/string rendering: `source/pi-mono/packages/coding-agent/src/modes/interactive/interactive-mode.ts`
-- Pi extension examples use event-driven state updates, not render-time loading.
-- pi-crew UI: `src/extension/register.ts`, `src/ui/run-dashboard.ts`, `src/ui/run-snapshot-cache.ts`, `src/ui/crew-widget.ts`, `src/ui/powerbar-publisher.ts`, `src/ui/render-scheduler.ts`
-
-## Rules
-
-- Treat every `render(width)` and widget/powerbar update as a hot synchronous path.
-- Render from in-memory snapshots only. Preload config, manifests, snapshots, agents, and mailbox counts asynchronously.
-- Use `RenderScheduler.schedule()` to coalesce renders; avoid direct repeated rendering.
-- Prefer `snapshotCache.get(runId)` in render paths. If a sync fallback is unavoidable, classify it as first-load/rare and document why.
-- Keep dashboard panes pure: accept a snapshot/model and format strings; do not call `fs.readFileSync`, `fs.readdirSync`, `fs.statSync`, or network APIs from pane render methods.
-- On session switch, cancel timers and ensure in-flight async preloads cannot update stale session UI.
-- Watch TTL interactions: a preload interval shorter than cache TTL prevents render-time refresh gaps.
-
-## Anti-patterns
-
-- Do not call `loadConfig()`, `manifestCache.list()`, or `refreshIfStale()` repeatedly inside `renderTick()` unless backed by preloaded frame data.
-- Do not do large JSON parsing or directory scans inside widget render/update functions.
-- Do not show stale health warnings for completed/cancelled/failed runs.
-
-## Verification
-
-```bash
-cd pi-crew
-npx tsc --noEmit
-node --experimental-strip-types --test test/unit/run-snapshot-cache.test.ts test/unit/crew-widget.test.ts test/unit/powerbar-publisher.test.ts test/unit/run-dashboard.test.ts
-npm test
-```
+---
+name: ui-render-performance
+description: Non-blocking Pi TUI render workflow. Use when changing widgets, powerbar/statusbar segments, dashboard panes, overlays, snapshot caches, or live UI refresh behavior.
+---
+
+# ui-render-performance
+
+Use this skill for Pi/pi-crew TUI work.
+
+## Source patterns distilled
+
+- Pi TUI is synchronous immediate-mode/string rendering: `source/pi-mono/packages/coding-agent/src/modes/interactive/interactive-mode.ts`
+- Pi extension examples use event-driven state updates, not render-time loading.
+- pi-crew UI: `src/extension/register.ts`, `src/ui/run-dashboard.ts`, `src/ui/run-snapshot-cache.ts`, `src/ui/crew-widget.ts`, `src/ui/powerbar-publisher.ts`, `src/ui/render-scheduler.ts`
+
+## Rules
+
+- Treat every `render(width)` and widget/powerbar update as a hot synchronous path.
+- Render from in-memory snapshots only. Preload config, manifests, snapshots, agents, and mailbox counts asynchronously.
+- Use `RenderScheduler.schedule()` to coalesce renders; avoid direct repeated rendering.
+- Prefer `snapshotCache.get(runId)` in render paths. If a sync fallback is unavoidable, classify it as first-load/rare and document why.
+- Keep dashboard panes pure: accept a snapshot/model and format strings; do not call `fs.readFileSync`, `fs.readdirSync`, `fs.statSync`, or network APIs from pane render methods.
+- On session switch, cancel timers and ensure in-flight async preloads cannot update stale session UI.
+- Watch TTL interactions: a preload interval shorter than cache TTL prevents render-time refresh gaps.
+
+## Anti-patterns
+
+- Do not call `loadConfig()`, `manifestCache.list()`, or `refreshIfStale()` repeatedly inside `renderTick()` unless backed by preloaded frame data.
+- Do not do large JSON parsing or directory scans inside widget render/update functions.
+- Do not show stale health warnings for completed/cancelled/failed runs.
+
+## Verification
+
+```bash
+cd pi-crew
+npx tsc --noEmit
+node --experimental-strip-types --test test/unit/run-snapshot-cache.test.ts test/unit/crew-widget.test.ts test/unit/powerbar-publisher.test.ts test/unit/run-dashboard.test.ts
+npm test
+```

package/skills/verification-before-done/SKILL.md

@@ -1,57 +1,57 @@
----
-name: verification-before-done
-description: Use when about to claim work is complete, fixed, passing, reviewed, committed, or ready to hand off.
----
-
-# verification-before-done
-
-Core principle: evidence before claims. A worker report, green-looking log, or previous run is not fresh verification.
-
-Distilled from detailed reads of agent-skill patterns for verification-before-completion, TDD, review reception, and QA workflows.
-
-## Gate Function
-
-Before any completion claim:
-
-1. Identify the command or inspection that proves the claim.
-2. Run the full command fresh, or explicitly state why a command cannot be run.
-3. Read the output, including exit code and failure counts.
-4. Compare the output to the claim.
-5. Report the claim only with the evidence.
-
-## Claim-to-Evidence Table
-
-| Claim | Requires | Not sufficient |
-|---|---|---|
-| Tests pass | Fresh test output with zero failures | Prior run, “should pass” |
-| Typecheck passes | Typecheck command exit 0 | Lint or targeted tests only |
-| Bug fixed | Original symptom/regression test passes | Code changed |
-| Requirements met | Checklist against request/plan | Generic test success |
-| Agent completed | Worker output plus artifact/diff/state inspection | Worker says DONE |
-| Safe to commit | Relevant checks pass and status reviewed | Partial local confidence |
-
-## Verification Ladder
-
-Choose the smallest reliable gate, then escalate when risk requires it:
-
-1. Read-only inspection for plans/reviews.
-2. Targeted unit test for touched behavior.
-3. Typecheck for TypeScript/schema/API changes.
-4. Integration test for runtime, subprocess, state, filesystem, UI, config, or session behavior.
-5. Full suite before commit/release or broad changes.
-6. Real Pi smoke only when safe and needed.
-
-## Done Report
-
-Include:
-
-- changed files or read-only status;
-- commands run and pass/fail result;
-- artifacts, run IDs, logs, or state paths inspected;
-- behavior actually verified;
-- skipped checks and why;
-- risks and rollback notes.
-
-## Red Flags
-
-Stop before saying done if you are using words like “should”, “probably”, “looks”, “seems”, “I think”, or if you are trusting an agent report without checking evidence.
+---
+name: verification-before-done
+description: Use when about to claim work is complete, fixed, passing, reviewed, committed, or ready to hand off.
+---
+
+# verification-before-done
+
+Core principle: evidence before claims. A worker report, green-looking log, or previous run is not fresh verification.
+
+Distilled from detailed reads of agent-skill patterns for verification-before-completion, TDD, review reception, and QA workflows.
+
+## Gate Function
+
+Before any completion claim:
+
+1. Identify the command or inspection that proves the claim.
+2. Run the full command fresh, or explicitly state why a command cannot be run.
+3. Read the output, including exit code and failure counts.
+4. Compare the output to the claim.
+5. Report the claim only with the evidence.
+
+## Claim-to-Evidence Table
+
+| Claim | Requires | Not sufficient |
+|---|---|---|
+| Tests pass | Fresh test output with zero failures | Prior run, “should pass” |
+| Typecheck passes | Typecheck command exit 0 | Lint or targeted tests only |
+| Bug fixed | Original symptom/regression test passes | Code changed |
+| Requirements met | Checklist against request/plan | Generic test success |
+| Agent completed | Worker output plus artifact/diff/state inspection | Worker says DONE |
+| Safe to commit | Relevant checks pass and status reviewed | Partial local confidence |
+
+## Verification Ladder
+
+Choose the smallest reliable gate, then escalate when risk requires it:
+
+1. Read-only inspection for plans/reviews.
+2. Targeted unit test for touched behavior.
+3. Typecheck for TypeScript/schema/API changes.
+4. Integration test for runtime, subprocess, state, filesystem, UI, config, or session behavior.
+5. Full suite before commit/release or broad changes.
+6. Real Pi smoke only when safe and needed.
+
+## Done Report
+
+Include:
+
+- changed files or read-only status;
+- commands run and pass/fail result;
+- artifacts, run IDs, logs, or state paths inspected;
+- behavior actually verified;
+- skipped checks and why;
+- risks and rollback notes.
+
+## Red Flags
+
+Stop before saying done if you are using words like “should”, “probably”, “looks”, “seems”, “I think”, or if you are trusting an agent report without checking evidence.

package/skills/worktree-isolation/SKILL.md

@@ -1,39 +1,39 @@
----
-name: worktree-isolation
-description: Conflict-safe git worktree workflow. Use when running parallel implementation workers, isolating risky edits, or cleaning up task worktrees.
----
-
-# worktree-isolation
-
-Use this skill for worktree-based execution or cleanup.
-
-## Source patterns distilled
-
-- pi-subagents worktree runner and cleanup patterns
-- pi-crew worktrees: `src/worktree/worktree-manager.ts`, `src/worktree/cleanup.ts`, `src/worktree/branch-freshness.ts`
-- Team runner workspace mode: `src/runtime/team-runner.ts`, workflow/team resource fields
-
-## Rules
-
-- Use worktree mode for parallel or risky code-changing tasks when the repository is clean enough and merge ownership is clear.
-- Assign one owner per file/symbol/migration path to avoid conflict-heavy merges.
-- Name branches/worktrees deterministically from run/task IDs; avoid user-controlled path fragments without sanitization.
-- Before cleanup, check dirty state. Preserve dirty worktrees unless `force` is explicitly set.
-- Record worktree paths and branch metadata in artifacts/events so the operator can inspect or recover.
-- Do not run destructive git operations without explicit confirmation and evidence of target path containment.
-
-## Anti-patterns
-
-- Parallel editing the same file in multiple worktrees without a merge plan.
-- Force-removing dirty worktrees by default.
-- Reusing stale worktrees after the base branch has moved without freshness checks.
-- Storing worktrees outside the intended contained workspace root.
-
-## Verification
-
-```bash
-cd pi-crew
-npx tsc --noEmit
-node --experimental-strip-types --test test/integration/worktree-mode.test.ts test/unit/run-index.test.ts
-npm test
-```
+---
+name: worktree-isolation
+description: Conflict-safe git worktree workflow. Use when running parallel implementation workers, isolating risky edits, or cleaning up task worktrees.
+---
+
+# worktree-isolation
+
+Use this skill for worktree-based execution or cleanup.
+
+## Source patterns distilled
+
+- pi-subagents worktree runner and cleanup patterns
+- pi-crew worktrees: `src/worktree/worktree-manager.ts`, `src/worktree/cleanup.ts`, `src/worktree/branch-freshness.ts`
+- Team runner workspace mode: `src/runtime/team-runner.ts`, workflow/team resource fields
+
+## Rules
+
+- Use worktree mode for parallel or risky code-changing tasks when the repository is clean enough and merge ownership is clear.
+- Assign one owner per file/symbol/migration path to avoid conflict-heavy merges.
+- Name branches/worktrees deterministically from run/task IDs; avoid user-controlled path fragments without sanitization.
+- Before cleanup, check dirty state. Preserve dirty worktrees unless `force` is explicitly set.
+- Record worktree paths and branch metadata in artifacts/events so the operator can inspect or recover.
+- Do not run destructive git operations without explicit confirmation and evidence of target path containment.
+
+## Anti-patterns
+
+- Parallel editing the same file in multiple worktrees without a merge plan.
+- Force-removing dirty worktrees by default.
+- Reusing stale worktrees after the base branch has moved without freshness checks.
+- Storing worktrees outside the intended contained workspace root.
+
+## Verification
+
+```bash
+cd pi-crew
+npx tsc --noEmit
+node --experimental-strip-types --test test/integration/worktree-mode.test.ts test/unit/run-index.test.ts
+npm test
+```

package/src/adapters/claude-adapter.ts

@@ -0,0 +1,25 @@
+import type { ExportAdapter, ExportContent } from "./types.ts";
+
+export const claudeAdapter: ExportAdapter = {
+	toolId: "claude",
+	toolName: "Claude Code",
+	fileExtension: ".md",
+
+	getFilePath(content: ExportContent): string {
+		return `.claude/commands/pi-crew/${content.id}.md`;
+	},
+
+	formatFile(content: ExportContent): string {
+		const tagLines = content.tags.length > 0
+			? ["tags:", ...content.tags.map((tag) => `  - ${JSON.stringify(tag)}`)]
+			: [];
+		const frontmatter = [
+			"---",
+			`description: ${JSON.stringify(content.description)}`,
+			`category: ${JSON.stringify(content.category)}`,
+			...tagLines,
+			"---",
+		].join("\n");
+		return `${frontmatter}\n\n# ${content.name}\n\n${content.body}\n`;
+	},
+};

package/src/adapters/codex-adapter.ts

@@ -0,0 +1,21 @@
+import type { ExportAdapter, ExportContent } from "./types.ts";
+
+export const codexAdapter: ExportAdapter = {
+	toolId: "codex",
+	toolName: "Codex",
+	fileExtension: ".md",
+
+	getFilePath(_content: ExportContent): string {
+		return "AGENTS.md";
+	},
+
+	formatFile(content: ExportContent): string {
+		const tags = content.tags.length > 0 ? ` (${content.tags.join(", ")})` : "";
+		return [
+			`## ${content.name}${tags}\n`,
+			`**Source:** ${content.source.type}/${content.source.name}  `,
+			`**Category:** ${content.category}\n`,
+			content.body,
+		].join("\n");
+	},
+};

package/src/adapters/cursor-adapter.ts

@@ -0,0 +1,17 @@
+import type { ExportAdapter, ExportContent } from "./types.ts";
+
+export const cursorAdapter: ExportAdapter = {
+	toolId: "cursor",
+	toolName: "Cursor",
+	fileExtension: ".md",
+
+	getFilePath(content: ExportContent): string {
+		return `.cursor/rules/pi-crew-${content.id}.md`;
+	},
+
+	formatFile(content: ExportContent): string {
+		const header = `# ${content.name}\n\n> ${content.description}`;
+		const tags = content.tags.length > 0 ? `\n\n**Tags:** ${content.tags.join(", ")}` : "";
+		return `${header}${tags}\n\n${content.body}\n`;
+	},
+};

package/src/adapters/export-util.ts

@@ -0,0 +1,137 @@
+import type { AgentConfig } from "../agents/agent-config.ts";
+import type { TeamConfig } from "../teams/team-config.ts";
+import type { WorkflowConfig } from "../workflows/workflow-config.ts";
+import type { SkillDescriptor } from "../skills/discover-skills.ts";
+import type { ExportContent } from "./types.ts";
+import { adapterRegistry } from "./registry.ts";
+import { resolveContainedPath } from "../utils/safe-paths.ts";
+
+function slugify(value: string): string {
+	return value
+		.toLowerCase()
+		.replace(/[^a-z0-9]+/g, "-")
+		.replace(/^-+|-+$/g, "");
+}
+
+export function agentToExportContent(agent: AgentConfig): ExportContent {
+	const category = agent.routing?.category ?? "agent";
+	const tags = agent.routing?.triggers ?? [];
+	return {
+		id: slugify(agent.name),
+		name: agent.name,
+		description: agent.description,
+		category,
+		tags,
+		body: agent.systemPrompt,
+		source: { type: "agent", name: agent.name },
+	};
+}
+
+export function teamToExportContent(team: TeamConfig): ExportContent {
+	const category = team.routing?.category ?? "team";
+	const tags = team.routing?.triggers ?? [];
+	const rolesDesc = team.roles
+		.map((role) => `- **${role.name}**: ${role.description ?? role.agent}`)
+		.join("\n");
+	const body = `${team.description}\n\n### Roles\n${rolesDesc}`;
+	return {
+		id: slugify(team.name),
+		name: team.name,
+		description: team.description,
+		category,
+		tags,
+		body,
+		source: { type: "team", name: team.name },
+	};
+}
+
+export function workflowToExportContent(workflow: WorkflowConfig): ExportContent {
+	const stepsDesc = workflow.steps
+		.map((step) => `- **${step.id}** (${step.role}): ${step.task}`)
+		.join("\n");
+	const body = `${workflow.description}\n\n### Steps\n${stepsDesc}`;
+	return {
+		id: slugify(workflow.name),
+		name: workflow.name,
+		description: workflow.description,
+		category: "workflow",
+		tags: [],
+		body,
+		source: { type: "workflow", name: workflow.name },
+	};
+}
+
+export function skillToExportContent(skill: SkillDescriptor): ExportContent {
+	return {
+		id: slugify(skill.name),
+		name: skill.name,
+		description: skill.description || `Skill: ${skill.name}`,
+		category: "skill",
+		tags: [],
+		body: `Skill loaded from ${skill.source}: ${skill.path}`,
+		source: { type: "skill", name: skill.name },
+	};
+}
+
+export type ExportableResource =
+	| { kind: "agent"; config: AgentConfig }
+	| { kind: "team"; config: TeamConfig }
+	| { kind: "workflow"; config: WorkflowConfig }
+	| { kind: "skill"; config: SkillDescriptor };
+
+export function resourcesToExportContent(resources: ExportableResource[]): ExportContent[] {
+	return resources.map((resource): ExportContent => {
+		switch (resource.kind) {
+			case "agent":
+				return agentToExportContent(resource.config);
+			case "team":
+				return teamToExportContent(resource.config);
+			case "workflow":
+				return workflowToExportContent(resource.config);
+			case "skill":
+				return skillToExportContent(resource.config);
+		}
+	});
+}
+
+export interface ToolExportResult {
+	toolId: string;
+	files: Array<{ path: string; content: string }>;
+}
+
+export function generateToolExport(
+	toolId: string,
+	resources: ExportableResource[],
+	projectRoot?: string,
+): ToolExportResult {
+	const adapter = adapterRegistry.get(toolId);
+	if (!adapter) {
+		throw new Error(`Unknown export adapter: ${toolId}. Available: ${adapterRegistry.getAll().map((a) => a.toolId).join(", ")}`);
+	}
+	const contents = resourcesToExportContent(resources);
+	const files = contents.map((content): { path: string; content: string } => {
+		const filePath = adapter.getFilePath(content);
+		// Validate path containment when a project root is provided
+		if (projectRoot) {
+			try {
+				resolveContainedPath(projectRoot, filePath);
+			} catch (e) {
+				throw new Error(
+					`Export path '${filePath}' escapes project root '${projectRoot}': ${e instanceof Error ? e.message : String(e)}`,
+				);
+			}
+		}
+		return {
+			path: filePath,
+			content: adapter.formatFile(content),
+		};
+	});
+	// Merge duplicate file paths (e.g., codex adapter maps everything to AGENTS.md)
+	const merged = new Map<string, string>();
+	for (const f of files) {
+		const existing = merged.get(f.path);
+		merged.set(f.path, existing ? `${existing}\n\n${f.content}` : f.content);
+	}
+	const mergedFiles = [...merged.entries()].map(([p, content]) => ({ path: p, content }));
+	return { toolId, files: mergedFiles };
+}

package/src/adapters/index.ts

@@ -0,0 +1,15 @@
+export type { ExportContent, ExportAdapter, AdapterRegistry } from "./types.ts";
+export { createAdapterRegistry, adapterRegistry } from "./registry.ts";
+export { claudeAdapter } from "./claude-adapter.ts";
+export { cursorAdapter } from "./cursor-adapter.ts";
+export { codexAdapter } from "./codex-adapter.ts";
+export { generateToolExport, resourcesToExportContent } from "./export-util.ts";
+
+import { adapterRegistry } from "./registry.ts";
+import { claudeAdapter } from "./claude-adapter.ts";
+import { cursorAdapter } from "./cursor-adapter.ts";
+import { codexAdapter } from "./codex-adapter.ts";
+
+adapterRegistry.register(claudeAdapter);
+adapterRegistry.register(cursorAdapter);
+adapterRegistry.register(codexAdapter);

package/src/adapters/registry.ts

@@ -0,0 +1,18 @@
+import type { AdapterRegistry, ExportAdapter } from "./types.ts";
+
+export function createAdapterRegistry(): AdapterRegistry {
+	const adapters = new Map<string, ExportAdapter>();
+	return {
+		get(toolId: string): ExportAdapter | undefined {
+			return adapters.get(toolId);
+		},
+		getAll(): ExportAdapter[] {
+			return [...adapters.values()];
+		},
+		register(adapter: ExportAdapter): void {
+			adapters.set(adapter.toolId, adapter);
+		},
+	};
+}
+
+export const adapterRegistry: AdapterRegistry = createAdapterRegistry();