swe-workflow-skills 0.9.0 → 0.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -6,76 +6,29 @@
6
6
  [![license: MIT](https://img.shields.io/badge/license-MIT-yellow.svg)](LICENSE)
7
7
 
8
8
  A curated library of **66 Claude Code Agent Skills** that walk Claude through the
9
- software lifecycle the way a disciplined senior engineer would — planning, design,
9
+ software lifecycle the way a disciplined senior engineer would: planning, design,
10
10
  TDD, review, security, deployment, incidents, and the project-management work around
11
11
  them.
12
12
 
13
- Each skill encodes a *method* (DRY, YAGNI, KISS, clean architecture, evidence-before-done),
14
- not just a task. They compose into end-to-end workflows and are kept honest by an
15
- LLM-as-judge eval harness.
13
+ Each skill encodes a *method* (DRY, YAGNI, KISS, clean architecture, evidence before
14
+ "done"), not just a task. An orchestrator skill, **`skill-router`**, matches your intent
15
+ to the right skills and chains them across phases. Every skill is kept honest by an
16
+ **LLM-as-judge evaluation harness** that compares the model with and without the skill.
16
17
 
17
18
  ![skill-router routing a live session](docs/demo/routing.gif)
18
19
 
19
- ## Why this library
20
-
21
- Not just a pile of skills — a routing layer over Claude Code's native skill
22
- activation, an eval discipline, and full-SDLC breadth that popular collections
23
- don't cover:
24
-
25
- - **An orchestrator, not auto-trigger roulette.** A `skill-router` skill maps your
26
- intent to the right skill(s) and chains them across phases. Community measurements put
27
- Claude's own description-based auto-triggering at roughly a coin flip to ~84%; here
28
- activation is *routed and deterministic* instead, and the routing eval harness measures
29
- it (top-1 accuracy 65/65 and one boundary misroute in 65 on the committed k=3 baseline,
30
- regression-gated in CI) — see the [routing benchmark](docs/ROUTING-BENCHMARK.md). This is the one thing the
31
- platform still doesn't do for you.
32
- - **Every skill stays reachable, no pre-picking.** Claude Code injects skill descriptions
33
- only up to ~1% of context, so large libraries silently stop auto-triggering past ~20–40
34
- skills. The fix is Claude Code's own **`name-only`** state (its docs recommend it for
35
- low-priority skills); this library just applies it wholesale — keeping the router +
36
- safety skills "loud" and listing the rest name-only — so the router can still invoke
37
- every skill by name, with no cropping and without making you pre-pick a subset
38
- ([how it works](docs/ROLES.md)).
39
- - **Tested like code, not prose.** Every skill ships 3 evals; two LLM-as-judge
40
- harnesses (content quality and routing accuracy) replay them with skill loaded vs
41
- absent and gate regressions in CI. Across all 66 skills — 234 cases, 1315 assertions,
42
- every row measured at k>=3 — the same model passes **64.1%** of assertions without the
43
- skill's content and **97.9%** with the skill loaded, and **no skill scores below the
44
- no-content baseline on any case**
45
- ([results](docs/EVALS.md#results-content-evals-full-catalog)). Safety-critical skills
46
- (deploys, releases, tests, incidents, security) are **hardened**: an Iron Law, a
47
- rationalization table distilled from real baseline failures, and pressure tests that
48
- try to talk the agent out of it.
49
- - **Curated, not a mega-catalog.** First-party skills, versioned and eval-gated in the
50
- repo — no arbitrary third-party skills pulled from a hub, and nothing that executes on
51
- its own (the content is instructions and templates; the only code is the open Node
52
- installer). In an ecosystem where researchers have flagged hundreds of malicious
53
- community skills, curated-and-reviewed is itself a feature — see [SECURITY.md](SECURITY.md).
54
- - **Full-SDLC breadth.** Planning, architecture/ADRs, API and data design, TDD, review,
55
- security, releases, deploys, GitOps, observability, incidents, MLOps, LLM apps
56
- and AI evaluation, data pipelines and data quality, and the PM/strategy work
57
- around them — a wider slice of the lifecycle than the community collections we
58
- know of aim for (they tend to go deep on the coding inner loop; see
59
- [Acknowledgements](#acknowledgements)).
60
- - **Role-scoped.** `/role backend` (or `frontend`, `devops`, `ml`, `ai`, `data`,
61
- `data-scientist`, `security`, `architect`, `em`, `pm`, `strategy`, `qa`, `mobile`,
62
- `designer`) promotes a working set to auto-trigger; the rest stay one route away.
63
- - **Cross-platform install.** The installer and SessionStart hook are **pure Node** — the
64
- one runtime Claude Code already requires — so they run identically on Linux, macOS, and
65
- Windows (no bash, Python, or `sed`).
66
-
67
20
  ## Quick Start
68
21
 
69
- **Most people — install the per-role plugin for your hat** (works on CLI, Claude Code
70
- web, claude.ai chat, and Cowork):
22
+ **Most people: install the per-role plugin for your hat.** It works on the CLI, Claude
23
+ Code web, claude.ai chat, and Cowork:
71
24
 
72
25
  ```text
73
26
  /plugin marketplace add SWEStash/swe-workflow-skills
74
27
  /plugin install swe-workflow-pm@swe-workflow
75
28
  ```
76
29
 
77
- **Want the whole library with the orchestrator** (CLI) — no clone needed. This is a
78
- **two-step** setup:
30
+ **Want the whole library with the orchestrator?** On the CLI, with no clone needed, it
31
+ is a **two-step** setup:
79
32
 
80
33
  ```bash
81
34
  # 1. Install all 66 skills + router + /role + the hook script, and apply the baseline
@@ -84,16 +37,16 @@ npx swe-workflow-skills install --global
84
37
 
85
38
  ```jsonc
86
39
  // 2. Wire the hook: merge the snippet the installer prints into your settings.json
87
- // (the installer never edits settings.json for you — it just prints the block).
40
+ // (the installer never edits settings.json for you; it just prints the block).
88
41
  // Then start a new session; /doctor should show the hook registered.
89
42
  { "hooks": { "SessionStart": [ /* ...the printed block... */ ] } }
90
43
  ```
91
44
 
92
45
  > ⚠️ **Don't skip step 2.** Step 1 alone installs the skills and prevents cropping, but
93
- > the hook is what nudges Claude to consult `skill-router` first — **without it, skills
94
- > won't auto-route** (the whole point of the library) and the baseline isn't re-asserted
46
+ > the hook is what nudges Claude to consult `skill-router` first. **Without it, skills
47
+ > won't auto-route** (the whole point of the library), and the baseline isn't re-asserted
95
48
  > after `/compact`. If you deliberately want no hook, pass `--no-hook`; auto-routing stays
96
- > off until a hook is wired. The **per-role plugin** path above needs no hook — it's
49
+ > off until a hook is wired. The **per-role plugin** path above needs no hook: it is
97
50
  > self-contained.
98
51
 
99
52
  Or from a clone: `node install.mjs --global`.
@@ -119,20 +72,20 @@ npx swe-workflow-skills uninstall --dry-run # preview removal; --global/--dir
119
72
 
120
73
  From a clone, the same commands are `node install.mjs …` / `node uninstall.mjs …`.
121
74
 
122
- The installer never edits `settings.json` — it prints the SessionStart hook snippet for
75
+ The installer never edits `settings.json`: it prints the SessionStart hook snippet for
123
76
  you to merge. Re-running is idempotent. See **[INSTALL-MATRIX.md](docs/INSTALL-MATRIX.md)**
124
77
  for every method × surface, and **[ROLES.md](docs/ROLES.md)** for the activation model.
125
78
 
126
79
  ## Usage
127
80
 
128
- On any non-trivial task, Claude consults **`skill-router`** first; it reads the full
81
+ On any non-trivial task, Claude consults **`skill-router`** first. It reads the full
129
82
  catalog and invokes the matching skill(s) by name, re-routing as the work changes phase.
130
- The default SessionStart hook nudges Claude to do this automatically; you can also route
131
- explicitly ("use the security-audit skill") or switch the promoted set with `/role`. Don't
132
- want a particular skill routed at all? `npx swe-workflow-skills disable <skill>` opts it out
133
- durably — see [disable a skill from routing](docs/ROLES.md#advanced-disable-a-skill-from-routing).
83
+ The default SessionStart hook nudges Claude to do this automatically. You can also route
84
+ explicitly ("use the security-audit skill") or switch the promoted set with `/role`.
85
+ Don't want a particular skill routed at all? `npx swe-workflow-skills disable <skill>`
86
+ opts it out durably; see [disable a skill from routing](docs/ROLES.md#advanced-disable-a-skill-from-routing).
134
87
 
135
- **A routed chain, by phase** — e.g. *"add OAuth login"*:
88
+ **A routed chain, by phase**, e.g. *"add OAuth login"*:
136
89
 
137
90
  ```
138
91
  feature-planning → scope tasks, acceptance criteria, risks
@@ -146,16 +99,37 @@ verification-before-completion
146
99
  deployment-checklist → pre-deploy safety + rollback readiness
147
100
  ```
148
101
 
149
- The router invokes each skill as you reach its phase rather than all at once. A single
150
- request often fans out to several skills — *"review this for accessibility and UX"* pulls
151
- in both `accessibility-design` and `ui-ux-design`. See a full session play out in
152
- **[what routing looks like](docs/ROLES.md#what-routing-looks-like-in-a-session)**; the
153
- pre-built chains (new feature · bug/incident · continuous improvement · pre-public
154
- review) live in the `skill-router` skill and **[ROLES.md](docs/ROLES.md)**.
102
+ The router invokes each skill as you reach its phase rather than all at once, and one
103
+ request can fan out to several skills. See a full session in
104
+ **[what routing looks like](docs/ROLES.md#what-routing-looks-like-in-a-session)**.
105
+
106
+ ## Why this library
107
+
108
+ - **An orchestrator, not auto-trigger roulette.** Description-based auto-triggering is
109
+ probabilistic. Here `skill-router` routes intent to skills by name, and a routing
110
+ harness measures it: 65/65 top-1 and 64/65 on boundary cases on the committed k=3
111
+ baseline ([routing benchmark](docs/ROUTING-BENCHMARK.md)).
112
+ - **Every skill stays reachable.** Claude Code lists skill descriptions only up to about
113
+ 1% of context, so large libraries stop auto-triggering past 20 to 40 skills. This
114
+ library keeps the router and safety skills fully listed and the rest **`name-only`**
115
+ (Claude Code's own setting for low-priority skills), so every skill is one route away
116
+ with no pre-picking ([how it works](docs/ROLES.md)).
117
+ - **Tested like code, not prose.** Across 234 eval cases and 1323 assertions, the same
118
+ model passes **63.6%** of assertions without the skill's content and **97.9%** with
119
+ it, and **no case scores lower with the skill** ([results](docs/EVALS.md#results-content-evals-full-catalog)).
120
+ Safety-critical skills are **hardened** with an Iron Law, a rationalization table, and
121
+ pressure tests.
122
+ - **Curated, not a mega-catalog.** First-party and reviewed. Nothing executes on its own
123
+ except the open Node installer ([SECURITY.md](SECURITY.md)).
124
+ - **Full-SDLC breadth, role-scoped.** From planning to incidents, plus MLOps, LLM apps,
125
+ data, and PM work. `/role backend` (or any of 15 roles) promotes a working set to
126
+ auto-trigger.
127
+ - **Cross-platform.** The installer and hook are pure Node, so they run the same on
128
+ Linux, macOS, and Windows.
155
129
 
156
130
  ## What's included
157
131
 
158
- 66 skills — **[full catalog → SKILLS.md](docs/SKILLS.md)**:
132
+ 66 skills, listed in the **[full catalog → SKILLS.md](docs/SKILLS.md)**:
159
133
 
160
134
  | Area | Count | Examples |
161
135
  |------|-------|----------|
@@ -171,31 +145,29 @@ review) live in the `skill-router` skill and **[ROLES.md](docs/ROLES.md)**.
171
145
  | Evaluation & Monitoring | 2 | observability-design, test-data-strategy |
172
146
  | Meta | 2 | skill-router, writing-skills |
173
147
 
174
- ## Documentation
148
+ ## Evaluation
175
149
 
176
- - **[ROLES.md](docs/ROLES.md)** — the activation model (name-only baseline, roles, the orchestrator) and the CLI vs web/plugin paths.
177
- - **[INSTALL-MATRIX.md](docs/INSTALL-MATRIX.md)** — every install method × surface, side by side.
178
- - **[SKILLS.md](docs/SKILLS.md)** — the full skill catalog by area.
179
- - **[EVALS.md](docs/EVALS.md)** — how the skills are tested (RED/GREEN, pressure tests, CI gate).
180
- - **[ROUTING-BENCHMARK.md](docs/ROUTING-BENCHMARK.md)** — the routing reliability numbers, methodology, and how to reproduce them.
181
- - **[AUTHORING.md](docs/AUTHORING.md)** — write or modify a skill (descriptions, budget, progressive disclosure, evals).
182
- - **[RELEASING.md](docs/RELEASING.md)** — versioning policy and how to cut a release. Changes are tracked in **[CHANGELOG.md](CHANGELOG.md)**.
183
- - **[SECURITY.md](SECURITY.md)** — the security model: trust boundaries, what runs automatically, supply-chain guarantees, and how to report a vulnerability.
150
+ Every skill ships 3 evals (happy path, edge case, scope boundary), and safety skills add
151
+ pressure tests. Each case is replayed with the skill loaded (GREEN) and without it (RED),
152
+ and a skeptical LLM-as-judge grades every assertion. Evals run in-session through
153
+ `evals/workflow-runner.mjs`, with no API key, and the results are committed to
154
+ `evals/baseline.json`. Merging a re-run reports any assertion that regressed. Full guide
155
+ in **[EVALS.md](docs/EVALS.md)**.
184
156
 
185
- ## Evaluation
157
+ ## Documentation
186
158
 
187
- Each skill carries an `evals/` directory; safety/discipline skills add a `pressure_tests`
188
- block. Two runners replay scenarios through Claude (skill loaded = GREEN, absent = RED)
189
- and judge each assertion with a skeptical LLM-as-judge: `evals/workflow-runner.mjs`
190
- (in-session, no API key) and `evals/run.py` (CI regression gate, wired into
191
- `.github/workflows/skill-evals.yml`). The GREEN arm reads the skill *and* the
192
- `references/`/`templates/` files it links to, so improving a reference file moves the
193
- score. The first runner writes `evals/baseline.json`; the second gates against it.
194
- Full guide in **[EVALS.md](docs/EVALS.md)**.
159
+ - **[ROLES.md](docs/ROLES.md)**: the activation model (name-only baseline, roles, the orchestrator) and the CLI vs web/plugin paths.
160
+ - **[INSTALL-MATRIX.md](docs/INSTALL-MATRIX.md)**: every install method × surface, side by side.
161
+ - **[SKILLS.md](docs/SKILLS.md)**: the full skill catalog by area.
162
+ - **[EVALS.md](docs/EVALS.md)**: how the skills are tested (RED/GREEN, pressure tests, the regression baseline).
163
+ - **[ROUTING-BENCHMARK.md](docs/ROUTING-BENCHMARK.md)**: the routing reliability numbers, methodology, and how to reproduce them.
164
+ - **[AUTHORING.md](docs/AUTHORING.md)**: write or modify a skill (descriptions, budget, progressive disclosure, evals).
165
+ - **[RELEASING.md](docs/RELEASING.md)**: versioning policy and how to cut a release. Changes are tracked in **[CHANGELOG.md](CHANGELOG.md)**.
166
+ - **[SECURITY.md](SECURITY.md)**: the security model, what runs automatically, supply-chain guarantees, and how to report a vulnerability.
195
167
 
196
168
  ## Contributing
197
169
 
198
- New or improved skills are welcome — start with **[AUTHORING.md](docs/AUTHORING.md)** (or
170
+ New or improved skills are welcome. Start with **[AUTHORING.md](docs/AUTHORING.md)** (or
199
171
  install the `writing-skills` skill). The short version: descriptions are everything, keep
200
172
  SKILL.md concise with detail in `references/`, and ship exactly 3 evals.
201
173
 
@@ -203,23 +175,23 @@ SKILL.md concise with detail in `references/`, and ship exactly 3 evals.
203
175
 
204
176
  This library stands on ideas from projects we found genuinely useful:
205
177
 
206
- - **[obra/superpowers](https://github.com/obra/superpowers)** — the guardrail pattern
178
+ - **[obra/superpowers](https://github.com/obra/superpowers)**: the guardrail pattern
207
179
  our hardened safety skills adopt (an Iron Law, a rationalization table distilled from
208
180
  real failures, and pressure tests that try to talk the agent out of it) comes from
209
181
  Jesse Vincent's work here, as does the idea of a Socratic brainstorming skill as the
210
182
  entry point to a feature. Superpowers goes deeper on the coding inner loop than we do;
211
183
  if that's what you want, use it.
212
- - **[anthropics/skills](https://github.com/anthropics/skills)** — Anthropic's official
184
+ - **[anthropics/skills](https://github.com/anthropics/skills)**: Anthropic's official
213
185
  skills (and `skill-creator` in particular) are the authoring practice we benchmark
214
186
  ours against; the eval-first loop in [AUTHORING.md](docs/AUTHORING.md) follows the
215
187
  same instinct.
216
188
  - **The [Agent Skills docs](https://code.claude.com/docs/en/skills) and Anthropic's
217
- engineering posts** — progressive disclosure, the listing budget, and the
189
+ engineering posts**: progressive disclosure, the listing budget, and the
218
190
  `name-only` + `skillOverrides` activation surface this library's routing model is
219
191
  built on.
220
- - **The awesome-claude-skills community lists** — the ecosystem survey that shaped our
192
+ - **The awesome-claude-skills community lists**: the ecosystem survey that shaped our
221
193
  gap analysis of what a full-SDLC library should cover.
222
194
 
223
195
  ## License
224
196
 
225
- MIT — see [LICENSE](LICENSE).
197
+ MIT, see [LICENSE](LICENSE).
package/VERSION CHANGED
@@ -1 +1 @@
1
- 0.9.0
1
+ 0.10.0
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "swe-workflow-skills",
3
- "version": "0.9.0",
3
+ "version": "0.10.0",
4
4
  "description": "A curated library of Claude Code Agent Skills covering the full software lifecycle, with orchestrator-routed activation that scales past the skill-listing budget.",
5
5
  "type": "module",
6
6
  "bin": {
@@ -10,7 +10,8 @@
10
10
  "Covers the RAG triad or equivalent — faithfulness/groundedness, answer relevance, and retrieval/context quality — and distinguishes retrieval metrics from generation metrics",
11
11
  "Recommends a concrete evaluation tool (ragas, deepeval, or promptfoo) and explains its role",
12
12
  "Addresses LLM-as-judge reliability with at least one concrete measure: rubric design, position/self-preference bias, majority voting, or calibrating the judge against human spot-checks",
13
- "Proposes running the evals as a repeatable regression gate (in CI or before each prompt/pipeline change), not only as a one-off pre-launch check"
13
+ "Proposes running the evals as a repeatable regression gate (in CI or before each prompt/pipeline change), not only as a one-off pre-launch check",
14
+ "Specifies the judge rubric as a separate score per quality criterion on a binary or 3-point scale, rather than one overall score such as 1–10"
14
15
  ]
15
16
  },
16
17
  {
@@ -11,7 +11,8 @@
11
11
  "Suggests percentage-based rollout for the feature flag",
12
12
  "Warns against committing any credential to version control",
13
13
  "Recommends startup validation to fail fast if secrets are missing",
14
- "Notes different values needed for dev/staging/production"
14
+ "Notes different values needed for dev/staging/production",
15
+ "Before adding the new keys, establishes what configuration already exists (existing keys or values, .env.example, config conventions), or says it cannot inspect the project and names what it would check"
15
16
  ]
16
17
  },
17
18
  {
@@ -12,7 +12,8 @@
12
12
  "Includes indexes for common access patterns (order lookup by user, product search)",
13
13
  "Foreign keys have explicit ON DELETE behavior",
14
14
  "Includes created_at/updated_at timestamps",
15
- "Validates schema against likely access patterns"
15
+ "Validates schema against likely access patterns",
16
+ "Before proposing tables, establishes what schema already exists, or says it is treating the project as greenfield or cannot inspect it and names what it would check"
16
17
  ]
17
18
  },
18
19
  {
@@ -13,7 +13,8 @@
13
13
  "Suggests computing averageRating in the database query, not in application code",
14
14
  "Does NOT start with micro-optimizations (variable names, array methods)",
15
15
  "Provides concrete refactored code",
16
- "Suggests adding an index on reviews.productId if not present"
16
+ "Suggests adding an index on reviews.productId if not present",
17
+ "Orders the fixes explicitly by impact relative to effort, putting the highest payoff for the least work first"
17
18
  ]
18
19
  },
19
20
  {
@@ -38,9 +39,10 @@
38
39
  "Identifies the algorithmic complexity (O(n²) from nested loops, O(n) from includes)",
39
40
  "Explains WHY this is slow for large arrays",
40
41
  "Refactors to a single O(n) pass using hashed lookups — a Map or object counting occurrences, or a Set of emails already seen",
41
- "Uses a Set for the duplicates result (not includes() on an array)",
42
+ "Removes the includes() scan over the result list: collects duplicates in a Set, or reads them off a Map of counts",
42
43
  "Notes the repeated toLowerCase() calls as a secondary optimization",
43
- "Provides working refactored code"
44
+ "Provides working refactored code",
45
+ "Says to confirm before shipping that the rewrite returns the same results as the original (its tests, or a side-by-side comparison on realistic input), not only that it is faster"
44
46
  ]
45
47
  }
46
48
  ]
@@ -22,7 +22,8 @@
22
22
  "Stops executing the affected phases instead of silently improvising a different approach under the old plan",
23
23
  "Explicitly triggers re-planning for the affected phases, involving the user or the feature-planning workflow",
24
24
  "Preserves and does not discard the completed, verified work from earlier phases",
25
- "Communicates the drift, its impact on the remaining plan, and the options — rather than quietly continuing"
25
+ "Communicates the drift, its impact on the remaining plan, and the options — rather than quietly continuing",
26
+ "Routes the structural question the plan did not answer (such as where queued, in-flight or failed writes are stored) to data-modeling or architecture-design rather than settling it inline"
26
27
  ]
27
28
  },
28
29
  {
@@ -22,7 +22,8 @@
22
22
  "Recommends fixing the shared contract/conventions first, before any fan-out, rather than gluing independently-designed pieces afterward",
23
23
  "Explains the failure mode: parallel agents without a shared contract produce incompatible outputs and costly reconciliation",
24
24
  "Offers a legitimate parallel structure instead — e.g. per-resource spec drafting against the fixed contract, or a multi-perspective review/judge panel of a single draft",
25
- "Does not simply execute the 6-way split as requested"
25
+ "Does not simply execute the 6-way split as requested",
26
+ "Notes that subagents cannot ask clarifying questions mid-flight, so open questions must be resolved before any fan-out"
26
27
  ]
27
28
  },
28
29
  {
@@ -19,7 +19,8 @@
19
19
  "assertions": [
20
20
  "Treats the prior CI run as stale, not as fresh evidence",
21
21
  "Does not rubber-stamp the merge on the 'only a comment' rationalization",
22
- "Bases the go/no-go on the fresh output"
22
+ "Bases the go/no-go on the fresh output",
23
+ "Counts the static gates the repo configures (type checker, linter) as part of the fresh check, not the test suite alone"
23
24
  ]
24
25
  },
25
26
  {
@@ -320,5 +320,5 @@ Full policy: docs/AUTHORING.md § Obsolescence review.
320
320
 
321
321
  - docs/AUTHORING.md — the canonical rules and common mistakes.
322
322
  - [references/pressure-testing.md](references/pressure-testing.md) — running baseline scenarios and the pressure levers.
323
- - `docs/EVALS.md` — the automated RED/GREEN harness that replays evals through subagents and gates regressions in CI.
323
+ - `docs/EVALS.md` — the automated RED/GREEN harness that replays evals through subagents and checks regressions against a committed baseline.
324
324
  - `verification-before-completion` — the discipline that proves a skill change works (run the eval, read the result).