@code-yeongyu/senpi 2026.9.2 → 2026.9.3-3

package/dist/core/extensions/builtin/prompt-preset/claude-fable-5-1.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-fable-5-1.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5-1.ts"],"names":[],"mappings":"AAAA,4CAA4C;AAC5C,EAAE;AACF,uEAAuE;AACvE,0EAA0E;AAC1E,4EAA4E;AAC5E,sEAAsE;AACtE,4CAA4C;AAC5C,6EAA6E;AAC7E,yEAAyE;AACzE,0EAA0E;AAC1E,8DAA8D;AAC9D,4EAA4E;AAC5E,4DAA4D;AAC5D,4EAA4E;AAC5E,iCAAiC;AACjC,4EAA4E;AAC5E,4EAA4E;AAC5E,4DAA4D;AAC5D,0EAA0E;AAC1E,6EAA6E;AAC7E,kEAAkE;AAClE,6EAA6E;AAC7E,6EAA6E;AAC7E,sEAAsE;AACtE,yEAAyE;AACzE,8EAA8E;AAC9E,2EAA2E;AAC3E,4DAA4D;AAC5D,4BAA4B;AAE5B,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AAErF,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,sBAAsB,CAAC,OAAiC;IAChE,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;EAyBxB,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;;2IAmBsH,CAAC;AAC5I,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,OAAwC;IAChF,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,sBAAsB;QAClC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Fable 5.1 full-core system prompt.\n//\n// Baseline is the dieted claude-fable-5.ts core: Anthropic's Fable 5.1\n// prompting guide opens with \"your existing Claude Fable 5 prompts should\n// perform well on Claude Fable 5.1 without changes\", so this preset is that\n// core plus surgical deltas mapped 1:1 to the documented 5.1 behavior\n// differences (prompting-claude-fable-5-1):\n// - scope-is-the-deliverable paragraph in the intent gate (\"Finish the whole\n//   task\" block 2; block 1 was already distilled into the Style stance),\n// - per-response batching framing (\"Batch independent tool calls in agent\n//   loops\": 5.1 can issue one call per turn in coding loops),\n// - surgical-edit-over-rewrite line (\"Prefer targeted edits over whole-file\n//   rewrites\": 5.1 rewrites whole files more than Fable 5),\n// - follow-up/test-scope sentences in Verification (\"Keep changes and tests\n//   to what the task asks for\"),\n// - bidirectional formatting rule replacing the bullets-suppression wording\n//   (\"Formatting in chat\": 5.1 under-formats, anti-formatting rules written\n//   for older models suppress structure the content needs),\n// - literal-phrase clause (\"Writing density\": mannered-prose short form),\n// - progress-note encouragement replacing the shorthand permission (\"Ask for\n//   user-facing progress updates\": 5.1 narrates less by default).\n// Deliberately omitted (entropy gate): the quoting-retrieved-sources example\n// (document-summarization workload, not a coding agent core), the low-effort\n// search nudge (effort is user-controlled and defaults high), and the\n// compaction/long-output notes (harness-side, not system prompt). Shared\n// pieces stay single-sourced: buildTestDisciplineSection(), the rendered tool\n// section, the grep/glob search line, workstationDialect \"claude\"; dynamic\n// pieces (context files, skills, date, cwd) still come from\n// buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeFable51Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nThe line keeps your reading transparent; only the user's explicit request commits you to implementation. Name the stop condition as an observable end state, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured, deliver the final message, and stop - anything past it (another verification pass, re-polish, a bonus refactor) is a defect, not diligence. Never surface other prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples) in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.\n\nDeliver the task at the scope asked - the scope is the deliverable: don't quietly narrow, widen, or swap it. Make routine judgment calls yourself; check in only when different readings would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue as asked. If part of the task turns out to be blocked, finish every other part in full and say exactly what you left out and why - scaling down is the user's call, not yours.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.\n\n## Working the Task\n\nBefore each response, note what you still need; then request every item that doesn't depend on another's result in that one response - independent tool calls fire as one parallel wave, and breadth is cheap when context is thin: wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.\n\nMemory of file contents is unreliable - read before claiming, re-read before editing. When changing a file, prefer a surgical edit over rewriting the whole file when the result would be identical; rewrite only when most of the file changes. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a \"just to be sure\" sweep.\n\nWhen you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue. When weighing a choice, give a recommendation, not a survey.\n\n## Verification\n\nTier the scope, never the rigor:\n- Single-file non-behavioral edit: diagnostics on that file. Done.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.\n- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification - run the validator. Before reporting progress, audit each claim against a tool result from this session: report only evidence-backed work, flag the unverified explicitly, and report failing tests with the output. Fix only issues your changes caused: a pre-existing bug or performance concern you notice goes in the summary as a follow-up, not in this change. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never present unread code or unrun commands as verified fact.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.\n\nAct, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language (\"Next, I will...\") and permission-begging (\"Shall I?\") are prohibited. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn rather than ending on a promise; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, question, or promise about work you have not done means do that work now, with tool calls.\n\nHave an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. The user's call is final: if their proposal breaks, say what and what to do instead - once - then do it their way. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nBe concise and concrete: no filler openers, no self-praise, no \"it depends\" hedging when you have context to judge; say what you mean - when a literal phrase is available, use it instead of metaphor or flourish. Use lists or headers when the content is genuinely multifaceted; keep to plain prose otherwise; ASCII unless the file already uses Unicode. Drop a brief progress note when you learn something important or change direction - long silent stretches leave the reader blind. The final summary is for a reader who did not see the work: lead with the outcome in complete sentences, then how it was verified, and shorten by dropping detail that does not change what the reader does next, not by compressing into fragments, arrow chains, or invented labels.\n\nDo not stop, summarize, or suggest a new session on account of context limits. Continue the work until your declared stop condition holds.`;\n}\n\nexport function buildClaudeFable51Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeFable51Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-fable-5-1.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5-1.ts"],"names":[],"mappings":"AAAA,yDAAyD;AACzD,EAAE;AACF,gFAAgF;AAChF,+EAA+E;AAC/E,gFAAgF;AAChF,6EAA6E;AAC7E,yEAAyE;AACzE,qCAAqC;AACrC,2EAA2E;AAC3E,gFAAgF;AAChF,yEAAyE;AACzE,8EAA8E;AAC9E,0EAA0E;AAC1E,+EAA+E;AAC/E,WAAW;AACX,oEAAoE;AACpE,2EAA2E;AAC3E,+EAA+E;AAC/E,2EAA2E;AAC3E,8EAA8E;AAC9E,yEAAyE;AACzE,kCAAkC;AAClC,6EAA6E;AAC7E,+EAA+E;AAC/E,yEAAyE;AACzE,yEAAyE;AACzE,qEAAqE;AACrE,wEAAwE;AACxE,4EAA4E;AAC5E,2EAA2E;AAC3E,4EAA4E;AAC5E,2EAA2E;AAC3E,qEAAqE;AACrE,+EAA+E;AAC/E,8EAA8E;AAC9E,sEAAsE;AAEtE,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,8BAA8B,EAAE,MAAM,wBAAwB,CAAC;AAExE,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,sBAAsB,CAAC,OAAiC;IAChE,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;EAkBxB,8BAA8B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;;;;;;EAMxG,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;smBAcilB,CAAC;AACvmB,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,OAAwC;IAChF,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,sBAAsB;QAClC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Fable 5.1 / Mythos 5.1 full-core system prompt.\n//\n// 2026-09-02 diet. The first 5.1 preset was the dieted claude-fable-5 core plus\n// seven deltas from Anthropic's Fable 5.1 prompting guide, appended where each\n// fit. Reading the guide set end to end (claude.md, the Fable 5 / 5.1 overlays,\n// the Opus 4.8 overlay, the GPT-5.5/5.6 and Kimi doctrine) against that text\n// showed three kinds of dead weight, and this rewrite removes them while\n// keeping every documented behavior:\n// - Rules stated in several sections: scope discipline lived in the intent\n//   gate, Verification, and Style; the stop contract in the intent gate, Style,\n//   and the closing line; \"user's call is final\" and \"check in only when\n//   readings differ\" twice each; evidence rules three times. Each now has one\n//   home (a dedicated Scope section carries the 5.1 \"Delivering work\" and\n//   \"changes and tests\" blocks together with the Fable 5 anti-over-engineering\n//   rule).\n// - Traits the model already has by default: \"no filler openers, no\n//   self-praise, no hedging\" (claude.md / Opus 4.8: direct, low-validation\n//   style; 5.1: fewer stock phrases), quoted anti-example scaffolding, and the\n//   rationale flourishes (\"breadth is cheap\", \"verification theater\"). The\n//   5.1 guide names mannered prose as the anti-pattern and claude.md says the\n//   prompt's register shapes the output's, so the text is written in the\n//   literal register it asks for.\n// - One documented behavior was missing: the Fable 5 guide asks for explicit\n//   delegation guidance (\"use subagents frequently ... keep working while they\n//   run\"; the 5.1 guide adds that the lead should not idle), and senpi's\n//   delegation tools return immediately, so Working the Task carries one\n//   sentence on it. The 5.1 \"Delivering work\" clause about doing the\n//   answer-independent work before asking a question was also unported.\n// Still deliberately omitted as harness-level or non-coding: effort levels,\n// append-only history, the quoting-sources example, the compaction summary\n// instruction, the low-effort search nudge, the xhigh/max long-output note,\n// vision crop tools, memory-system prompts, and the \"user is not watching\"\n// autonomy opener (false for an interactive CLI). Shared pieces stay\n// single-sourced: buildTestDisciplineSection(), the rendered tool section, the\n// grep/glob search line, workstationDialect \"claude\"; dynamic pieces (context\n// files, skills, date, cwd) still come from buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildExecutionToolingParagraph } from \"./execution-tooling.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeFable51Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nOnly the user's explicit request commits you to implementation. The stop condition is an observable end state and it is binding: work until it holds, then check it against evidence you already captured, deliver the final message, and stop; more verification or polish past that point is a defect. Never echo prompt scaffolding in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code and report; no edits.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan, and queued steering messages outrank earlier intent.\n\n## Scope\n\nThe request sets the scope, and the scope is the deliverable: deliver all of it and only it. Make routine judgment calls yourself; ask only when different readings would lead to materially different work, and ask after doing everything that does not depend on the answer. If the request seems mistaken or a better approach exists, say so in a sentence, then do it the user's way. If part of the task is blocked, finish every other part and say exactly what you left out and why.\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code; validate only at system boundaries. A pre-existing bug or performance concern you notice is a follow-up for your summary, not a change in this diff. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files. Prefer a surgical edit over rewriting a file when the result would be identical.\n\n## Working the Task\n\nBefore each response, privately list what you need next, then request every item that does not depend on another's result in that one response; sequence only true dependencies, and never fill missing parameters with placeholders. Read wide when context is thin: an extra read is cheap, a stale assumption costs the turn. Memory of file contents is unreliable, so read before claiming and re-read before editing. Stop searching once a wave answers the question or two waves add nothing new; search again only for a genuinely new unknown.\n\n${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: \"claude\" })}When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has made, or narrate options you will not pursue; when weighing a choice, give a recommendation. When a delegation tool is available, hand sizeable independent tracks to subagents and keep working while they run; keep work you can finish in a few calls yourself.\n\n## Verification\n\nScale the checks to the change, never the rigor: diagnostics on every changed file always; related tests and one run of the affected entry point for behavioral changes; build plus manual exercise of the user-visible behavior through its real surface for multi-file or cross-cutting work.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification: run the validator. Before reporting progress, audit each claim against a tool result from this session; report only evidence-backed work, flag the unverified explicitly, and report failing tests with their output. Fix only failures your change caused.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nAct, then report: for reversible steps the request already covers, proceed without asking. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, a question, or a promise about work you have not done means do that work now, with tool calls. Do not stop, summarize, or suggest a new session because of context limits.\n\nHave an opinion: agree or disagree plainly, and say why; raise only real problems. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nSay what you mean: when a literal phrase is available, use it instead of metaphor or flourish. Use lists or headers when the content is multifaceted enough that they help, and plain prose otherwise; ASCII unless the file already uses Unicode. Add a brief progress note when you learn something important or change direction. Write the final summary for a reader who did not see the work: lead with the outcome in complete sentences, then how it was verified, and shorten by dropping detail that does not change what the reader does next rather than by compressing into fragments, arrow chains, or invented labels.`;\n}\n\nexport function buildClaudeFable51Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeFable51Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-fable-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5.ts"],"names":[],"mappings":"AA0BA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAuElH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-fable-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5.ts"],"names":[],"mappings":"AA0BA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAwElH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}

