@seanmars/tospec 0.5.0 → 0.7.0

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.5.0",
+  "version": "0.7.0",
   "description": "Spec-driven development CLI for structured requirements and issue workflows",
   "license": "MIT",
   "publishConfig": {
@@ -47,6 +47,7 @@
   },
   "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,28 @@
+# [決策主題]
+
+## 狀態
+
+- proposed
+- 日期:[yyyyMMdd_HHmmss]
+
+<!-- 狀態: proposed(已提出) / accepted(已採用) / superseded(已被取代, 需註明取代者) -->
+
+## 背景
+<!-- 為什麼要做這個決策: 現況、限制與需求目標 -->
+
+## 決策
+<!-- 選了什麼方案; canonical 術語; 為什麼這樣選而非其他方案 -->
+
+## 影響
+<!-- 受影響的模組 / API / 文件 / 測試 -->
+
+## 替代方案
+<!-- 評估過哪些方案, 各自優缺點與結論 -->
+
+## 後續工作
+<!-- 分階段的後續實作項目 -->
+
+## 決策過程
+<!-- 選配: 關鍵問答紀錄 (問了什麼、使用者怎麼回), 摘要即可, 不貼逐字稿; 無互動討論可省略 -->
+- Q: [問題]
+  A: [回答]

package/schemas/decision/templates/index.md

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