@seanmars/tospec 0.8.0 → 0.10.0

package/dist/core/templates/workflows/apply.js

@@ -1,32 +1,50 @@
 import { VERIFY_METHODOLOGY } from './verify.js';
-// -----------------------------------------------------------------------------
-// Default apply — implement first, cover with tests after (no strict TDD loop)
-// -----------------------------------------------------------------------------
-const APPLY_BODY = `**Steps**
+// ponytail: one parameterized template literal, not a template engine.
+function buildApplyBody(v) {
+    return `**Task tracking is file-based only.** The tracks file's checkboxes (\`- [ ]\` / \`- [x]\`) are the single source of truth for progress. Never use a built-in todo or task-tracking tool — editing the checkbox in the file is the only way progress gets recorded.
+
+**Steps**
+
+1. **Select the change**
 
-1. **Confirm planning is done**
+   If the user named one, use it. Otherwise infer it from the conversation. If it is still ambiguous, run \`tospec list --json\` and let the user pick with \`AskUserQuestion\` — never guess.
+
+   Announce \`Using change: <name>\` and how to override.
+
+2. **Get apply instructions**
    \`\`\`bash
-   tospec status --change "<name>" --json
+   tospec instructions apply --change "<name>" --json
    \`\`\`
-   Every artifact in \`applyRequires\` must be \`done\` before you write any code. If one isn't, stop and send the user back to \`tospec-propose\` or \`tospec-issue\`. Note \`schemaName\` — it decides which branch below applies.
+   One call gives you the gate and the briefing: \`schemaName\` (decides which branch below applies), \`contextFiles\` (artifact id -> concrete paths), \`progress\`, \`tasks\`, and a dynamic \`instruction\`.
 
-2. **Work the tracks file one item at a time**
+   Act on \`state\`:
+   - \`blocked\` — required artifacts or the tracks file are missing; show \`instruction\` and STOP, sending the user back to \`tospec-propose\`/\`tospec-issue\`.
+   - \`all_done\` — everything is checked off already; skip to the verify step below.
+   - \`ready\` — proceed.
 
-   The tracks file is \`tasks.md\` (sdd) or \`task.md\` (issue). Take the next unchecked item, implement it, confirm it works against its specs, check it off (\`- [ ]\` → \`- [x]\`), then move to the next. Never batch multiple items into one pass.
+3. **Read the context files**
 
-### sdd branch — implement per slice
+   Read every path listed under \`contextFiles\` before writing any code. Take the ids and paths from the CLI output — never assume filenames.
 
-For each tracer-bullet slice in \`tasks.md\`:
-1. Implement the minimum that satisfies the behavior the slice's specs describe. Don't anticipate future slices or add speculative flexibility.
-2. Cover the new behavior with a test **at the seam \`design.md\` named** — written after the code works (test-after; no red-first requirement). Don't test internals or add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface).
-3. Verify the result matches the behavior the slice's specs describe and its test is green.
-4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.
+4. **Show current progress**
+
+   Schema in use, \`N/M tasks complete\`, the remaining items, and the CLI's \`instruction\`.
+
+5. **Work the tracks file one item at a time**
+
+   The tracks file is \`tasks.md\` (sdd) or \`task.md\` (issue). ${v.step2Intro} Never batch multiple items into one pass.
+
+   Before starting an item, re-read the parts of design/specs that cover its scope — don't rely on memory from earlier in the conversation, context may have been compressed since.
+
+   Before checking an item off, re-read its description and confirm every part of it is covered by your changes and the behavior it describes actually works. An item checked off half-finished is the most expensive mistake in this loop.
 
-### issue branch — fix root cause
+   **Pause if** the item is unclear, implementation reveals a design issue (suggest \`tospec-update\`), or you hit an error or blocker — report it and wait for guidance. Don't guess.
 
-Read \`task.md\`'s feedback loop, then fix the root cause, not the symptom — if the same defect is reachable through multiple callers of a shared function, the fix belongs in the shared function, not patched into just the caller the ticket named (grep every caller of the function you're touching). Cover the bug with the regression test from \`task.md\`'s feedback loop so it can't come back — extend the existing test if there's one at the right seam, otherwise add a new one.
+${v.sddBranch}
 
-3. **Re-validate artifacts**
+${v.issueBranch}
+
+6. **Re-validate artifacts**
    \`\`\`bash
    tospec validate "<name>" --json
    \`\`\`
@@ -43,35 +61,61 @@ ${VERIFY_METHODOLOGY}
 Report which tasks/checkboxes completed this pass, current progress (\`tospec status --change "<name>"\`), and whether all required artifacts are checked off. When everything is done, the verify review above has already run — if it came back clean, tell the user the change is ready for \`tospec-archive\`; if it surfaced blocking findings, keep working here to resolve them.
 
 **Guardrails**
-- One slice/task at a time — no batching
-- Every change ships with a test that covers its behavior (test-after is fine here — no red-before-green requirement)
-- Test only at the pre-agreed seam (design.md for sdd; the existing/new seam identified for issue) — never against internals
+${v.guardrailsHead}
+- Keep going through items until done or blocked; pause on errors, blockers, or unclear requirements — don't guess
+- Read the context files before starting, and use the paths from \`tospec instructions apply\` — don't assume filenames
+- Check the box in the tracks file immediately after finishing each item; no external task tracker
+- Keep code changes minimal and scoped to the item at hand
+- Any test you do write goes at the pre-agreed seam (design.md for sdd; the existing/new seam identified for issue) — never against internals
 - Fix root cause: check every caller of a shared function before declaring a fix complete
 - Don't hand off to archive until the automatic verify step is clean and the full test suite is green`;