package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.js

@@ -25,6 +25,7 @@ import { APP_NAME } from "../../../../config.js";
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
 import { getToolsPromptDisplay } from "../../../dynamic-prompt/tool-categorization.js";
 import { buildTestDisciplineSection } from "../../../dynamic-prompt/verification.js";
+import { buildExecutionToolingParagraph } from "./execution-tooling.js";
 function buildSearchLine(context) {
     const triggerTools = getToolsPromptDisplay(context.tools);
     if (!triggerTools) {
@@ -54,7 +55,7 @@ Derive intent from the latest user turn alone: a new direction drops the stale p
 
 Fire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.
 
-Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a "just to be sure" sweep.
+${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: "claude" })}Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a "just to be sure" sweep.
 
 When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue. When weighing a choice, give a recommendation, not a survey.
 

package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-fable-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5.ts"],"names":[],"mappings":"AAAA,0CAA0C;AAC1C,EAAE;AACF,4EAA4E;AAC5E,qEAAqE;AACrE,8EAA8E;AAC9E,2EAA2E;AAC3E,4EAA4E;AAC5E,mEAAmE;AACnE,wEAAwE;AACxE,+EAA+E;AAC/E,0EAA0E;AAC1E,QAAQ;AACR,EAAE;AACF,6EAA6E;AAC7E,8EAA8E;AAC9E,gFAAgF;AAChF,oEAAoE;AACpE,0EAA0E;AAC1E,0EAA0E;AAC1E,sDAAsD;AACtD,yEAAyE;AACzE,2EAA2E;AAC3E,+DAA+D;AAE/D,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AAErF,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,qBAAqB,CAAC,OAAiC;IAC/D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;;;;;;EAuBxB,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;;2IAmBsH,CAAC;AAC5I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,qBAAqB;QACjC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Fable 5 full-core system prompt.\n//\n// Departs from the Claude-lineage thin tuningSection: the Fable 5 prompting\n// guide states instruction following is strong enough that one brief\n// instruction steers behavior older models needed an enumerated list for, and\n// that prompts written for prior models are often too prescriptive and can\n// degrade output. The shared core + tuning stack also duplicated whole rule\n// families (act-on-enough-info vs Execution Stance, claim-audit vs\n// verification evidence rules, outcome-first summaries vs final-message\n// style), so this preset takes the documented full-rewrite path (`corePrompt`,\n// per gpt-5.5.ts / gpt-5.6.ts / grok-4.5.ts) and states each rule exactly\n// once.\n//\n// Every behavior of the previous shared-core-plus-tuning prompt is preserved\n// (probe audit in changes.md, 2026-07-24 entry) at ~3/4 of the static tokens.\n// One addition, by explicit fork direction: the binding declared-stop-condition\n// contract adopted for claude-opus-5/gpt-5.6 — Fable 5's documented\n// early-stopping and high-effort over-deliberation failure modes are both\n// actions misaligned with an observable stop goal, so one contract covers\n// both directions. Shared pieces stay single-sourced:\n// buildTestDisciplineSection(), the rendered tool section, the grep/glob\n// search line, workstationDialect \"claude\"; dynamic pieces (context files,\n// skills, date, cwd) still come from buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeFable5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nThe line keeps your reading transparent; only the user's explicit request commits you to implementation. Name the stop condition as an observable end state, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured, deliver the final message, and stop - anything past it (another verification pass, re-polish, a bonus refactor) is a defect, not diligence. Never surface other prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples) in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.\n\n## Working the Task\n\nFire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.\n\nMemory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a \"just to be sure\" sweep.\n\nWhen you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue. When weighing a choice, give a recommendation, not a survey.\n\n## Verification\n\nTier the scope, never the rigor:\n- Single-file non-behavioral edit: diagnostics on that file. Done.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.\n- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification - run the validator. Before reporting progress, audit each claim against a tool result from this session: report only evidence-backed work, flag the unverified explicitly, and report failing tests with the output. Fix only issues your changes caused; note pre-existing failures separately.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never present unread code or unrun commands as verified fact.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.\n\nAct, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language (\"Next, I will...\") and permission-begging (\"Shall I?\") are prohibited. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn rather than ending on a promise; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, question, or promise about work you have not done means do that work now, with tool calls.\n\nHave an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. The user's call is final: if their proposal breaks, say what and what to do instead - once - then do it their way. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nBe concise and concrete: no filler openers, no self-praise, no \"it depends\" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Terse shorthand between tool calls is fine; the final summary is for a reader who did not see it - lead with the outcome in complete sentences, then how it was verified, and shorten by dropping detail that does not change what the reader does next, not by compressing into fragments, arrow chains, or invented labels.\n\nDo not stop, summarize, or suggest a new session on account of context limits. Continue the work until your declared stop condition holds.`;\n}\n\nexport function buildClaudeFable5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeFable5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-fable-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-fable-5.ts"],"names":[],"mappings":"AAAA,0CAA0C;AAC1C,EAAE;AACF,4EAA4E;AAC5E,qEAAqE;AACrE,8EAA8E;AAC9E,2EAA2E;AAC3E,4EAA4E;AAC5E,mEAAmE;AACnE,wEAAwE;AACxE,+EAA+E;AAC/E,0EAA0E;AAC1E,QAAQ;AACR,EAAE;AACF,6EAA6E;AAC7E,8EAA8E;AAC9E,gFAAgF;AAChF,oEAAoE;AACpE,0EAA0E;AAC1E,0EAA0E;AAC1E,sDAAsD;AACtD,yEAAyE;AACzE,2EAA2E;AAC3E,+DAA+D;AAE/D,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,8BAA8B,EAAE,MAAM,wBAAwB,CAAC;AAExE,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,qBAAqB,CAAC,OAAiC;IAC/D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;EAYxB,8BAA8B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;;;;;;;;;;;EAWxG,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;;2IAmBsH,CAAC;AAC5I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,qBAAqB;QACjC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Fable 5 full-core system prompt.\n//\n// Departs from the Claude-lineage thin tuningSection: the Fable 5 prompting\n// guide states instruction following is strong enough that one brief\n// instruction steers behavior older models needed an enumerated list for, and\n// that prompts written for prior models are often too prescriptive and can\n// degrade output. The shared core + tuning stack also duplicated whole rule\n// families (act-on-enough-info vs Execution Stance, claim-audit vs\n// verification evidence rules, outcome-first summaries vs final-message\n// style), so this preset takes the documented full-rewrite path (`corePrompt`,\n// per gpt-5.5.ts / gpt-5.6.ts / grok-4.5.ts) and states each rule exactly\n// once.\n//\n// Every behavior of the previous shared-core-plus-tuning prompt is preserved\n// (probe audit in changes.md, 2026-07-24 entry) at ~3/4 of the static tokens.\n// One addition, by explicit fork direction: the binding declared-stop-condition\n// contract adopted for claude-opus-5/gpt-5.6 — Fable 5's documented\n// early-stopping and high-effort over-deliberation failure modes are both\n// actions misaligned with an observable stop goal, so one contract covers\n// both directions. Shared pieces stay single-sourced:\n// buildTestDisciplineSection(), the rendered tool section, the grep/glob\n// search line, workstationDialect \"claude\"; dynamic pieces (context files,\n// skills, date, cwd) still come from buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildExecutionToolingParagraph } from \"./execution-tooling.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeFable5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nThe line keeps your reading transparent; only the user's explicit request commits you to implementation. Name the stop condition as an observable end state, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured, deliver the final message, and stop - anything past it (another verification pass, re-polish, a bonus refactor) is a defect, not diligence. Never surface other prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples) in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.\n\n## Working the Task\n\nFire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.\n\n${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: \"claude\" })}Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a \"just to be sure\" sweep.\n\nWhen you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue. When weighing a choice, give a recommendation, not a survey.\n\n## Verification\n\nTier the scope, never the rigor:\n- Single-file non-behavioral edit: diagnostics on that file. Done.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.\n- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification - run the validator. Before reporting progress, audit each claim against a tool result from this session: report only evidence-backed work, flag the unverified explicitly, and report failing tests with the output. Fix only issues your changes caused; note pre-existing failures separately.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never present unread code or unrun commands as verified fact.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.\n\nAct, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language (\"Next, I will...\") and permission-begging (\"Shall I?\") are prohibited. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn rather than ending on a promise; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, question, or promise about work you have not done means do that work now, with tool calls.\n\nHave an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. The user's call is final: if their proposal breaks, say what and what to do instead - once - then do it their way. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nBe concise and concrete: no filler openers, no self-praise, no \"it depends\" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Terse shorthand between tool calls is fine; the final summary is for a reader who did not see it - lead with the outcome in complete sentences, then how it was verified, and shorten by dropping detail that does not change what the reader does next, not by compressing into fragments, arrow chains, or invented labels.\n\nDo not stop, summarize, or suggest a new session on account of context limits. Continue the work until your declared stop condition holds.`;\n}\n\nexport function buildClaudeFable5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeFable5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAQlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAOlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.js

