@slowcook-ai/cli 0.13.0 → 0.14.0-alpha.5

package/dist/commands/investigate/prompts.d.ts

@@ -1,90 +1,10 @@
 /**
- * Prompts for the `slowcook investigate` agent.
- *
- * The investigate agent is the bug-flow analogue of refine. Where
- * refine asks PM clarifying questions, investigate reads code to
- * find the failure locus. The two roles are mirror images:
- *
- *   refine          investigate
- *   ──────          ───────────
- *   "what to build" "what's broken"
- *   text-only       code-reading
- *   2-3 questions   0-1 questions (only on truly ambiguous symptoms)
- *   spec.yaml       bug-profile.yaml
- *
- * The system prompt below names the role explicitly so the LLM
- * doesn't drift back into refine-style behaviour (asking design
- * questions about a 1-line column rename, etc.).
+ * Re-export shim — the actual prompt strings + tool defs live in
+ * `@slowcook-ai/llm-anthropic` as of 0.13.1 (per the llm-agnosticism
+ * refactor). Kept as a passthrough so internal imports
+ * (`from "./prompts.js"`) keep working without touching every agent
+ * file. A future GPT / Gemini adapter package would publish drop-in
+ * replacements with the same exported names.
  */
-export declare const INVESTIGATE_SYSTEM = "You are the investigate agent for slowcook \u2014 a TDD-first agentic development harness with a bug-fix flow.\n\n## Your role\n\nYou receive a GitHub issue describing a bug. Your job: read the codebase, identify the failure locus (file, line, function) and the actual root cause, and emit a structured `bug-profile.yaml` that the next agent (sift) will use as its contract.\n\nYou are NOT refine. Refine asks PM clarifying questions and emits design specs. You investigate failed reality. Different posture, different tools, different output.\n\n## Posture\n\n- **Read the code.** The issue body tells you the symptom. The codebase tells you the cause. You have read tools \u2014 use them. A diagnosis built from issue text alone is hand-wavy; a diagnosis built from `outline_file(actual-route.ts)` + `find_references(broken-symbol)` + `grep -r 'thing_X'` is honest.\n- **Don't paraphrase the symptom.** The PM's words in the issue body are the authoritative description of what's broken from the user's perspective. Copy the symptom verbatim where you can; mild paraphrase is OK only when the issue body is unstructured prose. (See slowcook memory: \"PM intent carries weight\" \u2014 you cannot silently weaken it.)\n- **Don't suggest a fix.** Your output names the failure locus + the regression assertion. The actual code change is sift's job. If you find yourself writing \"and the fix should rename X to Y\", stop \u2014 that's beyond your scope.\n- **Ask only when truly stuck.** Most bugs have a single failure locus discoverable from one or two reads. If after reading the obvious files you can't find the failure mode, ask one focused clarifying question on the issue. Do NOT ask multiple rounds of questions like refine does.\n\n## Critical: read the code, NOT just the issue body\n\nIssue bodies often contain BOTH the symptom *and* the reporter's proposed fix (\"Expected fix: ...\"). The proposed fix is a hypothesis \u2014 it has not been verified or applied to the codebase. Your diagnosis must be based on **what the code actually contains right now**, not on what the issue says it should contain.\n\nConcrete rule: before claiming \"X is fixed\" or \"Y now does Z\", read X or Y with a tool. If the issue body describes a fix and you find the code in its pre-fix state, the bug is still active and you investigate it. If the code already contains the fix, the bug is closed and your profile should say so explicitly (`status: closed` is not in the v1 schema, but the diagnosis can name the resolution and the failure_locus.diagnosis can read \"bug already fixed in <commit/PR>\").\n\n## Output\n\nA single `bug-profile.yaml` document with these fields:\n\n```yaml\nschema_version: 1\nbug_id: B-<n>          # filled in by slowcook, you don't pick this\ntitle: \"<one-line bug title>\"\nsource_issue: \"#<NNN>\" # the issue you investigated\nstatus: investigated\ninvestigated_by: slowcook-investigate@<version>\ncreated_at: <ISO-8601 UTC>\n\nsymptom:\n  - \"<verbatim or near-verbatim from issue body \u2014 what the user sees>\"\n\nexpected:\n  - \"<what should happen instead \u2014 from issue body or implicit>\"\n\nreproduction:\n  - \"<minimum step 1>\"\n  - \"<minimum step 2>\"\n\nfailure_locus:\n  file: \"src/path/to/broken-file.ts\"\n  line: 42                  # optional; omit if not pinpointable\n  function: handlerName     # optional\n  diagnosis: |\n    <One paragraph: why is the bug happening? Be specific. Reference\n    the read evidence: \"src/foo.ts:42 selects column 'bar' but no\n    migration adds 'bar' (verified: grep returns 0 hits)\".>\n\nregression_assertion:\n  - \"Given <repro context>, when <action>, then <correct behavior>\"\n  - \"(may be multiple if the bug has compound effects)\"\n\nfix_scope:\n  - \"src/path/to/broken-file.ts\"\n  - \"supabase/migrations/\"   # for example, when the fix needs DDL\n\nrelated_specs:               # optional, omit if none\n  - id: \"story-007\"\n    relationship: touches\n    note: \"/api/X is owned by story-007's spec; check that contract\"\n```\n\n**Output format is strict.** Wrap the YAML in a single `<bug_profile>...</bug_profile>` XML block. The slowcook parser greps for the literal opening + closing tags; any output without those exact tags fails parsing and the run errors out.\n\nConcrete example of the expected final-message format:\n\n```\n<bug_profile>\nschema_version: 1\ntitle: \"<one-line bug title>\"\nsource_issue: \"#135\"\nstatus: investigated\ninvestigated_by: \"(slowcook stamps this)\"\ncreated_at: \"(slowcook stamps this)\"\n\nsymptom:\n  - \"Verbatim user-visible failure mode.\"\n\nexpected:\n  - \"What should happen instead.\"\n\nreproduction:\n  - \"Step 1.\"\n\nfailure_locus:\n  file: \"src/path/to/broken.ts\"\n  line: 42\n  function: \"handler\"\n  diagnosis: |\n    One paragraph naming the actual cause, citing read evidence\n    (e.g., 'src/foo.ts:42 selects column bar but no migration adds\n    bar \u2014 verified via grep').\n\nregression_assertion:\n  - \"Given <repro context>, when <action>, then <correct behavior>.\"\n\nfix_scope:\n  - \"src/path/to/broken.ts\"\n</bug_profile>\n```\n\nIf you have one preliminary thought to share, put it BEFORE the `<bug_profile>` block \u2014 but the parser only reads what's inside the tags. Anything outside is ignored.\n\nIf you cannot find a single failure locus from reading the obvious files, emit a `<halt>` block with a one-line description of what you couldn't disambiguate. Do not emit prose explaining your confusion \u2014 the slowcook parser doesn't read prose. `<halt>` is the structured way to ask for help.\n\n## Tools\n\nYou have read tools (read_file, outline_file, find_references, find_definition, grep, list_directory) \u2014 exactly the same ones brew uses for pre-write discovery. You do NOT have write_file: investigate doesn't write code, only diagnoses.\n\n## When to halt voluntarily\n\nIf after reading the issue body and the obvious files (mirrored path from issue mentions, fetch URLs, table names, etc.) you cannot identify a single failure locus, halt by emitting a `<halt>` block with a one-line description of what you couldn't disambiguate. Slowcook will surface this to the operator who will either edit the issue with more context or take the bug out of investigate flow. **Don't guess** \u2014 a wrong bug profile costs sift more than a clean halt costs the operator's time.\n";
-/**
- * Tool definitions the investigate agent has access to. Mirrors the
- * brew read-only subset (no write_file): investigate diagnoses, sift
- * fixes.
- *
- * Kept minimal in alpha.2a — alpha.2b wires the actual ts-morph
- * implementations from brew/retrieval.ts.
- */
-export declare const INVESTIGATE_TOOLS: ({
-    name: string;
-    description: string;
-    input_schema: {
-        type: "object";
-        properties: {
-            path: {
-                type: "string";
-                description: string;
-            };
-            symbol?: undefined;
-            pattern?: undefined;
-            glob?: undefined;
-        };
-        required: string[];
-    };
-} | {
-    name: string;
-    description: string;
-    input_schema: {
-        type: "object";
-        properties: {
-            symbol: {
-                type: "string";
-                description: string;
-            };
-            path?: undefined;
-            pattern?: undefined;
-            glob?: undefined;
-        };
-        required: string[];
-    };
-} | {
-    name: string;
-    description: string;
-    input_schema: {
-        type: "object";
-        properties: {
-            pattern: {
-                type: "string";
-                description: string;
-            };
-            glob: {
-                type: "string";
-                description: string;
-            };
-            path?: undefined;
-            symbol?: undefined;
-        };
-        required: string[];
-    };
-})[];
-/**
- * Build the per-issue user message. The issue body becomes the
- * agent's primary input; it tools its way out from there.
- */
-export declare function buildInvestigateUserPrompt(args: {
-    issueNumber: number;
-    issueTitle: string;
-    issueBody: string;
-    prior_comments?: string[];
-}): string;
+export { INVESTIGATE_SYSTEM, INVESTIGATE_TOOLS, buildInvestigateUserPrompt, } from "@slowcook-ai/llm-anthropic";
 //# sourceMappingURL=prompts.d.ts.map

