@cerebriline/core 4.100.240

package/dist/extensions/config/prompt-template-review.d.ts

@@ -0,0 +1,327 @@
+import { type PromptTemplate } from "@cerebriline/shared";
+import { type CompactionPromptSources } from "./prompt-template-compaction";
+export declare const DEFAULT_REQUIRED_REWRITES: readonly ["read_files", "search_codebase", "editor", "apply_patch", "run_commands", "fetch_web_content", "check_file", "ask_lsp", "grep", "sed", "awk"];
+export declare const PROMPT_TEMPLATE_REVIEW_INSTRUCTIONS = "You are being shown the prompt Cline gives you when it uses you as a coding agent: a system prompt and a set of tool descriptions. You are the intended reader of this text. Rewrite it into the form you would rather receive.\n\nThis is not a copy-editing task. The prompt below was written by someone reasoning about how you read, and they may have been wrong. Where a section is phrased in a way you would skim, reorder or restate it. Where a rule matters and is buried, put it where you would be when you are about to break it. Where something is repeated to no effect, cut it.\n\nFour failures are observed in practice with models in your family, and the rewrite is judged on whether it prevents them:\n\n1. Reaching for shell commands to do file work \u2014 'cat' to read, 'sed -i' or 'echo >' to write, 'grep' to search \u2014 when dedicated tools exist and are always available.\n2. Serialising independent work across turns: one read, wait, one read, wait, when all of them were known at the start.\n3. Announcing an intention instead of acting on it, or claiming a task is finished without reading back what was written.\n4. Answering a question about a symbol with a text search. Asking where something is defined, what uses it, what implements it, or what a name means, and then grepping for it and reading several files to work out which hit was the real one \u2014 when the IDE's language servers already know the answer exactly and will give it in one call. The same failure in its other form: running a compiler or a linter through the shell to find out whether one file is valid, and waiting for a whole-project build to answer a one-file question.\n\nOne thing you must get right, and which prompts written for this get wrong in both directions:\n\nA coding agent is multi-turn, and the end of a turn is never in itself the end of the work. What is final is the completion of the assigned work \u2014 the task, the work package, the milestone, the request. An end of turn may be a milestone reached, a point where you need direction, guidance or a clarification from the user, or simply an intermediate step between two things the user asked for. So:\n\n- Do not treat \"I have stopped emitting tool calls\" as \"the work is done\". It is not a signal about the work at all.\n- Do not write a rule that makes stopping feel like failure, such as \"a response without a tool call is considered complete\". A rule like that buys one more unnecessary tool call on every finished task, and it teaches the wrong thing: that continuing is always correct.\n- Keep your attention on the long horizon of the assigned work rather than on the current turn. Ending a turn to ask a question is correct when you need the answer. Ending it while work you were asked to do remains untouched, and saying nothing about that, is not.\n\nFour more things are settled by measurement rather than by opinion, and a rewrite is judged on whether it keeps them:\n\n- The checker and the run belong in the same turn. Call 'check_file' and the thing that executes the code - 'run_commands', or 'browser' for a page - together, not one or the other. Running it says *that* something is broken and where the parser gave up; the checker says *which line* to edit. Each is half the answer, and the half you skip is the half the turn gets spent guessing at.\n- A tool's report outranks your own reasoning about the same question. Where a tool has measured something - a delimiter scan naming the line to edit, a diagnostic naming a type - that is the measurement, and re-deriving it yourself is an estimate. Where the two disagree, it is the estimate that is wrong. Measured twice: a model called a delimiter scan a false positive, counted brackets by hand instead, and was wrong both times, at over 30,000 thinking tokens a turn. If you doubt a report, do not re-derive it - act on it and run the result. That costs milliseconds and settles it either way.\n- Make the planned changes one at a time, and confirm each one before starting the next. The cheap check that does not execute the code goes after every edit; the thing that runs the code is what settles whether the change was right. Six edits made together and checked once leave six things to undo and no way to tell which one was wrong - measured across ten runs, the template that said otherwise drew 13.6 'restore_file' calls per run against 0.23 for the family that did not.\n- Do not re-read a file to confirm your own edit. The edit call already reports whether it landed and what changed, and that is the confirmation. Measured on one session: 'read_files' was called 33 times, 31 of them byte-identical, returning 440,013 characters against a file of 14 KB - four times the tokens that session spent on all of its reasoning. Read again when the call failed, or when you need content you have not seen. A rule that says to read a file back after every edit is the one thing here you must not write.\n\nHard constraints:\n\n- Keep every placeholder exactly as written, including the braces: {{PLATFORM_NAME}}, {{CURRENT_DATE}}, {{IDE_NAME}}, {{CWD}}, {{CLINE_RULES}}, {{CLINE_METADATA}}, {{DEFAULT}}. They are substituted at runtime; a renamed or dropped placeholder breaks the prompt.\n- Keep the tool names exactly as written. They are the wire names of real tools.\n- Do not invent tools, parameters, or capabilities. Describe only what is described below.\n- Keep the file structure: YAML frontmatter between --- markers, then '# system', then one '# tool: <name>' section for EVERY tool listed below. Not only the ones you want to change \u2014 every one of them.\n- Covering every tool is a hard requirement. A tool with no section keeps its built-in description, and that fallback exists for exactly one situation: Cline gains a new tool and the templates have not been regenerated yet. It is not a way to skip tools you have nothing to say about. A template that covers six of thirty-one tools is not using the fallback, it is relying on it, and nothing in the file shows which twenty-five were left out.\n- '{{DEFAULT}}' expands to the tool's built-in description at runtime, and it is how you cover a tool cheaply. Where you would improve on the built-in wording, write your own and put '{{DEFAULT}}' on its own line where the built-in text should follow. Where you would not, the entire section body may be just '{{DEFAULT}}'. Either is a covered tool; an absent section is not.\n- These eight tools must be written in your own words, and a section containing only '{{DEFAULT}}' is not acceptable for any of them: read_files, search_codebase, editor, apply_patch, run_commands, fetch_web_content, check_file, ask_lsp. They are the tools models in your family are observed to misuse, so they are the whole reason this template exists. For these eight, your own text \u2014 not the inherited text \u2014 has to carry the three things listed below: every value of any closed set, every argument and when to use it, and what comes back. Adding '{{DEFAULT}}' after your text is allowed and does not excuse you from any of that.\n- For 'ask_lsp', say when to reach for it, not only what it does. List at least three concrete situations as the reader actually meets them \u2014 \"about to search for a name to find where it is defined\", \"about to open a file just to read a signature\", \"about to scroll or count brackets to work out a file's structure\" \u2014 each pointing at the operation that answers it, and name 'search_codebase' as the thing those situations would otherwise go to. This is not padding: measured across a whole session against a real bug, a template that described all eight operations correctly and said only \"prefer this over search_codebase for anything about a symbol\" produced zero calls to the tool, while the model hand-rolled the same answers in the shell twenty times. It could not recognise the moment.\n- Do not copy a built-in description out word for word. That is a snapshot: it says the same thing today and stops tracking the built-in text tomorrow, so the next edit to it reaches every model except you. If you would not change the wording, write '{{DEFAULT}}' \u2014 that is what it is for.\n- Where you rule a use of a tool out, name the tool that replaces it. 'run_commands' in particular must name 'read_files', 'editor' and 'search_codebase' in your own text: \"do not use this for file operations when dedicated tools exist\" is a rule the reader has to already know the answer to in order to follow, which is the same as not writing it.\n- Two of those eight \u2014 'run_commands' and 'skills' \u2014 must keep '{{DEFAULT}}' in the section as well. Their built-in descriptions are not fixed text: 'run_commands' is composed against the shell that will actually run the commands, so PowerShell, cmd and a POSIX shell get different quoting and sequencing advice, and 'skills' appends the skills installed on that machine. Replace either outright and you freeze one machine's answer into every machine's prompt, silently. Write your own text and put '{{DEFAULT}}' on its own line where the built-in text should follow.\n- For the other tools, a section whose body is exactly '{{DEFAULT}}' is a complete and correct answer. Do not pad them. Nothing about how you read changes what 'team_finalize_outcome' should say.\n- Emit every section exactly once. Do not repeat '# system', and do not write two '# tool: <name>' headings for the same tool. Only the last copy of a repeated section survives, so a duplicate silently throws away your own work.\n- Leave the 'match:' block in the frontmatter exactly as it is. It is what routes this template to you; change it and your rewrite reaches a different model, or none.\n\nReplace a description and you inherit everything it was carrying:\n\nIf a '# tool:' section contains '{{DEFAULT}}' anywhere, the built-in description is still delivered and you are only adding emphasis on top of it. Nothing further is asked of you for that tool \u2014 unless it is one of the eight above, which are judged on your words alone.\n\nIf it does not, your text is the only thing a model will ever see about that tool, so it must not lose what the built-in description said. Specifically, and only where the built-in text below says it:\n\n1. Closed sets. Where the built-in description lists the values an argument accepts \u2014 the operations of a language-server tool, the actions of a task tool, the statuses of a run \u2014 your replacement must list all of them too. Naming four of eight hides half the tool and a model cannot guess the rest.\n2. How to address the tool. Where the built-in description names the arguments, and says which one to use when, your replacement must say the same. A tool that can be addressed three ways needs all three, and what each is for.\n3. What comes back. Where the built-in description states an output, your replacement must state one: the shape, what the fields hold, and what an empty or failed result means. A model that cannot map a result back onto its request spends a turn working it out, and then stops trusting the tool.\n\nNothing is required of you that the built-in text did not already provide. Reproducing what is there is always enough; improving on it is better; dropping it is the one thing that is not allowed.\n\nDo not write 'Output:' followed by nothing, or by a single word. An empty label reads as an empty result, which is worse than saying nothing at all.\n\nFor any tool outside the eight, if restating all of that is not worth it to you, do not replace its description. Write your emphasis and leave '{{DEFAULT}}' in the section, or write nothing but the marker. That is cheaper and it is always correct.\n\nReply with the complete template file and nothing else: no preamble, no explanation, no code fence.";
+export declare function buildPromptTemplateReviewPrompt(defaultTemplate: string, familyTemplate: string | undefined, familyTemplateName: string | undefined, 
+/** What this model is, so a new template can be told how to claim itself. */
+target?: {
+    providerId: string;
+    modelId: string;
+    family?: string;
+}, 
+/** Real call shapes, so any example the model writes is a valid one. */
+toolSignatures?: readonly ToolCallSignature[], 
+/** Every tool the reply must give a section. Checked by the audit. */
+requiredSections?: readonly string[], 
+/**
+ * An explicit `match:` block, overriding both what is inferred from the
+ * generating model's identifiers AND the block the template being rewritten
+ * already carries.
+ */
+matchOverride?: PromptTemplateMatchOverride): string;
+/**
+ * Tell a model writing a template from scratch exactly how to claim itself.
+ *
+ * Observed in practice: a model rewriting an existing template keeps its match
+ * block, and a model writing a new one invents a shape — `match: [glm*]`,
+ * `match.id`, a bare string — every one of which either fails to parse or
+ * routes to nothing. Showing the block it should write, filled in with its own
+ * identifiers, is what stops that.
+ */
+/**
+ * An explicit `match:` block stated by the operator.
+ *
+ * Two things need this and they pull in opposite directions from the same
+ * cause -- what the generating model reports about itself is not what the
+ * template should claim.
+ *
+ * `model` is for a params overlay: the overlay is scaffolding
+ * (`igovet/minimax-m3-opencode`, `nemotron-3-super-tpl`) that reports no
+ * family, so an inferred block would claim the scaffolding.
+ *
+ * `family` is for a generational split. The inferred stem truncates at the
+ * first non-alphanumeric character, so `kimi-k2` and `kimi-k3` both infer
+ * `kimi*` -- one pattern for two generations that need different templates.
+ * Stating `kimi-k3*` is the only way to say what the model cannot.
+ */
+export interface PromptTemplateMatchOverride {
+    name?: string;
+    family?: readonly string[];
+    model?: readonly string[];
+}
+/**
+ * A one-line call signature per tool, built from the real input schema.
+ *
+ * This exists because of a failure seen in production logs rather than a
+ * hypothetical one. `fetch_web_content` requires `{requests: [{url, prompt}]}`
+ * and its description says "each request includes a URL and a prompt" — which
+ * describes the inner object and never names the array that wraps it. A qwen3.6
+ * session sent `{url, prompt}` four times and got
+ * `Invalid input: expected array, received undefined` every time, then gave up
+ * and shelled out. `read_files` has the same shape of gap: "at the provided
+ * absolute paths", but the schema wants `{files: [{path}]}`.
+ *
+ * So a model rewriting a template must be shown the envelope, not just the
+ * semantics — otherwise the confident, concrete example it writes is wrong, and
+ * a wrong example is worse than none.
+ */
+export interface ToolCallSignature {
+    name: string;
+    /** Top-level argument names, in schema order. */
+    parameters: string[];
+    required: string[];
+    /** `read_files(files: [{path, start_line?, end_line?}])` */
+    signature: string;
+    /**
+     * Every value of every enum in the schema, flattened.
+     *
+     * These are the closed sets a model cannot guess: `ask_lsp` accepts
+     * exactly eight operations and a description that names four of them has
+     * hidden half the tool. Collected here so the audit can require them
+     * without a hand-maintained list that would drift the first time an
+     * operation is added.
+     */
+    enumValues: string[];
+}
+export declare function summarizeToolCallSignatures(tools: readonly {
+    name: string;
+    inputSchema?: unknown;
+}[]): ToolCallSignature[];
+/**
+ * Hold a rewritten tool section to what the built-in one already told the model.
+ *
+ * A section that keeps `{{DEFAULT}}` inherits the whole built-in description
+ * and needs nothing from this: the model is adding emphasis on top of a
+ * complete text. A section that drops the marker has replaced that text, and
+ * replacing it is where information goes missing — measured across five models
+ * rewriting `ask_lsp`, the replacements ranged from complete to two lines
+ * naming none of the eight operations, none of the three ways to address a
+ * symbol, and no output at all. Both parsed. Both resolved. Both applied.
+ *
+ * So the rule is: replace it and you own it — do not lose what it was saying.
+ * Judged against the built-in text rather than against the schema, because the
+ * two are not the same thing and the difference is not academic. The built-in
+ * `team_send_message` description names neither `subject` nor `body`; a rule
+ * that demanded them would be asking a model to add what it was never shown,
+ * and one did exactly that for four attempts without converging, because there
+ * was nothing in front of it to converge on. Requiring only what the source
+ * carried is both fair and reachable: reproduce the built-in text and you pass.
+ */
+export declare function auditToolSectionContent(tools: Readonly<Record<string, string>>, signatures: readonly ToolCallSignature[], 
+/** The built-in description per tool. Nothing is required beyond these. */
+builtinDescriptions?: Readonly<Record<string, string>>, 
+/**
+ * Tools whose section must be written, not inherited.
+ *
+ * The marker is a fair way to cover a tool a model has nothing to say
+ * about, and for most of the thirty-one that is the honest answer. It is
+ * not the honest answer for the handful the model actually gets wrong: a
+ * 31B model handed the option produced twenty-four bare markers and two
+ * lines of its own on `ask_lsp`, which is not a template that reads
+ * differently from the default — it is the default with a preamble.
+ */
+requiredRewrites?: readonly string[]): string[];
+/** The block handed to a model so its examples use the real argument shapes. */
+export declare function renderToolCallSignatures(signatures: readonly ToolCallSignature[]): string;
+export interface PromptTemplateProposalAudit {
+    template?: PromptTemplate;
+    /** Empty means usable. Each entry is phrased to be handed back to a model. */
+    problems: string[];
+}
+export interface AuditPromptTemplateProposalArgs {
+    raw: string;
+    fileName: string;
+    /** The provider the template is being generated for. */
+    providerId: string;
+    /** The model this was written by and for, e.g. `gemma4:31b-cloud`. */
+    modelId: string;
+    /**
+     * The model family, when the provider can report one. Only Ollama does; for
+     * every other provider this is undefined and the template matches on the
+     * provider or the model id instead.
+     */
+    family: string | undefined;
+    knownToolNames: readonly string[];
+    /** The name it must keep, or undefined when writing a brand-new template. */
+    expectedName?: string;
+    /**
+     * Tools the rewrite has to say something about, anywhere in the file.
+     *
+     * Omitting a tool section is legal — it falls back to the default template
+     * — so a proposal that simply forgets a tool passes every structural check
+     * while quietly failing to do the thing it was asked to do. Observed once
+     * in six runs, which is exactly often enough to matter and rarely enough to
+     * miss by eye.
+     */
+    requiredMentions?: readonly string[];
+    /**
+     * Tools that must each have a `# tool:` section of their own.
+     *
+     * Stricter than `requiredMentions`, which only asks that the name appear
+     * somewhere. This asks for the section, because a tool with no section is
+     * a tool whose description this template does not govern.
+     */
+    requiredSections?: readonly string[];
+    /**
+     * Tools whose section must be the model's own words rather than the marker.
+     * These are the tools whose description actually changes behaviour.
+     */
+    requiredRewrites?: readonly string[];
+    /**
+     * Check the system section against `REQUIRED_SYSTEM_GUIDANCE`.
+     *
+     * Opt-in, because those are requirements on a *complete family template* and
+     * would otherwise fire on every fragment a caller asks to be checked. The
+     * generator and `audit-prompt-template.mts` both set it.
+     */
+    requireSystemGuidance?: boolean;
+    /**
+     * An operator-stated `match:` block, if one was given. Checked, because an
+     * instruction the model can quietly decline is not an instruction.
+     */
+    matchFamily?: readonly string[];
+    matchModel?: readonly string[];
+    /**
+     * Real call shapes, so example calls in the proposal can be checked.
+     * Without these the audit cannot tell `read_files(["a.ts"])` — which is
+     * rejected at runtime — from a correct one.
+     */
+    toolSignatures?: readonly ToolCallSignature[];
+    /** Injection point for tests; defaults to the shipped templates. */
+    baseTemplates?: readonly PromptTemplate[];
+}
+/**
+ * Lines in a system prompt that tell the model to batch its edits, or to save
+ * the run that would have caught a bad one for the end.
+ *
+ * Exported because the audit is only ever run against what a *model* proposes,
+ * and the rule reached the shipped templates by another road entirely: it was
+ * in `default.md`, which every regeneration is seeded from, and from there in
+ * six more. Seven of the ten carried it while the ban read as enforced. The
+ * detector belongs in one place so the shipped-template test and the proposal
+ * audit cannot drift apart.
+ */
+export declare function findBatchedEditRules(system: string): string[];
+export declare function auditPromptTemplateProposal(args: AuditPromptTemplateProposalArgs): PromptTemplateProposalAudit;
+/**
+ * Hand a model its own file back with the list of what is wrong with it.
+ *
+ * Asking for a fix works far better than asking for another draft: a fresh
+ * draft reintroduces the same mistakes at the same rate, because the thing that
+ * produced them has not changed.
+ */
+export declare function buildPromptTemplateRepairPrompt(previous: string, problems: readonly string[]): string;
+/**
+ * Pull the template out of a reply.
+ *
+ * The instructions ask for no code fence. Models add one anyway, and a fenced
+ * reply that is otherwise perfect should not cost a repair round.
+ */
+export declare function extractTemplateFromReply(reply: string): string;
+/**
+ * Ask a model for a template it would rather receive, and keep asking until the
+ * answer is usable.
+ *
+ * The model call is injected because the two callers reach a model by entirely
+ * different routes: the review script talks to Ollama over HTTP, and the
+ * extension goes through whichever provider the user has configured. What must
+ * not differ is everything around the call — the instructions, the audit, and
+ * the decision to try again — because a template generated from the settings
+ * panel and one generated from the script should be the same artefact.
+ */
+export interface GeneratePromptTemplateArgs {
+    /** `default.md`, the base layer the proposal is layered over. */
+    defaultTemplate: string;
+    /** The template this model is given today, if any. */
+    familyTemplate?: string;
+    familyFileName?: string;
+    providerId: string;
+    modelId: string;
+    family?: string;
+    knownToolNames: readonly string[];
+    requiredMentions?: readonly string[];
+    /**
+     * Tools the proposal must give a `# tool:` section each. Defaults to
+     * `knownToolNames`: every tool that exists is a tool the template governs.
+     */
+    requiredSections?: readonly string[];
+    /** Tools that must be rewritten rather than inherited via the marker. */
+    requiredRewrites?: readonly string[];
+    /**
+     * An explicit `model:` match for a template written from scratch.
+     *
+     * Needed when the generating model is a params overlay: the overlay is
+     * scaffolding, and a match inferred from its name would claim the
+     * scaffolding instead of the family the template is for.
+     */
+    matchModel?: readonly string[];
+    /**
+     * An explicit `family:` match, for a generational split.
+     *
+     * The inferred stem truncates at the first non-alphanumeric character, so
+     * `kimi-k2` and `kimi-k3` both infer `kimi*`. Stating `kimi-k3*` is the only
+     * way to give one generation its own template.
+     */
+    matchFamily?: readonly string[];
+    /** Real call shapes: put into the prompt and used to check the result. */
+    toolSignatures?: readonly ToolCallSignature[];
+    expectedName?: string;
+    /**
+     * The name the file will be written under. A template with no `name:` in
+     * its frontmatter takes its name from here, so auditing under a different
+     * one would judge a name the file will never have.
+     */
+    fileName?: string;
+    /**
+     * Rewrite only these tool sections, splicing them into `familyTemplate`.
+     *
+     * The reason this exists is that adding one tool otherwise rewrites all ten
+     * shipped templates end to end, putting thirty untouched sections per file
+     * at risk to change one. With it, the model is asked for the named sections
+     * and the rest of the file is carried through byte for byte.
+     *
+     * The audit is not relaxed: the delta is spliced first and the *whole* file
+     * is audited second, so full tool coverage and every other whole-file rule
+     * still has to hold. Requires `familyTemplate` — there is nothing to splice
+     * a section into otherwise.
+     */
+    onlyTools?: readonly string[];
+    /**
+     * Compaction prompts to translate into `# compaction: <id>` sections, by id,
+     * with the text to translate from. Omit, or pass none, and the proposal may
+     * carry no compaction section at all.
+     *
+     * Opt-in because a wrong compaction prompt is the one template failure that
+     * cannot be noticed and undone: its answer replaces the transcript. Whole
+     * file only -- a section rewrite (`onlyTools`) cannot also ask for these.
+     */
+    compactionPrompts?: CompactionPromptSources;
+    /** Tries, including the first. Each retry hands back the problem list. */
+    attempts?: number;
+    /** One completion. Returns the reply text; throws to abort. */
+    complete: (messages: readonly {
+        role: "user" | "assistant";
+        content: string;
+    }[]) => Promise<string>;
+    /** Progress, for a UI that has somewhere to put it. */
+    onAttempt?: (attempt: number, problems: readonly string[]) => void;
+}
+export interface GeneratePromptTemplateResult {
+    /** The best proposal produced, which is not always a clean one. */
+    raw: string;
+    audit: PromptTemplateProposalAudit;
+    /** How many model calls it took. */
+    attempts: number;
+    /**
+     * The compaction sections the file carries, and the ones that were removed
+     * because they still failed the check after the last attempt. Present only
+     * when `compactionPrompts` asked for some.
+     */
+    compaction?: {
+        kept: string[];
+        removed: string[];
+        unchanged: string[];
+    };
+}
+export declare function generatePromptTemplate(args: GeneratePromptTemplateArgs): Promise<GeneratePromptTemplateResult>;
+export declare function auditExampleCalls(raw: string, signatures: readonly ToolCallSignature[]): string[];