@@ -1,13 +1,17 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus45Tuning() {
-    return `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.
-
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;
+    return `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.`;
 }
 export function buildClaudeOpus45Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus45Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus45Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus45Tuning(): string {\n\treturn `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus45Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus45Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO,4MAA4M,CAAC;AACrN,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE;YACd,4BAA4B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,aAAa,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;YACrF,uBAAuB,EAAE;SACzB;aACC,MAAM,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC;aACvC,IAAI,CAAC,MAAM,CAAC;QACd,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildExecutionToolingSection } from \"./execution-tooling.ts\";\n\nfunction buildClaudeOpus45Tuning(): string {\n\treturn `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.`;\n}\n\nexport function buildClaudeOpus45Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: [\n\t\t\tbuildExecutionToolingSection({ toolNames: options.selectedTools, dialect: \"claude\" }),\n\t\t\tbuildClaudeOpus45Tuning(),\n\t\t]\n\t\t\t.filter((section) => section.length > 0)\n\t\t\t.join(\"\\n\\n\"),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAQlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAGlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.js

@@ -1,13 +1,9 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
-function buildClaudeOpus46Tuning() {
-    return `Choose an approach and commit to it; revisit only when new information directly contradicts your reasoning. When a request covers a set of items, apply it to every item and state the scope you applied.
-
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;
-}
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 export function buildClaudeOpus46Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus46Tuning(),
+        tuningSection: buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
         workstationDialect: "claude",
     });
 }

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus46Tuning(): string {\n\treturn `Choose an approach and commit to it; revisit only when new information directly contradicts your reasoning. When a request covers a set of items, apply it to every item and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus46Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus46Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,4BAA4B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,aAAa,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;QACpG,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildExecutionToolingSection } from \"./execution-tooling.ts\";\n\nexport function buildClaudeOpus46Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: \"claude\" }),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-7.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-7.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAalH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.js

