@anionzo/skill 1.3.0 → 1.6.0

package/skills/verification-before-completion/meta.yaml

@@ -1,26 +1,36 @@
 name: verification-before-completion
-version: 0.1.0
-category: verification
-summary: Require fresh evidence before claiming work is done, fixed, passing, or ready.
-summary_vi: Yêu cầu bằng chứng mới trước khi tuyên bố công việc đã xong, đã sửa, đã pass, hoặc sẵn sàng.
+version: 0.3.0
+category: quality
+summary: Iron law enforcement of fresh evidence before completion claims, with forbidden words, anti-rationalization, and AC coverage.
+summary_vi: "Thực thi nghiêm ngặt bằng chứng mới trước khi tuyên bố hoàn thành, với từ cấm, chống rationalization, và AC coverage."
 triggers:
+  - verify this works
+  - check before marking done
+  - confirm the fix
   - before saying a fix works
-  - before marking work complete
   - before commit, PR, or handoff
 inputs:
-  - work completed so far
-  - relevant verification commands or checks
+  - claim being made
+  - verification command or check
+  - optional spec reference for AC coverage
 outputs:
-  - verified claim
-  - blocked verification note
+  - verification status (verified/failed/blocked)
+  - verification levels per deliverable (L1/L2/L3)
+  - AC coverage report (if spec-linked)
   - remaining uncertainty
 constraints:
-  - no success claims without fresh evidence
-  - if verification is blocked, say so plainly
+  - no completion claims without fresh verification evidence
+  - forbidden words without evidence block completion
+  - must run fresh verification, not use stale output
+  - stubs (L1 only) block completion
 related_skills:
   - using-skills
+  - code-review
+  - commit
+  - docs-writer
   - feature-delivery
-  - bug-triage
-  - refactor-safe
+  - debug
+  - go-pipeline
   - planning
-  - code-review
+  - refactor-safe
+  - test-driven-development

package/templates/SKILL.md

@@ -17,7 +17,14 @@ State the job this skill performs.
 
 ## Output Format
 
-- Main sections the response or result should contain
+Present results using the Shared Output Contract:
+
+1. **Goal/Result** — what was accomplished or blocked
+2. **Key Details:**
+   - the most important supporting context
+   - concrete references (files, commands, evidence)
+   - assumptions or gaps
+3. **Next Action** — recommend a follow-up only when a natural handoff exists
 
 ## Red Flags
 

package/skills/bug-triage/SKILL.md

@@ -1,47 +0,0 @@
-# Bug Triage
-
-## Purpose
-
-Investigate failures methodically so the next fix is based on evidence instead of guesswork.
-
-## When To Use
-
-Load this skill when:
-
-- a user reports a bug or regression
-- a test starts failing without obvious cause
-- production behavior no longer matches the intended behavior
-
-## Workflow
-
-1. Restate the symptom in plain language.
-2. Attempt to reproduce the issue or explain why reproduction is blocked.
-3. Narrow the problem:
-   - identify the code path involved
-   - inspect recent behavior changes or assumptions
-   - check inputs, state, timing, or environment differences
-4. Form the smallest credible root-cause hypothesis.
-5. Define the minimal next change or experiment that would confirm the cause.
-6. Add or recommend regression coverage when the cause is clear.
-
-## Output Format
-
-- symptom summary
-- reproduction status
-- suspected root cause
-- impacted area
-- proposed next change
-- confidence level
-
-## Red Flags
-
-- proposing a rewrite before understanding the current failure
-- changing many files before narrowing the cause
-- ignoring whether the behavior is reproducible
-- treating logs or stack traces as proof without checking the code path
-
-## Done Criteria
-
-This skill is complete when the next fix or experiment is specific, minimal, and tied to a clearly stated hypothesis.
-
-If the fix is non-trivial or touches more than one area, hand off to `planning` before moving to `feature-delivery`.

package/skills/bug-triage/examples.md

@@ -1,68 +0,0 @@
-# Examples
-
-## Example 1
-
-User request:
-
-```text
-Users get logged out randomly after the deploy.
-```
-
-Expected result:
-
-- restate the symptom and affected surface area
-- inspect auth session code path and recent deploy changes
-- identify one or two likely causes before editing unrelated modules
-
-Sample completed output:
-
-```
-Symptom: Users with active sessions are being logged out unexpectedly after the v2.4.1 deploy.
-
-Reproduction: Confirmed on staging — session is invalidated ~10 minutes after login even without user action.
-
-Root-Cause Hypothesis:
-- Most likely: SESSION_TTL env var was changed from 3600 to 600 in the deploy config
-- Evidence: session.ts reads process.env.SESSION_TTL; config diff shows the change
-- Uncertainty: not yet confirmed whether all env changes were intentional
-
-Next Change: Restore SESSION_TTL to 3600 in production config and redeploy
-
-Confidence: high
-
-Handoff: feature-delivery (fix is already clear and local)
-```
-
-## Example 2
-
-User request:
-
-```text
-This integration test started failing with a timeout.
-```
-
-Expected result:
-
-- determine where the timeout occurs
-- distinguish between slow setup, deadlock, or missing response
-- propose the smallest confirming step
-
-### Completed output
-
-```
-Symptom: Integration test `test/integration/payment.test.ts` times out after 30s on the "processes valid refund" case.
-
-Reproduction: Confirmed locally — `npm test -- payment` hangs at step 3/5 of the refund flow test.
-
-Root-Cause Hypothesis:
-- Most likely: The mock payment gateway is not responding to the refund callback, causing the test to wait indefinitely
-- Evidence: The test uses a mock server on port 9999; logs show the request is sent but no response is received
-- Alternative: A database connection pool exhaustion from a previous test not cleaning up properly
-- Uncertainty: need to check if the mock server is started before the refund call
-
-Confirming Step: Add a 5s timeout to the mock refund endpoint and log whether it receives the request. If the mock receives it but doesn't respond, the mock handler is missing the refund route.
-
-Confidence: medium
-
-Handoff: planning (once root cause is confirmed, the fix is likely a one-line mock handler addition)
-```

package/skills/bug-triage/meta.yaml

@@ -1,25 +0,0 @@
-name: bug-triage
-version: 0.1.0
-category: debugging
-summary: Turn a bug report or failure symptom into a grounded root-cause hypothesis and a minimal next fix.
-summary_vi: Biến bug report hoặc triệu chứng lỗi thành giả thuyết nguyên nhân gốc có căn cứ và bước sửa tối thiểu tiếp theo.
-triggers:
-  - investigate this error
-  - debug this regression
-  - failing test or production issue
-inputs:
-  - bug report
-  - logs or stack traces when available
-  - code paths involved in the failure
-outputs:
-  - reproduction status
-  - root-cause hypothesis
-  - minimal next change
-constraints:
-  - prove or narrow the cause before broad refactors
-  - call out confidence and uncertainty explicitly
-related_skills:
-  - using-skills
-  - planning
-  - feature-delivery
-  - verification-before-completion

package/skills/bug-triage/references/output-template.md

@@ -1,26 +0,0 @@
-## Symptom
-
-- What is failing and how it shows up
-
-## Reproduction
-
-- reproduced: yes or no
-- notes:
-
-## Root-Cause Hypothesis
-
-- most likely cause:
-- evidence:
-- uncertainty:
-
-## Next Change
-
-- smallest fix or confirming experiment
-
-## Confidence
-
-- low, medium, or high
-
-## Handoff
-
-- Next skill: planning (if fix is non-trivial) or feature-delivery (if fix is already clear)