@seanmars/tospec 0.11.0 → 0.13.0

package/dist/core/templates/fragments/verify.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Verify methodology — apply's opt-in review.
+ *
+ * verify is not a standalone skill/command; it lives inside both apply variants
+ * and runs only when the user asks for it. The methodology is long enough that
+ * leaving it inline puts ~45 lines of end-of-run review in front of an agent
+ * that is still on task 1 of N, so the skill form discloses it to a sibling
+ * `VERIFY.md` and keeps only a pointer. The command form has no sibling file,
+ * so it inlines the same text. Either way this module is the single source of
+ * truth.
+ */
+/** The review protocol itself — shared by the disclosed file and the command. */
+export declare const VERIFY_METHODOLOGY = "Two-axis review of the implementation, run as **independent parallel subagents** so neither pollutes or reranks the other's findings \u2014 a change can pass one axis and fail the other, and reporting them separately is what keeps that visible.\n\n**Scope \u2014 two subagents, one pass each, and that is the whole review.** The subject under review is always the *code diff*, never another review's output. Do not spawn a third agent to grade the two axes' findings, do not re-review a report you have already written, do not audit the audit. Right-sized review beats deep review: enough eyes to catch real problems, no recursion for its own sake.\n\n**What counts as blocking.** Exactly two kinds of finding block: a **hard violation** of a convention this repo documents, and a **spec-correctness** problem \u2014 a requirement missing, implemented wrongly, or contradicting a decision `design.md` records. Everything else \u2014 judgement calls, style preferences, and every code smell named below \u2014 is **report-only**: report it, do not fix it, and do not re-review because of it. A report-only finding is the user's call to make later, not this run's work. Leave this unstated and the safe reading is to fix everything, which makes \"re-run only the affected axis\" fire on every axis, every time.\n\n**Steps**\n\n1. **Gather context**\n   ```bash\n   tospec status --change \"<name>\" --json\n   ```\n   Note `schemaName` (sdd \u2192 compare against `specs/`; issue \u2192 compare against `task.md`) and the files this change touched (from `tasks.md`/`task.md`, or `git diff` against the commit before the change started).\n\n2. **Spawn both axes in parallel** \u2014 a single message with two `Agent` tool calls, both `general-purpose`:\n\n   **Standards axis prompt** \u2014 include the diff and the brief: \"Report every place the diff violates this repo's documented conventions (cite the file/rule), plus any of Fowler's code smells you spot (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest) \u2014 name the smell, quote the hunk, and treat documented repo conventions as overriding the baseline. Distinguish hard violations from judgement calls. Skip anything tooling already enforces.\"\n\n   **Spec axis prompt** \u2014 include the diff plus, for sdd, the relevant `specs/<capability>/spec.md` delta content (`tospec show \"<name>\" --json`) and `design.md`'s decisions; for issue, `task.md`'s root cause and fix plan. Brief: \"Report (a) requirements/task items that are missing or partially implemented; (b) behavior in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but the implementation looks wrong, or that deviate from design.md's stated decisions. Quote the spec/task line for each finding.\"\n\n3. **Run the full test suite.** This is a hard gate alongside both axes \u2014 a change with green axes but red tests isn't verified.\n\n4. **Re-validate artifacts**\n   ```bash\n   tospec validate \"<name>\" --json\n   ```\n   If validation reports an artifact-format or structural problem, fix that artifact and re-run the command until it passes. A review is not complete while artifact validation is red.\n\n5. **Aggregate \u2014 do not merge or rerank**\n\n   Present the two reports under `## Standards` and `## Spec` headings. End with one line per axis: total findings and the worst issue within that axis. Do not pick a single overall verdict across axes.\n\n   This is a **mechanical collation you do yourself** \u2014 collect, label, count. It is not another review pass and not a job for a subagent: nothing reviews these two reports.\n\n**Verify output**\n\nReport the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified \u2014 tell the user it's ready for `tospec-archive`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply), then send **only the hunk that fixed it** back to the axis that reported it \u2014 never the whole axis, and never the other one. You are reviewing the changed code, not the previous report. A clean axis is not re-run for extra confidence.\n\n**Verify guardrails**\n- Standards and Spec axes are independent \u2014 never let one axis's findings influence the other's report\n- Full test suite must be green; a clean review with red tests is not verified\n- Quote the specific spec/task line or hunk for every finding \u2014 no unsupported claims\n- **One review pass per axis \u2014 never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix sees only the hunk that fixed it, and a clean axis is not re-run for extra confidence";
+/** Contents of the `VERIFY.md` shipped beside each apply skill's `SKILL.md`. */
+export declare const VERIFY_DOC = "# Verify \u2014 apply's opt-in review\n\nRun this **when the user asks for a review**, once every task in the tracks file is checked off and `tospec validate` passes. It is not a step apply reaches on its own.\n\nTwo-axis review of the implementation, run as **independent parallel subagents** so neither pollutes or reranks the other's findings \u2014 a change can pass one axis and fail the other, and reporting them separately is what keeps that visible.\n\n**Scope \u2014 two subagents, one pass each, and that is the whole review.** The subject under review is always the *code diff*, never another review's output. Do not spawn a third agent to grade the two axes' findings, do not re-review a report you have already written, do not audit the audit. Right-sized review beats deep review: enough eyes to catch real problems, no recursion for its own sake.\n\n**What counts as blocking.** Exactly two kinds of finding block: a **hard violation** of a convention this repo documents, and a **spec-correctness** problem \u2014 a requirement missing, implemented wrongly, or contradicting a decision `design.md` records. Everything else \u2014 judgement calls, style preferences, and every code smell named below \u2014 is **report-only**: report it, do not fix it, and do not re-review because of it. A report-only finding is the user's call to make later, not this run's work. Leave this unstated and the safe reading is to fix everything, which makes \"re-run only the affected axis\" fire on every axis, every time.\n\n**Steps**\n\n1. **Gather context**\n   ```bash\n   tospec status --change \"<name>\" --json\n   ```\n   Note `schemaName` (sdd \u2192 compare against `specs/`; issue \u2192 compare against `task.md`) and the files this change touched (from `tasks.md`/`task.md`, or `git diff` against the commit before the change started).\n\n2. **Spawn both axes in parallel** \u2014 a single message with two `Agent` tool calls, both `general-purpose`:\n\n   **Standards axis prompt** \u2014 include the diff and the brief: \"Report every place the diff violates this repo's documented conventions (cite the file/rule), plus any of Fowler's code smells you spot (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest) \u2014 name the smell, quote the hunk, and treat documented repo conventions as overriding the baseline. Distinguish hard violations from judgement calls. Skip anything tooling already enforces.\"\n\n   **Spec axis prompt** \u2014 include the diff plus, for sdd, the relevant `specs/<capability>/spec.md` delta content (`tospec show \"<name>\" --json`) and `design.md`'s decisions; for issue, `task.md`'s root cause and fix plan. Brief: \"Report (a) requirements/task items that are missing or partially implemented; (b) behavior in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but the implementation looks wrong, or that deviate from design.md's stated decisions. Quote the spec/task line for each finding.\"\n\n3. **Run the full test suite.** This is a hard gate alongside both axes \u2014 a change with green axes but red tests isn't verified.\n\n4. **Re-validate artifacts**\n   ```bash\n   tospec validate \"<name>\" --json\n   ```\n   If validation reports an artifact-format or structural problem, fix that artifact and re-run the command until it passes. A review is not complete while artifact validation is red.\n\n5. **Aggregate \u2014 do not merge or rerank**\n\n   Present the two reports under `## Standards` and `## Spec` headings. End with one line per axis: total findings and the worst issue within that axis. Do not pick a single overall verdict across axes.\n\n   This is a **mechanical collation you do yourself** \u2014 collect, label, count. It is not another review pass and not a job for a subagent: nothing reviews these two reports.\n\n**Verify output**\n\nReport the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified \u2014 tell the user it's ready for `tospec-archive`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply), then send **only the hunk that fixed it** back to the axis that reported it \u2014 never the whole axis, and never the other one. You are reviewing the changed code, not the previous report. A clean axis is not re-run for extra confidence.\n\n**Verify guardrails**\n- Standards and Spec axes are independent \u2014 never let one axis's findings influence the other's report\n- Full test suite must be green; a clean review with red tests is not verified\n- Quote the specific spec/task line or hunk for every finding \u2014 no unsupported claims\n- **One review pass per axis \u2014 never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix sees only the hunk that fixed it, and a clean axis is not re-run for extra confidence\n";
+/** The pointer that replaces the methodology inside the apply skills. */
+export declare const VERIFY_POINTER = "## Verify (opt-in \u2014 only when the user asks)\n\nThe two-axis review does **not** run on its own. Apply finishes on the full test suite and `tospec validate`; a change with those green is implemented, review or no review.\n\nWhen the user asks for a review, **read `VERIFY.md` in this skill's directory and run it in full.** Don't offer it unprompted either \u2014 no \"shall I review this?\" at the end of a run. If a review does run, the change stays unfinished \u2014 and must not go to `tospec-archive` \u2014 until it comes back clean.";
+/** The same block for the command form, which has no sibling file to point at. */
+export declare const VERIFY_INLINE = "## Verify (opt-in \u2014 only when the user asks)\n\nThe two-axis review does **not** run on its own. Apply finishes on the full test suite and `tospec validate`; a change with those green is implemented, review or no review.\n\nWhen the user asks for a review, run the methodology below in full. Don't offer it unprompted either \u2014 no \"shall I review this?\" at the end of a run. If a review does run, the change stays unfinished \u2014 and must not go to `tospec-archive` \u2014 until it comes back clean.\n\nTwo-axis review of the implementation, run as **independent parallel subagents** so neither pollutes or reranks the other's findings \u2014 a change can pass one axis and fail the other, and reporting them separately is what keeps that visible.\n\n**Scope \u2014 two subagents, one pass each, and that is the whole review.** The subject under review is always the *code diff*, never another review's output. Do not spawn a third agent to grade the two axes' findings, do not re-review a report you have already written, do not audit the audit. Right-sized review beats deep review: enough eyes to catch real problems, no recursion for its own sake.\n\n**What counts as blocking.** Exactly two kinds of finding block: a **hard violation** of a convention this repo documents, and a **spec-correctness** problem \u2014 a requirement missing, implemented wrongly, or contradicting a decision `design.md` records. Everything else \u2014 judgement calls, style preferences, and every code smell named below \u2014 is **report-only**: report it, do not fix it, and do not re-review because of it. A report-only finding is the user's call to make later, not this run's work. Leave this unstated and the safe reading is to fix everything, which makes \"re-run only the affected axis\" fire on every axis, every time.\n\n**Steps**\n\n1. **Gather context**\n   ```bash\n   tospec status --change \"<name>\" --json\n   ```\n   Note `schemaName` (sdd \u2192 compare against `specs/`; issue \u2192 compare against `task.md`) and the files this change touched (from `tasks.md`/`task.md`, or `git diff` against the commit before the change started).\n\n2. **Spawn both axes in parallel** \u2014 a single message with two `Agent` tool calls, both `general-purpose`:\n\n   **Standards axis prompt** \u2014 include the diff and the brief: \"Report every place the diff violates this repo's documented conventions (cite the file/rule), plus any of Fowler's code smells you spot (Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest) \u2014 name the smell, quote the hunk, and treat documented repo conventions as overriding the baseline. Distinguish hard violations from judgement calls. Skip anything tooling already enforces.\"\n\n   **Spec axis prompt** \u2014 include the diff plus, for sdd, the relevant `specs/<capability>/spec.md` delta content (`tospec show \"<name>\" --json`) and `design.md`'s decisions; for issue, `task.md`'s root cause and fix plan. Brief: \"Report (a) requirements/task items that are missing or partially implemented; (b) behavior in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but the implementation looks wrong, or that deviate from design.md's stated decisions. Quote the spec/task line for each finding.\"\n\n3. **Run the full test suite.** This is a hard gate alongside both axes \u2014 a change with green axes but red tests isn't verified.\n\n4. **Re-validate artifacts**\n   ```bash\n   tospec validate \"<name>\" --json\n   ```\n   If validation reports an artifact-format or structural problem, fix that artifact and re-run the command until it passes. A review is not complete while artifact validation is red.\n\n5. **Aggregate \u2014 do not merge or rerank**\n\n   Present the two reports under `## Standards` and `## Spec` headings. End with one line per axis: total findings and the worst issue within that axis. Do not pick a single overall verdict across axes.\n\n   This is a **mechanical collation you do yourself** \u2014 collect, label, count. It is not another review pass and not a job for a subagent: nothing reviews these two reports.\n\n**Verify output**\n\nReport the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified \u2014 tell the user it's ready for `tospec-archive`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply), then send **only the hunk that fixed it** back to the axis that reported it \u2014 never the whole axis, and never the other one. You are reviewing the changed code, not the previous report. A clean axis is not re-run for extra confidence.\n\n**Verify guardrails**\n- Standards and Spec axes are independent \u2014 never let one axis's findings influence the other's report\n- Full test suite must be green; a clean review with red tests is not verified\n- Quote the specific spec/task line or hunk for every finding \u2014 no unsupported claims\n- **One review pass per axis \u2014 never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix sees only the hunk that fixed it, and a clean axis is not re-run for extra confidence";
+//# sourceMappingURL=verify.d.ts.map