package/dist/commands/investigate/prompts.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../src/commands/investigate/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,eAAO,MAAM,kBAAkB,iwMAqH9B,CAAC;AAEF;;;;;;;GAOG;AACH,eAAO,MAAM,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;IAsE7B,CAAC;AAEF;;;GAGG;AACH,wBAAgB,0BAA0B,CAAC,IAAI,EAAE;IAC/C,WAAW,EAAE,MAAM,CAAC;IACpB,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,cAAc,CAAC,EAAE,MAAM,EAAE,CAAC;CAC3B,GAAG,MAAM,CAsBT"}
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../src/commands/investigate/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,EACL,kBAAkB,EAClB,iBAAiB,EACjB,0BAA0B,GAC3B,MAAM,4BAA4B,CAAC"}

package/dist/commands/investigate/prompts.js

@@ -1,237 +1,10 @@
 /**
- * Prompts for the `slowcook investigate` agent.
- *
- * The investigate agent is the bug-flow analogue of refine. Where
- * refine asks PM clarifying questions, investigate reads code to
- * find the failure locus. The two roles are mirror images:
- *
- *   refine          investigate
- *   ──────          ───────────
- *   "what to build" "what's broken"
- *   text-only       code-reading
- *   2-3 questions   0-1 questions (only on truly ambiguous symptoms)
- *   spec.yaml       bug-profile.yaml
- *
- * The system prompt below names the role explicitly so the LLM
- * doesn't drift back into refine-style behaviour (asking design
- * questions about a 1-line column rename, etc.).
+ * Re-export shim — the actual prompt strings + tool defs live in
+ * `@slowcook-ai/llm-anthropic` as of 0.13.1 (per the llm-agnosticism
+ * refactor). Kept as a passthrough so internal imports
+ * (`from "./prompts.js"`) keep working without touching every agent
+ * file. A future GPT / Gemini adapter package would publish drop-in
+ * replacements with the same exported names.
  */
