@aayushchugh/skills 0.1.0 → 0.1.2

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Ayush Chugh
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,39 @@
+# @aayushchugh/skills
+
+These are the agent skills I use while building real products. I keep optimizing them as better practices show up.
+
+The site is [skills.ayushchugh.com](https://skills.ayushchugh.com).
+
+## Install all of them
+
+Run this inside a project, so the package is a dependency:
+
+```bash
+npm install @aayushchugh/skills
+npx skills experimental_sync
+```
+
+`experimental_sync` is a command from the [Vercel skills CLI](https://github.com/vercel-labs/skills). It links skills shipped inside installed npm packages into your agent. The command is experimental, so its name and options can change.
+
+## Install one skill
+
+This installs a single skill from GitHub:
+
+```bash
+npx skills add aayushchugh/skills --skill no-slop -g
+```
+
+Replace `no-slop` with any id below.
+
+## Skills
+
+- `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.
+- `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.
+- `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,9 +1,15 @@
 {
 	"name": "@aayushchugh/skills",
-	"version": "0.1.0",
+	"version": "0.1.2",
 	"description": "The agent skills I use while building real products.",
-	"files": [
-		"skills"
-	],
-	"license": "MIT"
+	"author": "Ayush Chugh <hey@ayushchugh.com>",
+	"license": "MIT",
+	"homepage": "https://skills.ayushchugh.com",
+	"repository": {
+		"type": "git",
+		"url": "git+https://github.com/aayushchugh/skills.git"
+	},
+	"bugs": "https://github.com/aayushchugh/skills/issues",
+	"keywords": ["agent-skills", "skills", "cursor", "claude", "openai", "ai"],
+	"files": ["skills"]
 }

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.