@@ -1,17 +1,23 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus47Tuning() {
     return `Apply instructions at the scope the user evidently intends: "every", "all", and "each" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.
 
 Prefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up.
 
-For frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.
+Spawn the subagents for a fan-out across items or files in the same turn, not one at a time.
 
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;
+For frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.`;
 }
 export function buildClaudeOpus47Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus47Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus47Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus47Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus47Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus47Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;;;;;yOAMiO,CAAC;AAC1O,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE;YACd,4BAA4B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,aAAa,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;YACrF,uBAAuB,EAAE;SACzB;aACC,MAAM,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC;aACvC,IAAI,CAAC,MAAM,CAAC;QACd,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildExecutionToolingSection } from \"./execution-tooling.ts\";\n\nfunction buildClaudeOpus47Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up.\n\nSpawn the subagents for a fan-out across items or files in the same turn, not one at a time.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.`;\n}\n\nexport function buildClaudeOpus47Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: [\n\t\t\tbuildExecutionToolingSection({ toolNames: options.selectedTools, dialect: \"claude\" }),\n\t\t\tbuildClaudeOpus47Tuning(),\n\t\t]\n\t\t\t.filter((section) => section.length > 0)\n\t\t\t.join(\"\\n\\n\"),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-8.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-8.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAalH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.js

@@ -1,17 +1,23 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus48Tuning() {
     return `Apply instructions at the scope the user evidently intends: "every", "all", and "each" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.
 
-Prefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed; do not re-derive facts already established in the conversation.
+Prefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed rather than over the whole conversation.
 
-For frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.
+Spawn the subagents for a fan-out across items or files in the same turn, not one at a time.
 
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;
+For frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.`;
 }
 export function buildClaudeOpus48Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus48Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus48Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-8.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus48Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed; do not re-derive facts already established in the conversation.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus48Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus48Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-8.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;;;;;yOAMiO,CAAC;AAC1O,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE;YACd,4BAA4B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,aAAa,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;YACrF,uBAAuB,EAAE;SACzB;aACC,MAAM,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC;aACvC,IAAI,CAAC,MAAM,CAAC;QACd,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildExecutionToolingSection } from \"./execution-tooling.ts\";\n\nfunction buildClaudeOpus48Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed rather than over the whole conversation.\n\nSpawn the subagents for a fan-out across items or files in the same turn, not one at a time.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.`;\n}\n\nexport function buildClaudeOpus48Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: [\n\t\t\tbuildExecutionToolingSection({ toolNames: options.selectedTools, dialect: \"claude\" }),\n\t\t\tbuildClaudeOpus48Tuning(),\n\t\t]\n\t\t\t.filter((section) => section.length > 0)\n\t\t\t.join(\"\\n\\n\"),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-5.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AA6BA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAuElH,wBAAgB,sBAAsB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMvF"}