package/dist/extensions/config/prompt-template-session.d.ts

@@ -0,0 +1,46 @@
+import type { RenderedPromptTemplate } from "@cerebriline/shared";
+import { type PromptTemplateFileWarnings, type PromptTemplateLoadError } from "./prompt-template-loader";
+/**
+ * Work out which prompt template a session is on, once, for any host.
+ *
+ * This used to live in the VS Code extension, and the CLI had no equivalent —
+ * so a local model got its family's template in the plugin and the built-in
+ * default in the CLI. That is not a cosmetic difference. `qwen.md` is the file
+ * that says "use `editor`, never `sed -i`, never `cat`"; without it a run
+ * measured 119 `run_commands` calls in one transaction, most of them `node -e`
+ * one-liners reading and rewriting the file the `editor` tool exists to edit.
+ * Two hosts that disagree about the prompt cannot be compared, and a result
+ * measured on one cannot be carried to the other.
+ *
+ * The family is a parameter rather than something resolved here: only the
+ * caller knows how to ask its provider, and the extension's lookup reports
+ * progress through the editor's UI. Everything after that point — which
+ * directories to read, which template wins, how it merges over `default.md` —
+ * is identical for every host and lives here.
+ */
+export interface SessionPromptTemplateRequest {
+    providerId: string;
+    modelId: string;
+    /** The architecture the provider reported, when it could answer. */
+    family?: string;
+    /** `<data dir>/templates`, shared across projects. */
+    globalDir?: string;
+    /** `<workspace>/.clinerules/templates`, committed with the project. */
+    workspaceDir?: string;
+    /** Tool names, so a section naming something else can be reported. */
+    knownToolNames?: readonly string[];
+}
+export interface SessionPromptTemplateResult {
+    rendered: RenderedPromptTemplate | undefined;
+    errors: PromptTemplateLoadError[];
+    warnings: PromptTemplateFileWarnings[];
+}
+export declare function resolveSessionPromptTemplateFrom(request: SessionPromptTemplateRequest): SessionPromptTemplateResult;
+/**
+ * One line naming what a session ended up on, for a host's log.
+ *
+ * Written here rather than at each call site because it is the only evidence a
+ * template was applied at all: the CLI's silence on this is exactly how it went
+ * unnoticed that it was resolving none.
+ */
+export declare function describeResolvedPromptTemplate(request: Pick<SessionPromptTemplateRequest, "modelId" | "family">, rendered: RenderedPromptTemplate | undefined): string;

