@seanmars/tospec 0.6.0 → 0.8.0

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

@@ -1,4 +1,4 @@
-const EXPLORE_BODY = `**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and run \`tospec\` read-only commands, but you must NEVER write code or create artifact files during explore. When the requirement converges, hand off to \`tospec-propose\` or \`tospec-issue\` — those write the files.
+const EXPLORE_BODY = `**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and run \`tospec\` read-only commands, but you must NEVER write code or create artifact files during explore. When the requirement converges, record any material decisions via \`tospec-decision\` first, then hand off to \`tospec-propose\` or \`tospec-issue\` — those write the files.
 
 This is a grilling interview, not a freeform chat. Interview the user relentlessly about the idea or problem until you both share the same understanding, walking every branch of the decision tree — batching questions that stand on their own, but following dependent threads one question at a time.
 
@@ -34,12 +34,25 @@ This is a grilling interview, not a freeform chat. Interview the user relentless
 
    You're done when you can fully restate the requirement back to the user in your own words and they confirm it's correct — not when you run out of questions. If they correct your restatement, that's a sign there's still a hidden branch; keep grilling.
 
-6. **Restate and hand off**
+6. **Restate**
 
-   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). Explore persists nothing itself; the decisions get written into \`proposal.md\`/\`task.md\` by whichever skill you hand off to. Then ask whether to proceed to \`tospec-propose\` (new requirement) or \`tospec-issue\` (something is broken) — or keep exploring if the user isn't ready.
+   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**
+
+   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.
+
+   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.
+
+   \`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.
 
 **Guardrails**
 - **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
 - **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

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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yHA6CoG,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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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"}

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

@@ -0,0 +1,12 @@
+/**
+ * Grill Workflow Template
+ *
+ * On-demand deep-dive interrogation of any artifact (plan / decision / idea)
+ * using a Known/Unknown four-quadrant frame. Explicit-invocation only,
+ * read-only, and — unlike explore — under no obligation to hand off or persist
+ * anything.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getGrillSkillTemplate(): SkillTemplate;
+export declare function getTospecGrillCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=grill.d.ts.map

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

@@ -0,0 +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"}

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

@@ -0,0 +1,61 @@
+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.
+
+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.
+
+**The four quadrants**
+
+Sweep all four — the last two are where the real risk hides:
+
+1. **Known Knowns — what we think we know.** Restate the claims the artifact rests on, then *verify* them. If it's checkable in the codebase, check it — never assume a "known" is true just because it was asserted. A false Known Known is the most dangerous kind.
+2. **Known Unknowns — the open questions already on the table.** Enumerate them and put them to the user, each with your suggested answer and reasoning so they can just confirm.
+3. **Unknown Knowns — the unspoken assumptions.** Surface the premises nobody said out loud and *name them* — the implicit "of course X" that the whole thing quietly depends on. Drag each into the light and confirm it holds.
+4. **Unknown Unknowns — the blind spots.** Probe adjacent territory and reach for analogies that failed elsewhere, to unearth the questions the user didn't know to ask. Ask "what would have to be true for this to blow up?" and chase the answers.
+
+**Interview mechanics**
+
+- **Batch independent questions; sequence dependent ones.** Ask unrelated questions together in a single turn (use \`AskUserQuestion\` — up to 4 at once). A question whose answer depends on another still-open question isn't independent — hold it for a later turn once the question it hangs off is settled.
+- **Every question carries a suggested answer** and the reasoning behind it, so the user can confirm instead of writing an essay.
+- **Look up what's checkable.** Factual questions ("does X already exist", "what does Y currently do") are yours to answer from the codebase — never ask the user something you can verify yourself.
+- **Probe every answer for its hidden premise.** After each answer, ask what it implies that hasn't been said yet. Don't stop at the first plausible answer; keep pulling the thread until it stops giving new information.
+
+**Converge**
+
+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.
+
+**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 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.`;
+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.
+
+${GRILL_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Read', 'Grep', 'Glob', 'AskUserQuestion'],
+    };
+}
+export function getTospecGrillCommandTemplate() {
+    return {
+        name: 'TOSPEC: Grill',
+        description: 'Pressure-test any artifact through a relentless four-quadrant Known/Unknown interrogation',
+        category: 'Workflow',
+        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.
+
+${GRILL_BODY}`,
+    };
+}
+//# sourceMappingURL=grill.js.map

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

@@ -0,0 +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"}

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

@@ -1 +1 @@
-{"version":3,"file":"sync.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA4DlE,wBAAgB,0BAA0B,IAAI,aAAa,CAc1D;AAED,wBAAgB,4BAA4B,IAAI,eAAe,CAY9D"}
+{"version":3,"file":"sync.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA6DlE,wBAAgB,0BAA0B,IAAI,aAAa,CAc1D;AAED,wBAAgB,4BAA4B,IAAI,eAAe,CAY9D"}

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

@@ -54,7 +54,8 @@ Summarize how many Requirements were in sync, how many specs were updated, and w
 - Code is the source of truth for behavior — spec updates always follow code, never the other way around
 - Never edit source code from this workflow — a code-side mismatch is diagnosis, not a license to patch here
 - Every MODIFIED delta must re-pass \`tospec validate\` before moving to the next Requirement
-- \`sync-report.md\` is required output, in the exact format above — \`tospec archive --require-sync\` depends on both its existence and its \`結論:\` line`;
+- \`sync-report.md\` is required output, in the exact format above — \`tospec archive --require-sync\` depends on both its existence and its \`結論:\` line
+- One comparison pass per Requirement — check it against the code once and record the verdict. \`sync-report.md\` is the deliverable, not another review target: don't re-audit the report after writing it, and don't re-check a Requirement already judged MATCH`;
 export function getTospecSyncSkillTemplate() {
     return {
         name: 'tospec-sync',

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

@@ -1 +1 @@
-{"version":3,"file":"sync.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAYA,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0JAwDwI,CAAC;AAE3J,MAAM,UAAU,0BAA0B;IACxC,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,WAAW,EAAE,iTAAiT;QAC9T,YAAY,EAAE;;;;EAIhB,SAAS,EAAE;QACT,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,CAAC;KAC1E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,qEAAqE;QAClF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,MAAM,EAAE,cAAc,CAAC;QAC1C,OAAO,EAAE;;;;EAIX,SAAS,EAAE;KACV,CAAC;AACJ,CAAC"}
+{"version":3,"file":"sync.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAYA,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mQAyDiP,CAAC;AAEpQ,MAAM,UAAU,0BAA0B;IACxC,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,WAAW,EAAE,iTAAiT;QAC9T,YAAY,EAAE;;;;EAIhB,SAAS,EAAE;QACT,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,CAAC;KAC1E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,qEAAqE;QAClF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,MAAM,EAAE,cAAc,CAAC;QAC1C,OAAO,EAAE;;;;EAIX,SAAS,EAAE;KACV,CAAC;AACJ,CAAC"}

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

@@ -31,7 +31,7 @@ const UPDATE_BODY = `Revise a change's existing planning artifacts and keep them
 
 3. **Understand the request**
    - If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
-   - If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
+   - If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts once and check them against each other for contradictions, gaps, and duplication. This is a single read-through, not a recursive audit — don't re-review your own reconciliation after making it.
 
 4. **Read and reconcile**
    - Read the artifact(s) the request touches and the change's other existing artifacts.

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

@@ -5,5 +5,5 @@
  * 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.
  */
-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**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**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) and re-run this verify step until it's clean.\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";
+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**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) and re-run **only the affected axis against the fixed code** until it's clean \u2014 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\".\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 targets the changed code, and a clean axis is not re-run for extra confidence";
 //# sourceMappingURL=verify.d.ts.map

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

@@ -1 +1 @@
-{"version":3,"file":"verify.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/verify.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,eAAO,MAAM,kBAAkB,goGAmCuD,CAAC"}
+{"version":3,"file":"verify.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/verify.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,eAAO,MAAM,kBAAkB,ymIAwCoN,CAAC"}

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

@@ -7,6 +7,8 @@
  */
 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.
+
 **Steps**
 
 1. **Gather context**
@@ -33,12 +35,15 @@ export const VERIFY_METHODOLOGY = `Two-axis review of the implementation, run as
 
    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.
 
+   This is a **mechanical collation you do yourself** — collect, label, count. It is not another review pass and not a job for a subagent: nothing reviews these two reports.
+
 **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 this verify step until it's clean.
+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".
 
 **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`;
+- 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`;
 //# sourceMappingURL=verify.js.map

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

@@ -1 +1 @@
-{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/verify.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sFAmCoD,CAAC"}
+{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/verify.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mPAwCiN,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seanmars/tospec",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "description": "Spec-driven development CLI for structured requirements and issue workflows",
   "license": "MIT",
   "publishConfig": {
@@ -28,14 +28,6 @@
     "schemas",
     "assets"
   ],
-  "scripts": {
-    "build": "node build.js",
-    "skills": "node build.js && node scripts/gen-skills.mjs",
-    "dev": "tsc --watch",
-    "test": "vitest run",
-    "prepack": "node build.js",
-    "prepublish": "node build.js"
-  },
   "engines": {
     "node": ">=22.22.0"
   },
@@ -52,5 +44,12 @@
     "marked": "^18.0.6",
     "yaml": "^2.9.0",
     "zod": "^4.4.3"
+  },
+  "scripts": {
+    "build": "node build.js",
+    "skills": "node build.js && node scripts/gen-skills.mjs",
+    "dev": "tsc --watch",
+    "test": "vitest run",
+    "prepublish": "node build.js"
   }
-}
+}

package/schemas/decision/schema.yaml

@@ -0,0 +1,17 @@
+name: decision
+version: 1
+description: Architecture Decision Record (ADR) workflow
+artifacts:
+  # decision 由專屬 `tospec decision` 指令建立於 tospec/decisions/<yyyy-MM-dd>-<topic>.md,
+  # 不走 change 目錄; 此 artifact 只作為 template 與段落驗證的資料契約。
+  - id: decision
+    generates: decision.md
+    description: 單一 ADR 文件 — 狀態 / 背景 / 決策 / 影響 / 替代方案 / 後續工作
+    template: decision.md
+    requires: []
+    instruction: |
+      依 ADR 規範撰寫一份決策文件。狀態使用 proposed / accepted / superseded;
+      superseded 需註明取代者。決策段要寫清楚選了什麼與為什麼, 替代方案列出評估過的
+      選項與各自優缺點, 影響段列出受影響的模組 / API / 文件 / 測試。
+    validation:
+      requiredSections: [狀態, 背景, 決策, 影響, 替代方案, 後續工作]

package/schemas/decision/templates/decision.md

@@ -0,0 +1,34 @@
+# [決策主題]
+
+## 狀態
+
+- proposed
+- 日期:[yyyyMMdd_HHmmss]
+
+<!-- 狀態: proposed(已提出) / accepted(已採用) / superseded(已被取代, 需註明取代者) -->
+
+## 背景
+<!-- 為什麼要做這個決策: 現況、限制與需求目標 -->
+
+## 決策
+<!-- 選了什麼方案; canonical 術語; 為什麼這樣選而非其他方案 -->
+
+## 影響
+<!-- 受影響的模組 / API / 文件 / 測試 -->
+
+## 替代方案
+<!-- 評估過哪些方案, 各自優缺點與結論 -->
+
+## 後續工作
+<!-- 分階段的後續實作項目 -->
+
+## 決策過程
+<!-- 選配: 關鍵問答紀錄; 每組以 **Q:** 開頭, 下一段為回答; 摘要即可, 不貼逐字稿; 無互動討論可省略 -->
+
+**Q:** [問題]
+
+[回答]
+
+**Q:** [問題]
+
+[回答]

package/schemas/decision/templates/index.md

@@ -0,0 +1,2 @@
+| timestamp | title | summary | file |
+| ----- | ----- | ----- | ----- |