+{"version":3,"file":"claude-opus-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AA4CA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAsElH,wBAAgB,sBAAsB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMvF"}

package/dist/core/extensions/builtin/prompt-preset/claude-opus-5.js

@@ -1,33 +1,49 @@
 // Claude Opus 5 full-core system prompt.
 //
-// 2026-07-24: converted from the thin-tuningSection shape to a full core
-// rewrite via the `corePrompt` override, by explicit fork direction ("the
-// whole new prompt, not just appending") and matching the dieted
-// claude-fable-5.ts. The earlier rationale ("performs well out of the box on
-// Opus 4.8 prompts") argued the shared core was sufficient, not that it was
-// minimal: stacking the Opus 5 tuning on the full shared core restated
-// checkpoint/stop/verification rules the core already carried, and Anthropic's
-// Claude 5 guidance says instruction following is strong enough that brief
-// rules steer behavior enumerated lists were needed for before.
-//
-// Every behavior of the previous shared-core-plus-tuning prompt is preserved
-// (probe audit in changes.md, 2026-07-24 entry); each Opus 5 guide behavior
-// is merged where it binds tightest: the binding stop contract in the intent
-// gate, scope discipline beside intent routing, bounded single-pass
-// verification in the verification section, delegation caps in Working the
-// Task, narration cadence / correction filter / document calibration in
-// Style, auto-compaction continuation at the end. Deliberately NOT carried
-// (unchanged from the tuning-era preset): 4.7/4.8 scope literalism and the
-// house-style counter (documented inversions/undocumented for Opus 5), and no
-// added re-check instructions (the guide says they compound into
-// over-verification). Shared pieces stay single-sourced:
-// buildTestDisciplineSection(), the rendered tool section, the grep/glob
-// search line, workstationDialect "claude"; dynamic pieces (context files,
-// skills, date, cwd) still come from buildDynamicSystemPrompt.
+// 2026-09-03 diet. The 2026-07-24 full-core rewrite predated the Fable 5.1
+// diet (2026-09-02) and kept the dead weight that diet identified: the stop
+// contract restated three times inside one paragraph, scope stated in the
+// routing rules and again in its own paragraph, quoted anti-example
+// scaffolding ("Step 0", "Next, I will...", "Shall I?"), rationale
+// flourishes ("verification theater"), a trait list the model already has by
+// default ("no filler openers, no self-praise"), and a Hard Limit ("never
+// present unread code as verified fact") that the claim-audit rule covers.
+// Anthropic's Opus 5 guide names over-verification and scope expansion as the
+// model's failure modes and says re-check instructions compound with its own
+// behavior, so a prompt that itself repeats the stop rule works against the
+// guide. This rewrite is the Fable 5.1 skeleton (one home per rule; a Scope
+// section; literal register) with every Opus 5 guide behavior kept where it
+// binds tightest:
+// - Intent Gate: binding declared stop condition (the guide's two failure
+//   modes, addressed once).
+// - Scope: the guide's own scope text plus the 5.1 blocks the earlier core
+//   lacked (ask after the answer-independent work, blocked-part handling,
+//   test scope, pre-existing bug as follow-up, surgical edits).
+// - Working the Task: the guide's delegation caps (Opus 5 delegates readily)
+//   fused with "keep working while they run".
+// - Verification: bounded single pass ("you verify your own work by default")
+//   plus the claim-audit reporting rule (a reporting contract, not a
+//   re-check).
+// - Style: narration cadence, correction filter, document length, and the
+//   guide's outcome-first final-summary shape (previously missing), plus the
+//   guide's short conciseness instruction (Opus 5 responses run longer than
+//   prior Opus; this is the one place a brevity line is documented as
+//   needed). The guide's near-the-end reminder is not carried: project
+//   context and skills render after the core, so a block here is not near
+//   the end and would only restate the sentence above it.
+// Deliberately NOT carried: 4.7/4.8 scope literalism and the house-style
+// counter (undocumented for Opus 5), any added re-check instruction, the
+// thinking-disabled artifact mitigations (senpi runs Claude with thinking
+// on), and the code-review coverage prompt (review-harness specific). Shared
+// pieces stay single-sourced: buildTestDisciplineSection(), the rendered tool
+// section, the grep/glob search line, workstationDialect "claude"; dynamic
+// pieces (context files, skills, date, cwd) still come from
+// buildDynamicSystemPrompt.
 import { APP_NAME } from "../../../../config.js";
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
 import { getToolsPromptDisplay } from "../../../dynamic-prompt/tool-categorization.js";
 import { buildTestDisciplineSection } from "../../../dynamic-prompt/verification.js";