+}
+// -----------------------------------------------------------------------------
+// Default apply — implement per slice; tests are optional, not mandated
+// -----------------------------------------------------------------------------
+const APPLY_BODY = buildApplyBody({
+    step2Intro: 'Take the next unchecked item, implement it, confirm it works against its specs, check it off (\`- [ ]\` → \`- [x]\`), then move to the next.',
+    sddBranch: `### sdd branch — implement per slice
+
+For each tracer-bullet slice in \`tasks.md\`:
+1. Implement the minimum that satisfies the behavior the slice's specs describe. Don't anticipate future slices or add speculative flexibility.
+2. Verify the result matches the behavior the slice's specs describe, and that the existing test suite still passes.
+3. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.
+
+Writing a new test is **not required** in this loop — add one when it earns its keep. If you do, put it at the seam \`design.md\` named and don't test internals or add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface). Use \`tospec-apply-with-tdd\` when every slice must start from a failing test.`,
+    issueBranch: `### issue branch — fix root cause
+
+Read \`task.md\`'s feedback loop, then fix the root cause, not the symptom — if the same defect is reachable through multiple callers of a shared function, the fix belongs in the shared function, not patched into just the caller the ticket named (grep every caller of the function you're touching). Confirm the fix with \`task.md\`'s feedback loop and keep the existing suite green.
+
+A regression test is **not required** here — add one when the bug is likely to recur, extending the existing test if there's one at the right seam. Use \`tospec-apply-with-tdd\` when the fix must start from a red regression test.`,
+    guardrailsHead: `- One slice/task at a time — no batching
+- Tests are optional in this loop — write one when it earns its keep, and never let a missing test block progress; \`tospec-apply-with-tdd\` is the variant that mandates them
+- Never delete, skip, or weaken an existing test to get to green — fix the code instead`,
+});
 export function getTospecApplySkillTemplate() {
     return {
         name: 'tospec-apply',
-        description: 'Implement a change one task at a time, branching by schema, covering each change with a test as you go (test-after — no strict TDD loop), checking off tasks.md/task.md, then automatically run the two-axis verify review. Use when planning artifacts are complete (sdd: ticket/specs/design/tasks; issue: ticket/task) and the user wants to implement without a red-first (TDD) cycle.',
-        instructions: `Implement a change's tasks one slice at a time, branching by schema, covering each change with a test as you go, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        description: 'Implement tasks from a tospec change. Use when the user wants to start implementing, continue implementation, or work through tasks.',
+        instructions: `Implement a change's tasks one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
 
-**Input**: The user's request should name the change to implement (or continue implementing).
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 ${APPLY_BODY}`,
         license: 'MIT',
         compatibility: 'Requires tospec CLI.',
         metadata: { author: 'tospec', version: '1.0' },
-        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent'],
+        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent', 'AskUserQuestion'],
     };
 }
 export function getTospecApplyCommandTemplate() {
     return {
         name: 'TOSPEC: Apply',
-        description: 'Implement a change one slice at a time (test-after), then auto-run the two-axis verify review',
+        description: 'Implement tasks from a change, one slice at a time',
         category: 'Workflow',
         tags: ['workflow', 'implementation'],
-        content: `Implement a change's tasks one slice at a time, branching by schema, covering each change with a test as you go, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        content: `Implement a change's tasks one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
 
-**Input**: The argument after \`tospec-apply\` is the change name to implement (or continue implementing).
+**Input**: Optionally specify a change name after \`tospec-apply\` (e.g., \`tospec-apply add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 ${APPLY_BODY}`,
     };
@@ -79,81 +123,50 @@ ${APPLY_BODY}`,
 // -----------------------------------------------------------------------------
 // TDD apply — strict red → green per slice
 // -----------------------------------------------------------------------------
-const APPLY_TDD_BODY = `**Steps**
-
-1. **Confirm planning is done**
-   \`\`\`bash
-   tospec status --change "<name>" --json
-   \`\`\`
-   Every artifact in \`applyRequires\` must be \`done\` before you write any code. If one isn't, stop and send the user back to \`tospec-propose\` or \`tospec-issue\`. Note \`schemaName\` — it decides which branch below applies.
-
-2. **Work the tracks file one item at a time**
-
-   The tracks file is \`tasks.md\` (sdd) or \`task.md\` (issue). Take the next unchecked item, implement it, check it off (\`- [ ]\` → \`- [x]\`) only once its test is green, then move to the next. Never batch multiple items into one pass.
-
-### sdd branch — TDD per slice
+const APPLY_TDD_BODY = buildApplyBody({
+    step2Intro: 'Take the next unchecked item, implement it, check it off (\`- [ ]\` → \`- [x]\`) only once its test is green, then move to the next.',
+    sddBranch: `### sdd branch — TDD per slice
 
 For each tracer-bullet slice in \`tasks.md\`:
 1. Write the failing test first (red) — **only at the seam \`design.md\` named**. Don't test internals, don't add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface).
 2. Implement the minimum to pass (green). Don't anticipate future slices or add speculative flexibility.
 3. Verify the result matches the behavior the slice's specs describe.
-4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.
-
-### issue branch — three-way test split
+4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.`,
+    issueBranch: `### issue branch — three-way test split
 
 Read \`task.md\`'s feedback loop. Then:
 - **Existing test, failing** → the regression test from diagnosis already goes red. Find out why it fails and fix root cause (grep every caller of the function you're touching — the bug may hit more than the one path the ticket names).
 - **Existing test, passing** → the bug is an edge case the existing test doesn't cover. Add a new failing test for that edge case first, then fix.
 - **No existing test** → write the red regression test from \`task.md\`'s feedback loop first, then fix.
 
-Fix root cause, not symptom — if the same defect is reachable through multiple callers of a shared function, the fix belongs in the shared function, not patched into just the caller the ticket named.
-
-3. **Re-validate artifacts**
-   \`\`\`bash
-   tospec validate "<name>" --json
-   \`\`\`
-   Implementation sometimes touches tasks.md/specs directly (adding a discovered edge case, correcting an estimate) — confirm the change's artifacts are still structurally valid before handing off. Fix and re-run until it passes.
-
-## Verify (automatic — apply's final step)
-
-Once every task is checked off and \`tospec validate\` passes, run the two-axis review **automatically**. This is not a separate command the user has to invoke — verify is folded into apply and runs here as its last step, before the change is handed to \`tospec-archive\`.
-
-${VERIFY_METHODOLOGY}
-
-**Output**
-
-Report which tasks/checkboxes completed this pass, current progress (\`tospec status --change "<name>"\`), and whether all required artifacts are checked off. When everything is done, the verify review above has already run — if it came back clean, tell the user the change is ready for \`tospec-archive\`; if it surfaced blocking findings, keep working here to resolve them.
-
-**Guardrails**
-- Red before green, always — never write the implementation before its failing test
-- One slice/task at a time — no batching
-- Test only at the pre-agreed seam (design.md for sdd; the existing/new seam identified for issue) — never against internals
-- Fix root cause: check every caller of a shared function before declaring a fix complete
-- Don't hand off to archive until the automatic verify step is clean and the full test suite is green`;
+Fix root cause, not symptom — if the same defect is reachable through multiple callers of a shared function, the fix belongs in the shared function, not patched into just the caller the ticket named.`,
+    guardrailsHead: `- Red before green, always — never write the implementation before its failing test
+- One slice/task at a time — no batching`,
+});
 export function getTospecApplyWithTDDSkillTemplate() {
     return {
         name: 'tospec-apply-with-tdd',
-        description: 'Implement a change test-first (red → green), one tracer-bullet slice or task at a time, checking off tasks.md/task.md as you go, then automatically run the two-axis verify review. Use when planning artifacts are complete (sdd: ticket/specs/design/tasks; issue: ticket/task) and the user wants a strict test-first (TDD) implementation loop.',
+        description: 'Implement tasks from a tospec change test-first (red → green). Use when the user wants to start or continue implementation with a strict TDD loop.',
         instructions: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
 
-**Input**: The user's request should name the change to implement (or continue implementing).
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 ${APPLY_TDD_BODY}`,
         license: 'MIT',
         compatibility: 'Requires tospec CLI.',
         metadata: { author: 'tospec', version: '1.0' },
-        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent'],
+        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent', 'AskUserQuestion'],
     };
 }
 export function getTospecApplyWithTDDCommandTemplate() {
     return {
         name: 'TOSPEC: Apply (TDD)',
-        description: 'Implement a change test-first, one slice at a time, then auto-run the two-axis verify review',
+        description: 'Implement tasks from a change test-first (red → green)',
         category: 'Workflow',
         tags: ['workflow', 'tdd', 'implementation'],
         content: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
 
-**Input**: The argument after \`tospec-apply-with-tdd\` is the change name to implement (or continue implementing).
+**Input**: Optionally specify a change name after \`tospec-apply-with-tdd\` (e.g., \`tospec-apply-with-tdd add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 ${APPLY_TDD_BODY}`,
     };

package/dist/core/templates/workflows/apply.js.map

@@ -1 +1 @@
-{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAaA,OAAO,EAAE,kBAAkB,EAAE,MAAM,aAAa,CAAC;AAEjD,gFAAgF;AAChF,+EAA+E;AAC/E,gFAAgF;AAEhF,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAkCjB,kBAAkB;;;;;;;;;;;sGAWkF,CAAC;AAEvG,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,4XAA4X;QACzY,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC;KAC3F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,+FAA+F;QAC5G,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,gBAAgB,CAAC;QACpC,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,2CAA2C;AAC3C,gFAAgF;AAEhF,MAAM,cAAc,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAuCrB,kBAAkB;;;;;;;;;;;sGAWkF,CAAC;AAEvG,MAAM,UAAU,kCAAkC;IAChD,OAAO;QACL,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,qVAAqV;QAClW,YAAY,EAAE;;;;EAIhB,cAAc,EAAE;QACd,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC;KAC3F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,oCAAoC;IAClD,OAAO;QACL,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,8FAA8F;QAC3G,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,gBAAgB,CAAC;QAC3C,OAAO,EAAE;;;;EAIX,cAAc,EAAE;KACf,CAAC;AACJ,CAAC"}
+{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAaA,OAAO,EAAE,kBAAkB,EAAE,MAAM,aAAa,CAAC;AAiBjD,uEAAuE;AACvE,SAAS,cAAc,CAAC,CAAe;IACrC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEA+B0D,CAAC,CAAC,UAAU;;;;;;;;EAQ7E,CAAC,CAAC,SAAS;;EAEX,CAAC,CAAC,WAAW;;;;;;;;;;;;EAYb,kBAAkB;;;;;;;EAOlB,CAAC,CAAC,cAAc;;;;;;;sGAOoF,CAAC;AACvG,CAAC;AAED,gFAAgF;AAChF,wEAAwE;AACxE,gFAAgF;AAEhF,MAAM,UAAU,GAAG,cAAc,CAAC;IAChC,UAAU,EACR,8IAA8I;IAChJ,SAAS,EAAE;;;;;;;wYAO2X;IACtY,WAAW,EAAE;;;;sOAIuN;IACpO,cAAc,EAAE;;wFAEsE;CACvF,CAAC,CAAC;AAEH,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,sIAAsI;QACnJ,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;KAC9G,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,oDAAoD;QACjE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,gBAAgB,CAAC;QACpC,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,2CAA2C;AAC3C,gFAAgF;AAEhF,MAAM,cAAc,GAAG,cAAc,CAAC;IACpC,UAAU,EACR,sIAAsI;IACxI,SAAS,EAAE;;;;;;0KAM6J;IACxK,WAAW,EAAE;;;;;;;wMAOyL;IACtM,cAAc,EAAE;yCACuB;CACxC,CAAC,CAAC;AAEH,MAAM,UAAU,kCAAkC;IAChD,OAAO;QACL,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,oJAAoJ;QACjK,YAAY,EAAE;;;;EAIhB,cAAc,EAAE;QACd,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;KAC9G,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,oCAAoC;IAClD,OAAO;QACL,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,wDAAwD;QACrE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,gBAAgB,CAAC;QAC3C,OAAO,EAAE;;;;EAIX,cAAc,EAAE;KACf,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/archive.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"archive.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAiDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}
+{"version":3,"file":"archive.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAmDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/archive.js

@@ -22,16 +22,18 @@ If a sync is warranted, **ask the user one question** (make clear both answers a
 
 Synced branch (user chose to sync and \`sync-report.md\` says \`結論: PASS\`):
 \`\`\`bash
-tospec archive "<name>" --require-sync
+tospec archive "<name>" --json --require-sync
 \`\`\`
 \`--require-sync\` is the CLI's own machine-checkable half of the sync gate: it refuses unless \`sync-report.md\` exists with a \`結論: PASS\` line (\`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\`). If \`tospec-sync\` actually ran and passed, this succeeds for free — a CLI-enforced backstop behind the instruction-level order above. Only pass \`--require-sync\` when a sync actually ran; otherwise the CLI will (correctly) refuse.
 
 Not-synced branch (sync wasn't needed, or the user declined):
 \`\`\`bash
-tospec archive "<name>"
+tospec archive "<name>" --json
 \`\`\`
 
-Either way, the CLI then: re-validates the delta specs (blocking), checks tasks/task completion (asks for confirmation if incomplete), does a two-phase atomic merge into \`tospec/specs/\` (dry-run + re-validate every target first, writes only if all pass), and moves the change directory — including \`sync-report.md\` when present — into \`tospec/changes/archive/\` under a \`yyyyMMdd_HHmmss-<name>\` timestamp the CLI generates itself.
+Either way, the CLI then: re-validates the delta specs (blocking), checks tasks/task completion (with \`--json\`, incomplete tasks block unless you pass \`--yes\` after the user confirms), does a two-phase atomic merge into \`tospec/specs/\` (dry-run + re-validate every target first, writes only if all pass), and moves the change directory — including \`sync-report.md\` when present — into \`tospec/changes/archive/\` under a \`yyyyMMdd_HHmmss-<name>\` timestamp the CLI generates itself.
+
+**Reading the result**: the \`--json\` output is \`{archive, status}\`. Success → \`archive\` holds \`{change, archivedAs, path, specsUpdated}\`. Failure → \`archive\` is \`null\` and \`status[0].code\` tells you which ending you got: \`archive_validation_failed\` (fix artifacts, re-validate), \`archive_tasks_incomplete\` / \`archive_tasks_missing\` (ask the user, then rerun with \`--yes\` to override), \`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\` (the sync gate refused). Each status entry carries \`{code, message, fix}\` — follow \`fix\`.
 
 **Guardrails — explicit and non-negotiable**
 - Judge whether a sync is warranted before archiving; only ask the user when the change has spec deltas — and honor a "no" (archive still proceeds, just without \`--require-sync\`)

package/dist/core/templates/workflows/archive.js.map

@@ -1 +1 @@
-{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sJA6CiI,CAAC;AAEvJ,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,4UAA4U;QACzV,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,oGAAoG;QACjH,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}
+{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sJA+CiI,CAAC;AAEvJ,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,4UAA4U;QACzV,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,oGAAoG;QACjH,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/decision.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"decision.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/decision.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA4ClE,wBAAgB,8BAA8B,IAAI,aAAa,CAe9D;AAED,wBAAgB,gCAAgC,IAAI,eAAe,CAYlE"}
+{"version":3,"file":"decision.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/decision.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA8ClE,wBAAgB,8BAA8B,IAAI,aAAa,CAe9D;AAED,wBAAgB,gCAAgC,IAAI,eAAe,CAYlE"}

package/dist/core/templates/workflows/decision.js

@@ -32,7 +32,9 @@ const DECISION_BODY = `Capture a decision that has already been made or is ready
 
 **Output**
 
-Summarize the decision, its status, and the follow-up work. If it supersedes an older decision, state which one and flip that older file's 狀態 to \`superseded\`.
+Summarize the decision, its status, and the follow-up work. If it supersedes an older decision, state which one and flip that older file's 狀態 to \`superseded\`. Report the created filename explicitly — when a change later implements this decision, that filename is what \`tospec new change --decisions\` records to link the change back here (the file's optional \`## 關聯變更\` section can list those changes in return).
+
+Then point at the next step: if the decision came out of grilling or exploring an **existing** change, hand off to \`tospec-update\` to fold it into that change's artifacts; if no change exists yet, hand off to \`tospec-propose\`/\`tospec-issue\` and carry the filename into \`--decisions\`.
 
 **Guardrails**
 - The decision file, its date-prefixed filename, and the ledger row are all CLI-generated — pass \`--summary\`, and never create/rename decision files or hand-edit \`index.md\` yourself; only edit the decision file's section contents

package/dist/core/templates/workflows/decision.js.map

@@ -1 +1 @@
-{"version":3,"file":"decision.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/decision.ts"],"names":[],"mappings":"AASA,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8MAwCwL,CAAC;AAE/M,MAAM,UAAU,8BAA8B;IAC5C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EACT,mQAAmQ;QACrQ,YAAY,EAAE;;;;EAIhB,aAAa,EAAE;QACb,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,gCAAgC;IAC9C,OAAO;QACL,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,6FAA6F;QAC1G,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,KAAK,CAAC;QACrC,OAAO,EAAE;;;;EAIX,aAAa,EAAE;KACd,CAAC;AACJ,CAAC"}
+{"version":3,"file":"decision.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/decision.ts"],"names":[],"mappings":"AASA,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8MA0CwL,CAAC;AAE/M,MAAM,UAAU,8BAA8B;IAC5C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EACT,mQAAmQ;QACrQ,YAAY,EAAE;;;;EAIhB,aAAa,EAAE;QACb,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,gCAAgC;IAC9C,OAAO;QACL,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,6FAA6F;QAC1G,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,UAAU,EAAE,KAAK,CAAC;QACrC,OAAO,EAAE;;;;EAIX,aAAa,EAAE;KACd,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/explore.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"explore.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA8DlE,wBAAgB,uBAAuB,IAAI,aAAa,CAcvD;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}
+{"version":3,"file":"explore.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAgElE,wBAAgB,uBAAuB,IAAI,aAAa,CAcvD;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/explore.js

@@ -38,19 +38,21 @@ This is a grilling interview, not a freeform chat. Interview the user relentless
 
    Deliver the converged understanding back in the conversation — the problem, the decisions made (with reasoning), and anything explicitly ruled out — so \`tospec-propose\`/\`tospec-issue\` can synthesize it straight from context (that's exactly the input they expect).
 
-7. **Recommend the next step — then hand off**
+7. **Always ask for the next step — never pick it yourself**
 
-   Explore back-and-forth almost always settles decisions; judge whether any is *material* — a choice between real alternatives that will shape the change and get re-litigated if left in chat (a material decision weighed alternatives and has lasting architecture/design impact; an answered factual lookup or a trivial preference does not). That judgment sets your recommendation.
+   Once you've restated the understanding, you MUST put the next step to the user with \`AskUserQuestion\`. This is unconditional: explore never proceeds to the next action on its own, and never ends without asking.
 
-   Put the next step to the user with \`AskUserQuestion\` — one question, your recommended option **first** and labelled "(Recommended)", plus the real alternatives (including "keep exploring") so they can override:
-   - **A material decision was settled but isn't recorded** -> recommend \`tospec-decision\`; record the ADR **before** any proposal.
-   - **A new capability is ready to build** -> recommend \`tospec-propose\`.
-   - **Something is broken** -> recommend \`tospec-issue\`.
-   - **Still fuzzy** -> recommend keeping the exploration going.
+   One question, always these options, with your recommended one **first** and labelled "(Recommended)":
+   - **\`tospec-decision\`** — record a material decision as an ADR. Offer this only when the interview actually settled one: a choice between real alternatives with lasting architecture/design impact that will get re-litigated if left in chat. An answered factual lookup or a trivial preference is not material — drop this option when nothing material was settled.
+   - **\`tospec-propose\`** (or \`tospec-issue\` when something is broken) — start writing the proposal.
+   - **\`tospec-grill\`** — keep digging with a four-quadrant deep dive on what was just explored.
 
-   \`tospec-propose\`/\`tospec-issue\` synthesize the requirement straight from the conversation and write the change artifacts; explore persists nothing itself. If the user picks \`tospec-decision\`, record it, then ask again — now recommending \`tospec-propose\`/\`tospec-issue\` — because a recorded decision still needs to flow into a change.
+   Recommend \`tospec-decision\` when a material decision is unrecorded (the ADR comes **before** the proposal), \`tospec-propose\`/\`tospec-issue\` when the requirement is ready to build, and \`tospec-grill\` when it still feels fuzzy or under-tested.
+
+   \`tospec-propose\`/\`tospec-issue\` synthesize the requirement straight from the conversation and write the change artifacts; explore persists nothing itself. If the user picks \`tospec-decision\`, record it, then ask again — now recommending \`tospec-propose\`/\`tospec-issue\` — because a recorded decision still needs to flow into a change. Carry the recorded decision filename(s) (reported by \`tospec decision new\`) into that handoff: the propose/issue step passes them via \`tospec new change --decisions\` so the change's metadata links back to its ADRs.
 
 **Guardrails**
+- **Always end with the next-step question** — never choose the follow-up action yourself, and never finish explore without asking
 - **Don't implement** — never write application code or edit source files during explore
 - **Record decisions before proposing** — if the interview settled a material decision, hand off to \`tospec-decision\` to record it before \`tospec-propose\`/\`tospec-issue\`; a real decision must not survive only in chat
 - **Batch what's independent, sequence what's dependent** — ask unrelated questions together in one turn; split to one at a time only when A's answer decides B

package/dist/core/templates/workflows/explore.js.map

@@ -1 +1 @@
-{"version":3,"file":"explore.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yHA0DoG,CAAC;AAE1H,MAAM,UAAU,uBAAuB;IACrC,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,yQAAyQ;QACtR,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC5E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,sFAAsF;QACnG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}
+{"version":3,"file":"explore.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yHA4DoG,CAAC;AAE1H,MAAM,UAAU,uBAAuB;IACrC,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,yQAAyQ;QACtR,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC5E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,sFAAsF;QACnG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/grill.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"grill.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/grill.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAmClE,wBAAgB,qBAAqB,IAAI,aAAa,CAcrD;AAED,wBAAgB,6BAA6B,IAAI,eAAe,CAY/D"}
+{"version":3,"file":"grill.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/grill.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA0DlE,wBAAgB,qBAAqB,IAAI,aAAa,CAcrD;AAED,wBAAgB,6BAA6B,IAAI,eAAe,CAY/D"}

package/dist/core/templates/workflows/grill.js

@@ -1,6 +1,17 @@
-const GRILL_BODY = `**IMPORTANT: Grill is read-only pressure-testing, not building.** You may read files, search code, and run \`tospec\` read-only commands, but you must NEVER write code, edit sources, or create artifact files during a grill. Grill persists nothing — it hands off to nothing. Its only output is a shared, confirmed understanding delivered back in the conversation.
+const GRILL_BODY = `**IMPORTANT: Grill is read-only pressure-testing, not building.** You may read files, search code, and run \`tospec\` read-only commands, but you must NEVER write code, edit sources, or create artifact files during a grill. Grill writes nothing itself — when the interrogation lands something worth persisting, it hands off to the skill that owns that write.
 
-This is a relentless interrogation of whatever the user put on the table — a plan, a decision, an idea, a design. Stress-test it until every assumption is named and every open question is either answered or explicitly parked. Work the four quadrants below, batching questions that stand on their own and following dependent threads one question at a time.
+This is a relentless interrogation of whatever is on the table — a plan, a decision, an idea, a design. Stress-test it until every assumption is named and every open question is either answered or explicitly parked. Work the four quadrants below, batching questions that stand on their own and following dependent threads one question at a time.
+
+**Pick the target first — never assume one**
+
+Before asking a single question, establish *what* you are grilling. Resolve in this order:
+
+1. **The user named it** — an explicit target in the request wins outright; use it.
+2. **The conversation has an unambiguous subject** — an explore that just converged, or a proposal actively under discussion in this session. Only take this path when there is exactly one obvious candidate; a topic mentioned in passing does not count.
+3. **Otherwise, ask.** Run \`tospec list --json\` and offer the unfinished changes (\`status\` is not \`complete\`, most recently modified first) via \`AskUserQuestion\`, each labelled with its name, status, and how recently it changed. **Never pick one yourself** — not even the top hit, and not even when only one candidate exists.
+4. **Nothing to grill** — no explore in context and no unfinished changes: stop. Tell the user there is no subject available to dig into and suggest \`tospec-explore\` to start one. Do not invent a topic.
+
+Note which kind of target you settled on — a raw idea/explore versus an existing written proposal. That distinction decides the handoff at the end.
 
 **The four quadrants**
 
@@ -22,21 +33,33 @@ Sweep all four — the last two are where the real risk hides:
 
 You're done only when you can fully restate the shared understanding — the claims that held up, the assumptions now made explicit, the questions answered, and anything left deliberately open — and the user confirms it's right. Running out of questions is not convergence. If the user corrects your restatement, there's still a hidden branch; keep grilling.
 
+**Hand off once the understanding is confirmed**
+
+A grill that shifts the picture leaves work behind. After the user confirms the restatement:
+
+1. **Record a material decision, if the grill produced one.** A choice between real alternatives with lasting architecture/design impact belongs in an ADR before anything else — hand off to \`tospec-decision\`. Skip this when nothing material moved; a confirmed assumption is not a decision.
+2. **Then route by target kind:**
+   - **Target was an existing written proposal** -> hand off to \`tospec-update\` to fold the outcome into that change's artifacts. Name the change so update doesn't have to re-ask.
+   - **Target was a raw idea or an explore** -> nothing is written yet; recommend \`tospec-propose\` (or \`tospec-issue\` when something is broken), or keep grilling if it's still fuzzy.
+
+Grill itself writes nothing — \`tospec-decision\` and \`tospec-update\` own those files.
+
 **Guardrails**
 - **Don't implement** — never write application code, edit sources, or create artifact files during a grill
-- **Don't act before consensus** — take no action until the user has confirmed the restated understanding
+- **Don't pick the target yourself** — when the subject isn't explicit or unambiguous, ask; when there's no subject at all, stop
+- **Don't act before consensus** — take no action, including any handoff, until the user has confirmed the restated understanding
 - **Don't ask what you can look up** — codebase facts are yours to find, not the user's to recite
 - **Don't stop at the first plausible answer** — dig for the implied premise behind it
 - **Don't force closure** — if the user wants to keep grilling after you've restated where things stand, keep going
 
-Grill is on-demand deep-dive for *any* artifact — not the pre-change requirement convergence that \`tospec-explore\` owns, and it lands no files of its own.`;
+Grill is on-demand deep-dive for *any* artifact — not the pre-change requirement convergence that \`tospec-explore\` owns — and it lands no files of its own, only handoffs.`;
 export function getGrillSkillTemplate() {
     return {
         name: 'tospec-grill',
         description: "Pressure-test any artifact — a plan, a decision, an idea, a design — through a relentless four-quadrant Known/Unknown interrogation. Trigger whenever the user says 'grill', 'grill me', 'grilling', or 'grilling me', or otherwise wants to dig deeper, surface unspoken assumptions, and hunt blind spots before committing.",
         instructions: `Grill any artifact the user hands you — a plan, decision, idea, or design — through the four-quadrant Known/Unknown frame until every assumption is named and the understanding is shared and confirmed.
 
-**Input**: The user's request is whatever they want stress-tested — a plan file, a recorded decision, a raw idea, or a change name to interrogate in context of. May be empty, in which case ask what to grill.
+**Input**: The user's request is whatever they want stress-tested — a plan file, a recorded decision, a raw idea, or a change name to interrogate in context of. May be empty, in which case resolve the target per "Pick the target first" below — never assume one.
 
 ${GRILL_BODY}`,
         license: 'MIT',
@@ -53,7 +76,7 @@ export function getTospecGrillCommandTemplate() {
         tags: ['workflow', 'grill'],
         content: `Grill any artifact the user hands you — a plan, decision, idea, or design — through the four-quadrant Known/Unknown frame until every assumption is named and the understanding is shared and confirmed.
 
-**Input**: The argument after \`tospec-grill\` is whatever the user wants stress-tested — a plan file, a recorded decision, a raw idea, or a change name to interrogate in context of. May be empty, in which case ask what to grill.
+**Input**: The argument after \`tospec-grill\` is whatever the user wants stress-tested — a plan file, a recorded decision, a raw idea, or a change name to interrogate in context of. May be empty, in which case resolve the target per "Pick the target first" below — never assume one.
 
 ${GRILL_BODY}`,
     };

package/dist/core/templates/workflows/grill.js.map

@@ -1 +1 @@
-{"version":3,"file":"grill.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/grill.ts"],"names":[],"mappings":"AAUA,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6JA+B0I,CAAC;AAE9J,MAAM,UAAU,qBAAqB;IACnC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,gUAAgU;QAC7U,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC5E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,2FAA2F;QACxG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,OAAO,CAAC;QAC3B,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC"}
+{"version":3,"file":"grill.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/grill.ts"],"names":[],"mappings":"AAUA,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6KAsD0J,CAAC;AAE9K,MAAM,UAAU,qBAAqB;IACnC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,gUAAgU;QAC7U,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC5E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,2FAA2F;QACxG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,OAAO,CAAC;QAC3B,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/propose.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"propose.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAmDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}
+{"version":3,"file":"propose.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAqDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/propose.js

@@ -8,6 +8,8 @@ const PROPOSE_BODY = `Do NOT re-interview the user — synthesize what's already
    \`\`\`
    Derive a kebab-case name from the request if none was given. This also **auto-generates the ticket stub** in the global index at \`tospec/tickets/<yyyyMMdd_HHmmss>-<name>.md\` (yaml header + a short Summary) — the CLI owns that timestamped filename, so **never create or rename ticket files yourself**.
 
+   If ADRs recorded via \`tospec-decision\` drove this change (e.g. from a preceding \`tospec-explore\`), link them at creation with \`--decisions "<decision-file>[,<decision-file>...]"\` — the filenames under \`tospec/decisions/\` that \`tospec decision new\` reported. This is what lets the archived change trace back to its decisions.
+
 2. **Get the artifact build order**
    \`\`\`bash
    tospec status --change "<name>" --json
@@ -24,7 +26,7 @@ const PROPOSE_BODY = `Do NOT re-interview the user — synthesize what's already
 
    Artifact-specific rules on top of what \`instructions\` returns:
    - **ticket** (already created): keep it thin — just refine the one-line \`## Summary\` so it names what this change does. All the detail (why, what, scope, decisions) lives in \`proposal.md\`, not here. Don't duplicate proposal content into the ticket, and don't add a timestamp or filename yourself.
-   - **proposal**: the main document — Why (motivation, why now), What Changes (concrete add/modify/remove), Capabilities (New/Modified, each pointing at its \`specs/<name>/spec.md\`), Impact (affected code/API/deps/systems). **Never include file paths or code snippets** in the prose — they go stale fast. Exception: a snippet from an actual prototype that encodes a decision more precisely than prose (a state machine, a schema shape) — inline it, trimmed to the decision, and note it came from a prototype.
+   - **proposal**: the main document — Why (motivation, why now), What Changes (concrete add/modify/remove), Capabilities (New/Modified, each pointing at its \`specs/<name>/spec.md\`), Impact (affected code/API/deps/systems). If linked ADRs exist (\`--decisions\` above), name them in Why so a reader knows which recorded decisions this proposal builds on. **Never include file paths or code snippets** in the prose — they go stale fast. Exception: a snippet from an actual prototype that encodes a decision more precisely than prose (a state machine, a schema shape) — inline it, trimmed to the decision, and note it came from a prototype.
    - **design**: pick the testing seam before writing anything else — prefer an existing seam over a new one, the highest layer that still catches the behavior, and as few seams as possible (ideally one). State the seam explicitly in "Testing Seams" so \`tospec-apply\` knows exactly where to test.
    - **tasks**: cut the work into **tracer-bullet vertical slices** — each slice cuts a complete path through every layer touched (not "all the schema changes, then all the UI"), is independently demoable, and fits a single implementation pass. Every slice's implementation step is preceded by its own "write the failing test" step (red before green). A **wide mechanical refactor** (rename a shared symbol, retype a column) is the one exception to vertical slicing — sequence it as expand -> migrate-in-batches -> contract instead of forcing it into a tracer bullet.
 

package/dist/core/templates/workflows/propose.js.map

@@ -1 +1 @@
-{"version":3,"file":"propose.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gIA+C2G,CAAC;AAEjI,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,kRAAkR;QAC/R,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,wEAAwE;QACrF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,WAAW,CAAC;QACtC,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}
+{"version":3,"file":"propose.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gIAiD2G,CAAC;AAEjI,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,kRAAkR;QAC/R,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,wEAAwE;QACrF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,WAAW,CAAC;QACtC,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/update.js

@@ -86,9 +86,9 @@ ${UPDATE_BODY}`,
 export function getTospecUpdateCommandTemplate() {
     return {
         name: 'TOSPEC: Update',
-        description: 'Update a change - revise existing planning artifacts and keep them coherent (Experimental)',
+        description: 'Update a change - revise existing planning artifacts and keep them coherent',
         category: 'Workflow',
-        tags: ['workflow', 'artifacts', 'experimental'],
+        tags: ['workflow', 'artifacts'],
         content: `Revise a change's existing planning artifacts and keep them coherent. Never edit code.
 
 **Input**: Optionally specify a change name after \`tospec-update\` (e.g., \`tospec-update add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

package/dist/core/templates/workflows/update.js.map

@@ -1 +1 @@
-{"version":3,"file":"update.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/update.ts"],"names":[],"mappings":"AAQA,MAAM,WAAW,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oLAqEgK,CAAC;AAErL,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,oPAAoP;QACjQ,YAAY,EAAE;;;;EAIhB,WAAW,EAAE;QACX,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC;KAClF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,8BAA8B;IAC5C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,4FAA4F;QACzG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,WAAW,EAAE,cAAc,CAAC;QAC/C,OAAO,EAAE;;;;EAIX,WAAW,EAAE;KACZ,CAAC;AACJ,CAAC"}
+{"version":3,"file":"update.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/update.ts"],"names":[],"mappings":"AAQA,MAAM,WAAW,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oLAqEgK,CAAC;AAErL,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,oPAAoP;QACjQ,YAAY,EAAE;;;;EAIhB,WAAW,EAAE;QACX,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC;KAClF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,8BAA8B;IAC5C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,6EAA6E;QAC1F,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,WAAW,CAAC;QAC/B,OAAO,EAAE;;;;EAIX,WAAW,EAAE;KACZ,CAAC;AACJ,CAAC"}

package/dist/core/update.d.ts

@@ -14,10 +14,6 @@ export declare class UpdateCommand {
     private readonly force;
     constructor(options?: UpdateCommandOptions);
     execute(projectPath: string): Promise<void>;
-    /**
-     * Display message when all tools are up to date.
-     */
-    private displayUpToDateMessage;
     /**
      * Display the update plan showing which tools need updating.
      */
@@ -31,11 +27,6 @@ export declare class UpdateCommand {
      * four-workflow core set. Keep custom profiles user-owned; do not mutate them.
      */
     private displayOldCoreCustomProfileNote;
-    /**
-     * Removes skill directories for workflows when delivery changed to commands-only.
-     * Returns the number of directories removed.
-     */
-    private removeSkillDirs;
     /**
      * Removes skill directories for workflows that are no longer selected in the
      * active profile, from a tool's `skills/` dir (dirs named `tospec-<workflow>`).

package/dist/core/update.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"update.d.ts","sourceRoot":"","sources":["../../src/core/update.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAoCH;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC;CACjB;AAED,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAU;gBAEpB,OAAO,GAAE,oBAAyB;IAIxC,OAAO,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IA+KjD;;OAEG;IACH,OAAO,CAAC,sBAAsB;IAQ9B;;OAEG;IACH,OAAO,CAAC,iBAAiB;IAsBzB;;OAEG;IACH,OAAO,CAAC,cAAc;IAkBtB;;;OAGG;IACH,OAAO,CAAC,+BAA+B;IAkBvC;;;OAGG;YACW,eAAe;IAqB7B;;;;OAIG;YACW,yBAAyB;CA0BxC"}
+{"version":3,"file":"update.d.ts","sourceRoot":"","sources":["../../src/core/update.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAmCH;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC;CACjB;AAED,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAU;gBAEpB,OAAO,GAAE,oBAAyB;IAIxC,OAAO,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAqKjD;;OAEG;IACH,OAAO,CAAC,iBAAiB;IAsBzB;;OAEG;IACH,OAAO,CAAC,cAAc;IAkBtB;;;OAGG;IACH,OAAO,CAAC,+BAA+B;IAkBvC;;;;OAIG;YACW,yBAAyB;CA0BxC"}