package/dist/core/templates/fragments/verify.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"verify.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/fragments/verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,iFAAiF;AACjF,eAAO,MAAM,kBAAkB,kyJA0C4N,CAAC;AAE5P,gFAAgF;AAChF,eAAO,MAAM,UAAU,y/JAKtB,CAAC;AAEF,yEAAyE;AACzE,eAAO,MAAM,cAAc,qiBAIoR,CAAC;AAEhT,kFAAkF;AAClF,eAAO,MAAM,aAAa,syKAMJ,CAAC"}

package/dist/core/templates/{workflows → fragments}/verify.js

@@ -1,14 +1,21 @@
 /**
- * Verify methodology (embedded into apply's final step).
+ * Verify methodology — apply's opt-in review.
  *
- * verify is no longer a standalone skill/command — it runs automatically at
- * the end of `tospec-apply`. This module exports the methodology text so
- * `apply.ts` can inline it; there is no skill/command template here anymore.
+ * verify is not a standalone skill/command; it lives inside both apply variants
+ * and runs only when the user asks for it. The methodology is long enough that
+ * leaving it inline puts ~45 lines of end-of-run review in front of an agent
+ * that is still on task 1 of N, so the skill form discloses it to a sibling
+ * `VERIFY.md` and keeps only a pointer. The command form has no sibling file,
+ * so it inlines the same text. Either way this module is the single source of
+ * truth.
  */