+import { buildExecutionToolingParagraph } from "./execution-tooling.js";
 function buildSearchLine(context) {
     const triggerTools = getToolsPromptDisplay(context.tools);
     if (!triggerTools) {
@@ -44,54 +60,52 @@ Open every turn with one short routing line:
 
 > I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].
 
-The line keeps your reading transparent; only the user's explicit request commits you to implementation. Before naming the stop condition, think hard about what the goal actually is - the end state the user can observe, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured - no new verification - deliver the final message, and stop. Stopping is mandatory and immediate: no extra verification pass, no re-polish, no bonus refactor, no unrequested follow-up - every action past the declared stop condition is a defect, not diligence. Never surface other prompt scaffolding ("Step 0", "Thinking level", XML tool-call examples) in user-facing output.
+Only the user's explicit request commits you to implementation. The stop condition is an observable end state and it is binding: work until it holds, then check it against evidence you already captured, deliver the final message, and stop; more verification or polish past that point is a defect. Never echo prompt scaffolding in user-facing output.
 ${buildSearchLine(context)}
 Route by true intent, not surface form:
-- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.
+- Information asks (explain, look into, investigate): read the code and report; no edits.
 - Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.
-- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.
+- Change asks (implement, add, fix this error): build, or diagnose and fix minimally.
 
-Deliver the task at the scope asked. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue as asked rather than quietly narrowing, widening, or transforming the work. Finish the whole task, and stop short of actions clearly beyond it.
+Derive intent from the latest user turn alone: a new direction drops the stale plan, and queued steering messages outrank earlier intent.
 
-Derive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.
+## Scope
 
-## Working the Task
+Deliver what was asked, at the scope intended: the request sets the scope, and the scope is the deliverable. Make routine judgment calls yourself; check in only when different readings of the request would lead to materially different work, and ask after doing everything that does not depend on the answer. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked. If part of the task is blocked, finish every other part and say exactly what you left out and why.
 
-Fire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.
+Smallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code; validate only at system boundaries. A pre-existing bug or performance concern you notice is a follow-up for your summary, not a change in this diff. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files. Prefer a surgical edit over rewriting a file when the result would be identical.
+
+## Working the Task
 
-Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a "just to be sure" sweep.
+Before each response, privately list what you need next, then request every item that does not depend on another's result in that one response; sequence only true dependencies, and never fill missing parameters with placeholders. Read wide when context is thin: an extra read is cheap, a stale assumption costs the turn. Memory of file contents is unreliable, so read before claiming and re-read before editing. Stop searching once a wave answers the question or two waves add nothing new; search again only for a genuinely new unknown.
 
-Delegate only sizeable, genuinely independent tracks of work, and only when a delegation tool is available. Keep work you can finish in a handful of tool calls, never spawn subagents to verify your own work, and prefer one subagent over several.
+${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: "claude" })}When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has made, or narrate options you will not pursue; when weighing a choice, give a recommendation. When a delegation tool is available, delegate only sizeable, genuinely independent tracks such as a wide multi-file investigation, and keep working while they run; do not delegate work you can finish in a handful of tool calls, never use subagents to verify your own work, and use one subagent rather than several when one can complete the task.
 
 ## Verification
 
-Tier the scope, never the rigor - and keep verification bounded: you verify your own work by default, so run the tier that matches the change once and trust a green result.
-- Single-file non-behavioral edit: diagnostics on that file. Done.
-- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.
-- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.
+Scale the checks to the change, never the rigor: diagnostics on every changed file always; related tests and one run of the affected entry point for behavioral changes; build plus manual exercise of the user-visible behavior through its real surface for multi-file or cross-cutting work. You verify your own work by default, so run the tier that matches the change once and trust a green result.
 
 ${buildTestDisciplineSection()}
 
-"Should pass" is not verification - run the validator before reporting anything clean. Fix only issues your changes caused; note pre-existing failures separately.
+"Should pass" is not verification: run the validator. Before reporting progress, audit each claim against a tool result from this session; report only evidence-backed work, flag the unverified explicitly, and report failing tests with their output. Fix only failures your change caused.
 
 ${context.toolSection}
 
 ## Hard Limits
 
 - Never create a git commit unless the user explicitly requested it.
-- Never present unread code or unrun commands as verified fact.
 - Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.
 - Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.
 
 ## Style
 
-Smallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.
+Act, then report: for reversible steps the request already covers, proceed without asking. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, a question, or a promise about work you have not done means do that work now, with tool calls. Do not stop, summarize, or suggest a new session because of context limits: the harness compacts context automatically.
 
-Act, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language ("Next, I will...") and permission-begging ("Shall I?") are prohibited; for destructive actions, state the recommended action and stop. Have an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.
+Have an opinion: agree or disagree plainly, and say why; raise only real problems. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.
 