package/dist/extensions/config/runtime-commands.d.ts

@@ -0,0 +1,23 @@
+import type { UserInstructionConfigWatcher } from "./user-instruction-config-loader";
+export type RuntimeCommandKind = "skill" | "workflow";
+export type AvailableRuntimeCommand = {
+    id: string;
+    name: string;
+    instructions: string;
+    description?: string;
+    kind: RuntimeCommandKind;
+};
+export declare function normalizeRuntimeCommandName(name: string): string;
+export declare function listAvailableRuntimeCommandsFromWatcher(watcher: UserInstructionConfigWatcher): AvailableRuntimeCommand[];
+export type ResolveRuntimeSlashCommandOptions = {
+    /**
+     * Whether a matched skill command is textually expanded into the prompt.
+     * Hosts pass false when the session registers the runtime's `skills`
+     * tool: the typed `/skill args` then goes through as-is and the model
+     * loads the instructions via the tool, so the persisted transcript keeps
+     * the typed command instead of the skill body. Workflows always expand —
+     * the skills tool does not serve them. Defaults to true.
+     */
+    expandSkillCommands?: boolean;
+};
+export declare function resolveRuntimeSlashCommandFromWatcher(input: string, watcher: UserInstructionConfigWatcher, options?: ResolveRuntimeSlashCommandOptions): string;

