@aayushchugh/skills 0.1.2 → 0.1.4

package/README.md

@@ -29,7 +29,7 @@ Replace `no-slop` with any id below.
 
 - `no-slop` — No slop. Write the smallest readable code that reuses existing code, installed utilities, and repo patterns, and fixes bugs at the root cause.
 - `plain-paper` — Plain paper. Write a spec or other documentation from the request, the code, and relevant sources.
-- `cases-to-run` — Cases to run. Write a small, risk-based set of test cases from a spec, diff, or bug report.
+- `cases-to-run` — Cases to run. List the cases to verify by hand, or name the code tests for `no-slop` to write when asked.
 - `open-doors` — Open doors. Review application code, APIs, dependencies, secrets, and deploy config for injection, web attacks, and DDoS controls.
 - `one-shape` — One shape. Audit a repo for duplication, divergent flows, dead code, over-engineering, waste, and standards drift, then apply approved steps.
 - `red-pen` — Red pen. Review a diff or pull request for bugs, regressions, broken callers, missing tests, and unmet requirements.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@aayushchugh/skills",
-	"version": "0.1.2",
+	"version": "0.1.4",
 	"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,16 +1,16 @@
 ---
 name: cases-to-run
 description: >-
-  Write a small, risk-based set of test cases from a spec, diff, or bug
-  report. Use when the user asks for test cases or QA coverage. Do not write
-  test code or audit security.
+  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.
 ---
 
 # Cases to run
 
 ## Scope
 
-Write the test-case document only. Do not write test code, run tests, or change the source. Cover a security requirement or access rule the source already states. Do not invent controls.
+Do not edit code. `no-slop` is the only skill that writes. Do not write anything until asked. Cover a security requirement or access rule the source already states. Do not invent controls.
 
 Write the smallest set that would catch a real failure. Skip a case that does not change the outcome.
 
@@ -26,41 +26,38 @@ Ask what would change the expected behavior, data, environment, limits, or permi
 - Code or a diff: the changed behavior, its contract, its callers, and the conditions that changed. Stop at the affected path.
 - A bug report: the shortest reproduction, expected versus actual behavior, and the environment when it changes the result.
 
-If the repository already tests a behavior, cite that test. Do not write a duplicate manual case.
+If the repository already tests a behavior, say so. Do not ask `no-slop` to add a second copy, and do not repeat it as a manual case.
 
 ## Which cases
 
 Cover the relevant happy path, failure, boundary, state change, permission, and regression. Use one representative value per equivalence class. A boundary is the edge: the last allowed value and the first rejected value.
 
-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. Cite both sources on that case.
+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.
 
-## Priority
+These rules stay inside the skill. Do not print them as labels on a case.
 
-Order the document P0, then P1, then P2.
+## The list
 
-- 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.
+Each case has these parts, in this order, in plain language a person can follow without the codebase:
 
-## Each case
+- **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.
 
-- ID
-- Title
-- Source requirement or changed behavior
-- Priority
-- Preconditions: role, starting data, and starting state
-- Test data
-- Steps: actions only. Do not repeat the expected result.
-- Expected result: only what a person can see, including the error, the resulting state, and data that must stay unchanged
-- Tags: `happy`, `failure`, `boundary`, `permission`, or `regression`. Use one only when it applies. Use no other tag.
+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
+
+Write code tests only when the user asks for them. Name the behaviors. `no-slop` writes the test in the repo's existing style. If the repo has no test runner, ask once before `no-slop` adds one.
 
 ## Summary
 
-Counts by priority. Each source requirement or changed behavior mapped to case IDs. Anything left uncovered. Then assumptions and open questions. Do not add a matrix. 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

@@ -11,7 +11,7 @@ description: >-
 
 Read the diff, the test results, the migrations, the feature flags, the dependency changes, the deploy config, and the known risks. Do not deploy, change production, or create a release until the user explicitly approves that step.
 
-No-go when a test result, a migration check, or a rollback is missing. Do not talk the release into a go.
+No-go when a migration check or a rollback is missing. A failed or missing test result is a no-go only when the repo already has test code. A repo with no test code skips that check. Do not talk the release into a go.
 
 ## Before writing
 
@@ -22,7 +22,7 @@ Ask the target environment, the migrations included, and the checks already run.
 ## The check
 
 - What changed, in one line per user-facing change. Leave out internal refactors.
-- Tests: which ran, which failed, and which did not run.
+- Tests, when the repo has test code: which ran, which failed, and which did not run. A repo with no test code skips this check.
 - Migrations and backfills. Each one needs the current state (table, row count, rows touched), the forward change, a rollback or the data that would be lost, steps that are safe to re-run, batching for a large table, and a check that proves the result. A migration missing any of these is a no-go.
 - Feature flags and dependency changes.
 - Known risks, each with the check that would catch it.