+/** The review protocol itself — shared by the disclosed file and the command. */
 export const VERIFY_METHODOLOGY = `Two-axis review of the implementation, run as **independent parallel subagents** so neither pollutes or reranks the other's findings — a change can pass one axis and fail the other, and reporting them separately is what keeps that visible.
 
 **Scope — two subagents, one pass each, and that is the whole review.** The subject under review is always the *code diff*, never another review's output. Do not spawn a third agent to grade the two axes' findings, do not re-review a report you have already written, do not audit the audit. Right-sized review beats deep review: enough eyes to catch real problems, no recursion for its own sake.
 
+**What counts as blocking.** Exactly two kinds of finding block: a **hard violation** of a convention this repo documents, and a **spec-correctness** problem — a requirement missing, implemented wrongly, or contradicting a decision \`design.md\` records. Everything else — judgement calls, style preferences, and every code smell named below — is **report-only**: report it, do not fix it, and do not re-review because of it. A report-only finding is the user's call to make later, not this run's work. Leave this unstated and the safe reading is to fix everything, which makes "re-run only the affected axis" fire on every axis, every time.
+
 **Steps**
 
 1. **Gather context**
@@ -39,11 +46,32 @@ export const VERIFY_METHODOLOGY = `Two-axis review of the implementation, run as
 
 **Verify output**
 
-Report the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified — tell the user it's ready for \`tospec-archive\`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply) and re-run **only the affected axis against the fixed code** until it's clean — you are re-reviewing the changed code, not the previous report, and a passing axis is done, so don't re-run it "to be sure".
+Report the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified — tell the user it's ready for \`tospec-archive\`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply), then send **only the hunk that fixed it** back to the axis that reported it — never the whole axis, and never the other one. You are reviewing the changed code, not the previous report. A clean axis is not re-run for extra confidence.
 
 **Verify guardrails**
 - Standards and Spec axes are independent — never let one axis's findings influence the other's report
 - Full test suite must be green; a clean review with red tests is not verified
 - Quote the specific spec/task line or hunk for every finding — no unsupported claims
