npm - @zelari/core - Versions diffs - 0.7.9 → 0.7.11 - Mend

@zelari/core 0.7.9 → 0.7.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (14) hide show

package/LICENSE +21 -21
package/dist/agents/councilDirectives.js +46 -46
package/dist/agents/promptModules.js +65 -65
package/dist/agents/roles.js +198 -198
package/dist/agents/skills/builtin/debugging.js +109 -109
package/dist/agents/skills/builtin/docs.js +172 -172
package/dist/agents/skills/builtin/git-ops.js +166 -166
package/dist/agents/skills/builtin/planning.js +123 -123
package/dist/agents/skills/builtin/refactoring.js +83 -83
package/dist/agents/skills/builtin/review.js +108 -108
package/dist/agents/skills/builtin/testing.js +107 -107
package/dist/agents/skills.js +23 -23
package/dist/council/modeBanners.js +2 -2
package/package.json +1 -1

package/dist/agents/skills/builtin/git-ops.js CHANGED Viewed

@@ -1,17 +1,17 @@
 import { registerCodingSkill } from '../../skills.js';
-const CLARIFICATION_PROTOCOL = `
-WHEN TO ASK THE USER (clarification):
-If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
----QUESTION---
-{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
----END---
-Rules for clarifications:
-- Ask AT MOST ONE question per turn, and only when genuinely blocked.
-- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
-- Do NOT ask for information that could be reasonably assumed or already in shared context.
+const CLARIFICATION_PROTOCOL = `
+WHEN TO ASK THE USER (clarification):
+If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
+---QUESTION---
+{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
+---END---
+Rules for clarifications:
+- Ask AT MOST ONE question per turn, and only when genuinely blocked.
+- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
+- Do NOT ask for information that could be reasonably assumed or already in shared context.
 - If you can proceed with a sound documented assumption, DO SO instead of asking.`;
 const commitMessage = {
     id: 'commit-message',
@@ -42,11 +42,11 @@ const commitMessage = {
             input: 'Staged diff: 3 files changed, +45/-12. Adds brain event types and EventBus class.',
             output: {
                 subject: 'feat(events): add BrainEvent types + EventBus (Phase 11)',
-                body: `Adds the provider-neutral event layer:
-- 12 BrainEvent discriminated union types
-- EventBus class with typed subscribers + error isolation
-- emit/subscribe/subscribeAll API
+                body: `Adds the provider-neutral event layer:
+- 12 BrainEvent discriminated union types
+- EventBus class with typed subscribers + error isolation
+- emit/subscribe/subscribeAll API
 Foundation for Phase 12 (AgentHarness extraction).`,
                 footer: 'Refs: docs/plans/2026-06-28-zelari-code.md',
                 type: 'feat',
@@ -55,48 +55,48 @@ Foundation for Phase 12 (AgentHarness extraction).`,
         },
     ],
     outputSchema: '{ subject: string; body: string; footer: string; type: "feat" | "fix" | "refactor" | "docs" | "test" | "chore" | "perf" | "style"; scope: string }',
-    systemPromptFragment: `You are writing a Conventional Commits message.
-## Format
-<type>(<scope>): <subject>
-<body — explain WHY, not WHAT>
-<footer — issue refs, breaking changes>
-## Types
-- feat: new feature
-- fix: bug fix
-- refactor: code change that neither fixes a bug nor adds a feature
-- docs: documentation only
-- test: adding/correcting tests
-- chore: build/tooling changes (deps, CI, config)
-- perf: performance improvement
-- style: formatting, missing semicolons, etc. (no logic change)
-## Subject rules
-- Imperative mood ("add" not "added")
-- Lowercase (except proper nouns)
-- Max 72 characters
-- No trailing period
-## Body rules
-- Wrap at 72 characters
-- Explain WHY the change was made
-- Bullet points for multiple distinct changes
-## Footer rules
-- \`Refs: #123\` for related issues
-- \`BREAKING CHANGE: <description>\` for breaking changes
-- \`Co-authored-by: Name <email>\` for pair work
-## Output format (JSON-typed)
-- subject: string
-- body: string
-- footer: string
-- type: ConventionalCommitType
-- scope: string (optional, lowercase module name)
+    systemPromptFragment: `You are writing a Conventional Commits message.
+## Format
+<type>(<scope>): <subject>
+<body — explain WHY, not WHAT>
+<footer — issue refs, breaking changes>
+## Types
+- feat: new feature
+- fix: bug fix
+- refactor: code change that neither fixes a bug nor adds a feature
+- docs: documentation only
+- test: adding/correcting tests
+- chore: build/tooling changes (deps, CI, config)
+- perf: performance improvement
+- style: formatting, missing semicolons, etc. (no logic change)
+## Subject rules
+- Imperative mood ("add" not "added")
+- Lowercase (except proper nouns)
+- Max 72 characters
+- No trailing period
+## Body rules
+- Wrap at 72 characters
+- Explain WHY the change was made
+- Bullet points for multiple distinct changes
+## Footer rules
+- \`Refs: #123\` for related issues
+- \`BREAKING CHANGE: <description>\` for breaking changes
+- \`Co-authored-by: Name <email>\` for pair work
+## Output format (JSON-typed)
+- subject: string
+- body: string
+- footer: string
+- type: ConventionalCommitType
+- scope: string (optional, lowercase module name)
 Stay under 300 words.${CLARIFICATION_PROTOCOL}`,
 };
 const prDescription = {
@@ -147,30 +147,30 @@ const prDescription = {
         },
     ],
     outputSchema: '{ title: string; summary: string; motivation: string; changes: string[]; testing: string; risks: string[] }',
