@aayushchugh/skills 0.1.1 → 0.1.2

package/README.md

@@ -35,4 +35,5 @@ Replace `no-slop` with any id below.
 - `red-pen` — Red pen. Review a diff or pull request for bugs, regressions, broken callers, missing tests, and unmet requirements.
 - `the-cause` — The cause. Find a bug's root cause from the report, the code path, and the evidence.
 - `go-or-stop` — Go or stop. Decide if a change is ready to ship, with a go or no-go, what to watch, and how to roll back.
+- `the-map` — The map. Map, propose, or improve a system's design like a senior engineer, grounding the recommendation in real usage and activity.
 - `which-skill` — Which skill. Pick and run the right skill, or a chain of skills, for a request.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@aayushchugh/skills",
-	"version": "0.1.1",
+	"version": "0.1.2",
 	"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

@@ -12,6 +12,8 @@ description: >-
 
 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.
 
+Write the smallest set that would catch a real failure. Skip a case that does not change the outcome.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

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

@@ -11,6 +11,8 @@ 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.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

package/skills/no-slop/SKILL.md

@@ -12,6 +12,8 @@ description: >-
 
 Code only. Product docs, PRDs, and other non-code writing are out of scope. On a review, apply these rules to the diff and do not edit unless asked.
 
+Refuse a layer, abstraction, or dependency the current code does not need.
+
 ## Before editing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

package/skills/one-shape/SKILL.md

@@ -12,6 +12,8 @@ description: >-
 
 The audit is read-only until the user approves a batch. Then apply one step at a time with `no-slop`.
 
+Make the smallest change that removes the drift. Do not add an abstraction a third copy does not force.
+
 Skip code the team does not own: `node_modules`, build output, generated files, vendored code, lockfiles, and migrations. A security issue gets one line pointing to `open-doors`.
 
 ## Before auditing

package/skills/open-doors/SKILL.md

@@ -14,6 +14,8 @@ Review application code, APIs, dependencies, secrets, and deployment configurati
 
 This is a read-only audit, not active pentesting. Do not send probes, payloads, traffic, or requests to a live target. Do not claim a control works unless repository evidence proves it. Do not edit the source.
 
+Report a gap a person can actually reach. A theoretical issue with no evidence is not a finding.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

package/skills/plain-paper/SKILL.md

@@ -14,10 +14,12 @@ A spec describes what will be built. Documentation describes what exists.
 
 - A PRD says what and why. It does not choose the implementation.
 - An engineering spec says how the system behaves: interfaces, data, failure, trade-offs, rollout, and verification.
-- Documentation covers a flow, API reference, architecture note, runbook, onboarding guide, README, changelog, user guide, or another document the user names.
+- Documentation covers a flow, API reference, runbook, onboarding guide, README, changelog, user guide, or another document the user names. An architecture note, a system design, or a scale or performance review goes to `the-map`.
 
 Code changes are out of scope. A security need is one requirement. Do not invent controls or run an audit.
 
+Write the short document a person can build or follow. Leave out a section that does not change a decision.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

package/skills/red-pen/SKILL.md

@@ -12,6 +12,8 @@ description: >-
 
 Read the diff, the request it was meant to satisfy, every caller of a changed function, and the tests that cover the path. For a pull request, read the diff with `gh pr diff`. Do not edit the code.
 
+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`.
 
 ## Before writing

package/skills/the-cause/SKILL.md

@@ -12,6 +12,8 @@ description: >-
 
 Read only the path the bug touches, its callers, and the logs, traces, or connected sources needed to prove the cause. Do not edit the code. The fix goes to `no-slop`. The regression case goes to `cases-to-run`.
 
+Name the source. A local workaround is not a cause, and a cause without evidence stays a hypothesis.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.

package/skills/the-map/SKILL.md

@@ -0,0 +1,42 @@
+---
+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.
+---
+
+# The map
+
+## Scope
+
+Writes the design. Does not change code. A PRD or engineering spec stays with `plain-paper`. Building an approved change stays with `no-slop`, and only after the user approves.
+
+Write as a senior engineer: recommend the smallest design that fits the evidence, name the trade-off of what you did not choose, and never reach for a pattern the evidence does not justify.
+
+## Before writing
+
+Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.
+
+Ask which mode when the request does not say:
+
+- **As it is.** Read the repo: entry points, callers, routes, data stores, integrations, and deploy config. Every component cites a file. An unknown part goes under Open questions.
+- **A proposal.** Ask the constraints that would change the design: scale, what already exists, and what must not change. Recommend one design. Name the trade-off and what was not chosen, in one line. Do not invent users, scale, or a deadline.
+- **An improvement.** Read the current design from the code first. Then gather real usage and activity: traffic, growth, hot paths, read/write ratio, latency, error rate, and cost. Read what the repo already exposes for this: logging and metrics code, dashboard config, APM setup. Ask the user for a number the repo does not show. Do not estimate a number neither source gives; put it under Open questions.
+
+## The document
+
+Use only the sections that apply: the job, the components and what each owns, the request path, where data lives, what failure loses or retries, what sits outside the system, the trade-off, and open questions.
+
+For an improvement, add: the evidence read, each proposed change tied to the evidence that justifies it, and a priority of P0, P1, or P2.
+
+- P0: a risk the evidence shows is already happening.
+- P1: a real but smaller gap.
+- P2: polish.
+
+A change with no cited evidence is not proposed. A security need is one line pointing to `open-doors`.
+
+## Replies
+
+Say which mode you used, and what is still open or unconfirmed.

package/skills/which-skill/SKILL.md

@@ -7,6 +7,10 @@ description: >-
 
 # Which skill
 
+## Scope
+
+Run one skill when one fits. Do not start a chain to look thorough.
+
 ## Before writing
 
 Ask every blocking question in one turn. Never invent a fact. Put an unknown under Open questions and name what it blocks. Replies are 1–2 lines. Write a paragraph only when the user asks.
@@ -25,6 +29,7 @@ Read the chosen skill and follow it. Do not restate its rules here.
 | Review a diff or pull request | `red-pen` |
 | Diagnose or debug a failure | `the-cause` |
 | Release check or go / no-go | `go-or-stop` |
+| System design, architecture review, or scale/performance improvement | `the-map` |
 
 Run one skill when one fits. Say which skill or chain you picked in one line. Ask one question when two skills fit equally.
 
@@ -36,5 +41,6 @@ Pause for approval before a step that writes code or would deploy.
 - Feature: `plain-paper` as a spec, then `no-slop`, then `red-pen`.
 - Release: `red-pen`, then `go-or-stop`. A migration is covered inside `go-or-stop`.
 - Cleanup: `one-shape`, which applies its changes through `no-slop`.
+- Design: `the-map`, then `plain-paper` if a spec is still needed, then `no-slop` after approval.
 
-`go-or-stop` does not deploy. `one-shape` does not edit until a batch is approved.
+`go-or-stop` does not deploy. `one-shape` does not edit until a batch is approved. `the-map` does not write code.