-- **One review pass per axis — never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix targets the changed code, and a clean axis is not re-run for extra confidence`;
+- **One review pass per axis — never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix sees only the hunk that fixed it, and a clean axis is not re-run for extra confidence`;
+/** Contents of the `VERIFY.md` shipped beside each apply skill's `SKILL.md`. */
+export const VERIFY_DOC = `# Verify — apply's opt-in review
+
+Run this **when the user asks for a review**, once every task in the tracks file is checked off and \`tospec validate\` passes. It is not a step apply reaches on its own.
+
+${VERIFY_METHODOLOGY}
+`;
+/** The pointer that replaces the methodology inside the apply skills. */
+export const VERIFY_POINTER = `## Verify (opt-in — only when the user asks)
+
+The two-axis review does **not** run on its own. Apply finishes on the full test suite and \`tospec validate\`; a change with those green is implemented, review or no review.
+
+When the user asks for a review, **read \`VERIFY.md\` in this skill's directory and run it in full.** Don't offer it unprompted either — no "shall I review this?" at the end of a run. If a review does run, the change stays unfinished — and must not go to \`tospec-archive\` — until it comes back clean.`;
+/** The same block for the command form, which has no sibling file to point at. */
+export const VERIFY_INLINE = `## Verify (opt-in — only when the user asks)
+
+The two-axis review does **not** run on its own. Apply finishes on the full test suite and \`tospec validate\`; a change with those green is implemented, review or no review.
+
+When the user asks for a review, run the methodology below in full. Don't offer it unprompted either — no "shall I review this?" at the end of a run. If a review does run, the change stays unfinished — and must not go to \`tospec-archive\` — until it comes back clean.
+
+${VERIFY_METHODOLOGY}`;
 //# sourceMappingURL=verify.js.map

package/dist/core/templates/fragments/verify.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/core/templates/fragments/verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,iFAAiF;AACjF,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2PA0CyN,CAAC;AAE5P,gFAAgF;AAChF,MAAM,CAAC,MAAM,UAAU,GAAG;;;;EAIxB,kBAAkB;CACnB,CAAC;AAEF,yEAAyE;AACzE,MAAM,CAAC,MAAM,cAAc,GAAG;;;;+SAIiR,CAAC;AAEhT,kFAAkF;AAClF,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;EAM3B,kBAAkB,EAAE,CAAC"}

package/dist/core/templates/skill-templates.d.ts

@@ -11,6 +11,6 @@ export { getTospecIssueSkillTemplate, getTospecIssueCommandTemplate } from './wo
 export { getTospecDecisionSkillTemplate, getTospecDecisionCommandTemplate } from './workflows/decision.js';
 export { getTospecUpdateSkillTemplate, getTospecUpdateCommandTemplate } from './workflows/update.js';
 export { getTospecApplySkillTemplate, getTospecApplyCommandTemplate, getTospecApplyWithTDDSkillTemplate, getTospecApplyWithTDDCommandTemplate, } from './workflows/apply.js';
-export { getTospecSyncSkillTemplate, getTospecSyncCommandTemplate } from './workflows/sync.js';
+export { getTospecReconcileSkillTemplate, getTospecReconcileCommandTemplate } from './workflows/reconcile.js';
 export { getTospecArchiveSkillTemplate, getTospecArchiveCommandTemplate } from './workflows/archive.js';
 //# sourceMappingURL=skill-templates.d.ts.map