-export const INVESTIGATE_SYSTEM = `You are the investigate agent for slowcook — a TDD-first agentic development harness with a bug-fix flow.
-
-## Your role
-
-You receive a GitHub issue describing a bug. Your job: read the codebase, identify the failure locus (file, line, function) and the actual root cause, and emit a structured \`bug-profile.yaml\` that the next agent (sift) will use as its contract.
-
-You are NOT refine. Refine asks PM clarifying questions and emits design specs. You investigate failed reality. Different posture, different tools, different output.
-
-## Posture
-
-- **Read the code.** The issue body tells you the symptom. The codebase tells you the cause. You have read tools — use them. A diagnosis built from issue text alone is hand-wavy; a diagnosis built from \`outline_file(actual-route.ts)\` + \`find_references(broken-symbol)\` + \`grep -r 'thing_X'\` is honest.
-- **Don't paraphrase the symptom.** The PM's words in the issue body are the authoritative description of what's broken from the user's perspective. Copy the symptom verbatim where you can; mild paraphrase is OK only when the issue body is unstructured prose. (See slowcook memory: "PM intent carries weight" — you cannot silently weaken it.)
-- **Don't suggest a fix.** Your output names the failure locus + the regression assertion. The actual code change is sift's job. If you find yourself writing "and the fix should rename X to Y", stop — that's beyond your scope.
-- **Ask only when truly stuck.** Most bugs have a single failure locus discoverable from one or two reads. If after reading the obvious files you can't find the failure mode, ask one focused clarifying question on the issue. Do NOT ask multiple rounds of questions like refine does.
-
-## Critical: read the code, NOT just the issue body
-
-Issue bodies often contain BOTH the symptom *and* the reporter's proposed fix ("Expected fix: ..."). The proposed fix is a hypothesis — it has not been verified or applied to the codebase. Your diagnosis must be based on **what the code actually contains right now**, not on what the issue says it should contain.
-
-Concrete rule: before claiming "X is fixed" or "Y now does Z", read X or Y with a tool. If the issue body describes a fix and you find the code in its pre-fix state, the bug is still active and you investigate it. If the code already contains the fix, the bug is closed and your profile should say so explicitly (\`status: closed\` is not in the v1 schema, but the diagnosis can name the resolution and the failure_locus.diagnosis can read "bug already fixed in <commit/PR>").
-
-## Output
-
-A single \`bug-profile.yaml\` document with these fields:
-
-\`\`\`yaml
-schema_version: 1
-bug_id: B-<n>          # filled in by slowcook, you don't pick this
-title: "<one-line bug title>"
-source_issue: "#<NNN>" # the issue you investigated
-status: investigated
-investigated_by: slowcook-investigate@<version>
-created_at: <ISO-8601 UTC>
-
-symptom:
-  - "<verbatim or near-verbatim from issue body — what the user sees>"
-
-expected:
-  - "<what should happen instead — from issue body or implicit>"
-
-reproduction:
-  - "<minimum step 1>"
-  - "<minimum step 2>"
-
-failure_locus:
-  file: "src/path/to/broken-file.ts"
-  line: 42                  # optional; omit if not pinpointable
-  function: handlerName     # optional
-  diagnosis: |
-    <One paragraph: why is the bug happening? Be specific. Reference
-    the read evidence: "src/foo.ts:42 selects column 'bar' but no
-    migration adds 'bar' (verified: grep returns 0 hits)".>
-
-regression_assertion:
-  - "Given <repro context>, when <action>, then <correct behavior>"
-  - "(may be multiple if the bug has compound effects)"
-
-fix_scope:
-  - "src/path/to/broken-file.ts"
-  - "supabase/migrations/"   # for example, when the fix needs DDL
-
-related_specs:               # optional, omit if none
-  - id: "story-007"
-    relationship: touches
-    note: "/api/X is owned by story-007's spec; check that contract"
-\`\`\`
-
-**Output format is strict.** Wrap the YAML in a single \`<bug_profile>...</bug_profile>\` XML block. The slowcook parser greps for the literal opening + closing tags; any output without those exact tags fails parsing and the run errors out.
-
-Concrete example of the expected final-message format:
-
-\`\`\`
-<bug_profile>
-schema_version: 1
-title: "<one-line bug title>"
-source_issue: "#135"
-status: investigated
-investigated_by: "(slowcook stamps this)"
-created_at: "(slowcook stamps this)"
-
-symptom:
-  - "Verbatim user-visible failure mode."
-
-expected:
-  - "What should happen instead."
-
-reproduction:
-  - "Step 1."
-
-failure_locus:
-  file: "src/path/to/broken.ts"
-  line: 42
-  function: "handler"
-  diagnosis: |
-    One paragraph naming the actual cause, citing read evidence
-    (e.g., 'src/foo.ts:42 selects column bar but no migration adds
-    bar — verified via grep').
-
-regression_assertion:
-  - "Given <repro context>, when <action>, then <correct behavior>."
-
-fix_scope:
-  - "src/path/to/broken.ts"
-</bug_profile>
-\`\`\`
-
-If you have one preliminary thought to share, put it BEFORE the \`<bug_profile>\` block — but the parser only reads what's inside the tags. Anything outside is ignored.
-
-If you cannot find a single failure locus from reading the obvious files, emit a \`<halt>\` block with a one-line description of what you couldn't disambiguate. Do not emit prose explaining your confusion — the slowcook parser doesn't read prose. \`<halt>\` is the structured way to ask for help.
-
-## Tools
-
-You have read tools (read_file, outline_file, find_references, find_definition, grep, list_directory) — exactly the same ones brew uses for pre-write discovery. You do NOT have write_file: investigate doesn't write code, only diagnoses.
-
-## When to halt voluntarily
-
-If after reading the issue body and the obvious files (mirrored path from issue mentions, fetch URLs, table names, etc.) you cannot identify a single failure locus, halt by emitting a \`<halt>\` block with a one-line description of what you couldn't disambiguate. Slowcook will surface this to the operator who will either edit the issue with more context or take the bug out of investigate flow. **Don't guess** — a wrong bug profile costs sift more than a clean halt costs the operator's time.
-`;
-/**
- * Tool definitions the investigate agent has access to. Mirrors the
- * brew read-only subset (no write_file): investigate diagnoses, sift
- * fixes.
- *
- * Kept minimal in alpha.2a — alpha.2b wires the actual ts-morph
- * implementations from brew/retrieval.ts.
- */
-export const INVESTIGATE_TOOLS = [
-    {
-        name: "read_file",
-        description: "Read a file's full contents. Use sparingly — outline_file is cheaper for initial scoping.",
-        input_schema: {
-            type: "object",
-            properties: {
-                path: { type: "string", description: "Repo-relative path." },
-            },
-            required: ["path"],
-        },
-    },
-    {
-        name: "outline_file",
-        description: "Compact ~200-token outline of a TS/TSX file: imports, top-level exports, signatures with line numbers. Use this first to decide whether a file is relevant.",
-        input_schema: {
-            type: "object",
-            properties: {
-                path: { type: "string", description: "Repo-relative path." },
-            },
-            required: ["path"],
-        },
-    },
-    {
-        name: "list_directory",
-        description: "List entries in a directory.",
-        input_schema: {
-            type: "object",
-            properties: {
-                path: { type: "string", description: "Repo-relative path." },
-            },
-            required: ["path"],
-        },
-    },
-    {
-        name: "find_references",
-        description: "Find all references to a symbol across the repo (definitions + use sites). Returns file:line entries.",
-        input_schema: {
-            type: "object",
-            properties: {
-                symbol: {
-                    type: "string",
-                    description: "Identifier name to search for.",
-                },
-            },
-            required: ["symbol"],
-        },
-    },
-    {
-        name: "grep",
-        description: "Repo-wide ripgrep for a literal or regex string. Use when find_references is too narrow (e.g. searching column names in SQL files).",
-        input_schema: {
-            type: "object",
-            properties: {
-                pattern: {
-                    type: "string",
-                    description: "Pattern to search.",
-                },
-                glob: {
-                    type: "string",
-                    description: "Optional glob restriction (e.g. 'supabase/migrations/*.sql').",
-                },
-            },
-            required: ["pattern"],
-        },
-    },
-];
-/**
- * Build the per-issue user message. The issue body becomes the
- * agent's primary input; it tools its way out from there.
- */
-export function buildInvestigateUserPrompt(args) {
-    const lines = [];
-    lines.push(`# Investigate bug — issue #${args.issueNumber}`);
-    lines.push("");
-    lines.push(`## Title`);
-    lines.push(args.issueTitle);
-    lines.push("");
-    lines.push(`## Issue body`);
-    lines.push(args.issueBody);
-    if (args.prior_comments && args.prior_comments.length > 0) {
-        lines.push("");
-        lines.push(`## Prior comments (in chronological order)`);
-        for (const c of args.prior_comments) {
-            lines.push("---");
-            lines.push(c);
-        }
-    }
-    lines.push("");
-    lines.push(`## Your task\n\nInvestigate. Identify the failure locus + diagnosis. Emit a single \`<bug_profile>\` block following the system-prompt schema.`);
-    return lines.join("\n");
-}
+export { INVESTIGATE_SYSTEM, INVESTIGATE_TOOLS, buildInvestigateUserPrompt, } from "@slowcook-ai/llm-anthropic";
 //# sourceMappingURL=prompts.js.map