@@ -35,7 +35,7 @@ Ask the target environment, the migrations included, and the checks already run.
 - The rollback steps, in the order to run them.
 - A short note of what changed for users.
 
-A missing test result, a migration missing any item above, or an unknown rollback is a no-go. Do not invent a test result.
+A migration missing any item above, or an unknown rollback, is a no-go. A missing test result is a no-go only when the repo has test code. Do not invent a test result.
 
 ## Replies
 

package/skills/no-slop/SKILL.md

@@ -27,7 +27,7 @@ Ask only what would change the requested files, behavior, API, or approach. Leav
 3. Prefer, in order: do nothing, existing code, the standard library, a native platform feature, an already-installed dependency. If that dependency exports the function, call it. Do not rewrite date-fns, lodash, or any other installed package.
 4. Make the smallest readable change that finishes the requested behavior. A bug report names a symptom. Find the source and fix that. A shared-function fix keeps existing callers working, unless their current behavior is the bug.
 5. Keep trust-boundary validation and error handling that prevents data loss.
-6. Run the repo's existing test for the changed path. Add one small check only when that path has no test and the branch is non-trivial.
+6. Run the existing test for the changed path when one exists. If the project has no test code, do not add one and do not block. Write a test only when `cases-to-run` or the user asks.
 
 ## Rules
 

package/skills/one-shape/SKILL.md

@@ -54,11 +54,11 @@ Mark each step's effort and risk as low, medium, or high.
 
 Order the steps: delete dead code, then replace reimplemented code, then fix standards drift, then unify flows, then simplify what is left. A formatting-only change is its own step and uses the repo's formatter. Never mix it with a logic change.
 
-Each step is small, keeps behavior the same, ships on its own, names its files, and names the test that checks it. When no test covers a step, say so and use `cases-to-run` before that step. A merge keeps every current caller's output the same. If any caller's output would change, that needs its own approved step. On a big repo, the user approves one batch at a time.
+Each step is small, keeps behavior the same, ships on its own, names its files, and names the test that checks it when one exists. A repo with no test code does not block a step. A merge keeps every current caller's output the same. If any caller's output would change, that needs its own approved step. On a big repo, the user approves one batch at a time.
 
 Stop after the report. Edit nothing until the user approves a batch.
 
-1. Before the first step, run the repo's lint, typecheck, and tests, and record what already fails.
+1. Before the first step, run the repo's lint, typecheck, and tests when the repo has them, and record what already fails.
 2. Apply one approved step at a time with `no-slop`. Each step stays its own diff.
 3. After each step, run the same checks. If a new failure appears, revert that step, stop, and report.
 4. After a batch, re-check the remaining steps, then wait for the next approval.

package/skills/red-pen/SKILL.md

@@ -14,7 +14,7 @@ Read the diff, the request it was meant to satisfy, every caller of a changed fu
 
 Report a bug, a regression, or a missed requirement. A style comment is not a finding.
 
-A security finding gets one line pointing to `open-doors`. A structure or duplication finding gets one line pointing to `one-shape`. A missing test gets one line pointing to `cases-to-run`.
+A security finding gets one line pointing to `open-doors`. A structure or duplication finding gets one line pointing to `one-shape`. A missing test is a finding only where the project already tests that kind of path. A project with no tests gets one line pointing to `cases-to-run`, not a finding per file.
 
 ## Before writing
 
@@ -24,7 +24,7 @@ Ask what would change whether a finding is real.
 
 ## Findings
 
-Report a correctness bug, a regression, a break in an API a caller depends on, a missing test for a changed path, or a requirement the change did not meet.
+Report a correctness bug, a regression, a break in an API a caller depends on, a missing test where the project already tests that kind of path, or a requirement the change did not meet.
 
 Each finding has: ID, Title, Severity, File and line, Evidence, Impact, Fix in one or two lines.
 
@@ -34,7 +34,7 @@ One finding per root cause. The same bug in several callers is one finding: name
 
 - Critical: the change loses data, breaks a primary flow, or breaks callers that are already in use.
 - High: a real bug on a common path, or a requirement the change missed.
-- Medium: a bug that needs another condition, or a missing test on a non-trivial branch.
+- Medium: a bug that needs another condition, or a missing test on a non-trivial branch where the project already has tests.
 
 ## Summary
 

package/skills/which-skill/SKILL.md

@@ -23,7 +23,7 @@ Read the chosen skill and follow it. Do not restate its rules here.
 | --- | --- |
 | Implement, fix, or review code | `no-slop` |
 | PRD, engineering spec, flow, API reference, runbook, guide, or README | `plain-paper` |
-| Test cases or regression coverage | `cases-to-run` |
+| Manual test cases, or code tests for `no-slop` when asked | `cases-to-run` |
 | Security audit | `open-doors` |
 | Refactor or clean up a repo | `one-shape` |
 | Review a diff or pull request | `red-pen` |