package/dist/extensions/config/shipped-tool-signatures.d.ts

@@ -0,0 +1,36 @@
+/**
+ * The call shapes of the shipped tools, for whoever is generating a template.
+ *
+ * A model asked to rewrite a prompt template writes example calls into it, and
+ * an example is copied far more readily than a schema is read — so an example
+ * with the wrong envelope does not just fail to help, it actively teaches the
+ * wrong thing to every session that template is then applied to. The generator
+ * audits examples against these signatures for exactly that reason, and it can
+ * only do that if it has them.
+ *
+ * The tools are constructed with an executor that throws, because nothing here
+ * runs them: `inputSchema` is fixed at construction and is all this needs.
+ *
+ * Host-contributed tools cannot be built here, so their schemas are restated
+ * below and guarded by a test on the host side.
+ */
+import { type ToolCallSignature } from "./prompt-template-review";
+/**
+ * The host tools' schemas, restated, because this package cannot build them.
+ *
+ * `check_file`, `ask_lsp`, `switch_to_act_mode`, `browser` and
+ * `list_files` are
+ * contributed by the VS Code extension. The review script runs here and has no way to reach them,
+ * and leaving them out would mean the audit never checked the one tool with a
+ * closed set of operations — which is precisely the tool a rewrite was
+ * observed to gut. `HOST_TOOL_NAMES` in the shipped-templates test is the same
+ * compromise for the same reason.
+ *
+ * A test in `apps/vscode` asserts these match the real schemas, so the copy
+ * cannot drift without something failing.
+ */
+export declare const HOST_TOOL_INPUT_SCHEMAS: readonly {
+    name: string;
+    inputSchema: unknown;
+}[];
+export declare function getShippedToolCallSignatures(): readonly ToolCallSignature[];