-    systemPromptFragment: `You are writing a Pull Request description.
-## Sections (use all)
-1. **Title** (max 72 chars, imperative mood)
-2. **Summary** (1 paragraph): what does this PR do?
-3. **Motivation** (1-2 paragraphs): WHY? What problem does it solve?
-4. **Changes** (bullet list, 5-15 items): specific files/concepts changed
-5. **Testing** (1 paragraph): how was it verified? Test counts, manual steps
-6. **Risks** (bullet list, 2-5 items): what could go wrong? Migration needed?
-## Output format (JSON-typed)
-- title: string
-- summary: string
-- motivation: string
-- changes: string[]
-- testing: string
-- risks: string[]
-## PR description principles
-- **Reviewer-first**: optimize for someone who has NEVER seen this code
-- **Concrete not abstract**: cite file paths, line numbers, function names
-- **Risk-honest**: don't hide breaking changes or migration steps
-- **Self-contained**: PR description should make sense without clicking through to issues
+    systemPromptFragment: `You are writing a Pull Request description.
+## Sections (use all)
+1. **Title** (max 72 chars, imperative mood)
+2. **Summary** (1 paragraph): what does this PR do?
+3. **Motivation** (1-2 paragraphs): WHY? What problem does it solve?
+4. **Changes** (bullet list, 5-15 items): specific files/concepts changed
+5. **Testing** (1 paragraph): how was it verified? Test counts, manual steps
+6. **Risks** (bullet list, 2-5 items): what could go wrong? Migration needed?
+## Output format (JSON-typed)
+- title: string
+- summary: string
+- motivation: string
+- changes: string[]
+- testing: string
+- risks: string[]
+## PR description principles
+- **Reviewer-first**: optimize for someone who has NEVER seen this code
+- **Concrete not abstract**: cite file paths, line numbers, function names
+- **Risk-honest**: don't hide breaking changes or migration steps
+- **Self-contained**: PR description should make sense without clicking through to issues
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 const ciPipeline = {
@@ -203,55 +203,55 @@ const ciPipeline = {
             input: 'Generate GitHub Actions for AnathemaBrain (Electron + React + TS + Vitest)',
             output: {
                 workflowFile: '.github/workflows/ci.yml',
-                content: `name: CI
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    timeout-minutes: 15
-    strategy:
-      matrix:
-        node-version: [20.x]
-    steps:
-      - uses: actions/checkout@v4
-      - name: Setup Node.js \${{ matrix.node-version }}
-        uses: actions/setup-node@v4
-        with:
-          node-version: \${{ matrix.node-version }}
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm ci
-      - name: Typecheck (node config)
-        run: npm run typecheck:node
-      - name: Typecheck (web config)
-        run: npm run typecheck:web
-      - name: Lint
-        run: npm run lint
-      - name: Test
-        run: npm run test
-      - name: Build (Electron renderer + main)
-        run: npm run build
-      - name: Upload coverage
-        if: success()
-        uses: actions/upload-artifact@v4
-        with:
-          name: coverage-\${{ matrix.node-version }}
-          path: coverage/
+                content: `name: CI
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    strategy:
+      matrix:
+        node-version: [20.x]
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup Node.js \${{ matrix.node-version }}
+        uses: actions/setup-node@v4
+        with:
+          node-version: \${{ matrix.node-version }}
+          cache: 'npm'
+      - name: Install dependencies
+        run: npm ci
+      - name: Typecheck (node config)
+        run: npm run typecheck:node
+      - name: Typecheck (web config)
+        run: npm run typecheck:web
+      - name: Lint
+        run: npm run lint
+      - name: Test
+        run: npm run test
+      - name: Build (Electron renderer + main)
+        run: npm run build
+      - name: Upload coverage
+        if: success()
+        uses: actions/upload-artifact@v4
+        with:
+          name: coverage-\${{ matrix.node-version }}
+          path: coverage/
 `,
                 jobs: ['test'],
                 triggers: ['push to main', 'pull_request to main'],
@@ -260,39 +260,39 @@ jobs:
         },
     ],
     outputSchema: '{ workflowFile: string; content: string; jobs: string[]; triggers: string[]; nodeVersion: string }',
-    systemPromptFragment: `You are writing a GitHub Actions workflow YAML.
-## Required structure
-1. **name**: workflow display name
-2. **on**: triggers (push to main, pull_request, manual workflow_dispatch)
-3. **jobs**: at least one job with steps
-4. **runs-on**: ubuntu-latest (default)
-5. **timeout-minutes**: 15 (default, increase for slower builds)
-6. **matrix.node-version**: pin to a specific major version (e.g. 20.x)
-## Standard steps (in order)
-1. actions/checkout@v4
-2. actions/setup-node@v4 with cache: 'npm'
-3. npm ci (NOT npm install — faster in CI)
-4. typecheck (run the project's typecheck script)
-5. lint (run the project's lint script)
-6. test (run the project's test script)
-7. build (run the project's build script, if applicable)
-## Output format (JSON-typed)
-- workflowFile: string (path like .github/workflows/ci.yml)
-- content: string (the full YAML)
-- jobs: string[] (job names)
-- triggers: string[] (trigger events)
-- nodeVersion: string (pinned Node version)
-## CI principles
-- **Fail fast**: order steps from fastest → slowest (typecheck before build)
-- **Cache dependencies**: cache: 'npm' saves 30s+ on cold builds
-- **Pin versions**: use @v4 not @latest for reproducibility
-- **Don't cache build artifacts**: cache only deps
-- **Separate jobs for parallel**: typecheck, lint, test can be parallel jobs
+    systemPromptFragment: `You are writing a GitHub Actions workflow YAML.
+## Required structure
+1. **name**: workflow display name
+2. **on**: triggers (push to main, pull_request, manual workflow_dispatch)
+3. **jobs**: at least one job with steps
+4. **runs-on**: ubuntu-latest (default)
+5. **timeout-minutes**: 15 (default, increase for slower builds)
+6. **matrix.node-version**: pin to a specific major version (e.g. 20.x)
+## Standard steps (in order)
+1. actions/checkout@v4
+2. actions/setup-node@v4 with cache: 'npm'
+3. npm ci (NOT npm install — faster in CI)
+4. typecheck (run the project's typecheck script)
+5. lint (run the project's lint script)
+6. test (run the project's test script)
+7. build (run the project's build script, if applicable)
+## Output format (JSON-typed)
+- workflowFile: string (path like .github/workflows/ci.yml)
+- content: string (the full YAML)
+- jobs: string[] (job names)
+- triggers: string[] (trigger events)
+- nodeVersion: string (pinned Node version)
+## CI principles
+- **Fail fast**: order steps from fastest → slowest (typecheck before build)
+- **Cache dependencies**: cache: 'npm' saves 30s+ on cold builds
+- **Pin versions**: use @v4 not @latest for reproducibility
+- **Don't cache build artifacts**: cache only deps
+- **Separate jobs for parallel**: typecheck, lint, test can be parallel jobs
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 registerCodingSkill(commitMessage);

package/dist/agents/skills/builtin/planning.js CHANGED Viewed

@@ -1,17 +1,17 @@
 import { registerCodingSkill } from '../../skills.js';
-const CLARIFICATION_PROTOCOL = `
-WHEN TO ASK THE USER (clarification):
-If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
----QUESTION---
-{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
----END---
-Rules for clarifications:
-- Ask AT MOST ONE question per turn, and only when genuinely blocked.
-- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
-- Do NOT ask for information that could be reasonably assumed or already in shared context.
+const CLARIFICATION_PROTOCOL = `
+WHEN TO ASK THE USER (clarification):
+If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
+---QUESTION---
+{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
+---END---
+Rules for clarifications:
+- Ask AT MOST ONE question per turn, and only when genuinely blocked.
+- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
+- Do NOT ask for information that could be reasonably assumed or already in shared context.
 - If you can proceed with a sound documented assumption, DO SO instead of asking.`;
 const architectFeature = {
     id: 'architect-feature',
@@ -76,27 +76,27 @@ const architectFeature = {
         },
     ],
     outputSchema: '{ goal: string; alternatives: Array<{ approach: string; score: string; rationale: string }>; chosen: { approach: string; rationale: string }; adrPath: string; risks: Array<{ risk: string; mitigation: string }> }',
-    systemPromptFragment: `You are designing a feature with multi-perspective analysis.
-## Methodology
-1. Restate the goal in ONE sentence: what user need does this serve?
-2. Search prior decisions with the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG — never call one that is not listed), query: "<feature-keyword>"
-3. Generate 3-5 DISTINCT approaches (vary the axis: library vs custom, sync vs async, desktop vs server, etc.).
-4. Score each approach on three dimensions (1-5 each):
-   - Feasibility (F): how easy to implement given the current stack
-   - Risk (R, INVERTED — lower is better): likelihood of bugs, security holes, scope creep
-   - Maintenance (M): long-term cost (bus factor, doc quality, ecosystem health)
-5. Pick the top approach and justify in 1-2 sentences.
-6. Generate an ADR (link to architect-decision-record skill).
-7. List 2-5 concrete risks + mitigations.
-## Output format (JSON-typed)
-- goal: string
-- alternatives: Array<{ approach: string; score: string; rationale: string }>
-- chosen: { approach: string; rationale: string }
-- adrPath: string
-- risks: Array<{ risk: string; mitigation: string }>
+    systemPromptFragment: `You are designing a feature with multi-perspective analysis.
+## Methodology
+1. Restate the goal in ONE sentence: what user need does this serve?
+2. Search prior decisions with the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG — never call one that is not listed), query: "<feature-keyword>"
+3. Generate 3-5 DISTINCT approaches (vary the axis: library vs custom, sync vs async, desktop vs server, etc.).
+4. Score each approach on three dimensions (1-5 each):
+   - Feasibility (F): how easy to implement given the current stack
+   - Risk (R, INVERTED — lower is better): likelihood of bugs, security holes, scope creep
+   - Maintenance (M): long-term cost (bus factor, doc quality, ecosystem health)
+5. Pick the top approach and justify in 1-2 sentences.
+6. Generate an ADR (link to architect-decision-record skill).
+7. List 2-5 concrete risks + mitigations.
+## Output format (JSON-typed)
+- goal: string
+- alternatives: Array<{ approach: string; score: string; rationale: string }>
+- chosen: { approach: string; rationale: string }
+- adrPath: string
+- risks: Array<{ risk: string; mitigation: string }>
 Stay under 400 words. Be decisive: pick ONE approach, do not list 3 equally good options.${CLARIFICATION_PROTOCOL}`,
 };
 const architectDecisionRecord = {
@@ -129,57 +129,57 @@ const architectDecisionRecord = {
             input: 'Document why we use SQLite over Postgres for local storage',
             output: {
                 path: 'docs/adr/0007-sqlite-over-postgres.md',
-                content: `# 7. SQLite over Postgres for local storage
-## Context
-AnathemaBrain is an Electron desktop app that runs entirely on the user's machine. We need persistent storage for vault documents, RAG vectors, settings, and council sessions.
-## Decision
-Use SQLite (via better-sqlite3) for all local storage.
-## Consequences
-- Zero-config: works out of the box, no separate DB server to manage
-- Single-file backups: copy ~/.anathemabrain/db.sqlite
-- FTS5 + JSON1 support built-in (used by RAG and vault search)
-- Cross-platform: tested on macOS, Linux, Windows
-### Positive
-- No network round-trip — sub-millisecond reads
-- Embedded = no auth/connection-string management
-- Mature ecosystem (better-sqlite3, sqlite-vss)
-### Negative
-- Single-writer: concurrent writes are serialized (acceptable for desktop)
-- No horizontal scaling (irrelevant for desktop)
-- Migration tooling requires custom scripts (we have db/migrations.ts)
-## Alternatives Considered
-- **Postgres**: rejected — requires a server process, overkill for desktop
-- **LevelDB / RocksDB**: rejected — no SQL, harder to query vector data
-- **JSON files**: rejected — no concurrent access, no FTS
+                content: `# 7. SQLite over Postgres for local storage
+## Context
+AnathemaBrain is an Electron desktop app that runs entirely on the user's machine. We need persistent storage for vault documents, RAG vectors, settings, and council sessions.
+## Decision
+Use SQLite (via better-sqlite3) for all local storage.
+## Consequences
+- Zero-config: works out of the box, no separate DB server to manage
+- Single-file backups: copy ~/.anathemabrain/db.sqlite
+- FTS5 + JSON1 support built-in (used by RAG and vault search)
+- Cross-platform: tested on macOS, Linux, Windows
+### Positive
+- No network round-trip — sub-millisecond reads
+- Embedded = no auth/connection-string management
+- Mature ecosystem (better-sqlite3, sqlite-vss)
+### Negative
+- Single-writer: concurrent writes are serialized (acceptable for desktop)
+- No horizontal scaling (irrelevant for desktop)
+- Migration tooling requires custom scripts (we have db/migrations.ts)
+## Alternatives Considered
+- **Postgres**: rejected — requires a server process, overkill for desktop
+- **LevelDB / RocksDB**: rejected — no SQL, harder to query vector data
+- **JSON files**: rejected — no concurrent access, no FTS
 `,
             },
         },
     ],
     outputSchema: '{ path: string; content: string }',
-    systemPromptFragment: `You are writing an Architecture Decision Record (ADR).
-## Required sections
-1. **# N. <Title>** — short title in present tense ("Use X for Y")
-2. **## Context** — what is the situation? What forces are at play? (2-3 paragraphs)
-3. **## Decision** — what did we decide? State it clearly in 1-2 sentences.
-4. **## Consequences** — what becomes easier (+) and harder (-) as a result?
-5. **## Alternatives Considered** — 2-4 alternatives with one-line rejection reasons.
-## Numbering
-- Check docs/adr/ for the next available number (NNN-title.md format)
-- ADR numbers are permanent — never reuse, even if an ADR is superseded (mark superseded in the body instead)
-## Tone
-- Factual, not promotional
-- Acknowledge trade-offs honestly
-- Link to relevant code/PRs/files using relative paths
+    systemPromptFragment: `You are writing an Architecture Decision Record (ADR).
+## Required sections
+1. **# N. <Title>** — short title in present tense ("Use X for Y")
+2. **## Context** — what is the situation? What forces are at play? (2-3 paragraphs)
+3. **## Decision** — what did we decide? State it clearly in 1-2 sentences.
+4. **## Consequences** — what becomes easier (+) and harder (-) as a result?
+5. **## Alternatives Considered** — 2-4 alternatives with one-line rejection reasons.
+## Numbering
+- Check docs/adr/ for the next available number (NNN-title.md format)
+- ADR numbers are permanent — never reuse, even if an ADR is superseded (mark superseded in the body instead)
+## Tone
+- Factual, not promotional
+- Acknowledge trade-offs honestly
+- Link to relevant code/PRs/files using relative paths
 Stay under 800 words.${CLARIFICATION_PROTOCOL}`,
 };
 const migrateStack = {
@@ -228,27 +228,27 @@ const migrateStack = {
         },
     ],
     outputSchema: '{ goal: string; phases: Array<{ name: string; exitCriterion: string; durationDays: number }>; rollbackStrategy: string; risks: Array<{ risk: string; mitigation: string }> }',
-    systemPromptFragment: `You are planning a stack migration.
-## Methodology
-1. State the GOAL in measurable terms (e.g. "reduce build time from 60s to 10s").
-2. Decompose into 3-6 phases. Each phase has a CLEAR exit criterion (testable condition).
-3. Each phase should be DEPLOYABLE on its own (no big-bang steps).
-4. Plan a ROLLBACK strategy: which single commit reverts to the previous state?
-5. List 3-7 concrete risks + mitigations per phase.
-## Migration principles
-- **Strangler Fig**: new system grows alongside old, traffic migrates incrementally
-- **No big-bang rewrites**: every phase must be independently shippable
-- **Reversibility first**: every phase has a tested rollback path
-- **Data migration last**: schema changes follow code changes (dual-write during transition)
-## Output format (JSON-typed)
-- goal: string (measurable)
-- phases: Array<{ name: string; exitCriterion: string; durationDays: number }>
-- rollbackStrategy: string (the single command or commit that reverts)
-- risks: Array<{ risk: string; mitigation: string }>
+    systemPromptFragment: `You are planning a stack migration.
+## Methodology
+1. State the GOAL in measurable terms (e.g. "reduce build time from 60s to 10s").
+2. Decompose into 3-6 phases. Each phase has a CLEAR exit criterion (testable condition).
+3. Each phase should be DEPLOYABLE on its own (no big-bang steps).
+4. Plan a ROLLBACK strategy: which single commit reverts to the previous state?
+5. List 3-7 concrete risks + mitigations per phase.
+## Migration principles
+- **Strangler Fig**: new system grows alongside old, traffic migrates incrementally
+- **No big-bang rewrites**: every phase must be independently shippable
+- **Reversibility first**: every phase has a tested rollback path
+- **Data migration last**: schema changes follow code changes (dual-write during transition)
+## Output format (JSON-typed)
+- goal: string (measurable)
+- phases: Array<{ name: string; exitCriterion: string; durationDays: number }>
+- rollbackStrategy: string (the single command or commit that reverts)
+- risks: Array<{ risk: string; mitigation: string }>
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 const scopeCheck = {
@@ -302,28 +302,28 @@ const scopeCheck = {
         },
     ],
     outputSchema: '{ feasibility: "yes" | "partial" | "no"; estimatedEffortDays: number; hiddenCosts: Array<{ cost: string; mitigation: string }>; reducedScope: { phase1: string; phase2: string; phase3: string }; risks: string[] }',
-    systemPromptFragment: `You are validating the scope of a proposed feature or change.
-## Methodology
-1. Restate the proposal in ONE sentence.
-2. Search the knowledge base with the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG — never call one that is not listed), query: "<proposed-keyword>"
-3. Estimate effort realistically (in person-days, with calibration from prior projects).
-4. List HIDDEN costs: auth flows, data migration, third-party APIs, deployment, monitoring.
-5. Propose a REDUCED SCOPE that delivers 80% of the value in 20% of the time.
-6. Flag risks that could block the project.
-## Output format (JSON-typed)
-- feasibility: 'yes' | 'partial' | 'no'
-- estimatedEffortDays: number
-- hiddenCosts: Array<{ cost: string; mitigation: string }>
-- reducedScope: { phase1: string; phase2: string; phase3: string } (3 phases, each independently shippable)
-- risks: string[] (3-5 risks)
-## When to be skeptical
-- "Just add X" usually hides auth + persistence + UI work (3x multiplier)
-- "Use the existing system" usually means new integration code
-- Estimates from optimistic people — multiply by 2-3x for calendar time
+    systemPromptFragment: `You are validating the scope of a proposed feature or change.
+## Methodology
+1. Restate the proposal in ONE sentence.
+2. Search the knowledge base with the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG — never call one that is not listed), query: "<proposed-keyword>"
+3. Estimate effort realistically (in person-days, with calibration from prior projects).
+4. List HIDDEN costs: auth flows, data migration, third-party APIs, deployment, monitoring.
+5. Propose a REDUCED SCOPE that delivers 80% of the value in 20% of the time.
+6. Flag risks that could block the project.
+## Output format (JSON-typed)
+- feasibility: 'yes' | 'partial' | 'no'
+- estimatedEffortDays: number
+- hiddenCosts: Array<{ cost: string; mitigation: string }>
+- reducedScope: { phase1: string; phase2: string; phase3: string } (3 phases, each independently shippable)
+- risks: string[] (3-5 risks)
+## When to be skeptical
+- "Just add X" usually hides auth + persistence + UI work (3x multiplier)
+- "Use the existing system" usually means new integration code
+- Estimates from optimistic people — multiply by 2-3x for calendar time
 Stay under 400 words. Be honest about feasibility — say NO when the answer is NO.${CLARIFICATION_PROTOCOL}`,
 };
 // Register all 4 skills at module load time in topological dependency order.