@zelari/core 0.7.9 → 0.7.11

package/dist/agents/skills/builtin/debugging.js

@@ -1,17 +1,17 @@
 import * as skillsModule 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 wave-in response.
-- 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 wave-in response.
+- 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 reproduceBug = {
     id: 'reproduce-bug',
@@ -43,31 +43,31 @@ const reproduceBug = {
         {
             input: 'Bug report: "Council sometimes shows duplicate messages at the start of a session"',
             output: {
-                minimalRepro: `// tests/regression/duplicate-messages.test.ts
-import { runCouncilPure } from '../agents/councilApi.js';
-
-describe('council duplicate message bug', () => {
-  it('does not emit duplicate user message when session resumes', async () => {
-    const mockProvider = async function* () {
-      yield { kind: 'text', delta: 'first' };
-      yield { kind: 'finish', reason: 'stop' };
-    };
-    const harness = new AgentHarness({
-      model: 'test', provider: 'test',
-      messages: [
-        { role: 'user', content: 'hi' },
-        { role: 'user', content: 'hi' }, // duplicate from session resume
-      ],
-      tools: [],
-      providerStream: mockProvider,
-    });
-    const events = [];
-    for await (const e of harness.run()) events.push(e);
-    const userMessages = events.filter(e => e.type === 'message_delta').length;
-    expect(userMessages).toBeGreaterThan(0); // sanity
-    // The actual bug: duplicate is rendered twice
-    // After fix, expect exactly 1 user message rendered
-  });
+                minimalRepro: `// tests/regression/duplicate-messages.test.ts
+import { runCouncilPure } from '../agents/councilApi.js';
+
+describe('council duplicate message bug', () => {
+  it('does not emit duplicate user message when session resumes', async () => {
+    const mockProvider = async function* () {
+      yield { kind: 'text', delta: 'first' };
+      yield { kind: 'finish', reason: 'stop' };
+    };
+    const harness = new AgentHarness({
+      model: 'test', provider: 'test',
+      messages: [
+        { role: 'user', content: 'hi' },
+        { role: 'user', content: 'hi' }, // duplicate from session resume
+      ],
+      tools: [],
+      providerStream: mockProvider,
+    });
+    const events = [];
+    for await (const e of harness.run()) events.push(e);
+    const userMessages = events.filter(e => e.type === 'message_delta').length;
+    expect(userMessages).toBeGreaterThan(0); // sanity
+    // The actual bug: duplicate is rendered twice
+    // After fix, expect exactly 1 user message rendered
+  });
 });`,
                 reproSteps: [
                     '1. Set up session with duplicate user message in transcript',
@@ -79,28 +79,28 @@ describe('council duplicate message bug', () => {
         },
     ],
     outputSchema: '{ minimalRepro: string; reproSteps: string[]; whyMinimal: string }',
-    systemPromptFragment: `You are converting a bug report into a minimal failing test.
-
-## Methodology
-1. **Read the bug report** carefully: what's the exact symptom? When does it happen?
-2. **Strip to essentials**: remove every agent, tool, env var, user state that isn't strictly required.
-3. **Identify the trigger**: what ONE input causes the bug?
-4. **Write the failing test**: it must FAIL on the current (buggy) code.
-5. **Verify it fails**: the test must fail without any code changes.
-6. **After the fix lands**, the test must PASS.
-
-## Output format (JSON-typed)
-- minimalRepro: string (the test code, runnable as-is)
-- reproSteps: string[] (3-7 numbered steps to reproduce manually)
-- whyMinimal: string (what you stripped + why)
-
-## Minimal-repro principles
-- **One assertion per test** — easier to debug when the test fails
-- **Deterministic** — no flaky timing, no random data
-- **No external dependencies** — use mocks for network/DB
-- **Fast** — under 100ms if possible
-- **Independent** — doesn't depend on other tests' state
-
+    systemPromptFragment: `You are converting a bug report into a minimal failing test.
+
+## Methodology
+1. **Read the bug report** carefully: what's the exact symptom? When does it happen?
+2. **Strip to essentials**: remove every agent, tool, env var, user state that isn't strictly required.
+3. **Identify the trigger**: what ONE input causes the bug?
+4. **Write the failing test**: it must FAIL on the current (buggy) code.
+5. **Verify it fails**: the test must fail without any code changes.
+6. **After the fix lands**, the test must PASS.
+
+## Output format (JSON-typed)
+- minimalRepro: string (the test code, runnable as-is)
+- reproSteps: string[] (3-7 numbered steps to reproduce manually)
+- whyMinimal: string (what you stripped + why)
+
+## Minimal-repro principles
+- **One assertion per test** — easier to debug when the test fails
+- **Deterministic** — no flaky timing, no random data
+- **No external dependencies** — use mocks for network/DB
+- **Fast** — under 100ms if possible
+- **Independent** — doesn't depend on other tests' state
+
 Stay under 300 words.${CLARIFICATION_PROTOCOL}`,
 };
 const debugWithRag = {
@@ -136,38 +136,38 @@ const debugWithRag = {
                 ragSearch: 'searchRAG(query="Council.tsx undefined map error") returned 2 prior incidents: similar bug fixed in commit a3f9d by adding optional chaining; another similar issue in Council.tsx:612.',
                 stackTraceAnalysis: 'Line 847 is inside `renderMessages()`. The most likely cause: `messages` is undefined when `runCouncilPure()` returns early on the first iteration before any agent has produced output.',
                 rootCause: 'race condition: messages array is set after the first agent completes, but renderMessages() is called during the loading state when messages is still undefined.',
-                proposedFix: `function renderMessages() {
-  const messages = session.messages ?? [];
-  return messages.map(m => <Message key={m.id} {...m} />);
+                proposedFix: `function renderMessages() {
+  const messages = session.messages ?? [];
+  return messages.map(m => <Message key={m.id} {...m} />);
 }`,
                 verification: 'Add a unit test that calls renderMessages() with messages=undefined and expects [] (not crash). Manual: trigger the bug scenario, confirm no crash.',
             },
         },
     ],
     outputSchema: '{ ragSearch: string; stackTraceAnalysis: string; rootCause: string; proposedFix: string; verification: string }',
-    systemPromptFragment: `You are debugging a bug using the knowledge base.
-
-## Methodology
-1. **Extract key terms** from the error message + stack trace (file names, function names, error type).
-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: "<key terms>"
-3. **Read the relevant files**: use read_file with line ranges from the stack trace.
-4. **Identify the root cause**: what's the actual logic error? Don't just fix the symptom.
-5. **Propose a minimal fix**: the SMALLEST change that addresses the root cause.
-6. **Specify verification**: how to confirm the fix works (test case + manual steps).
-
-## Output format (JSON-typed)
-- ragSearch: string (what you searched + what you found)
-- stackTraceAnalysis: string (which line + what's likely happening)
-- rootCause: string (the actual bug, not the symptom)
-- proposedFix: string (code snippet)
-- verification: string (test + manual steps)
-
-## Debugging principles
-- **Fix the cause, not the symptom** (e.g. don't add a try/catch to silence an error)
-- **Minimal change** — don't refactor surrounding code while debugging
-- **One hypothesis at a time** — don't list 5 possible causes
-- **Verify the fix actually fixes** — write a failing test BEFORE the fix
-
+    systemPromptFragment: `You are debugging a bug using the knowledge base.
+
+## Methodology
+1. **Extract key terms** from the error message + stack trace (file names, function names, error type).
+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: "<key terms>"
+3. **Read the relevant files**: use read_file with line ranges from the stack trace.
+4. **Identify the root cause**: what's the actual logic error? Don't just fix the symptom.
+5. **Propose a minimal fix**: the SMALLEST change that addresses the root cause.
+6. **Specify verification**: how to confirm the fix works (test case + manual steps).
+
+## Output format (JSON-typed)
+- ragSearch: string (what you searched + what you found)
+- stackTraceAnalysis: string (which line + what's likely happening)
+- rootCause: string (the actual bug, not the symptom)
+- proposedFix: string (code snippet)
+- verification: string (test + manual steps)
+
+## Debugging principles
+- **Fix the cause, not the symptom** (e.g. don't add a try/catch to silence an error)
+- **Minimal change** — don't refactor surrounding code while debugging
+- **One hypothesis at a time** — don't list 5 possible causes
+- **Verify the fix actually fixes** — write a failing test BEFORE the fix
+
 Stay under 400 words.${CLARIFICATION_PROTOCOL}`,
 };
 const rootCauseFiveWhys = {
@@ -215,29 +215,29 @@ const rootCauseFiveWhys = {
         },
     ],
     outputSchema: '{ whys: Array<{ level: number; question: string; answer: string }>; rootCause: string; systemicFix: string; processFix: string; councilConsensus: string }',
-    systemPromptFragment: `You are applying the 5-whys technique with council consensus.
-
-## Methodology
-1. **State the symptom** as the starting point for "why?"
-2. **Ask "why?" 5 times**, drilling down through layers of cause
-3. **Each answer must be FACTUAL**, not speculative
-4. **At the 5th why**, you've reached the systemic root cause
-5. **Propose TWO fixes**: systemic (code/architecture) + process (team/workflow)
-6. **Get council consensus**: chairman summarizes agreement from sisyphus (orchestrator) and oracle (analyst)
-
-## Output format (JSON-typed)
-- whys: Array<{ level: number; question: string; answer: string }>
-- rootCause: string (the deepest why)
-- systemicFix: string (code/architecture change)
-- processFix: string (team/workflow change)
-- councilConsensus: string (chairman's summary of agreement)
-
-## Anti-patterns to avoid
-- **"Human error"** is NEVER the root cause — the system should make the error impossible
-- **"Lack of training"** is NEVER the root cause — automation + checklists > training
-- **"Not enough time"** is NEVER the root cause — find the constraint, not the excuse
-- Stop at the FIRST level if it's a trivial bug — don't overthink simple cases
-
+    systemPromptFragment: `You are applying the 5-whys technique with council consensus.
+
+## Methodology
+1. **State the symptom** as the starting point for "why?"
+2. **Ask "why?" 5 times**, drilling down through layers of cause
+3. **Each answer must be FACTUAL**, not speculative
+4. **At the 5th why**, you've reached the systemic root cause
+5. **Propose TWO fixes**: systemic (code/architecture) + process (team/workflow)
+6. **Get council consensus**: chairman summarizes agreement from sisyphus (orchestrator) and oracle (analyst)
+
+## Output format (JSON-typed)
+- whys: Array<{ level: number; question: string; answer: string }>
+- rootCause: string (the deepest why)
+- systemicFix: string (code/architecture change)
+- processFix: string (team/workflow change)
+- councilConsensus: string (chairman's summary of agreement)
+
+## Anti-patterns to avoid
+- **"Human error"** is NEVER the root cause — the system should make the error impossible
+- **"Lack of training"** is NEVER the root cause — automation + checklists > training
+- **"Not enough time"** is NEVER the root cause — find the constraint, not the excuse
+- Stop at the FIRST level if it's a trivial bug — don't overthink simple cases
+
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 // prettier-ignore

package/dist/agents/skills/builtin/docs.js

@@ -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 writeReadme = {
     id: 'write-readme',
@@ -42,81 +42,81 @@ const writeReadme = {
         {
             input: 'Generate README for AnathemaBrain (Electron + React + TypeScript AI agent platform)',
             output: {
-                readme: `# AnathemaBrain
-
-> An educational Python project for learning how coding agents are built.
-
-AnathemaBrain is an Electron desktop app... (truncated)
-
-## Quick Start
-
-\`\`\`bash
-npm install
-npm run dev
-\`\`\`
-
-## Architecture
-
-- **Main process** (electron/main/): Node.js, IPC handlers, LLM streaming
-- **Renderer** (src/): React 19 UI, Zustand stores
-- **Agent system** (src/agents/): Council multi-agent orchestration
-
-## Development
-
-\`\`\`bash
-npm run typecheck
-npm run test
-npm run lint
-\`\`\`
-
-## Testing
-
-96+ tests via Vitest + jsdom.
-
-## Deployment
-
-\`\`\`bash
-npm run build
-npm run electron:build
-\`\`\`
-
-## Contributing
-
-See docs/plans/ for active roadmaps. Pull requests welcome.
-
-## License
-
-Apache 2.0
+                readme: `# AnathemaBrain
+
+> An educational Python project for learning how coding agents are built.
+
+AnathemaBrain is an Electron desktop app... (truncated)
+
+## Quick Start
+
+\`\`\`bash
+npm install
+npm run dev
+\`\`\`
+
+## Architecture
+
+- **Main process** (electron/main/): Node.js, IPC handlers, LLM streaming
+- **Renderer** (src/): React 19 UI, Zustand stores
+- **Agent system** (src/agents/): Council multi-agent orchestration
+
+## Development
+
+\`\`\`bash
+npm run typecheck
+npm run test
+npm run lint
+\`\`\`
+
+## Testing
+
+96+ tests via Vitest + jsdom.
+
+## Deployment
+
+\`\`\`bash
+npm run build
+npm run electron:build
+\`\`\`
+
+## Contributing
+
+See docs/plans/ for active roadmaps. Pull requests welcome.
+
+## License
+
+Apache 2.0
 `,
                 sections: ['Title + tagline', 'Badges', 'Description', 'Quick Start', 'Architecture diagram', 'Development commands', 'Testing', 'Deployment', 'Contributing link', 'License'],
             },
         },
     ],
     outputSchema: '{ readme: string; sections: string[] }',
-    systemPromptFragment: `You are writing a project README.md.
-
-## Required sections (in order)
-1. **Title + tagline** (1 sentence): what is this project?
-2. **Badges** (optional): CI status, npm version, license
-3. **Description** (2-3 paragraphs): what does it do, who is it for
-4. **Quick Start** (5-10 lines): install + run + see something working
-5. **Architecture** (1-2 paragraphs + diagram): high-level structure
-6. **Development** (commands): how to run tests, typecheck, lint
-7. **Testing**: what kind of tests exist, how to run them
-8. **Deployment** (if applicable): how to build + ship
-9. **Contributing**: link to CONTRIBUTING.md or describe PR process
-10. **License**: license type
-
-## Output format (JSON-typed)
-- readme: string (the full README content in markdown)
-- sections: string[] (the sections you included)
-
-## README principles
-- **Show, don't tell**: code examples for non-trivial concepts
-- **Up-to-date**: don't include commands that don't work
-- **Scannable**: use headers, bullets, code blocks
-- **One page max**: link to deeper docs rather than nesting everything
-
+    systemPromptFragment: `You are writing a project README.md.
+
+## Required sections (in order)
+1. **Title + tagline** (1 sentence): what is this project?
+2. **Badges** (optional): CI status, npm version, license
+3. **Description** (2-3 paragraphs): what does it do, who is it for
+4. **Quick Start** (5-10 lines): install + run + see something working
+5. **Architecture** (1-2 paragraphs + diagram): high-level structure
+6. **Development** (commands): how to run tests, typecheck, lint
+7. **Testing**: what kind of tests exist, how to run them
+8. **Deployment** (if applicable): how to build + ship
+9. **Contributing**: link to CONTRIBUTING.md or describe PR process
+10. **License**: license type
+
+## Output format (JSON-typed)
+- readme: string (the full README content in markdown)
+- sections: string[] (the sections you included)
+
+## README principles
+- **Show, don't tell**: code examples for non-trivial concepts
+- **Up-to-date**: don't include commands that don't work
+- **Scannable**: use headers, bullets, code blocks
+- **One page max**: link to deeper docs rather than nesting everything
+
 Stay under 600 words.${CLARIFICATION_PROTOCOL}`,
 };
 const writeTsdoc = {
@@ -148,54 +148,54 @@ const writeTsdoc = {
         {
             input: 'Add TSDoc to src/lib/formatDuration.ts',
             output: {
-                documented: `/**
- * Formats a duration in milliseconds as a human-readable string.
- *
- * @param ms - Duration in milliseconds. Must be a non-negative finite number.
- * @param opts - Formatting options.
- * @param opts.style - 'compact' (1h 23m), 'full' (1:23:45), or 'minimal' (23m).
- *   Defaults to 'compact'.
- * @returns The formatted duration string.
- * @throws {RangeError} If ms is negative.
- * @throws {TypeError} If ms is NaN or Infinity.
- *
- * @example
- *   formatDuration(4980000);                       // '1h 23m'
- *   formatDuration(4980000, { style: 'full' });    // '1:23:45'
- *   formatDuration(60000, { style: 'minimal' });   // '1m'
- */
-export function formatDuration(ms: number, opts?: { style?: 'compact' | 'full' | 'minimal' }): string {
-  // ... existing implementation
+                documented: `/**
+ * Formats a duration in milliseconds as a human-readable string.
+ *
+ * @param ms - Duration in milliseconds. Must be a non-negative finite number.
+ * @param opts - Formatting options.
+ * @param opts.style - 'compact' (1h 23m), 'full' (1:23:45), or 'minimal' (23m).
+ *   Defaults to 'compact'.
+ * @returns The formatted duration string.
+ * @throws {RangeError} If ms is negative.
+ * @throws {TypeError} If ms is NaN or Infinity.
+ *
+ * @example
+ *   formatDuration(4980000);                       // '1h 23m'
+ *   formatDuration(4980000, { style: 'full' });    // '1:23:45'
+ *   formatDuration(60000, { style: 'minimal' });   // '1m'
+ */
+export function formatDuration(ms: number, opts?: { style?: 'compact' | 'full' | 'minimal' }): string {
+  // ... existing implementation
 }`,
                 tagsAdded: ['@param', '@param (nested)', '@returns', '@throws x2', '@example'],
             },
         },
     ],
     outputSchema: '{ documented: string; tagsAdded: string[] }',
-    systemPromptFragment: `You are writing TSDoc comments for a TypeScript function or class.
-
-## TSDoc tags (use these)
-- \`@param {type} name - description\` — for each parameter
-- \`@returns description\` (or \`@return\` legacy alias)
-- \`@throws {ErrorType} condition\` — for each throw path
-- \`@example\` followed by code block (for non-trivial usage)
-- \`@deprecated reason\` — if the function is being phased out
-- \`@see FunctionName\` — for cross-references
-- \`@remarks\` — additional context
-- \`@internal\` — for internal helpers (suppresses from public docs)
-
-## Output format (JSON-typed)
-- documented: string (the full code block with TSDoc added)
-- tagsAdded: string[] (which tags you included)
-
-## TSDoc principles
-- **First sentence is the summary**: ends with a period, capital letter
-- **One @param per parameter**: don't omit even if obvious
-- **@throws for EVERY throw path**: callers need to know
-- **@example for non-trivial usage**: best way to communicate intent
-- **No marketing language**: just describe what the function does
-- **No implementation details**: TSDoc is for the API contract, not internals
-
+    systemPromptFragment: `You are writing TSDoc comments for a TypeScript function or class.
+
+## TSDoc tags (use these)
+- \`@param {type} name - description\` — for each parameter
+- \`@returns description\` (or \`@return\` legacy alias)
+- \`@throws {ErrorType} condition\` — for each throw path
+- \`@example\` followed by code block (for non-trivial usage)
+- \`@deprecated reason\` — if the function is being phased out
+- \`@see FunctionName\` — for cross-references
+- \`@remarks\` — additional context
+- \`@internal\` — for internal helpers (suppresses from public docs)
+
+## Output format (JSON-typed)
+- documented: string (the full code block with TSDoc added)
+- tagsAdded: string[] (which tags you included)
+
+## TSDoc principles
+- **First sentence is the summary**: ends with a period, capital letter
+- **One @param per parameter**: don't omit even if obvious
+- **@throws for EVERY throw path**: callers need to know
+- **@example for non-trivial usage**: best way to communicate intent
+- **No marketing language**: just describe what the function does
+- **No implementation details**: TSDoc is for the API contract, not internals
+
 Stay under 400 words.${CLARIFICATION_PROTOCOL}`,
 };
 const writeChangelog = {
@@ -227,23 +227,23 @@ const writeChangelog = {
         {
             input: 'Generate changelog for v0.3.1 from commits since v0.3.0 (last 30 commits)',
             output: {
-                changelog: `# Changelog
-
-All notable changes to zelari-code are documented in this file.
-
-## [0.3.1] - 2026-07-01
-
-### Added
-- **Council roles renamed to Dante's Inferno bosses**: Sisyphus→Caronte, Prometheus→Nettuno, Hephaestus→Gerione, Atlas→Plutone, Oracle→Minosse, Chairman→Lucifero.
-
-### Changed
-- Versioning aligned across main.ts, package.json, package-lock.json
-- Stale Electron path references removed from CLI dispatcher comments
-
-### Fixed
-- Background update check now compares correct version against npm registry
-
-[0.3.0] - 2026-07-01
+                changelog: `# Changelog
+
+All notable changes to zelari-code are documented in this file.
+
+## [0.3.1] - 2026-07-01
+
+### Added
+- **Council roles renamed to Dante's Inferno bosses**: Sisyphus→Caronte, Prometheus→Nettuno, Hephaestus→Gerione, Atlas→Plutone, Oracle→Minosse, Chairman→Lucifero.
+
+### Changed
+- Versioning aligned across main.ts, package.json, package-lock.json
+- Stale Electron path references removed from CLI dispatcher comments
+
+### Fixed
+- Background update check now compares correct version against npm registry
+
+[0.3.0] - 2026-07-01
 ... (previous entries)`,
                 sectionsUsed: ['Added', 'Changed', 'Fixed'],
                 commitsProcessed: 30,
@@ -251,37 +251,37 @@ All notable changes to zelari-code are documented in this file.
         },
     ],
     outputSchema: '{ changelog: string; sectionsUsed: string[]; commitsProcessed: number }',
-    systemPromptFragment: `You are writing a CHANGELOG.md entry from git history.
-
-## Keep a Changelog format
-Sections (use only those with content):
-- **Added** — new features
-- **Changed** — changes in existing functionality
-- **Deprecated** — soon-to-be removed features
-- **Removed** — now removed features
-- **Fixed** — bug fixes
-- **Security** — vulnerability fixes
-
-## Methodology
-1. **List commits since the last release** (use git log).
-2. **Categorize each commit** into the right section.
-3. **Translate to user-facing language**: "feat: add event bus" → "EventBus: typed in-memory pub/sub".
-4. **Group related commits**: if 5 commits all touch the event system, write ONE entry.
-5. **Skip internal-only changes**: refactors that don't change behavior.
-6. **Add version + date**: top of the entry.
-
-## Output format (JSON-typed)
-- changelog: string (the full CHANGELOG.md content)
-- sectionsUsed: string[] (which sections you wrote)
-- commitsProcessed: number
-
-## Changelog principles
-- **User-facing language**: write for end-users, not developers
-- **Group, don't list**: 1 entry per feature, not 1 per commit
-- **Highlight breaking changes**: bold or callout
-- **Link to issues/PRs**: reference #123, fixes #456
-- **Date format**: ISO 8601 (YYYY-MM-DD)
-
+    systemPromptFragment: `You are writing a CHANGELOG.md entry from git history.
+
+## Keep a Changelog format
+Sections (use only those with content):
+- **Added** — new features
+- **Changed** — changes in existing functionality
+- **Deprecated** — soon-to-be removed features
+- **Removed** — now removed features
+- **Fixed** — bug fixes
+- **Security** — vulnerability fixes
+
+## Methodology
+1. **List commits since the last release** (use git log).
+2. **Categorize each commit** into the right section.
+3. **Translate to user-facing language**: "feat: add event bus" → "EventBus: typed in-memory pub/sub".
+4. **Group related commits**: if 5 commits all touch the event system, write ONE entry.
+5. **Skip internal-only changes**: refactors that don't change behavior.
+6. **Add version + date**: top of the entry.
+
+## Output format (JSON-typed)
+- changelog: string (the full CHANGELOG.md content)
+- sectionsUsed: string[] (which sections you wrote)
+- commitsProcessed: number
+
+## Changelog principles
+- **User-facing language**: write for end-users, not developers
+- **Group, don't list**: 1 entry per feature, not 1 per commit
+- **Highlight breaking changes**: bold or callout
+- **Link to issues/PRs**: reference #123, fixes #456
+- **Date format**: ISO 8601 (YYYY-MM-DD)
+
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 // Register all skills