-While working, add a progress note only when you find something important or change direction - the routing line already announced the plan. Keep responses focused and reasonably concise: no filler openers, no self-praise, no "it depends" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing and move on without noting them. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.
+Keep responses focused and concise: spend the words on the main answer and keep caveats short. Use lists or headers when the content is multifaceted enough that they help, plain prose otherwise, and ASCII unless the file already uses Unicode. The routing line already announced the plan, so add a brief update only when you find something important or change direction, and correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing without noting them.
 
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until your declared stop condition is met.`;
+When you finish, lead with the outcome: the first sentence answers what happened or what you found, then supporting detail and how it was verified, in complete sentences for a reader who did not see the work; drop detail that does not change what the reader does next rather than compressing into fragments. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.`;
 }
 export function buildClaudeOpus5Prompt(options) {
     return buildDynamicSystemPrompt({

package/dist/core/extensions/builtin/prompt-preset/claude-opus-5.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AAAA,yCAAyC;AACzC,EAAE;AACF,yEAAyE;AACzE,0EAA0E;AAC1E,iEAAiE;AACjE,6EAA6E;AAC7E,4EAA4E;AAC5E,uEAAuE;AACvE,+EAA+E;AAC/E,2EAA2E;AAC3E,gEAAgE;AAChE,EAAE;AACF,6EAA6E;AAC7E,4EAA4E;AAC5E,6EAA6E;AAC7E,oEAAoE;AACpE,2EAA2E;AAC3E,wEAAwE;AACxE,2EAA2E;AAC3E,2EAA2E;AAC3E,8EAA8E;AAC9E,iEAAiE;AACjE,yDAAyD;AACzD,yEAAyE;AACzE,2EAA2E;AAC3E,+DAA+D;AAE/D,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AAErF,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,oBAAoB,CAAC,OAAiC;IAC9D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;EAyBxB,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;2JAiBsI,CAAC;AAC5J,CAAC;AAED,MAAM,UAAU,sBAAsB,CAAC,OAAwC;IAC9E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,oBAAoB;QAChC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Opus 5 full-core system prompt.\n//\n// 2026-07-24: converted from the thin-tuningSection shape to a full core\n// rewrite via the `corePrompt` override, by explicit fork direction (\"the\n// whole new prompt, not just appending\") and matching the dieted\n// claude-fable-5.ts. The earlier rationale (\"performs well out of the box on\n// Opus 4.8 prompts\") argued the shared core was sufficient, not that it was\n// minimal: stacking the Opus 5 tuning on the full shared core restated\n// checkpoint/stop/verification rules the core already carried, and Anthropic's\n// Claude 5 guidance says instruction following is strong enough that brief\n// rules steer behavior enumerated lists were needed for before.\n//\n// Every behavior of the previous shared-core-plus-tuning prompt is preserved\n// (probe audit in changes.md, 2026-07-24 entry); each Opus 5 guide behavior\n// is merged where it binds tightest: the binding stop contract in the intent\n// gate, scope discipline beside intent routing, bounded single-pass\n// verification in the verification section, delegation caps in Working the\n// Task, narration cadence / correction filter / document calibration in\n// Style, auto-compaction continuation at the end. Deliberately NOT carried\n// (unchanged from the tuning-era preset): 4.7/4.8 scope literalism and the\n// house-style counter (documented inversions/undocumented for Opus 5), and no\n// added re-check instructions (the guide says they compound into\n// over-verification). Shared pieces stay single-sourced:\n// buildTestDisciplineSection(), the rendered tool section, the grep/glob\n// search line, workstationDialect \"claude\"; dynamic pieces (context files,\n// skills, date, cwd) still come from buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeOpus5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nThe line keeps your reading transparent; only the user's explicit request commits you to implementation. Before naming the stop condition, think hard about what the goal actually is - the end state the user can observe, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured - no new verification - deliver the final message, and stop. Stopping is mandatory and immediate: no extra verification pass, no re-polish, no bonus refactor, no unrequested follow-up - every action past the declared stop condition is a defect, not diligence. Never surface other prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples) in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.\n\nDeliver the task at the scope asked. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue as asked rather than quietly narrowing, widening, or transforming the work. Finish the whole task, and stop short of actions clearly beyond it.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.\n\n## Working the Task\n\nFire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.\n\nMemory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a \"just to be sure\" sweep.\n\nDelegate only sizeable, genuinely independent tracks of work, and only when a delegation tool is available. Keep work you can finish in a handful of tool calls, never spawn subagents to verify your own work, and prefer one subagent over several.\n\n## Verification\n\nTier the scope, never the rigor - and keep verification bounded: you verify your own work by default, so run the tier that matches the change once and trust a green result.\n- Single-file non-behavioral edit: diagnostics on that file. Done.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.\n- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification - run the validator before reporting anything clean. Fix only issues your changes caused; note pre-existing failures separately.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never present unread code or unrun commands as verified fact.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.\n\nAct, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language (\"Next, I will...\") and permission-begging (\"Shall I?\") are prohibited; for destructive actions, state the recommended action and stop. Have an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nWhile working, add a progress note only when you find something important or change direction - the routing line already announced the plan. Keep responses focused and reasonably concise: no filler openers, no self-praise, no \"it depends\" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing and move on without noting them. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until your declared stop condition is met.`;\n}\n\nexport function buildClaudeOpus5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeOpus5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AAAA,yCAAyC;AACzC,EAAE;AACF,2EAA2E;AAC3E,4EAA4E;AAC5E,0EAA0E;AAC1E,oEAAoE;AACpE,mEAAmE;AACnE,6EAA6E;AAC7E,0EAA0E;AAC1E,2EAA2E;AAC3E,8EAA8E;AAC9E,6EAA6E;AAC7E,4EAA4E;AAC5E,4EAA4E;AAC5E,4EAA4E;AAC5E,kBAAkB;AAClB,0EAA0E;AAC1E,4BAA4B;AAC5B,2EAA2E;AAC3E,0EAA0E;AAC1E,gEAAgE;AAChE,6EAA6E;AAC7E,8CAA8C;AAC9C,8EAA8E;AAC9E,qEAAqE;AACrE,eAAe;AACf,0EAA0E;AAC1E,6EAA6E;AAC7E,4EAA4E;AAC5E,sEAAsE;AACtE,uEAAuE;AACvE,0EAA0E;AAC1E,0DAA0D;AAC1D,yEAAyE;AACzE,yEAAyE;AACzE,0EAA0E;AAC1E,6EAA6E;AAC7E,8EAA8E;AAC9E,2EAA2E;AAC3E,4DAA4D;AAC5D,4BAA4B;AAE5B,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,8BAA8B,EAAE,MAAM,wBAAwB,CAAC;AAExE,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,oBAAoB,CAAC,OAAiC;IAC9D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;EAkBxB,8BAA8B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;;;;;;EAMxG,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;sbAgBia,CAAC;AACvb,CAAC;AAED,MAAM,UAAU,sBAAsB,CAAC,OAAwC;IAC9E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,oBAAoB;QAChC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Opus 5 full-core system prompt.\n//\n// 2026-09-03 diet. The 2026-07-24 full-core rewrite predated the Fable 5.1\n// diet (2026-09-02) and kept the dead weight that diet identified: the stop\n// contract restated three times inside one paragraph, scope stated in the\n// routing rules and again in its own paragraph, quoted anti-example\n// scaffolding (\"Step 0\", \"Next, I will...\", \"Shall I?\"), rationale\n// flourishes (\"verification theater\"), a trait list the model already has by\n// default (\"no filler openers, no self-praise\"), and a Hard Limit (\"never\n// present unread code as verified fact\") that the claim-audit rule covers.\n// Anthropic's Opus 5 guide names over-verification and scope expansion as the\n// model's failure modes and says re-check instructions compound with its own\n// behavior, so a prompt that itself repeats the stop rule works against the\n// guide. This rewrite is the Fable 5.1 skeleton (one home per rule; a Scope\n// section; literal register) with every Opus 5 guide behavior kept where it\n// binds tightest:\n// - Intent Gate: binding declared stop condition (the guide's two failure\n//   modes, addressed once).\n// - Scope: the guide's own scope text plus the 5.1 blocks the earlier core\n//   lacked (ask after the answer-independent work, blocked-part handling,\n//   test scope, pre-existing bug as follow-up, surgical edits).\n// - Working the Task: the guide's delegation caps (Opus 5 delegates readily)\n//   fused with \"keep working while they run\".\n// - Verification: bounded single pass (\"you verify your own work by default\")\n//   plus the claim-audit reporting rule (a reporting contract, not a\n//   re-check).\n// - Style: narration cadence, correction filter, document length, and the\n//   guide's outcome-first final-summary shape (previously missing), plus the\n//   guide's short conciseness instruction (Opus 5 responses run longer than\n//   prior Opus; this is the one place a brevity line is documented as\n//   needed). The guide's near-the-end reminder is not carried: project\n//   context and skills render after the core, so a block here is not near\n//   the end and would only restate the sentence above it.\n// Deliberately NOT carried: 4.7/4.8 scope literalism and the house-style\n// counter (undocumented for Opus 5), any added re-check instruction, the\n// thinking-disabled artifact mitigations (senpi runs Claude with thinking\n// on), and the code-review coverage prompt (review-harness specific). Shared\n// pieces stay single-sourced: buildTestDisciplineSection(), the rendered tool\n// section, the grep/glob search line, workstationDialect \"claude\"; dynamic\n// pieces (context files, skills, date, cwd) still come from\n// buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildExecutionToolingParagraph } from \"./execution-tooling.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeOpus5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nOnly the user's explicit request commits you to implementation. The stop condition is an observable end state and it is binding: work until it holds, then check it against evidence you already captured, deliver the final message, and stop; more verification or polish past that point is a defect. Never echo prompt scaffolding in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code and report; no edits.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan, and queued steering messages outrank earlier intent.\n\n## Scope\n\nDeliver what was asked, at the scope intended: the request sets the scope, and the scope is the deliverable. Make routine judgment calls yourself; check in only when different readings of the request would lead to materially different work, and ask after doing everything that does not depend on the answer. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked. If part of the task is blocked, finish every other part and say exactly what you left out and why.\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code; validate only at system boundaries. A pre-existing bug or performance concern you notice is a follow-up for your summary, not a change in this diff. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files. Prefer a surgical edit over rewriting a file when the result would be identical.\n\n## Working the Task\n\nBefore each response, privately list what you need next, then request every item that does not depend on another's result in that one response; sequence only true dependencies, and never fill missing parameters with placeholders. Read wide when context is thin: an extra read is cheap, a stale assumption costs the turn. Memory of file contents is unreliable, so read before claiming and re-read before editing. Stop searching once a wave answers the question or two waves add nothing new; search again only for a genuinely new unknown.\n\n${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: \"claude\" })}When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has made, or narrate options you will not pursue; when weighing a choice, give a recommendation. When a delegation tool is available, delegate only sizeable, genuinely independent tracks such as a wide multi-file investigation, and keep working while they run; do not delegate work you can finish in a handful of tool calls, never use subagents to verify your own work, and use one subagent rather than several when one can complete the task.\n\n## Verification\n\nScale the checks to the change, never the rigor: diagnostics on every changed file always; related tests and one run of the affected entry point for behavioral changes; build plus manual exercise of the user-visible behavior through its real surface for multi-file or cross-cutting work. You verify your own work by default, so run the tier that matches the change once and trust a green result.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification: run the validator. Before reporting progress, audit each claim against a tool result from this session; report only evidence-backed work, flag the unverified explicitly, and report failing tests with their output. Fix only failures your change caused.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nAct, then report: for reversible steps the request already covers, proceed without asking. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, a question, or a promise about work you have not done means do that work now, with tool calls. Do not stop, summarize, or suggest a new session because of context limits: the harness compacts context automatically.\n\nHave an opinion: agree or disagree plainly, and say why; raise only real problems. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nKeep responses focused and concise: spend the words on the main answer and keep caveats short. Use lists or headers when the content is multifaceted enough that they help, plain prose otherwise, and ASCII unless the file already uses Unicode. The routing line already announced the plan, so add a brief update only when you find something important or change direction, and correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing without noting them.\n\nWhen you finish, lead with the outcome: the first sentence answers what happened or what you found, then supporting detail and how it was verified, in complete sentences for a reader who did not see the work; drop detail that does not change what the reader does next rather than compressing into fragments. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.`;\n}\n\nexport function buildClaudeOpus5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeOpus5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/execution-tooling.d.ts

@@ -0,0 +1,39 @@
+export type ExecutionToolingRuleId = "eval-default-surface" | "eval-real-code" | "eval-stay-direct";
+export type ExecutionToolingConcern = "code-cell-routing";
+export type ExecutionToolingDialect = "claude" | "kimi";
+export interface ExecutionToolingRule {
+    readonly id: ExecutionToolingRuleId;
+    readonly concern: ExecutionToolingConcern;
+    readonly directive: Readonly<Record<ExecutionToolingDialect, string>>;
+}
+export declare const EXECUTION_TOOLING_RULES: readonly [{
+    readonly id: "eval-default-surface";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        readonly claude: "`eval` is your DEFAULT execution surface, not a fallback: the moment a step needs more than one tool call - reads, searches, symbol lookups, shell commands, web fetches, subagent spawns - write ONE cell that performs the WHOLE step. Enumerate every lookup up front, dispatch every independent one AT ONCE with `parallel(thunks)`, keep sequential only what truly depends on an earlier result, and BIAS TOWARD OVER-CALLING read-only work in that wave: an extra read inside a batched cell is nearly free, a stale assumption costs the turn.";
+        readonly kimi: "**MAKE `eval` YOUR DEFAULT WAY TO ACT.** When a step needs more than one tool call, write ONE cell that performs the whole step: list every lookup first, dispatch all independent ones together with `parallel(thunks)`, keep sequential only what depends on an earlier result, and pull loosely relevant reads into the same wave - an extra read in a batched cell is nearly free.";
+    };
+}, {
+    readonly id: "eval-real-code";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        readonly claude: "Write REAL programs in those cells, not call lists: `if`/`for` over targets, `map`/`filter`/`reduce`, joins, dedup, aggregation, a `try`/`catch` per risky item so one failure degrades only that item, and return DISTILLED, decision-ready facts - never raw dumps.";
+        readonly kimi: "**WRITE REAL CODE IN THE CELL:** `if`/`for` over targets, `map`/`filter`/`reduce`, joins and aggregation, a `try`/`catch` per risky item so the rest of the batch completes, and return distilled facts.";
+    };
+}, {
+    readonly id: "eval-stay-direct";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        readonly claude: "Call a tool directly only when one call is enough, the result decides the next call, semantic judgment sits between calls, or the action needs approval.";
+        readonly kimi: "Use a direct tool call when one call is enough, when each result decides the next call, or when the action needs approval - then stop deliberating and make it.";
+    };
+}];
+export interface BuildExecutionToolingSectionOptions {
+    readonly toolNames: readonly string[];
+    readonly dialect: ExecutionToolingDialect;
+}
+/** Directives for the selected tools, or "" when eval is not available. */
+export declare function buildExecutionToolingSection(options: BuildExecutionToolingSectionOptions): string;
+/** Same as buildExecutionToolingSection but followed by a paragraph gap, for inline placement. */
+export declare function buildExecutionToolingParagraph(options: BuildExecutionToolingSectionOptions): string;
+//# sourceMappingURL=execution-tooling.d.ts.map