@aayushchugh/skills 0.1.3 → 0.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@aayushchugh/skills",
-	"version": "0.1.3",
+	"version": "0.1.5",
 	"description": "The agent skills I use while building real products.",
 	"author": "Ayush Chugh <hey@ayushchugh.com>",
 	"license": "MIT",

package/skills/cases-to-run/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: cases-to-run
 description: >-
-  List cases to verify by hand, or name the code tests for no-slop when
-  asked. Use when the user asks for test cases or to test a flow. Do not edit
-  code or audit security.
+  Use when asked for test cases, QA coverage, or how to test a flow by hand.
+  Not for writing the test code or a security audit.
 ---
 
 # Cases to run
@@ -34,17 +33,22 @@ Cover the relevant happy path, failure, boundary, state change, permission, and
 
 Test one invalid condition at a time. Combine inputs only when they change the outcome together. One behavior is one case, even when the spec and the code both mention it.
 
-Skip a behavior the spec lists as a non-goal. A missing P0 behavior gets a case, or an open question that says why it cannot be tested yet.
+Skip a behavior the spec lists as a non-goal. A missing behavior that loses data, money, access, or the main flow gets a case, or an open question that says why it cannot be tested yet.
 
-A bug gets one regression case: it fails on the current behavior and passes once the expected behavior is true. A state flow gets the valid path plus the invalid transitions a person can actually attempt.
+A bug gets one case: it fails now and passes once the expected behavior is true. A flow gets the valid path plus the invalid steps a person can actually try.
+
+These rules stay inside the skill. Do not print them as labels on a case.
 
 ## The list
 
-The default is a bullet list to verify by hand. Order it P0, then P1, then P2. Each bullet is the behavior and the expected result.
+Each case has these parts, in this order, in plain language a person can follow without the codebase:
+
+- **Case:** a short name of the behavior.
+- **Prerequisites:** only when the case needs a starting state. Leave this out when there is none.
+- **Description:** one or two sentences of what should happen, including the result a person can see.
+- **Steps to verify:** numbered actions. The last step says what to look at and what should be true.
 
-- P0: data loss, money, access, a broken primary flow, or an existing caller that would regress.
-- P1: a common failure or a boundary.
-- P2: a rare edge.
+No priority, no tags, no source line, and no separate test-data or expected-result field. Do not use a word such as journal or handler unless the product shows that word on screen.
 
 ## Code tests
 
@@ -52,7 +56,7 @@ Write code tests only when the user asks for them. Name the behaviors. `no-slop`
 
 ## Summary
 
-Counts by priority, and anything left uncovered. Do not claim complete coverage when the source is ambiguous.
+Say what is still uncovered. Do not claim complete coverage when the source is ambiguous.
 
 ## Replies
 

package/skills/go-or-stop/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: go-or-stop
 description: >-
-  Decide if a change is ready to ship, with a go or no-go, what to watch, and
-  how to roll back. Use when the user asks for a release check. Do not deploy.
+  Use when asked if a change is ready to ship, or for a go or no-go. Not for
+  deploying.
 ---
 
 # Go or stop

package/skills/no-slop/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: no-slop
 description: >-
-  Write the smallest readable code that reuses existing code, installed
-  utilities, and repo patterns, and fixes bugs at the root cause. Use when
-  implementing, fixing, or reviewing code. Do not use for docs.
+  Use when writing or changing code, including a test that was asked for.
+  Not for docs, a review, or a design.
 ---
 
 # No slop

package/skills/one-shape/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: one-shape
 description: >-
-  Audit a repo for duplication, divergent flows, dead code, over-engineering,
-  waste, and standards drift, then apply approved steps. Use when the user
-  asks to refactor or clean up a codebase. Do not audit security.
+  Use when asked to refactor, clean up, or standardize a repo. Not for a
+  security audit or a single pull request.
 ---
 
 # One shape

package/skills/open-doors/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: open-doors
 description: >-
-  Review application code, APIs, dependencies, secrets, and deploy config for
-  injection, web attacks, and DDoS controls. Use when the user asks for a
-  security audit. Never attack a live target.
+  Use when asked for a security audit or a pentest-readiness review. Not for
+  a live attack or a normal code review.
 ---
 
 # Open doors

package/skills/plain-paper/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: plain-paper
 description: >-
-  Write a spec or other documentation from the request, the code, and relevant
-  sources. Use when the user asks for a PRD, spec, flow, API reference,
-  runbook, guide, or README. Do not change code.
+  Use when asked for a PRD, spec, flow, API reference, runbook, guide, or
+  README. Not for code or a system design.
 ---
 
 # Plain paper

package/skills/red-pen/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: red-pen
 description: >-
-  Review a diff or pull request for bugs, regressions, broken callers, missing
-  tests, and unmet requirements. Use when the user asks for a code review. Do
-  not audit security, refactor, or write tests.
+  Use when asked to review a diff, a pull request, or a change. Not for a
+  security audit, a refactor, or writing tests.
 ---
 
 # Red pen

package/skills/the-cause/SKILL.md

@@ -1,9 +1,8 @@
 ---
 name: the-cause
 description: >-
-  Find a bug's root cause from the report, the code path, and the evidence.
-  Use when the user asks to diagnose or debug a failure. Do not write the fix
-  or the regression test.
+  Use when asked to diagnose, debug, or find why something fails. Not for
+  writing the fix or the test.
 ---
 
 # The cause

package/skills/the-map/SKILL.md

@@ -1,10 +1,8 @@
 ---
 name: the-map
 description: >-
-  Map, propose, or improve a system's design like a senior engineer,
-  grounding the recommendation in real usage and activity. Use when the user
-  asks for a system design, architecture review, or scale or performance
-  improvement. Do not write code.
+  Use when asked for a system design, an architecture review, or a scale or
+  performance improvement. Not for writing code or a PRD.
 ---
 
 # The map

package/skills/which-skill/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: which-skill
 description: >-
-  Pick and run the right skill, or a chain of skills, for a request. Use when
-  unsure which skill applies or when a task spans several steps.
+  Use when a request could match more than one skill, or needs several skills
+  in a row.
 ---
 
 # Which skill