package/dist/core/templates/skill-templates.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"skill-templates.d.ts","sourceRoot":"","sources":["../../../src/core/templates/skill-templates.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,YAAY,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,YAAY,CAAC;AAEjE,OAAO,EAAE,uBAAuB,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AAClG,OAAO,EAAE,qBAAqB,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAC5F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AACxG,OAAO,EAAE,2BAA2B,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAClG,OAAO,EAAE,8BAA8B,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3G,OAAO,EAAE,4BAA4B,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACrG,OAAO,EACL,2BAA2B,EAC3B,6BAA6B,EAC7B,kCAAkC,EAClC,oCAAoC,GACrC,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EAAE,0BAA0B,EAAE,4BAA4B,EAAE,MAAM,qBAAqB,CAAC;AAC/F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC"}
+{"version":3,"file":"skill-templates.d.ts","sourceRoot":"","sources":["../../../src/core/templates/skill-templates.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,YAAY,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,YAAY,CAAC;AAEjE,OAAO,EAAE,uBAAuB,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AAClG,OAAO,EAAE,qBAAqB,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAC5F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AACxG,OAAO,EAAE,2BAA2B,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAClG,OAAO,EAAE,8BAA8B,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3G,OAAO,EAAE,4BAA4B,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACrG,OAAO,EACL,2BAA2B,EAC3B,6BAA6B,EAC7B,kCAAkC,EAClC,oCAAoC,GACrC,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EAAE,+BAA+B,EAAE,iCAAiC,EAAE,MAAM,0BAA0B,CAAC;AAC9G,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC"}

package/dist/core/templates/skill-templates.js

@@ -10,6 +10,6 @@ export { getTospecIssueSkillTemplate, getTospecIssueCommandTemplate } from './wo
 export { getTospecDecisionSkillTemplate, getTospecDecisionCommandTemplate } from './workflows/decision.js';
 export { getTospecUpdateSkillTemplate, getTospecUpdateCommandTemplate } from './workflows/update.js';
 export { getTospecApplySkillTemplate, getTospecApplyCommandTemplate, getTospecApplyWithTDDSkillTemplate, getTospecApplyWithTDDCommandTemplate, } from './workflows/apply.js';
-export { getTospecSyncSkillTemplate, getTospecSyncCommandTemplate } from './workflows/sync.js';
+export { getTospecReconcileSkillTemplate, getTospecReconcileCommandTemplate } from './workflows/reconcile.js';
 export { getTospecArchiveSkillTemplate, getTospecArchiveCommandTemplate } from './workflows/archive.js';
 //# sourceMappingURL=skill-templates.js.map

package/dist/core/templates/skill-templates.js.map

@@ -1 +1 @@
-{"version":3,"file":"skill-templates.js","sourceRoot":"","sources":["../../../src/core/templates/skill-templates.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAIH,OAAO,EAAE,uBAAuB,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AAClG,OAAO,EAAE,qBAAqB,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAC5F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AACxG,OAAO,EAAE,2BAA2B,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAClG,OAAO,EAAE,8BAA8B,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3G,OAAO,EAAE,4BAA4B,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACrG,OAAO,EACL,2BAA2B,EAC3B,6BAA6B,EAC7B,kCAAkC,EAClC,oCAAoC,GACrC,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EAAE,0BAA0B,EAAE,4BAA4B,EAAE,MAAM,qBAAqB,CAAC;AAC/F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC"}
+{"version":3,"file":"skill-templates.js","sourceRoot":"","sources":["../../../src/core/templates/skill-templates.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAIH,OAAO,EAAE,uBAAuB,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AAClG,OAAO,EAAE,qBAAqB,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAC5F,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC;AACxG,OAAO,EAAE,2BAA2B,EAAE,6BAA6B,EAAE,MAAM,sBAAsB,CAAC;AAClG,OAAO,EAAE,8BAA8B,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3G,OAAO,EAAE,4BAA4B,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACrG,OAAO,EACL,2BAA2B,EAC3B,6BAA6B,EAC7B,kCAAkC,EAClC,oCAAoC,GACrC,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EAAE,+BAA+B,EAAE,iCAAiC,EAAE,MAAM,0BAA0B,CAAC;AAC9G,OAAO,EAAE,6BAA6B,EAAE,+BAA+B,EAAE,MAAM,wBAAwB,CAAC"}

package/dist/core/templates/types.d.ts

@@ -11,6 +11,12 @@ export interface SkillTemplate {
     allowedTools?: string[];
     /** When true, emits `disable-model-invocation: true` so the skill only runs when explicitly invoked (e.g. via its slash command), never auto-triggered. */
     disableModelInvocation?: boolean;
+    /**
+     * Extra files written beside `SKILL.md` in the skill directory, keyed by
+     * filename. Used for progressive disclosure: reference the skill points at
+     * but shouldn't carry inline (e.g. apply's `VERIFY.md`).
+     */
+    extraFiles?: Record<string, string>;
 }
 export interface CommandTemplate {
     name: string;

package/dist/core/templates/types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../src/core/templates/types.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,MAAM,WAAW,aAAa;IAC5B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAClC,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;IACxB,2JAA2J;IAC3J,sBAAsB,CAAC,EAAE,OAAO,CAAC;CAClC;AAED,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;CACjB"}
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../src/core/templates/types.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,MAAM,WAAW,aAAa;IAC5B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAClC,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;IACxB,2JAA2J;IAC3J,sBAAsB,CAAC,EAAE,OAAO,CAAC;IACjC;;;;OAIG;IACH,UAAU,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACrC;AAED,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;CACjB"}

package/dist/core/templates/workflows/apply.d.ts

@@ -4,8 +4,8 @@
  * This file is generated by splitting the legacy monolithic
  * templates file into workflow-focused modules.
  *
- * Two apply variants share the same gating (`applyRequires`), auto-verify
- * step, and re-validate step; they differ only in how tests relate to the
+ * Two apply variants share the same gating (`applyRequires`), opt-in verify
+ * section, and re-validate step; they differ only in how tests relate to the
  * implementation:
  *   - `tospec-apply`          — default, tests optional (write one when it earns its keep)
  *   - `tospec-apply-with-tdd` — strict TDD, red → green per slice

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

@@ -1 +1 @@
-{"version":3,"file":"apply.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAmHlE,wBAAgB,2BAA2B,IAAI,aAAa,CAc3D;AAED,wBAAgB,6BAA6B,IAAI,eAAe,CAY/D;AA4BD,wBAAgB,kCAAkC,IAAI,aAAa,CAclE;AAED,wBAAgB,oCAAoC,IAAI,eAAe,CAYtE"}
+{"version":3,"file":"apply.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAsHlE,wBAAgB,2BAA2B,IAAI,aAAa,CAe3D;AAED,wBAAgB,6BAA6B,IAAI,eAAe,CAY/D;AA+BD,wBAAgB,kCAAkC,IAAI,aAAa,CAelE;AAED,wBAAgB,oCAAoC,IAAI,eAAe,CAYtE"}

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

@@ -1,6 +1,10 @@
-import { VERIFY_METHODOLOGY } from './verify.js';
+import { VERIFY_DOC, VERIFY_POINTER, VERIFY_INLINE } from '../fragments/verify.js';
+/**
+ * @param verifySection Skills pass `VERIFY_POINTER` (methodology disclosed to a
+ *   sibling `VERIFY.md`); commands pass `VERIFY_INLINE`, having no sibling file.
+ */
 // ponytail: one parameterized template literal, not a template engine.
-function buildApplyBody(v) {
+function buildApplyBody(v, verifySection) {
     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**
@@ -19,7 +23,7 @@ function buildApplyBody(v) {
 
    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.
+   - \`all_done\` — everything is checked off already; say so and stop. A change being complete is not by itself a reason to review it.
    - \`ready\` — proceed.
 
 3. **Read the context files**
@@ -32,7 +36,7 @@ function buildApplyBody(v) {
 
 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.
+   The tracks file is \`tasks.md\` (sdd) or \`task.md\` (issue). ${v.checkOffRule} 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.
 
@@ -50,15 +54,11 @@ ${v.issueBranch}
    \`\`\`
    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}
+${verifySection}
 
 **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.
+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 and the test suite is green, tell the user the change is ready for \`tospec-archive\`. If they asked for a review and it surfaced findings it defines as blocking, keep working here to resolve them.
 
 **Guardrails**
 ${v.guardrailsHead}
@@ -68,43 +68,46 @@ ${v.guardrailsHead}
 - 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`;
+- Don't hand off to archive until the full test suite is green — and, when a review was requested, until it comes back clean`;
 }
 // -----------------------------------------------------------------------------
 // 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.',
+const APPLY_VARIANT = {
+    checkOffRule: '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.
+3. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; raise it separately once the slice is green.
 
-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.`,
+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).`,
     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.`,
+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.`,
     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`,
-});
+};
+const APPLY_BODY = buildApplyBody(APPLY_VARIANT, VERIFY_POINTER);
+const APPLY_BODY_COMMAND = buildApplyBody(APPLY_VARIANT, VERIFY_INLINE);
 export function getTospecApplySkillTemplate() {
     return {
         name: 'tospec-apply',
-        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.
+        description: "Implement a tospec change's tasks slice by slice (tests optional). Use when the user wants to start or continue implementing a change.",
+        instructions: `Implement a change's tasks one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **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', 'AskUserQuestion'],
+        metadata: { author: 'tospec' },
+        allowedTools: ['Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent', 'AskUserQuestion'],
+        extraFiles: { 'VERIFY.md': VERIFY_DOC },
     };
 }
 export function getTospecApplyCommandTemplate() {
@@ -113,25 +116,25 @@ export function getTospecApplyCommandTemplate() {
         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, 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 — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **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}`,
+${APPLY_BODY_COMMAND}`,
     };
 }
 // -----------------------------------------------------------------------------
 // TDD apply — strict red → green 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.',
+const APPLY_TDD_VARIANT = {
+    checkOffRule: '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.`,
+4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; raise it separately once the slice is green.`,
     issueBranch: `### issue branch — three-way test split
 
 Read \`task.md\`'s feedback loop. Then:
@@ -142,20 +145,23 @@ Read \`task.md\`'s feedback loop. Then:
 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`,
-});
+};
+const APPLY_TDD_BODY = buildApplyBody(APPLY_TDD_VARIANT, VERIFY_POINTER);
+const APPLY_TDD_BODY_COMMAND = buildApplyBody(APPLY_TDD_VARIANT, VERIFY_INLINE);
 export function getTospecApplyWithTDDSkillTemplate() {
     return {
         name: 'tospec-apply-with-tdd',
         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.
+        instructions: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **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', 'AskUserQuestion'],
+        metadata: { author: 'tospec' },
+        allowedTools: ['Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent', 'AskUserQuestion'],
+        extraFiles: { 'VERIFY.md': VERIFY_DOC },
     };
 }
 export function getTospecApplyWithTDDCommandTemplate() {
@@ -164,11 +170,11 @@ export function getTospecApplyWithTDDCommandTemplate() {
         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.
+        content: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **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}`,
+${APPLY_TDD_BODY_COMMAND}`,
     };
 }
 //# sourceMappingURL=apply.js.map

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;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"}
+{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAaA,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AAiBnF;;;GAGG;AACH,uEAAuE;AACvE,SAAS,cAAc,CAAC,CAAe,EAAE,aAAqB;IAC5D,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEA+B0D,CAAC,CAAC,YAAY;;;;;;;;EAQ/E,CAAC,CAAC,SAAS;;EAEX,CAAC,CAAC,WAAW;;;;;;;;EAQb,aAAa;;;;;;;EAOb,CAAC,CAAC,cAAc;;;;;;;6HAO2G,CAAC;AAC9H,CAAC;AAED,gFAAgF;AAChF,wEAAwE;AACxE,gFAAgF;AAEhF,MAAM,aAAa,GAAiB;IAClC,YAAY,EACV,8IAA8I;IAChJ,SAAS,EAAE;;;;;;;yTAO4S;IACvT,WAAW,EAAE;;;;oJAIqI;IAClJ,cAAc,EAAE;;wFAEsE;CACvF,CAAC;AAEF,MAAM,UAAU,GAAG,cAAc,CAAC,aAAa,EAAE,cAAc,CAAC,CAAC;AACjE,MAAM,kBAAkB,GAAG,cAAc,CAAC,aAAa,EAAE,aAAa,CAAC,CAAC;AAExE,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,wIAAwI;QACrJ,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,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,kBAAkB,EAAE;KACnB,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,2CAA2C;AAC3C,gFAAgF;AAEhF,MAAM,iBAAiB,GAAiB;IACtC,YAAY,EACV,sIAAsI;IACxI,SAAS,EAAE;;;;;;4JAM+I;IAC1J,WAAW,EAAE;;;;;;;wMAOyL;IACtM,cAAc,EAAE;yCACuB;CACxC,CAAC;AAEF,MAAM,cAAc,GAAG,cAAc,CAAC,iBAAiB,EAAE,cAAc,CAAC,CAAC;AACzE,MAAM,sBAAsB,GAAG,cAAc,CAAC,iBAAiB,EAAE,aAAa,CAAC,CAAC;AAEhF,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;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,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,sBAAsB,EAAE;KACvB,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;AAmDlE,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;AA6ClE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

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

@@ -1,73 +1,67 @@
-const ARCHIVE_BODY = `**Finishing a change: confirm verify, decide about sync, then archive — in that order.** Do not run \`tospec archive\` speculatively "to see what happens"; each step below must actually hold first.
+const ARCHIVE_BODY = `**Finishing a change: decide about reconcile, then archive — in that order.** Do not run \`tospec archive\` speculatively "to see what happens"; each step below must actually hold first.
 
-**Step 0 — verify already happened in apply**
-
-verify is not a separate command anymore — it runs automatically at the end of \`tospec-apply\`. Before archiving, confirm apply's verify step came back clean (both Standards and Spec axes clear of blocking findings, full test suite green). If apply's verify surfaced blocking issues, **stop** and go back to \`tospec-apply\` to fix them — do not archive over them.
-
-**Step 1 — judge whether a sync is needed, and only ask if it is**
+**Step 1 — judge whether a reconcile is needed, and only ask if it is**
 
 Archive merges the change's delta specs into \`tospec/specs/\`, so if those specs have drifted from what the code actually does, archiving would lock in a spec that no longer matches reality. Decide **proactively** whether that risk applies here:
 
-- **Sync is warranted** when the change produced delta specs (a non-empty \`specs/<capability>/spec.md\` under the change dir) — i.e. behavior was added or changed, so spec-vs-code drift is possible.
-- **Sync is not needed** when there are no delta specs at all (e.g. a purely cosmetic issue fix with no behavior change). In that case skip straight to Step 2 and archive directly — don't ask a pointless question.
+- **Reconcile is warranted** when the change produced delta specs (a non-empty \`specs/<capability>/spec.md\` under the change dir) — i.e. behavior was added or changed, so spec-vs-code drift is possible.
+- **Reconcile is not needed** when there are no delta specs at all (e.g. a purely cosmetic issue fix with no behavior change). In that case skip straight to Step 2 and archive directly — don't ask a pointless question.
 
-If a sync is warranted, **ask the user one question** (make clear both answers are fine):
+If a reconcile is warranted, **ask the user one question** (make clear both answers are fine):
 
-> "This change has spec deltas. Run \`tospec-sync\` to reconcile the specs against the code before archiving? (recommended, but you can archive without it.)"
+> "This change has spec deltas. Run \`tospec-reconcile\` to check the specs against the code before archiving? (recommended, but you can archive without it.)"
 
-- **User says yes** → run the \`tospec-sync\` workflow now. It reconciles each Requirement against the code (code wins) and writes \`sync-report.md\` with \`Conclusion: PASS\`. If it ends in \`Conclusion: FAIL\` (a real CODE-BUG), **stop** and return to \`tospec-apply\` to fix the code — do not archive. On PASS, archive **with** \`--require-sync\` (Step 2, synced branch).
-- **User says no** → that's allowed. Skip the sync and archive **without** \`--require-sync\` (Step 2, not-synced branch). Declining does not block archiving.
+- **User says yes** → run the \`tospec-reconcile\` workflow now. It reconciles each Requirement against the code (code wins) and writes \`reconcile-report.md\` with \`Conclusion: PASS\`. If it ends in \`Conclusion: FAIL\` (a real CODE-BUG), **stop** and return to \`tospec-apply\` to fix the code — do not archive. On PASS, archive **with** \`--require-reconcile\` (Step 2, reconciled branch).
+- **User says no** → that's allowed. Skip the reconcile and archive **without** \`--require-reconcile\` (Step 2, not-reconciled branch). Declining does not block archiving.
 
 **Step 2 — archive**
 
-Synced branch (user chose to sync and \`sync-report.md\` says \`Conclusion: PASS\`):
+Reconciled branch (user chose to reconcile and \`reconcile-report.md\` says \`Conclusion: PASS\`):
 \`\`\`bash
-tospec archive "<name>" --json --require-sync
+tospec archive "<name>" --json --require-reconcile
 \`\`\`
-\`--require-sync\` is the CLI's own machine-checkable half of the sync gate: it refuses unless \`sync-report.md\` exists with a \`Conclusion: 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.
+\`--require-reconcile\` is the CLI's own machine-checkable half of the reconcile gate: it refuses unless \`reconcile-report.md\` exists with a \`Conclusion: PASS\` line (\`RECONCILE_REPORT_MISSING\` / \`RECONCILE_REPORT_FAILED\`). If \`tospec-reconcile\` actually ran and passed, this succeeds for free — a CLI-enforced backstop behind the instruction-level order above. Only pass \`--require-reconcile\` when a reconcile actually ran; otherwise the CLI will (correctly) refuse.
 
-Not-synced branch (sync wasn't needed, or the user declined):
+Not-reconciled branch (reconcile wasn't needed, or the user declined):
 \`\`\`bash
 tospec archive "<name>" --json
 \`\`\`
 
-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.
+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 \`reconcile-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\`.
+**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), \`RECONCILE_REPORT_MISSING\` / \`RECONCILE_REPORT_FAILED\` (the reconcile 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\`)
-- Only pass \`--require-sync\` when \`tospec-sync\` actually produced a passing \`sync-report.md\` this run
-- **Never** construct an archive directory name yourself (the \`yyyyMMdd_HHmmss-<name>\` timestamp is generated by \`tospec archive\`'s internals — you have no way to reproduce it correctly, and guessing risks a collision or a wrong sort order)
-- **Never** create the archive directory yourself
-- **Never** manually move, copy, or rename the change directory
+- Judge whether a reconcile is warranted before archiving; only ask the user when the change has spec deltas — and honor a "no" (archive still proceeds, just without \`--require-reconcile\`)
+- Only pass \`--require-reconcile\` when \`tospec-reconcile\` actually produced a passing \`reconcile-report.md\` this run
+- **\`tospec archive\` owns the archive directory** — it generates the \`yyyyMMdd_HHmmss-<name>\` name and moves the change there. Let the command do it: the timestamp comes from internals you cannot reproduce, so a hand-built name risks a collision or a wrong sort order
 - If \`tospec archive\` reports a validation failure or asks for confirmation on incomplete tasks, resolve the underlying issue (or explicitly confirm with the user) — do not route around it with manual file operations
 
 **Output**
 
-Report the archived name and path from \`tospec archive\`'s output, whether a sync ran, and confirm \`tospec/specs/\` now reflects the merged change.`;
+Report the archived name and path from \`tospec archive\`'s output, whether a reconcile ran, and confirm \`tospec/specs/\` now reflects the merged change.`;
 export function getTospecArchiveSkillTemplate() {
     return {
         name: 'tospec-archive',
-        description: 'Finish and archive a completed change: confirm apply\'s verify was clean, judge whether a spec/code sync is needed (asking the user first when it is), then run the one true tospec archive command. Use when the user wants to finalize an implemented change — never to manually move change directories or invent archive folder names.',
-        instructions: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+        description: 'Finish and archive a completed tospec change via `tospec archive`, deciding first whether a spec/code reconcile is needed. Use when the user wants to finalize an implemented change.',
+        instructions: `Finish a completed change: decide about reconcile (run \`tospec-reconcile\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
 
 **Input**: The user's request should name the change to archive.
 
 ${ARCHIVE_BODY}`,
         license: 'MIT',
         compatibility: 'Requires tospec CLI.',
-        metadata: { author: 'tospec', version: '1.0' },
+        metadata: { author: 'tospec' },
         allowedTools: ['Bash(tospec:*)', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'AskUserQuestion'],
     };
 }
 export function getTospecArchiveCommandTemplate() {
     return {
         name: 'TOSPEC: Archive',
-        description: 'Judge whether a spec/code sync is needed (ask if so), then finalize and archive a completed change',
+        description: 'Judge whether a spec/code reconcile is needed (ask if so), then finalize and archive a completed change',
         category: 'Workflow',
         tags: ['workflow', 'archive'],
-        content: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+        content: `Finish a completed change: decide about reconcile (run \`tospec-reconcile\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
 
 **Input**: The argument after \`tospec-archive\` is the change name to archive.
 

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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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"}
+{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2JAyCsI,CAAC;AAE5J,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,uLAAuL;QACpM,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,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,yGAAyG;QACtH,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;AA8ClE,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;AAiDlE,wBAAgB,8BAA8B,IAAI,aAAa,CAe9D;AAED,wBAAgB,gCAAgC,IAAI,eAAe,CAYlE"}

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

@@ -1,3 +1,4 @@
+import { nextStepLabelRule } from '../fragments/next-step.js';
 const DECISION_BODY = `Capture a decision that has already been made or is ready to be adopted — the reasoning, the alternatives weighed, and what it affects. A decision left only in chat is a decision that gets re-litigated next week.
 
 **Steps**
@@ -14,15 +15,18 @@ const DECISION_BODY = `Capture a decision that has already been made or is ready
    \`\`\`
    Derive a kebab-case \`<topic>\` from the subject. The CLI produces both files: it writes \`tospec/decisions/<yyyyMMdd_HHmmss>-<topic>.md\` from its template (Status/Date/title pre-filled) and appends a row to \`tospec/decisions/index.md\` (seeding that ledger on first use). **The CLI owns the dated filename and the index — never create/rename decision files or hand-edit \`index.md\` yourself.** Use \`--status accepted\` if already agreed, or \`--status superseded\` (and name the successor) when replacing an older decision; pass \`--date\` only to backfill a past decision.
 
-4. **Fill the six sections**
-   Open the created file and complete every section:
+4. **Fill the sections**
+   Open the created file. Six sections are required — they are the structure the schema validates against:
    - **Status** — proposed / accepted / superseded (+ Date); if superseded, name the decision that replaces it.
    - **Context** — the situation and forces that made this decision necessary.
    - **Decision** — what was chosen, the canonical terms, and why this over the alternatives.
    - **Impact** — the modules / APIs / docs / tests this touches.
    - **Alternatives** — each option considered, its trade-offs, and the conclusion.
    - **Follow-up** — the follow-up implementation items, phased if useful.
-   - **Decision Process** (optional) — the key questions you asked and the user's answers that shaped this decision. Format each pair as a \`**Q:** question\` line followed by the answer in the next paragraph, one pair per block. Summarize each Q&A; don't paste a full transcript. Omit the section if there was no interactive discussion.
+
+   The template carries two more that are optional:
+   - **Decision Process** — the key questions you asked and the user's answers that shaped this decision. Format each pair as a \`**Q:** question\` line followed by the answer in the next paragraph, one pair per block. Summarize each Q&A; don't paste a full transcript. Omit the section entirely if there was no interactive discussion.
+   - **Related Changes** — leave it empty. It fills in later, as changes link back via \`tospec new change --decisions\`.
 
 5. **Verify**
    \`\`\`bash
@@ -34,17 +38,16 @@ const DECISION_BODY = `Capture a decision that has already been made or is ready
 
 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 Status 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 \`## Related Changes\` section can list those changes in return).
 
-Then point at the next step. When you put these options to the user, write each label from the decision you just recorded — a short, conversational phrase naming the concrete next action — then append the fixed action keyword in parentheses (\`(update)\`, \`(propose)\`/\`(issue)\`); the words before it must describe *this* action in *this* context, never a canned phrase, and never the raw \`tospec-*\` skill name. If the decision came out of grilling or exploring an **existing** change, offer **(update)** via \`tospec-update\` to fold it into that change's artifacts; if no change exists yet, offer **(propose)** / **(issue)** via \`tospec-propose\`/\`tospec-issue\` and carry the filename into \`--decisions\`.
+Then point at the next step. ${nextStepLabelRule('the decision you just recorded', '\`(update)\`, \`(propose)\`/\`(issue)\`')} If the decision came out of grilling or exploring an **existing** change, offer **(update)** via \`tospec-update\` to fold it into that change's artifacts; if no change exists yet, offer **(propose)** / **(issue)** via \`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
 - Don't record a decision whose rationale or alternatives you can't state — clarify with the user first
-- \`superseded\` must name its successor; the superseded record's Status must be updated too
-- Keep the six required sections — they are the structure the schema validates against; Decision Process is an optional seventh for the Q&A trail (each pair starts with a \`**Q:**\` line, answer in the next paragraph)`;
+- \`superseded\` must name its successor; the superseded record's Status must be updated too`;
 export function getTospecDecisionSkillTemplate() {
     return {
         name: 'tospec-decision',
-        description: 'Record an architecture decision as a permanent ADR (dated decision file + derived index). Use when a design/architecture choice has been made or is ready to adopt and should be documented with its rationale, alternatives, and impact instead of left in chat.',
+        description: 'Record an architecture decision as a permanent ADR. Use when a design/architecture choice has been made or is ready to adopt and should be documented with its rationale, alternatives, and impact instead of left in chat.',
         instructions: `Turn a made (or ready-to-adopt) decision into a permanent ADR record via the \`tospec decision\` command.
 
 **Input**: The user's request should describe the decision and, ideally, the reasoning and the alternatives that were considered.
@@ -52,7 +55,7 @@ export function getTospecDecisionSkillTemplate() {
 ${DECISION_BODY}`,
         license: 'MIT',
         compatibility: 'Requires tospec CLI.',
-        metadata: { author: 'tospec', version: '1.0' },
+        metadata: { author: 'tospec' },
         allowedTools: ['Bash(tospec:*)', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'AskUserQuestion'],
     };
 }