@kynetic-ai/spec 0.8.0 → 0.9.0

package/plugin/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "kspec",
       "description": "kspec agent skills",
-      "version": "0.8.0",
+      "version": "0.9.0",
       "source": "./plugins/kspec",
       "category": "development"
     }

package/plugin/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "kspec",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "kspec agent skills"
 }

package/plugin/plugins/kspec/skills/create-workflow/SKILL.md

@@ -133,6 +133,16 @@ git add templates/skills/<name>/SKILL.md
 git commit -m "feat: add <name> skill for workflow integration"
 ```
 
+### Cross-Skill Consistency Check (When Updating Existing Skills)
+
+If your workflow or wording change is cross-cutting, run this quick consistency pass before committing:
+
+1. List related skills/templates that describe the same concept (for example: `codex`, `pr-review`, `local-review`, review templates).
+2. Verify each related file is either updated in the same PR or explicitly noted as intentionally unchanged.
+3. Add a short checklist in PR notes showing which related files were reviewed.
+
+This prevents partial updates where one skill changes but sibling skills keep outdated guidance.
+
 ## Step Design Guidelines
 
 ### Action Steps

package/plugin/plugins/kspec/skills/plan/SKILL.md

@@ -281,6 +281,16 @@ kspec task set @task-slug --depends-on @other-task
 kspec plan get @plan-slug
 ```
 
+If derived tasks are too generic to execute without chat history, add a structured task note immediately:
+
+```bash
+kspec task note @task-slug "Execution context:
+- Background: why this task exists
+- Scope: concrete boundaries for this task
+- Files: exact files/areas to touch
+- Verification: commands/tests to run"
+```
+
 ## Plan Lifecycle
 
 ```

package/plugin/plugins/kspec/skills/review/SKILL.md

@@ -109,6 +109,7 @@ grep -rn "// AC: @spec-ref" tests/
 ```
 
 Each AC listed in the spec output must have a corresponding annotation. Missing annotations are MUST-FIX.
+Before accepting coverage, confirm each annotation matches the AC text from `kspec item get @spec-ref` (not only the `ac-N` label).
 
 ## Trait AC Coverage
 
@@ -149,6 +150,7 @@ If a trait AC genuinely doesn't apply to this spec, annotate it with a reason:
 ```
 
 The annotation must exist so coverage tooling can track it.
+Annotations must be standalone line comments (`// AC:` or `# AC:`), not embedded inside block/JSDoc comments.
 
 ### No Traits?
 

package/plugin/plugins/kspec/skills/task-work/SKILL.md

@@ -120,6 +120,16 @@ Note when you:
 - Encounter a blocker
 - Complete a significant piece
 
+For tasks that are missing standalone context (for example, generic derived notes), add one structured note before deep implementation work:
+
+```bash
+kspec task note @ref "Execution context:
+- Background: why this task matters
+- Scope: what is in/out for this task
+- Files: exact files expected to change
+- Verification: tests/commands that prove completion"
+```
+
 ### 5. Commit
 
 Include task and spec trailers:

package/plugin/plugins/kspec/skills/triage-automation/SKILL.md

@@ -67,6 +67,7 @@ For each task shown:
   - Is the spec appropriate for this task?
   - Are the ACs adequate and testable?
   - Does the task have sufficient context?
+  - Can the task be executed from task data alone (without hidden chat/session context)?
 - If yes: `kspec task set @ref --automation eligible`
 - If no: Fix issues or mark `needs_review` with specific reason
 

package/templates/skills/create-workflow/SKILL.md

@@ -126,6 +126,16 @@ git add templates/skills/<name>/SKILL.md
 git commit -m "feat: add <name> skill for workflow integration"
 ```
 
+### Cross-Skill Consistency Check (When Updating Existing Skills)
+
+If your workflow or wording change is cross-cutting, run this quick consistency pass before committing:
+
+1. List related skills/templates that describe the same concept (for example: `codex`, `pr-review`, `local-review`, review templates).
+2. Verify each related file is either updated in the same PR or explicitly noted as intentionally unchanged.
+3. Add a short checklist in PR notes showing which related files were reviewed.
+
+This prevents partial updates where one skill changes but sibling skills keep outdated guidance.
+
 ## Step Design Guidelines
 
 ### Action Steps

package/templates/skills/plan/SKILL.md

@@ -274,6 +274,16 @@ kspec task set @task-slug --depends-on @other-task
 kspec plan get @plan-slug
 ```
 
+If derived tasks are too generic to execute without chat history, add a structured task note immediately:
+
+```bash
+kspec task note @task-slug "Execution context:
+- Background: why this task exists
+- Scope: concrete boundaries for this task
+- Files: exact files/areas to touch
+- Verification: commands/tests to run"
+```
+
 ## Plan Lifecycle
 
 ```

package/templates/skills/review/SKILL.md

@@ -102,6 +102,7 @@ grep -rn "// AC: @spec-ref" tests/
 ```
 
 Each AC listed in the spec output must have a corresponding annotation. Missing annotations are MUST-FIX.
+Before accepting coverage, confirm each annotation matches the AC text from `kspec item get @spec-ref` (not only the `ac-N` label).
 
 ## Trait AC Coverage
 
@@ -142,6 +143,7 @@ If a trait AC genuinely doesn't apply to this spec, annotate it with a reason:
 ```
 
 The annotation must exist so coverage tooling can track it.
+Annotations must be standalone line comments (`// AC:` or `# AC:`), not embedded inside block/JSDoc comments.
 
 ### No Traits?
 

package/templates/skills/task-work/SKILL.md

@@ -113,6 +113,16 @@ Note when you:
 - Encounter a blocker
 - Complete a significant piece
 
+For tasks that are missing standalone context (for example, generic derived notes), add one structured note before deep implementation work:
+
+```bash
+kspec task note @ref "Execution context:
+- Background: why this task matters
+- Scope: what is in/out for this task
+- Files: exact files expected to change
+- Verification: tests/commands that prove completion"
+```
+
 ### 5. Commit
 
 Include task and spec trailers:

package/templates/skills/triage-automation/SKILL.md

@@ -61,6 +61,7 @@ For each task shown:
   - Is the spec appropriate for this task?
   - Are the ACs adequate and testable?
   - Does the task have sufficient context?
+  - Can the task be executed from task data alone (without hidden chat/session context)?
 - If yes: `kspec task set @ref --automation eligible`
 - If no: Fix issues or mark `needs_review` with specific reason