package/dist/extensions/config/skill-frontmatter-toggle.d.ts

@@ -0,0 +1,11 @@
+export interface ToggleSkillFrontmatterOptions {
+    filePath: string;
+    enabled: boolean;
+}
+export interface ToggleSkillFrontmatterResult {
+    filePath: string;
+    enabled: boolean;
+    disabled: boolean;
+}
+export declare function updateSkillMarkdownEnabledState(content: string, enabled: boolean): string;
+export declare function toggleSkillFrontmatter({ filePath, enabled, }: ToggleSkillFrontmatterOptions): Promise<ToggleSkillFrontmatterResult>;

package/dist/extensions/config/unified-config-file-watcher.d.ts

@@ -0,0 +1,77 @@
+export interface UnifiedConfigFileContext<TType extends string = string> {
+    type: TType;
+    directoryPath: string;
+    fileName: string;
+    filePath: string;
+    content: string;
+}
+export interface UnifiedConfigFileCandidate {
+    directoryPath: string;
+    fileName: string;
+    filePath: string;
+}
+export interface UnifiedConfigDefinition<TType extends string = string, TItem = unknown> {
+    type: TType;
+    directories: ReadonlyArray<string>;
+    discoverFiles?: (directoryPath: string) => Promise<ReadonlyArray<UnifiedConfigFileCandidate>>;
+    includeFile?: (fileName: string, filePath: string) => boolean;
+    parseFile: (context: UnifiedConfigFileContext<TType>) => TItem;
+    resolveId: (item: TItem, context: UnifiedConfigFileContext<TType>) => string;
+}
+export interface UnifiedConfigWatcherOptions {
+    debounceMs?: number;
+    emitParseErrors?: boolean;
+}
+export interface UnifiedConfigRecord<TType extends string = string, TItem = unknown> {
+    type: TType;
+    id: string;
+    item: TItem;
+    filePath: string;
+}
+export type UnifiedConfigWatcherEvent<TType extends string = string, TItem = unknown> = {
+    kind: "upsert";
+    record: UnifiedConfigRecord<TType, TItem>;
+} | {
+    kind: "remove";
+    type: TType;
+    id: string;
+    filePath: string;
+} | {
+    kind: "error";
+    type: TType;
+    error: unknown;
+    filePath?: string;
+};
+export declare class UnifiedConfigFileWatcher<TType extends string = string, TItem = unknown> {
+    private readonly definitions;
+    private readonly debounceMs;
+    private readonly emitParseErrors;
+    private readonly listeners;
+    private readonly recordsByType;
+    private readonly watchersByDirectory;
+    private readonly baseTypesByDirectory;
+    private watchedTypesByDirectory;
+    private readonly discoveredDirectoriesByType;
+    private readonly definitionsByType;
+    private readonly pendingTypes;
+    private flushTimer;
+    private refreshQueue;
+    private started;
+    constructor(definitions: ReadonlyArray<UnifiedConfigDefinition<TType, TItem>>, options?: UnifiedConfigWatcherOptions);
+    subscribe(listener: (event: UnifiedConfigWatcherEvent<TType, TItem>) => void): () => void;
+    start(): Promise<void>;
+    stop(): void;
+    refreshAll(): Promise<void>;
+    refreshType(type: TType): Promise<void>;
+    getSnapshot(type: TType): Map<string, UnifiedConfigRecord<TType, TItem>>;
+    getAllSnapshots(): Map<TType, Map<string, UnifiedConfigRecord<TType, TItem>>>;
+    private emit;
+    private enqueueRefresh;
+    private startDirectoryWatchers;
+    private syncDirectoryWatchers;
+    private scheduleFlush;
+    private refreshTypeInternal;
+    private loadDefinition;
+    private buildDesiredTypesByDirectory;
+    private readDirectoryFileCandidates;
+}

