@soleri/core 2.1.0 → 2.5.0

package/src/playbooks/generic/brainstorming.ts

@@ -0,0 +1,110 @@
+/**
+ * Generic Playbook: Brainstorming
+ *
+ * Design-before-code enforcement.
+ * Ported from Salvador's brainstorming playbook.
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const brainstormingPlaybook: PlaybookDefinition = {
+  id: 'generic-brainstorming',
+  tier: 'generic',
+  title: 'Brainstorming — Design Before Code',
+  trigger:
+    'Use when the request is creative, ambiguous, or involves building something new. Activates before any implementation work to ensure design is explored and approved.',
+  description:
+    'Structured design exploration before writing any code. The agent explores context, asks clarifying questions, proposes 2-3 approaches with trade-offs, and presents the design in digestible sections for approval. No code is written until the design is approved. This prevents the common failure mode of jumping into implementation before understanding what to build.',
+  steps: `1. EXPLORE CONTEXT
+   - What exists? Read relevant code, docs, prior art
+   - What constraints apply? Tech stack, patterns, conventions
+   - What's been tried before? Search vault for related patterns
+
+2. ASK CLARIFYING QUESTIONS
+   - Surface assumptions that could derail implementation
+   - Ask about edge cases, error handling, user expectations
+   - Ask about scope boundaries — what's explicitly NOT included
+
+3. PROPOSE 2-3 APPROACHES
+   - Each approach with clear trade-offs (complexity, performance, maintainability)
+   - Recommend one with rationale
+   - Wait for user feedback before proceeding
+
+4. PRESENT DESIGN IN SECTIONS
+   - Break design into chunks short enough to read and digest
+   - Architecture, data flow, API surface, error handling, testing strategy
+   - Get approval on each section before moving to next
+
+5. WRITE DESIGN DOCUMENT
+   - Save approved design to docs/ or vault
+   - Include decisions and rationale
+   - This becomes the source of truth for implementation
+
+HARD GATE: No implementation code until design is approved.`,
+  expectedOutcome:
+    'A clear, approved design document that eliminates ambiguity. Implementation follows a known path. Decisions are documented with rationale. No surprises during coding.',
+  category: 'methodology',
+  tags: ['brainstorming', 'design', 'planning', 'exploration', 'generic'],
+  matchIntents: ['BUILD', 'PLAN'],
+  matchKeywords: [
+    'build',
+    'create',
+    'design',
+    'architect',
+    'plan',
+    'new feature',
+    'from scratch',
+    'rethink',
+  ],
+  brainstormSections: [
+    {
+      title: 'Architecture',
+      description: 'High-level structure, components, and their relationships.',
+      questions: [
+        'What are the main building blocks?',
+        'How do they communicate?',
+        'What are the boundaries and interfaces?',
+      ],
+    },
+    {
+      title: 'Data Flow',
+      description: 'How data moves through the system — inputs, transformations, outputs.',
+      questions: [
+        'What data does this consume and produce?',
+        'Where does state live?',
+        'What are the data dependencies?',
+      ],
+    },
+    {
+      title: 'Error Handling',
+      description: 'What can go wrong and how to handle it gracefully.',
+      questions: [
+        'What are the failure modes?',
+        'How should errors be surfaced to users?',
+        'What recovery strategies are needed?',
+      ],
+    },
+    {
+      title: 'Testing Strategy',
+      description: 'How to verify correctness at each level.',
+      questions: [
+        'What are the critical behaviors to test?',
+        'Unit vs integration vs e2e — what balance?',
+        'What edge cases matter most?',
+      ],
+    },
+  ],
+  gates: [
+    {
+      phase: 'brainstorming',
+      requirement: 'Design must be explored and approved before plan creation',
+      checkType: 'brainstorm',
+    },
+  ],
+  taskTemplates: [],
+  toolInjections: ['search_intelligent'],
+  verificationCriteria: [
+    'Design document exists and covers architecture, data flow, and error handling',
+    'User approved the design before implementation started',
+  ],
+};

package/src/playbooks/generic/code-review.ts

@@ -0,0 +1,181 @@
+/**
+ * Generic Playbook: Code Review
+ *
+ * Structured PR review discipline — 7-category grading with smell detection.
+ * Ported from Salvador's code-review playbook.
+ * Based on vault knowledge: "Structured Code Review: Grade Each Category Then Provide Verdict"
+ * and "5-Step Systematic Refactoring: Ingest → Scan → Plan → Edit → Verify".
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const codeReviewPlaybook: PlaybookDefinition = {
+  id: 'generic-code-review',
+  tier: 'generic',
+  title: 'Structured Code Review',
+  trigger:
+    'Use when reviewing a pull request, code diff, or any code submission. Activates for REVIEW intent or when keywords like "review", "PR", "pull request", "diff", "check code" appear.',
+  description:
+    'Systematic code review using 7 independent grading categories (A-F). Each category is evaluated separately so no area hides behind others. Combines automated smell detection heuristics with human judgment. Produces a structured verdict with prioritized action items.',
+  steps: `1. UNDERSTAND THE CHANGE
+   - Read the PR description, linked issues, and acceptance criteria
+   - Understand the WHY before judging the HOW
+   - Identify the blast radius — what areas of the codebase are touched?
+   - Check: is this a feature, bugfix, refactor, or infrastructure change?
+
+2. AUTOMATED SMELL SCAN
+   - Deep nesting: any indentation 8+ spaces (3+ levels)
+   - Else after return: guard clause opportunities missed
+   - Long functions: >35 LOC = critical, 25-35 = warning, <15 = ideal
+   - Long parameter lists: >5 params = data clump smell
+   - Magic numbers: unnamed numeric literals in conditions
+   - Duplication: similar blocks of 3+ lines
+   - Dead code: commented-out code, unreachable branches
+   - Utils/helpers anti-modules: catch-all files with unrelated functions
+
+3. GRADE 7 CATEGORIES (A-F each)
+   A. NAMING
+      - Variables, functions, classes reveal intent?
+      - Consistent naming convention (camelCase, PascalCase, etc.)?
+      - No abbreviations or single-letter names (except i/j in loops)?
+      - Boolean names read as questions (isActive, hasPermission)?
+
+   B. FUNCTION DESIGN
+      - Each function does ONE thing (the "and" test)?
+      - Function length within limits (<15 ideal, >35 critical)?
+      - Parameters count reasonable (<5)?
+      - Return types explicit and consistent?
+      - Pure functions where possible?
+
+   C. COMMENTS & DOCUMENTATION
+      - Comments explain WHY, never WHAT?
+      - No commented-out code (version control is your backup)?
+      - Public API has JSDoc/TSDoc?
+      - Complex algorithms are documented?
+      - No redundant comments restating the code?
+
+   D. STRUCTURE & LAYOUT
+      - Single Responsibility at file/module level?
+      - Imports organized and minimal?
+      - No circular dependencies introduced?
+      - Consistent file organization matching project conventions?
+      - Changes are in the right place architecturally?
+
+   E. ERROR HANDLING
+      - Errors handled at the right level (not swallowed)?
+      - Error messages are actionable (not just "Something went wrong")?
+      - Edge cases covered (null, empty, boundary values)?
+      - No bare catch blocks that hide failures?
+      - Async errors properly propagated?
+
+   F. CODE SMELLS & CLEANLINESS
+      - No duplication (DRY without premature abstraction)?
+      - Guard clauses used instead of deep nesting?
+      - Early returns flatten control flow?
+      - No feature envy (method using another object's data excessively)?
+      - No shotgun surgery risk (change requires touching many files)?
+
+   G. SOLID & DESIGN PRINCIPLES
+      - Open/Closed: can this be extended without modification?
+      - Dependency Inversion: depends on abstractions, not concretions?
+      - Interface Segregation: no forcing unused dependencies on consumers?
+      - Liskov: subtypes are substitutable without surprises?
+      - Single Responsibility (already in Structure, reinforce here)?
+
+4. SECURITY & PERFORMANCE QUICK-CHECK
+   - No secrets, tokens, or credentials in code?
+   - No SQL injection, XSS, or command injection vectors?
+   - No N+1 query patterns or unbounded loops?
+   - No memory leaks (event listeners, subscriptions not cleaned up)?
+
+5. DELIVER VERDICT
+   - Overall grade (A-F) based on category grades
+   - Top 3 prioritized action items (most impactful first)
+   - Specific line references for each issue
+   - Praise what's done well — reinforcement matters
+   - Classify: APPROVE, REQUEST CHANGES, or COMMENT
+
+GRADING SCALE:
+| Grade | Meaning |
+|-------|---------|
+| A | Excellent — clean, idiomatic, well-designed |
+| B | Good — minor issues, mostly clean |
+| C | Acceptable — some issues need attention |
+| D | Below standard — significant issues |
+| F | Critical — must fix before merge |`,
+  expectedOutcome:
+    'Every PR receives a structured, fair, and thorough review. Each category is graded independently. The verdict includes specific, actionable feedback with line references. Good patterns are celebrated, problems are caught early.',
+  category: 'methodology',
+  tags: ['code-review', 'pr-review', 'quality', 'refactoring', 'smells', 'grading', 'generic'],
+  matchIntents: ['REVIEW'],
+  matchKeywords: [
+    'review',
+    'code review',
+    'pr review',
+    'pull request',
+    'diff',
+    'check code',
+    'review code',
+    'critique',
+    'feedback',
+    'approve',
+    'merge',
+  ],
+  gates: [
+    {
+      phase: 'pre-execution',
+      requirement: 'PR description and linked issues must be read before reviewing code',
+      checkType: 'review-context',
+    },
+    {
+      phase: 'post-task',
+      requirement: 'All 7 categories must have an explicit grade (A-F) with notes',
+      checkType: 'review-grading-complete',
+    },
+    {
+      phase: 'completion',
+      requirement: 'Verdict must include prioritized action items with specific line references',
+      checkType: 'review-verdict',
+    },
+  ],
+  taskTemplates: [
+    {
+      taskType: 'verification',
+      titleTemplate: 'Automated smell scan for: {objective}',
+      acceptanceCriteria: [
+        'Scanned for deep nesting (8+ spaces / 3+ levels)',
+        'Scanned for else-after-return patterns',
+        'Scanned for long functions (>35 LOC)',
+        'Scanned for long parameter lists (>5 params)',
+        'Scanned for magic numbers in conditions',
+        'Scanned for dead/commented-out code',
+        'Scanned for duplication across changed files',
+      ],
+      tools: [],
+      order: 'before-implementation',
+    },
+    {
+      taskType: 'verification',
+      titleTemplate: 'Grade 7 categories for: {objective}',
+      acceptanceCriteria: [
+        'Naming graded A-F with specific notes',
+        'Function Design graded A-F with specific notes',
+        'Comments graded A-F with specific notes',
+        'Structure graded A-F with specific notes',
+        'Error Handling graded A-F with specific notes',
+        'Smells graded A-F with specific notes',
+        'SOLID graded A-F with specific notes',
+      ],
+      tools: [],
+      order: 'after-implementation',
+    },
+  ],
+  toolInjections: [],
+  verificationCriteria: [
+    'All 7 categories have explicit A-F grades',
+    'At least 3 prioritized action items with line references',
+    'Security quick-check completed (no secrets, no injection vectors)',
+    'Automated smell scan results documented',
+    'Overall verdict delivered: APPROVE, REQUEST CHANGES, or COMMENT',
+  ],
+};

package/src/playbooks/generic/subagent-execution.ts

@@ -0,0 +1,74 @@
+/**
+ * Generic Playbook: Subagent-Driven Execution
+ *
+ * One fresh subagent per task with two-stage review.
+ * Ported from Salvador's subagent-execution playbook.
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const subagentExecutionPlaybook: PlaybookDefinition = {
+  id: 'generic-subagent-execution',
+  tier: 'generic',
+  title: 'Subagent-Driven Execution',
+  trigger:
+    'Use when a plan has 3 or more tasks. Dispatches a fresh subagent per task with two-stage review (spec compliance, then code quality). The controller agent manages the queue but never implements.',
+  description:
+    'Each plan task is executed by a fresh subagent that receives the full task spec, context, and self-review checklist. After each task completes, two reviewer subagents verify the work: first for spec compliance (did it do what was asked?), then for code quality (is it well-built?). The controller never writes implementation code — it only dispatches, reviews, and integrates.',
+  steps: `1. PREPARE DISPATCH
+   - Read the full task spec from the plan
+   - Gather relevant vault knowledge for this task
+   - Build the implementer prompt with task spec + context + self-review checklist
+
+2. DISPATCH IMPLEMENTER
+   - Spawn a fresh subagent with the implementer prompt
+   - Subagent asks clarifying questions before starting (blockers gate)
+   - Subagent implements, self-reviews, and reports back
+
+3. REVIEW STAGE 1: SPEC COMPLIANCE
+   - Spawn spec-reviewer subagent
+   - Reviewer reads ACTUAL CODE, not the implementer's report
+   - Compares implementation against task acceptance criteria line by line
+   - Returns: pass or fail with specific file:line references
+
+4. REVIEW STAGE 2: CODE QUALITY (only if Stage 1 passes)
+   - Spawn code-quality-reviewer subagent
+   - Reviews architecture, naming, error handling, test quality
+   - Returns: pass or issues by severity (critical blocks, others noted)
+
+5. INTEGRATE OR RETRY
+   - If both stages pass: mark task complete, move to next
+   - If Stage 1 fails: dispatch new implementer with failure feedback
+   - If Stage 2 has critical issues: dispatch targeted fix subagent
+   - Maximum 2 retries per task before escalating to human
+
+6. FINAL REVIEW
+   - After all tasks: one final review of the complete implementation
+   - Check cross-cutting concerns (consistency, integration points)`,
+  expectedOutcome:
+    'Each task is independently verified by reviewers who read actual code. The controller maintains oversight without implementation bias. Failed tasks get specific feedback and retry.',
+  category: 'methodology',
+  tags: ['subagent', 'execution', 'review', 'dispatch', 'generic'],
+  matchIntents: ['BUILD', 'IMPROVE'],
+  matchKeywords: ['implement', 'execute', 'build', 'multi-step', 'parallel'],
+  gates: [
+    {
+      phase: 'post-task',
+      requirement: 'Spec compliance review must pass before code quality review',
+      checkType: 'spec-review',
+    },
+    {
+      phase: 'post-task',
+      requirement:
+        'Code quality review must pass (no critical issues) before task is marked complete',
+      checkType: 'quality-review',
+    },
+  ],
+  taskTemplates: [],
+  toolInjections: [],
+  verificationCriteria: [
+    'All tasks passed spec compliance review',
+    'All tasks passed code quality review (no critical issues)',
+    'Final cross-cutting review completed',
+  ],
+};

package/src/playbooks/generic/systematic-debugging.ts

@@ -0,0 +1,92 @@
+/**
+ * Generic Playbook: Systematic Debugging
+ *
+ * 4-phase root cause process. No fixes without understanding.
+ * Ported from Salvador's systematic-debugging playbook.
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const systematicDebuggingPlaybook: PlaybookDefinition = {
+  id: 'generic-systematic-debugging',
+  tier: 'generic',
+  title: 'Systematic Debugging',
+  trigger:
+    'Use when something is broken, failing, or behaving unexpectedly. Activates for any FIX intent. Prevents the common failure mode of guessing at fixes without understanding the root cause.',
+  description:
+    'Four-phase root cause analysis: gather evidence, analyze patterns, form and test hypotheses, then implement the minimal fix. No fix is applied without first understanding WHY the bug exists. If 3+ fix attempts fail, the architecture is questioned rather than trying more patches.',
+  steps: `1. ROOT CAUSE ANALYSIS
+   - Reproduce the bug reliably (exact steps, exact output)
+   - Trace backward: symptom → immediate cause → what called this → original trigger
+   - Read the actual error output — do not guess from the description
+   - Search vault for similar bugs and their root causes
+
+2. PATTERN ANALYSIS
+   - Is this a known pattern? (race condition, stale cache, off-by-one, null ref)
+   - Has this module had bugs before? Check git history
+   - Are there related symptoms elsewhere?
+   - Map the failure boundary: what works, what doesn't, what's the edge
+
+3. HYPOTHESIS TESTING
+   - Form 1-3 specific hypotheses about the root cause
+   - For each: predict what you'd see if this hypothesis is correct
+   - Test each prediction with the smallest possible experiment
+   - One hypothesis at a time — don't combine changes
+
+4. MINIMAL FIX
+   - Fix the root cause, not the symptom
+   - Write a test that reproduces the bug FIRST (RED)
+   - Apply the smallest change that fixes it (GREEN)
+   - Verify no regressions (run full test suite)
+   - If 3+ fixes fail: stop and question the architecture
+
+IRON LAW: No fix without root cause understanding. No "try this and see."`,
+  expectedOutcome:
+    'Bug is fixed at the root cause with a regression test. The fix is minimal and targeted. Understanding is documented for future reference.',
+  category: 'methodology',
+  tags: ['debugging', 'root-cause', 'systematic', 'fix', 'generic'],
+  matchIntents: ['FIX'],
+  matchKeywords: [
+    'bug',
+    'broken',
+    'fix',
+    'error',
+    'failing',
+    'crash',
+    'wrong',
+    'unexpected',
+    'regression',
+  ],
+  gates: [
+    {
+      phase: 'pre-execution',
+      requirement: 'Root cause must be identified before any fix is attempted',
+      checkType: 'root-cause',
+    },
+    {
+      phase: 'completion',
+      requirement: 'Regression test exists and passes',
+      checkType: 'regression-test',
+    },
+  ],
+  taskTemplates: [
+    {
+      taskType: 'test',
+      titleTemplate: 'Write regression test reproducing: {objective}',
+      acceptanceCriteria: [
+        'Test reproduces the exact bug (fails without fix)',
+        'Test passes after fix is applied',
+        'Test is specific enough to catch this exact regression',
+      ],
+      tools: ['search_intelligent'],
+      order: 'before-implementation',
+    },
+  ],
+  toolInjections: ['search_intelligent'],
+  verificationCriteria: [
+    'Root cause is documented (not just "it works now")',
+    'Regression test exists and fails without fix, passes with fix',
+    'Full test suite passes (no new regressions)',
+    'Fix is minimal — only the root cause is addressed',
+  ],
+};

package/src/playbooks/generic/tdd.ts

@@ -0,0 +1,75 @@
+/**
+ * Generic Playbook: Test-Driven Development
+ *
+ * RED -> GREEN -> REFACTOR cycle.
+ * Ported from Salvador's TDD playbook with agent-agnostic tool injections.
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const tddPlaybook: PlaybookDefinition = {
+  id: 'generic-tdd',
+  tier: 'generic',
+  title: 'Test-Driven Development',
+  trigger:
+    'Use when intent is BUILD or FIX and implementation involves writing new code or modifying existing behavior. Activates for any task that produces production code.',
+  description:
+    'Enforces the RED-GREEN-REFACTOR cycle: write a failing test first, implement minimal code to pass it, then refactor. No production code exists without a test that demanded it. Tests drive the design — if something is hard to test, the design needs simplification.',
+  steps: `1. RED — Write the test first
+   - Write a test that describes the desired behavior
+   - Run it and watch it FAIL (read the actual output)
+   - If it passes without new code, the test is wrong or the feature already exists
+
+2. GREEN — Write minimal code to pass
+   - Write the simplest implementation that makes the test pass
+   - Do NOT write more code than the test demands
+   - Run the test and watch it PASS (read the actual output)
+
+3. REFACTOR — Clean up while green
+   - Improve structure, naming, duplication — without changing behavior
+   - Run tests after every change — they must stay green
+   - Commit when clean
+
+4. REPEAT — Next behavior, next test
+   - Each cycle should take 2-5 minutes
+   - If a cycle takes longer, the step is too big — break it down
+
+IRON LAW: If you wrote production code before the test, DELETE IT and start over.`,
+  expectedOutcome:
+    'Every piece of production code is demanded by a failing test. Test suite is comprehensive, fast, and trustworthy. Design emerges from testing pressure — simple, decoupled, focused.',
+  category: 'methodology',
+  tags: ['tdd', 'testing', 'red-green-refactor', 'discipline', 'generic'],
+  matchIntents: ['BUILD', 'FIX'],
+  matchKeywords: ['implement', 'build', 'create', 'add', 'fix', 'refactor', 'feature', 'code'],
+  gates: [
+    {
+      phase: 'post-task',
+      requirement: 'Test must exist and fail before implementation code is written',
+      checkType: 'tdd-red',
+    },
+    {
+      phase: 'completion',
+      requirement: 'All tests pass with actual output verified (not self-reported)',
+      checkType: 'tdd-green',
+    },
+  ],
+  taskTemplates: [
+    {
+      taskType: 'test',
+      titleTemplate: 'Write failing tests for: {objective}',
+      acceptanceCriteria: [
+        'Tests describe desired behavior, not implementation details',
+        'Tests run and FAIL (output read and verified)',
+        'No production code written yet',
+      ],
+      tools: ['search_intelligent'],
+      order: 'before-implementation',
+    },
+  ],
+  toolInjections: ['search_intelligent'],
+  verificationCriteria: [
+    'Test suite passes (run command, read output)',
+    'No skipped or pending tests',
+    'Coverage covers the new/modified code paths',
+  ],
+};

package/src/playbooks/generic/verification.ts

@@ -0,0 +1,79 @@
+/**
+ * Generic Playbook: Verification Before Completion
+ *
+ * Evidence-based completion — no self-reported success.
+ * Ported from Salvador's verification playbook.
+ */
+
+import type { PlaybookDefinition } from '../playbook-types.js';
+
+export const verificationPlaybook: PlaybookDefinition = {
+  id: 'generic-verification',
+  tier: 'generic',
+  title: 'Verification Before Completion',
+  trigger:
+    'Use at the completion of any task or plan. Activates automatically as a completion gate. Prevents the common failure mode of claiming success without running verification commands.',
+  description:
+    'Every completion claim must be backed by evidence: run the command, read the output, only then assert the result. No self-reported success. No "the tests should pass." Actual output or it didn\'t happen.',
+  steps: `1. IDENTIFY VERIFICATION COMMANDS
+   - What commands prove this works? (test runner, build, lint, type check)
+   - What manual checks are needed? (UI renders, API responds, file exists)
+   - What acceptance criteria need evidence?
+
+2. RUN EACH COMMAND
+   - Execute each verification command
+   - READ THE ACTUAL OUTPUT (not just the exit code)
+   - If any command fails: the task is NOT complete
+
+3. COLLECT EVIDENCE
+   - For each claim, record the command and its output
+   - "Tests pass" → show the test runner output
+   - "Build succeeds" → show the build output
+   - "No regressions" → show the full test suite output
+
+4. VERIFY AGAINST ACCEPTANCE CRITERIA
+   - Check each acceptance criterion against collected evidence
+   - Mark each as: VERIFIED (with evidence) or UNVERIFIED
+   - If any criterion is UNVERIFIED: the task is NOT complete
+
+COMMON FALSE COMPLETIONS:
+| Claim | NOT Sufficient | Required |
+|-------|---------------|----------|
+| "Tests pass" | "I believe tests pass" | npm test output showing all pass |
+| "Build works" | "Should compile fine" | npm run build output with 0 errors |
+| "No regressions" | "Didn't change much" | Full test suite output |
+| "Types correct" | "Looks right to me" | tsc --noEmit output |`,
+  expectedOutcome:
+    'Every completion claim is backed by command output evidence. No ambiguity about whether the work is actually done.',
+  category: 'methodology',
+  tags: ['verification', 'evidence', 'completion', 'discipline', 'generic'],
+  matchIntents: ['BUILD', 'FIX', 'IMPROVE', 'DELIVER'],
+  matchKeywords: ['done', 'complete', 'finish', 'ship', 'merge', 'deploy', 'release'],
+  gates: [
+    {
+      phase: 'completion',
+      requirement: 'All acceptance criteria must have evidence (command output, not self-report)',
+      checkType: 'verification-evidence',
+    },
+  ],
+  taskTemplates: [
+    {
+      taskType: 'verification',
+      titleTemplate: 'Verify: {objective}',
+      acceptanceCriteria: [
+        'All verification commands executed and output read',
+        'All acceptance criteria matched against evidence',
+        'No unverified claims remain',
+      ],
+      tools: [],
+      order: 'after-implementation',
+    },
+  ],
+  toolInjections: [],
+  verificationCriteria: [
+    'Test suite passes (actual output, not self-report)',
+    'Build succeeds (actual output)',
+    'Type checking passes (actual output)',
+    'All acceptance criteria have matching evidence',
+  ],
+};

package/src/playbooks/index.ts

@@ -0,0 +1,27 @@
+// ─── Playbook Types ─────────────────────────────────────────────────
+export type {
+  PlaybookTier,
+  PlaybookIntent,
+  BrainstormSection,
+  PlaybookGate,
+  PlaybookTaskTemplate,
+  PlaybookDefinition,
+  MergedPlaybook,
+  PlaybookMatchResult,
+} from './playbook-types.js';
+
+// ─── Playbook Registry ──────────────────────────────────────────────
+export {
+  getBuiltinPlaybook,
+  getAllBuiltinPlaybooks,
+  scorePlaybook,
+  mergePlaybooks,
+  matchPlaybooks,
+} from './playbook-registry.js';
+
+// ─── Playbook Seeder ────────────────────────────────────────────────
+export {
+  playbookDefinitionToEntry,
+  entryToPlaybookDefinition,
+  seedDefaultPlaybooks,
+} from './playbook-seeder.js';