package/dist/commands/investigate/prompts.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../../src/commands/investigate/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqHjC,CAAC;AAEF;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B;QACE,IAAI,EAAE,WAAW;QACjB,WAAW,EACT,2FAA2F;QAC7F,YAAY,EAAE;YACZ,IAAI,EAAE,QAAiB;YACvB,UAAU,EAAE;gBACV,IAAI,EAAE,EAAE,IAAI,EAAE,QAAiB,EAAE,WAAW,EAAE,qBAAqB,EAAE;aACtE;YACD,QAAQ,EAAE,CAAC,MAAM,CAAC;SACnB;KACF;IACD;QACE,IAAI,EAAE,cAAc;QACpB,WAAW,EACT,6JAA6J;QAC/J,YAAY,EAAE;YACZ,IAAI,EAAE,QAAiB;YACvB,UAAU,EAAE;gBACV,IAAI,EAAE,EAAE,IAAI,EAAE,QAAiB,EAAE,WAAW,EAAE,qBAAqB,EAAE;aACtE;YACD,QAAQ,EAAE,CAAC,MAAM,CAAC;SACnB;KACF;IACD;QACE,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,8BAA8B;QAC3C,YAAY,EAAE;YACZ,IAAI,EAAE,QAAiB;YACvB,UAAU,EAAE;gBACV,IAAI,EAAE,EAAE,IAAI,EAAE,QAAiB,EAAE,WAAW,EAAE,qBAAqB,EAAE;aACtE;YACD,QAAQ,EAAE,CAAC,MAAM,CAAC;SACnB;KACF;IACD;QACE,IAAI,EAAE,iBAAiB;QACvB,WAAW,EACT,uGAAuG;QACzG,YAAY,EAAE;YACZ,IAAI,EAAE,QAAiB;YACvB,UAAU,EAAE;gBACV,MAAM,EAAE;oBACN,IAAI,EAAE,QAAiB;oBACvB,WAAW,EAAE,gCAAgC;iBAC9C;aACF;YACD,QAAQ,EAAE,CAAC,QAAQ,CAAC;SACrB;KACF;IACD;QACE,IAAI,EAAE,MAAM;QACZ,WAAW,EACT,qIAAqI;QACvI,YAAY,EAAE;YACZ,IAAI,EAAE,QAAiB;YACvB,UAAU,EAAE;gBACV,OAAO,EAAE;oBACP,IAAI,EAAE,QAAiB;oBACvB,WAAW,EAAE,oBAAoB;iBAClC;gBACD,IAAI,EAAE;oBACJ,IAAI,EAAE,QAAiB;oBACvB,WAAW,EAAE,+DAA+D;iBAC7E;aACF;YACD,QAAQ,EAAE,CAAC,SAAS,CAAC;SACtB;KACF;CACF,CAAC;AAEF;;;GAGG;AACH,MAAM,UAAU,0BAA0B,CAAC,IAK1C;IACC,MAAM,KAAK,GAAa,EAAE,CAAC;IAC3B,KAAK,CAAC,IAAI,CAAC,8BAA8B,IAAI,CAAC,WAAW,EAAE,CAAC,CAAC;IAC7D,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACf,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;IACvB,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;IAC5B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACf,KAAK,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;IAC5B,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;IAC3B,IAAI,IAAI,CAAC,cAAc,IAAI,IAAI,CAAC,cAAc,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC1D,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,4CAA4C,CAAC,CAAC;QACzD,KAAK,MAAM,CAAC,IAAI,IAAI,CAAC,cAAc,EAAE,CAAC;YACpC,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;YAClB,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAChB,CAAC;IACH,CAAC;IACD,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACf,KAAK,CAAC,IAAI,CACR,gJAAgJ,CACjJ,CAAC;IACF,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC1B,CAAC"}
+{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../../src/commands/investigate/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,EACL,kBAAkB,EAClB,iBAAiB,EACjB,0BAA0B,GAC3B,MAAM,4BAA4B,CAAC"}

package/dist/commands/map/emit-tokens.d.ts

@@ -0,0 +1,53 @@
+/**
+ * 0.13.3 (brownfield-extraction track for 0.14 mockup-first refinement) —
+ * walk `**\/*.css` files (excluding build output) and extract design tokens
+ * declared via `:root { --var: value }` and `@theme { --var: value }` blocks.
+ *
+ * Supports the Tailwind v4 idiom (inline `@theme`) and classic CSS-vars
+ * theming. Light/dark variants captured separately when `:root` lives
+ * inside `@media (prefers-color-scheme: dark)`.
+ *
+ * Output: `.brewing/diagrams/tokens.md` — refine reads this so its
+ * mockup proposals reuse the consumer's existing palette / scale rather
+ * than inventing arbitrary hex values.
+ */
+export interface TokenEntry {
+    name: string;
+    value: string;
+    variant: "light" | "dark";
+    source: string;
+}
+export interface TokenCatalog {
+    light: TokenEntry[];
+    dark: TokenEntry[];
+    themeMappings: TokenEntry[];
+    filesScanned: number;
+}
+/**
+ * Parse a CSS file's :root and @theme blocks into TokenEntry rows.
+ *
+ * Strategy: walk top-level by tracking brace depth + remembering the
+ * last selector / at-rule prefix. We need only enough to distinguish:
+ *   - `:root { ... }` at depth 0 → light variant
+ *   - `:root { ... }` inside `@media (prefers-color-scheme: dark)` → dark
+ *   - `@theme { ... }` → theme mappings (Tailwind v4)
+ *
+ * We are not building a full CSS AST; the regex+brace pass is enough
+ * for the conventional vars-in-:root pattern and degrades gracefully
+ * on weird input by emitting fewer rows.
+ */
+export declare function parseCssTokens(content: string, sourceLabel: string): {
+    light: TokenEntry[];
+    dark: TokenEntry[];
+    themeMappings: TokenEntry[];
+};
+export declare function emitTokensCatalog(repoRoot: string): {
+    written: boolean;
+    filesScanned: number;
+    lightCount?: number;
+    darkCount?: number;
+    themeCount?: number;
+    skippedReason?: string;
+};
+export declare function renderTokensMarkdown(catalog: TokenCatalog): string;
+//# sourceMappingURL=emit-tokens.d.ts.map

package/dist/commands/map/emit-tokens.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"emit-tokens.d.ts","sourceRoot":"","sources":["../../../src/commands/map/emit-tokens.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;GAYG;AAEH,MAAM,WAAW,UAAU;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,OAAO,GAAG,MAAM,CAAC;IAC1B,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,YAAY;IAC3B,KAAK,EAAE,UAAU,EAAE,CAAC;IACpB,IAAI,EAAE,UAAU,EAAE,CAAC;IACnB,aAAa,EAAE,UAAU,EAAE,CAAC;IAC5B,YAAY,EAAE,MAAM,CAAC;CACtB;AA0CD;;;;;;;;;;;;GAYG;AACH,wBAAgB,cAAc,CAC5B,OAAO,EAAE,MAAM,EACf,WAAW,EAAE,MAAM,GAClB;IAAE,KAAK,EAAE,UAAU,EAAE,CAAC;IAAC,IAAI,EAAE,UAAU,EAAE,CAAC;IAAC,aAAa,EAAE,UAAU,EAAE,CAAA;CAAE,CAsE1E;AAkGD,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,MAAM,GAAG;IACnD,OAAO,EAAE,OAAO,CAAC;IACjB,YAAY,EAAE,MAAM,CAAC;IACrB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,aAAa,CAAC,EAAE,MAAM,CAAC;CACxB,CAoDA;AAED,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,YAAY,GAAG,MAAM,CAmDlE"}