package/dist/extensions/config/user-instruction-config-loader.d.ts

@@ -0,0 +1,77 @@
+import { RULES_CONFIG_DIRECTORY_NAME, SKILLS_CONFIG_DIRECTORY_NAME, WORKFLOWS_CONFIG_DIRECTORY_NAME } from "@cerebriline/shared/storage";
+import { type AgentPluginPackageSkill } from "../agent-plugin";
+import { type UnifiedConfigDefinition, UnifiedConfigFileWatcher, type UnifiedConfigWatcherEvent } from "./unified-config-file-watcher";
+export { RULES_CONFIG_DIRECTORY_NAME, SKILLS_CONFIG_DIRECTORY_NAME, WORKFLOWS_CONFIG_DIRECTORY_NAME, };
+export interface ParseMarkdownFrontmatterResult {
+    data: Record<string, unknown>;
+    body: string;
+    hadFrontmatter: boolean;
+    parseError?: string;
+}
+export interface SkillConfig {
+    name: string;
+    description?: string;
+    disabled?: boolean;
+    instructions: string;
+    frontmatter: Record<string, unknown>;
+    source?: {
+        type: "agent-plugin";
+        pluginName: string;
+        pluginRoot: string;
+        skillRoot: string;
+        filePath: string;
+    };
+}
+export interface RuleConfig {
+    name: string;
+    disabled?: boolean;
+    instructions: string;
+    frontmatter: Record<string, unknown>;
+}
+export interface WorkflowConfig {
+    name: string;
+    disabled?: boolean;
+    description?: string;
+    instructions: string;
+    frontmatter: Record<string, unknown>;
+}
+export type UserInstructionConfigType = "skill" | "rule" | "workflow";
+export type UserInstructionConfig = SkillConfig | RuleConfig | WorkflowConfig;
+export type UserInstructionConfigWatcher = UnifiedConfigFileWatcher<UserInstructionConfigType, UserInstructionConfig>;
+export type UserInstructionConfigWatcherEvent = UnifiedConfigWatcherEvent<UserInstructionConfigType, UserInstructionConfig>;
+export interface CreateInstructionWatcherOptions {
+    debounceMs?: number;
+    emitParseErrors?: boolean;
+}
+export interface CreateSkillsConfigDefinitionOptions {
+    directories?: ReadonlyArray<string>;
+    workspacePath?: string;
+    includePluginSkills?: boolean;
+    pluginSkillDirectories?: ReadonlyArray<string>;
+    agentPluginSkills?: ReadonlyArray<AgentPluginPackageSkill>;
+    pluginPaths?: ReadonlyArray<string>;
+    cwd?: string;
+}
+export interface CreateRulesConfigDefinitionOptions {
+    directories?: ReadonlyArray<string>;
+    workspacePath?: string;
+}
+export interface CreateWorkflowsConfigDefinitionOptions {
+    directories?: ReadonlyArray<string>;
+    workspacePath?: string;
+}
+export declare function parseSkillConfigFromMarkdown(content: string, fallbackName: string): SkillConfig;
+export declare function parseRuleConfigFromMarkdown(content: string, fallbackName: string): RuleConfig;
+export declare function parseWorkflowConfigFromMarkdown(content: string, fallbackName: string): WorkflowConfig;
+export declare function resolveSkillsConfigSearchPaths(workspacePath?: string): string[];
+export declare function resolveRulesConfigSearchPaths(workspacePath?: string): string[];
+export declare function resolveWorkflowsConfigSearchPaths(workspacePath?: string): string[];
+export declare function createSkillsConfigDefinition(options?: CreateSkillsConfigDefinitionOptions): UnifiedConfigDefinition<"skill", SkillConfig>;
+export declare function createRulesConfigDefinition(options?: CreateRulesConfigDefinitionOptions): UnifiedConfigDefinition<"rule", RuleConfig>;
+export declare function createWorkflowsConfigDefinition(options?: CreateWorkflowsConfigDefinitionOptions): UnifiedConfigDefinition<"workflow", WorkflowConfig>;
+export interface CreateUserInstructionConfigWatcherOptions extends CreateInstructionWatcherOptions {
+    skills?: CreateSkillsConfigDefinitionOptions;
+    rules?: CreateRulesConfigDefinitionOptions;
+    workflows?: CreateWorkflowsConfigDefinitionOptions;
+}
+export declare function createUserInstructionConfigWatcher(options?: CreateUserInstructionConfigWatcherOptions): UserInstructionConfigWatcher;

package/dist/extensions/config/user-instruction-plugin.d.ts

@@ -0,0 +1,26 @@
+import type { AgentExtension } from "@cerebriline/shared";
+import { type SkillsExecutorWithMetadata } from "../tools";
+import type { SkillConfig, UserInstructionConfigWatcher } from "./user-instruction-config-loader";
+type SkillsExecutorMetadataItem = {
+    id: string;
+    name: string;
+    description?: string;
+    disabled: boolean;
+};
+type ConfiguredSkill = SkillsExecutorMetadataItem & {
+    skill: SkillConfig;
+};
+export declare function formatSkillInvocation(skill: Pick<SkillConfig, "name" | "description" | "instructions" | "source">, args?: string): string;
+export interface CreateUserInstructionPluginOptions {
+    watcher: UserInstructionConfigWatcher;
+    watcherReady?: Promise<void>;
+    includeRules?: boolean;
+    includeSkills?: boolean;
+    includeWorkflows?: boolean;
+    registerSkillsTool?: boolean;
+    allowedSkillNames?: ReadonlyArray<string>;
+}
+export declare function getConfiguredSkillsFromWatcher(watcher: UserInstructionConfigWatcher, allowedSkillNames?: ReadonlyArray<string>): ConfiguredSkill[];
+export declare function createUserInstructionSkillsExecutor(watcher: UserInstructionConfigWatcher, watcherReady?: Promise<void>, allowedSkillNames?: ReadonlyArray<string>): SkillsExecutorWithMetadata;
+export declare function createUserInstructionPlugin(options: CreateUserInstructionPluginOptions): AgentExtension;
+export {};