agentscamp 0.5.0 → 0.6.0

package/README.md

@@ -1,6 +1,6 @@
 # agentscamp
 
-> 183 ready-to-use Claude Code agents, skills, and slash commands — installable in one command.
+> 198 ready-to-use Claude Code agents, skills, and slash commands — installable in one command.
 
 [AgentsCamp](https://agentscamp.com) is a curated, format-validated directory of AI coding artifacts. This CLI bundles the full catalog and installs items straight into your `.claude/` directory.
 
@@ -43,7 +43,7 @@ These are Claude Code's standard locations — agents get delegated to automatic
 ## What's inside
 
 - **58 agents** — specialized subagents for development, data/AI, infra, security, and more → [browse agents](https://agentscamp.com/agents)
-- **75 skills** — on-demand capabilities for testing, databases, refactoring, releases → [browse skills](https://agentscamp.com/skills)
+- **90 skills** — on-demand capabilities for testing, databases, refactoring, releases → [browse skills](https://agentscamp.com/skills)
 - **50 commands** — reusable slash commands for planning, review, git, scaffolding → [browse commands](https://agentscamp.com/commands)
 
 Every item has a full page with docs, examples, and related picks at [agentscamp.com](https://agentscamp.com).

package/content/manifest.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-06-18T02:36:19.351Z",
+  "generatedAt": "2026-06-18T02:50:33.985Z",
   "counts": {
     "agents": 58,
-    "skills": 75,
+    "skills": 90,
     "commands": 50
   },
   "items": [
@@ -1762,6 +1762,20 @@
       "installAs": "skills/chunking-strategy-optimizer/SKILL.md",
       "url": "https://agentscamp.com/skills/data/chunking-strategy-optimizer"
     },
+    {
+      "id": "skills/circular-dependency-breaker",
+      "type": "skill",
+      "slug": "circular-dependency-breaker",
+      "category": "refactor",
+      "title": "Circular Dependency Breaker",
+      "description": "Detect and break a circular import — map the exact cycle with a real tool, then break the right edge by extracting the shared piece into a leaf module, inverting a layering dependency, merging two falsely-split modules, or (last resort) deferring an import. Use when you hit an import cycle error, an undefined-on-import or 'cannot access before initialization' bug, or a bundler/linter flags a cycle.",
+      "topics": [
+        "coding-languages"
+      ],
+      "file": "skills/circular-dependency-breaker.md",
+      "installAs": "skills/circular-dependency-breaker/SKILL.md",
+      "url": "https://agentscamp.com/skills/refactor/circular-dependency-breaker"
+    },
     {
       "id": "skills/claude-settings-auditor",
       "type": "skill",
@@ -1790,6 +1804,20 @@
       "installAs": "skills/cold-start-optimizer/SKILL.md",
       "url": "https://agentscamp.com/skills/performance/cold-start-optimizer"
     },
+    {
+      "id": "skills/commit-splitter",
+      "type": "skill",
+      "slug": "commit-splitter",
+      "category": "git",
+      "title": "Commit Splitter",
+      "description": "Split one big, mixed-up change into a series of small, atomic commits — each a single logical change that builds and passes tests on its own — by grouping hunks by intent and staging them piecemeal. Use when a working tree or a fat commit mixes a feature, a refactor, a bug fix, and formatting, or before opening a PR you want reviewers to actually read.",
+      "topics": [
+        "review-qa"
+      ],
+      "file": "skills/commit-splitter.md",
+      "installAs": "skills/commit-splitter/SKILL.md",
+      "url": "https://agentscamp.com/skills/git/commit-splitter"
+    },
     {
       "id": "skills/connection-pool-tuner",
       "type": "skill",
@@ -1846,6 +1874,20 @@
       "installAs": "skills/coverage-gap-finder/SKILL.md",
       "url": "https://agentscamp.com/skills/testing/coverage-gap-finder"
     },
+    {
+      "id": "skills/dashboard-designer",
+      "type": "skill",
+      "slug": "dashboard-designer",
+      "category": "observability",
+      "title": "Dashboard Designer",
+      "description": "Design a service dashboard that answers one question at a glance — is the service healthy, and if not, where's the problem? — by structuring panels around RED/USE instead of dumping every metric. Use when a service has no dashboard, when the existing one is an unreadable metric wall, or during incident-readiness prep.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "skills/dashboard-designer.md",
+      "installAs": "skills/dashboard-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/observability/dashboard-designer"
+    },
     {
       "id": "skills/dead-code-finder",
       "type": "skill",
@@ -1860,6 +1902,20 @@
       "installAs": "skills/dead-code-finder/SKILL.md",
       "url": "https://agentscamp.com/skills/refactor/dead-code-finder"
     },
+    {
+      "id": "skills/deadlock-diagnoser",
+      "type": "skill",
+      "slug": "deadlock-diagnoser",
+      "category": "database",
+      "title": "Deadlock Diagnoser",
+      "description": "Diagnose a database deadlock from the engine's own deadlock report, reconstruct the lock cycle (A holds 1 wants 2, B holds 2 wants 1), name the root cause — almost always two code paths locking the same rows in different orders — and fix it with consistent lock ordering, shorter transactions, and a retry-the-victim safeguard. Use when the DB logs deadlock errors, when transactions intermittently fail under load, or when queries mysteriously block each other.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "skills/deadlock-diagnoser.md",
+      "installAs": "skills/deadlock-diagnoser/SKILL.md",
+      "url": "https://agentscamp.com/skills/database/deadlock-diagnoser"
+    },
     {
       "id": "skills/dependency-audit",
       "type": "skill",
@@ -1960,6 +2016,20 @@
       "installAs": "skills/extract-module/SKILL.md",
       "url": "https://agentscamp.com/skills/refactor/extract-module"
     },
+    {
+      "id": "skills/feature-flag-retirer",
+      "type": "skill",
+      "slug": "feature-flag-retirer",
+      "category": "refactor",
+      "title": "Feature Flag Retirer",
+      "description": "Retire stale feature flags by confirming each flag's decided final state, then collapsing every conditional to the winning branch and deleting the loser plus the now-dead code it reached. Use when temporary flags have outlived their rollout, when flag conditionals clutter the code, or during a flag-debt cleanup.",
+      "topics": [
+        "coding-languages"
+      ],
+      "file": "skills/feature-flag-retirer.md",
+      "installAs": "skills/feature-flag-retirer/SKILL.md",
+      "url": "https://agentscamp.com/skills/refactor/feature-flag-retirer"
+    },
     {
       "id": "skills/finetune-dataset-builder",
       "type": "skill",
@@ -1974,6 +2044,34 @@
       "installAs": "skills/finetune-dataset-builder/SKILL.md",
       "url": "https://agentscamp.com/skills/data/finetune-dataset-builder"
     },
+    {
+      "id": "skills/flamegraph-analyzer",
+      "type": "skill",
+      "slug": "flamegraph-analyzer",
+      "category": "performance",
+      "title": "Flamegraph Analyzer",
+      "description": "Turn a CPU profile or flamegraph into a concrete optimization instead of guessing where the time goes: capture under a realistic workload with a sampling profiler, read the graph correctly (width = time, depth ≠ time), find the widest self-time leaves, ask if that work is necessary/redundant/algorithmically wrong, fix the biggest contributor, then re-profile. Use when code is CPU-bound and slow, a function is hot but you don't know which part, or you have a profile you can't interpret.",
+      "topics": [
+        "review-qa"
+      ],
+      "file": "skills/flamegraph-analyzer.md",
+      "installAs": "skills/flamegraph-analyzer/SKILL.md",
+      "url": "https://agentscamp.com/skills/performance/flamegraph-analyzer"
+    },
+    {
+      "id": "skills/git-blame-investigator",
+      "type": "skill",
+      "slug": "git-blame-investigator",
+      "category": "git",
+      "title": "Git Blame Investigator",
+      "description": "Reconstruct why a line of code exists from Git history — find the originating commit, read its message and full diff for intent, and see through reformatting/rename commits with ignore-revs and the pickaxe — before you change or delete it. Use when a line looks wrong or pointless and you want to remove it, when tracing a regression to its commit, or when onboarding to unfamiliar code.",
+      "topics": [
+        "review-qa"
+      ],
+      "file": "skills/git-blame-investigator.md",
+      "installAs": "skills/git-blame-investigator/SKILL.md",
+      "url": "https://agentscamp.com/skills/git/git-blame-investigator"
+    },
     {
       "id": "skills/github-actions-optimizer",
       "type": "skill",
@@ -1988,6 +2086,20 @@
       "installAs": "skills/github-actions-optimizer/SKILL.md",
       "url": "https://agentscamp.com/skills/workflow/github-actions-optimizer"
     },
+    {
+      "id": "skills/graphql-schema-designer",
+      "type": "skill",
+      "slug": "graphql-schema-designer",
+      "category": "api",
+      "title": "GraphQL Schema Designer",
+      "description": "Design a clean, evolvable GraphQL schema (SDL) that won't paint you into a corner — model the graph around domain types and their relationships rather than as RPC-over-GraphQL, set nullability deliberately, standardize lists with Relay connections, plan DataLoader batching for per-parent fields, and evolve by adding + @deprecated instead of versioning. Use when designing a new GraphQL API, reviewing an SDL, or migrating REST endpoints to a graph.",
+      "topics": [
+        "architecture"
+      ],
+      "file": "skills/graphql-schema-designer.md",
+      "installAs": "skills/graphql-schema-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/api/graphql-schema-designer"
+    },
     {
       "id": "skills/graphrag-scaffolder",
       "type": "skill",
@@ -2002,6 +2114,20 @@
       "installAs": "skills/graphrag-scaffolder/SKILL.md",
       "url": "https://agentscamp.com/skills/data/graphrag-scaffolder"
     },
+    {
+      "id": "skills/hallucination-evaluator",
+      "type": "skill",
+      "slug": "hallucination-evaluator",
+      "category": "data",
+      "title": "Hallucination Evaluator",
+      "description": "Detect and measure ungroundedness in LLM and RAG outputs — claims the source doesn't support — by decomposing answers into atomic claims and checking each for entailment, so you can quantify faithfulness and gate on it instead of eyeballing it. Use when a RAG/LLM feature makes confident wrong claims, before shipping anything that must be factual, or to add a groundedness gate to evals/CI.",
+      "topics": [
+        "llm-evals"
+      ],
+      "file": "skills/hallucination-evaluator.md",
+      "installAs": "skills/hallucination-evaluator/SKILL.md",
+      "url": "https://agentscamp.com/skills/data/hallucination-evaluator"
+    },
     {
       "id": "skills/hook-writer",
       "type": "skill",
@@ -2044,6 +2170,20 @@
       "installAs": "skills/idempotency-designer/SKILL.md",
       "url": "https://agentscamp.com/skills/api/idempotency-designer"
     },
+    {
+      "id": "skills/integration-test-designer",
+      "type": "skill",
+      "slug": "integration-test-designer",
+      "category": "testing",
+      "title": "Integration Test Designer",
+      "description": "Design integration tests that exercise components against REAL collaborators — actual database, queue, HTTP boundary — at a deliberately chosen seam, instead of a unit suite that mocks everything or a slow flaky full E2E. Use when bugs slip past green unit tests, when wiring or contracts between layers break in production, or when a mocked DB test passes but the real query/migration/serialization fails.",
+      "topics": [
+        "review-qa"
+      ],
+      "file": "skills/integration-test-designer.md",
+      "installAs": "skills/integration-test-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/testing/integration-test-designer"
+    },
     {
       "id": "skills/llm-as-judge-scorer",
       "type": "skill",
@@ -2171,6 +2311,20 @@
       "installAs": "skills/mock-data-factory/SKILL.md",
       "url": "https://agentscamp.com/skills/testing/mock-data-factory"
     },
+    {
+      "id": "skills/model-router-designer",
+      "type": "skill",
+      "slug": "model-router-designer",
+      "category": "data",
+      "title": "Model Router Designer",
+      "description": "Design a model router that sends each LLM request to the cheapest model that can handle it and escalates only the hard cases to the strongest — cutting cost and latency without tanking quality, gated by an eval set so the savings don't come from silently worse answers. Use when one expensive model serves all traffic (most of it easy), when LLM cost or latency is too high, or when balancing quality against spend across a range of request difficulty.",
+      "topics": [
+        "llm-app-dev"
+      ],
+      "file": "skills/model-router-designer.md",
+      "installAs": "skills/model-router-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/data/model-router-designer"
+    },
     {
       "id": "skills/multimodal-document-extractor",
       "type": "skill",
@@ -2200,6 +2354,20 @@
       "installAs": "skills/mutation-test-runner/SKILL.md",
       "url": "https://agentscamp.com/skills/testing/mutation-test-runner"
     },
+    {
+      "id": "skills/onboarding-guide-writer",
+      "type": "skill",
+      "slug": "onboarding-guide-writer",
+      "category": "docs",
+      "title": "Onboarding Guide Writer",
+      "description": "Write a developer onboarding guide that gets a new contributor from clone to first merged change fast — a verified golden path, a quick architecture map, the real workflow conventions, and the gotchas that live only in senior engineers' heads. Use when a repo has no onboarding doc, when new hires keep asking the same setup questions, or when the README is a marketing page instead of a contributor guide.",
+      "topics": [
+        "workflow-prompting"
+      ],
+      "file": "skills/onboarding-guide-writer.md",
+      "installAs": "skills/onboarding-guide-writer/SKILL.md",
+      "url": "https://agentscamp.com/skills/docs/onboarding-guide-writer"
+    },
     {
       "id": "skills/openapi-doc-writer",
       "type": "skill",
@@ -2398,6 +2566,20 @@
       "installAs": "skills/rate-limiter-designer/SKILL.md",
       "url": "https://agentscamp.com/skills/api/rate-limiter-designer"
     },
+    {
+      "id": "skills/rbac-designer",
+      "type": "skill",
+      "slug": "rbac-designer",
+      "category": "security",
+      "title": "RBAC Designer",
+      "description": "Design the authorization model itself — fine-grained permissions on resources composed into roles, with the right amount of resource/tenant scoping — instead of scattering role-name checks through handlers. Use when building multi-user or multi-tenant authorization, when `if user.isAdmin` checks are sprawling across the codebase, or when 'who can do what' needs a real model rather than ad-hoc gates.",
+      "topics": [
+        "architecture"
+      ],
+      "file": "skills/rbac-designer.md",
+      "installAs": "skills/rbac-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/security/rbac-designer"
+    },
     {
       "id": "skills/react-render-profiler",
       "type": "skill",
@@ -2427,6 +2609,20 @@
       "installAs": "skills/readme-generator/SKILL.md",
       "url": "https://agentscamp.com/skills/docs/readme-generator"
     },
+    {
+      "id": "skills/release-notes-writer",
+      "type": "skill",
+      "slug": "release-notes-writer",
+      "category": "release",
+      "title": "Release Notes Writer",
+      "description": "Write user-facing release notes — the curated 'what's new and what it means for you' — by starting from the real changes (git log / merged PRs / the changelog since the last release) and translating developer-speak into user impact, grouped by what the user cares about with breaking changes and required actions surfaced first. Use when shipping a release to users or customers and the raw commit log isn't something a user should read, when you need a published GitHub-release / blog / in-app announcement, or when a breaking change must be made unmissable so upgrades don't break.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "skills/release-notes-writer.md",
+      "installAs": "skills/release-notes-writer/SKILL.md",
+      "url": "https://agentscamp.com/skills/release/release-notes-writer"
+    },
     {
       "id": "skills/runbook-writer",
       "type": "skill",
@@ -2651,6 +2847,20 @@
       "installAs": "skills/web-research-pipeline/SKILL.md",
       "url": "https://agentscamp.com/skills/data/web-research-pipeline"
     },
+    {
+      "id": "skills/web-vitals-optimizer",
+      "type": "skill",
+      "slug": "web-vitals-optimizer",
+      "category": "performance",
+      "title": "Web Vitals Optimizer",
+      "description": "Diagnose and fix Core Web Vitals — LCP, CLS, and INP — by treating real-user field data at p75 as the source of truth, using Lighthouse/WebPageTest only to find the at-fault element, script, or shift, then applying the one targeted fix per metric and re-measuring. Use when a page feels slow, scores poorly on PageSpeed/Lighthouse, or fails CWV in CrUX/RUM field data.",
+      "topics": [
+        "coding-languages"
+      ],
+      "file": "skills/web-vitals-optimizer.md",
+      "installAs": "skills/web-vitals-optimizer/SKILL.md",
+      "url": "https://agentscamp.com/skills/performance/web-vitals-optimizer"
+    },
     {
       "id": "skills/webhook-handler-scaffolder",
       "type": "skill",

package/content/skills/circular-dependency-breaker.md

@@ -0,0 +1,48 @@
+---
+name: "circular-dependency-breaker"
+description: "Detect and break a circular import — map the exact cycle with a real tool, then break the right edge by extracting the shared piece into a leaf module, inverting a layering dependency, merging two falsely-split modules, or (last resort) deferring an import. Use when you hit an import cycle error, an undefined-on-import or 'cannot access before initialization' bug, or a bundler/linter flags a cycle."
+allowed-tools: "Read, Grep, Glob, Edit"
+version: 1.0.0
+---
+
+A circular import is two or more modules that need each other to finish loading before either can finish loading — so one of them gets a half-built version of the other, and you get an `undefined` export, a `cannot access X before initialization`, or a bundler warning that surfaces "randomly" depending on which file ran first. This skill refuses to guess: it maps the exact cycle with a real dependency tool, identifies *which edge* is the wrong one, breaks it with the technique that matches the cause, and re-runs the tool to prove the cycle is gone.
+
+## When to use this skill
+
+- An import throws `cannot access '<x>' before initialization`, `ReferenceError`, or an export reads as `undefined` even though it is clearly exported.
+- A bundler (webpack/Vite/Rollup/esbuild), a linter (`import/no-cycle`), `madge --circular`, `import-linter`, or `go vet` flags a circular dependency.
+- A value works in one entry order and breaks in another — tests pass alone but fail in a suite, or prod breaks while dev works, because module load order differs.
+- You are about to "fix" a crash by moving an import inside a function and want to know whether that hides the real problem (it does).
+
+## Instructions
+
+1. **Map the cycle with a tool before changing one line.** Do not infer the cycle from the stack trace — the trace shows where it *crashed*, not which edge to cut. Run the right tool for the stack: JS/TS `npx madge --circular --extensions ts,tsx src` or `npx dpdm --circular src/index.ts`; Python `import-linter` (with a `[importlinter]` contract) or `pydeps --show-cycles pkg`; Go `go list -deps` / `go mod graph`; or read the bundler's own circular-dependency warning. Capture the full ordered chain, e.g. `auth → user → session → auth`, so you are fixing a real edge.
+2. **Find the one edge that is wrong.** A cycle has N edges but usually one of them is the design mistake — a lower-level module reaching back up to a higher-level one, or two leaf-ish modules each grabbing one symbol from the other. With `Grep`, list *exactly which symbols* each module imports from the next in the chain. The edge to break is the one importing the fewest, most-extractable symbols — often a single shared type, constant, or helper.
+3. **Prefer extracting the shared thing into a leaf module — this is the cleanest fix and the most common cause.** If A and B both need a type, constant, or pure helper that currently lives in one of them, move that symbol into a new dependency-free module (`types.ts`, `constants.ts`, `shared/`) that both A and B import *from*, and which imports from neither. The cycle dissolves because the contested symbol no longer lives on the cycle. Update every importer with `Edit`.
+4. **Invert the dependency when there is a true layering violation.** If a lower-level module imports a higher-level one only to call back into it (e.g. a storage layer importing a service to notify it), apply dependency inversion: define the interface/type at the *lower* module (it owns the contract), and have the caller inject the concrete implementation as an argument or via a registration call. The lower module now depends on nothing above it; the arrow points one way.
+5. **Merge the two modules if they are genuinely one unit.** If A and B call deep into each other through many symbols and neither has a coherent identity without the other, they were split artificially. Combine them into one module and re-export from the old paths as a barrel so external callers stay green. A cycle between two files that are really one concept is a packaging bug, not a dependency to invert.
+6. **Defer the import only as a last resort — and say so out loud.** Moving `import` inside the function that uses it (lazy/local import, `require()` at call time, or a TYPE_CHECKING-only import in Python) makes the crash stop because the import now runs after both modules finished loading. It does not remove the cycle — `madge` will still report it. Use it only when the real fixes are blocked (e.g. a third-party constraint), and flag it explicitly as deferring a known design smell.
+7. **Re-run the same tool and check import-time side effects.** Re-run the step-1 command and confirm the cycle no longer appears in its output — that is your proof, not "the crash went away." Then verify nothing relied on import-time side effects whose order you just changed: a module that registered a handler, populated a singleton, or ran top-level code now runs in a new order. Search for top-level statements (not inside a function/class) in the moved code and confirm they still fire when expected.
+
+> [!WARNING]
+> A lazy/deferred import "fixes" the crash but leaves the architectural cycle fully in place — the next person hits the same partially-initialized-module bug from a different entry point. Treat it as a tourniquet, not a cure. Always reach for extracting the shared dependency (step 3) or inverting the layer (step 4) first; only defer when those are genuinely blocked, and label it as a deferral.
+
+> [!NOTE]
+> The bug is in the import graph, not the stack trace. `cannot access X before initialization` points at the line that *read* the half-built module, which is rarely where the cycle should be cut. Map the graph first (step 1) — the right edge to break is almost never the one the error names.
+
+## Output
+
+1. **The dependency cycle diagram** — the exact ordered chain from the tool, annotated with the symbols crossing each edge:
+
+   ```
+   auth.ts ──(needs SessionToken)──▶ session.ts
+      ▲                                   │
+      └──────(needs currentUser)──────────┘
+   Cycle: auth → session → auth   (madge --circular)
+   ```
+
+2. **The chosen break technique with rationale** — e.g. "Extract `SessionToken` (a type, the only symbol `session` takes from `auth`) into `auth/types.ts` leaf; both import from it. Chosen over deferral because the cycle is a misplaced shared type, not a real layering need."
+
+3. **The concrete import/module changes** — the new/edited files and every `import` line that moved, as applied edits (new leaf module created, contested symbol relocated, importers re-pointed).
+
+4. **Proof the cycle is gone** — the re-run of the step-1 command showing no cycle, e.g. `madge --circular src` → `✔ No circular dependency found!`, plus a one-line confirmation that any import-time side effects in the moved code still execute in the right order.

package/content/skills/commit-splitter.md

@@ -0,0 +1,54 @@
+---
+name: "commit-splitter"
+description: "Split one big, mixed-up change into a series of small, atomic commits — each a single logical change that builds and passes tests on its own — by grouping hunks by intent and staging them piecemeal. Use when a working tree or a fat commit mixes a feature, a refactor, a bug fix, and formatting, or before opening a PR you want reviewers to actually read."
+allowed-tools: "Read, Grep, Bash"
+version: 1.0.0
+---
+
+A 600-line diff that mixes a feature, a drive-by refactor, a bug fix, and a formatter run is unreviewable — reviewers skim it and approve on faith. This skill decomposes that change into a sequence of small commits, each one a single logical intent that compiles and passes tests on its own. It groups the diff by purpose, stages one group at a time with `git add -p`, orders them so prerequisites land first, and gives each commit a focused message — so reviewers read the story instead of guessing at it, and `git bisect`/`git revert` stay meaningful.
+
+## When to use this skill
+
+- An uncommitted working tree mixes concerns — a new feature, an unrelated refactor, a bug fix, and whitespace/formatting churn all tangled together.
+- A single fat commit (yours, not yet pushed) bundles several logical changes and you want to split it before review.
+- You're about to open a PR and want the commit series to read as a deliberate narrative, not a `wip` dump.
+
+> [!WARNING]
+> Splitting only pays off if **each** commit independently builds and passes tests. A series where intermediate commits are broken defeats `git bisect` and makes any single-commit `revert` land a non-working tree — worse than one honest fat commit. Verify every commit, not just the tip.
+
+## Instructions
+
+1. **Inventory what changed.** Run `git status --porcelain` and `git diff --stat` (add `--cached` for staged hunks; `git show --stat HEAD` if splitting an existing commit). Read the actual hunks with `git diff` so you reason about real code, not filenames. Note any new/deleted/renamed files — those move as whole units, not per-hunk.
+2. **Group hunks by logical intent.** Assign every hunk to exactly one group. Typical buckets, in dependency order:
+   - **Prerequisite refactor** — renames, extractions, signature changes the feature depends on (no behavior change).
+   - **Bug fix** — a self-contained correctness fix, ideally with its own test.
+   - **Feature** — the new behavior, built on the refactor above.
+   - **Formatting / lint** — pure whitespace, import sorting, autoformatter noise. Isolate this; mixed-in formatting is what makes diffs unreadable.
+   - **Unrelated cleanup** — dead code, typo, comment. Its own commit (or a separate PR).
+   Watch for **hidden coupling**: a feature that won't compile without the refactor must come *after* it, never before.
+3. **Stage one group at a time.** Use `git add -p <files>` and answer per hunk: `y` to stage, `n` to skip, `s` to split a hunk into smaller pieces. When a single hunk mixes two intents that `s` can't separate (e.g. a logic change and a reformat on adjacent lines), use `git add -e` (or `e` at the prompt) to hand-edit the staged patch — delete the `+`/`-` lines that belong to the other group, keep context lines intact. Stage exactly one group, then go to step 4.
+4. **Verify the staged group in isolation, then commit.** Before committing, prove the staged subset stands alone: `git stash push --keep-index` parks everything *not* staged, leaving only this group in the tree. Run the project's build + tests (detect them — `npm run build && npm test`, `pytest`, `go build ./... && go test ./...`). If it builds and passes, commit (step 6); then `git stash pop` to restore the rest and return to step 3 for the next group. If it fails, you mis-grouped — a prerequisite is in a later group; re-order and re-stage.
+5. **For an already-committed mess, rewrite local history.** Two routes:
+   - **Re-stage the whole commit:** `git reset HEAD~1` (soft-ish — keeps changes in the working tree, unstaged), then proceed from step 2 to rebuild it as several commits.
+   - **Surgical split inside a series:** `git rebase -i <base>`, mark the offending commit `edit`. When the rebase stops on it, `git reset HEAD~1` to unstage its contents, then split via steps 3–6, and `git rebase --continue`. Use `git rebase --abort` to bail back to the original state if anything looks wrong.
+6. **Write a focused conventional message per commit.** One intent per subject line: `refactor(parser): extract tokenizer`, `fix(auth): reject expired tokens`, `feat(auth): add SSO login`, `style: apply formatter`. The subject names the *single* thing this commit does; if you need "and" or a bullet list of unrelated items, the commit is still mixed — split further.
+7. **Confirm the series reads as a story and every commit is green.** Run `git log --oneline <base>..HEAD` to read the sequence top-to-bottom: prerequisites → fix → feature → cleanup. Then verify *each* commit independently — `git rebase --exec '<build && test>' <base>` replays the series running your command after every commit, failing on the first that breaks. This is the proof that the split is bisect-safe.
+
+> [!WARNING]
+> Rewriting history that's already pushed or shared (`reset`, `rebase -i`) forces every collaborator to recover their local copy and can orphan their work. Only reshape **local, unpushed** history. If the commits are already on a shared branch, coordinate first — or leave history alone and split going forward.
+
+## Output
+
+- **Commit breakdown** — an ordered table: each proposed commit's purpose (its single intent), the files/hunks it claims, and its dependency on earlier commits.
+- **Exact reproduction steps** — the concrete `git add -p` / `git add -e` sequence (or the `rebase -i` + `reset HEAD~1` plan) that produces that breakdown, including the per-group `stash push --keep-index` → build/test → commit → `stash pop` loop.
+- **Recommended commit messages** — one conventional-commit subject (and body where it earns it) per commit, in apply order.
+- **Verification result** — confirmation that `git rebase --exec` ran the build+tests after every commit and the whole series is green, with any commit that needed re-grouping called out.
+
+Example breakdown for a tangled working tree:
+
+| # | Commit | Hunks / files | Depends on |
+|---|--------|---------------|------------|
+| 1 | `refactor(parser): extract Tokenizer class` | `parser.ts` (lines 12–88), new `tokenizer.ts` | — |
+| 2 | `fix(parser): handle empty input` | `parser.ts` (lines 140–152), `parser.test.ts` (new case) | 1 |
+| 3 | `feat(parser): support inline comments` | `tokenizer.ts` (lines 40–72), `parser.ts` (lines 95–110) | 1 |
+| 4 | `style: apply prettier` | whitespace-only across 6 files | — |

package/content/skills/dashboard-designer.md

@@ -0,0 +1,38 @@
+---
+name: "dashboard-designer"
+description: "Design a service dashboard that answers one question at a glance — is the service healthy, and if not, where's the problem? — by structuring panels around RED/USE instead of dumping every metric. Use when a service has no dashboard, when the existing one is an unreadable metric wall, or during incident-readiness prep."
+allowed-tools: "Read, Grep, Glob"
+version: 1.0.0
+---
+
+A dashboard is read in two modes: a calm weekly glance, and a 3am incident with an angry pager. Most dashboards are built for neither — they're a wall of every metric the system can emit, ranked by nothing, where the panel that matters is the same size as the one that never moves. This skill designs the opposite: a dashboard structured by a proven method (RED for request services, USE for resources) so the top row answers "is the service healthy?" in one glance, and the rows below answer "then where's the problem?" only when you need them.
+
+## When to use this skill
+- A service is running in production with no dashboard, or only a default auto-generated one nobody trusts.
+- An existing dashboard is a 40-panel metric dump — technically complete, useless in an incident, because nothing is ranked.
+- Incident-readiness or on-call onboarding: you need a board a new engineer can read cold at 3am.
+- You're defining or visualizing SLOs and need error-budget burn to live next to the signals that drive it.
+- A postmortem found that the dashboard existed but the operator couldn't find the symptom on it fast enough.
+
+## Instructions
+1. **Classify the thing you're instrumenting, then pick the method.** Request-driven service (HTTP/gRPC/API) → **RED**: Rate (requests/sec), Errors (failed requests/sec and error %), Duration (latency distribution). Resource or queue (worker pool, broker, DB, cache, thread pool) → **USE**: Utilization (% busy), Saturation (queue depth / backlog / wait time), Errors. A typical service is RED on top with a USE block below for its hottest dependency.
+2. **Put user-facing, SLO-aligned signals in the top row — nothing else competes for that space.** Request rate, error rate (%), latency p95/p99, and **error-budget burn rate** if an SLO exists. These four answer "are users being served?" A reader who sees the top row green should be able to stop reading. Everything below is for when it's red.
+3. **Show latency as percentiles — p50, p95, p99 — never an average.** Average latency is a lie that hides the tail: a p99 of 4s with a 120ms mean reads as "fine" on an average and "users are rage-quitting" on a percentile. Plot p50/p95/p99 as separate series on one panel so the spread between them (the tail blowing out) is visible.
+4. **Place cause metrics BELOW the signals, as drill-down — not mixed in.** CPU, memory, GC pause, queue depth, DB connection pool usage/saturation, downstream dependency latency, restart/OOM counts. These don't tell you if users hurt; they tell you *why* once the top row says they do. Group them so the path is top-down: symptom (top) → suspected cause (below).
+5. **Put correlated panels adjacent so the eye does the joining.** Error rate next to the deploy marker. Latency next to the saturated dependency it's waiting on. Queue depth next to consumer error rate. An operator should be able to see "errors started exactly at the deploy" or "latency tracks the DB pool maxing out" without flipping between boards.
+6. **Annotate the timeline with deploys and incidents.** Wire deploy/release events and incident start/end onto every time-series panel as vertical markers. Half of all "where's the problem?" questions are answered by a deploy line landing on the exact second the graph turns — make that free to see.
+7. **Set thresholds and colors that mean something, plus units and a sane default range.** Color by SLO/alert boundary, not by gut feel: green within budget, amber approaching, red breached — and keep it consistent across panels. Label every axis with units (ms, req/s, %, MiB). Default the time range to something an incident needs (last 1–6h, not 30 days) with the ability to zoom out.
+8. **One dashboard per service or user journey — linked, not merged.** Resist the urge to build one giant board for the whole platform. Per-service boards stay readable; link them (this service → its dependencies' boards, the journey board → each service board) so drill-down is a click, not a scroll through 200 panels.
+9. **Cut every panel that doesn't earn its place.** For each candidate ask: "In an incident, would this change what I do next?" If no, it's decoration — leave it off or push it to a separate deep-dive board. Noise hides signal; a 12-panel board you trust beats a 40-panel board you scan past.
+
+> [!WARNING]
+> A dashboard that shows every metric with equal weight is unreadable in an incident — the operator has to reason about *which* panel matters at exactly the moment they have no spare attention. Rank by user impact (RED/USE on top, causes below) or the board is decoration, not a tool.
+
+> [!WARNING]
+> Average latency on a dashboard hides the tail where users actually hurt. A healthy-looking mean can sit on top of a p99 that's timing out for 1% of traffic. Always plot percentiles (p50/p95/p99); never let an average latency panel be the thing on-call looks at first.
+
+## Output
+- **A top-down layout spec** for one service/journey: the chosen method (RED and/or USE) and the ordered rows — top row of user-facing/SLO signals, then cause/drill-down rows below.
+- **A per-panel table**: panel title → metric/query intent → visualization (time series, single-stat, percentile lines, heatmap) → threshold/color rule → units. Latency panels specify p50/p95/p99.
+- **The annotations and links to wire in**: deploy/incident markers on time-series panels, default time range, and the cross-links to dependency or journey dashboards.
+- **A "cut list"**: panels deliberately left off (and where they live instead), so the omission is a decision, not an oversight.

package/content/skills/deadlock-diagnoser.md

@@ -0,0 +1,45 @@
+---
+name: "deadlock-diagnoser"
+description: "Diagnose a database deadlock from the engine's own deadlock report, reconstruct the lock cycle (A holds 1 wants 2, B holds 2 wants 1), name the root cause — almost always two code paths locking the same rows in different orders — and fix it with consistent lock ordering, shorter transactions, and a retry-the-victim safeguard. Use when the DB logs deadlock errors, when transactions intermittently fail under load, or when queries mysteriously block each other."
+allowed-tools: "Read, Grep, Glob, Bash"
+version: 1.0.0
+---
+
+A deadlock looks random from the application — a transaction that worked a thousand times suddenly errors out under load — but the database already did the forensics for you. When the engine detects a cycle it picks a victim, rolls it back, and logs *exactly* who held what and waited on what. This skill reads that report instead of guessing: it pulls the Postgres deadlock log lines (or the SQL Server deadlock graph / `innodb status` in MySQL), reconstructs the cycle (A holds lock 1 and wants lock 2 while B holds 2 and wants 1), and names the real root cause — which is almost always two code paths acquiring the **same** rows or tables in **different** orders. Then it fixes the cause: enforce one consistent lock-acquisition order everywhere, shrink the lock window so the race rarely opens, and add a retry-the-victim safeguard for the deadlocks you can't design away — in that priority, because retries without ordering just trade a deadlock for a rollback storm.
+
+## When to use this skill
+
+- The database log shows `deadlock detected` (Postgres), a deadlock graph / error 1205 (SQL Server), or `Deadlock found when trying to get lock` (MySQL/InnoDB).
+- A transaction intermittently fails or auto-retries only under concurrency — fine in dev, flaky in production at peak.
+- Two queries or endpoints mysteriously block each other, or you see processes stuck in a lock wait that times out.
+- You're adding a write path that touches multiple rows/tables and want to confirm it locks in the same order as existing code before it ships.
+- Lock contention (not a true cycle) is serializing throughput, and you need to tell genuine deadlocks apart from long lock waits.
+
+## Instructions
+
+1. **Get the engine's deadlock report — don't reconstruct from app logs.** In Postgres, read the server log around the error: it prints both processes, their full SQL statements, and the `Process N waits for <lockmode> on <relation/tuple>; blocked by process M` lines for each side of the cycle (raise `log_lock_waits = on` and `deadlock_timeout` context if it's terse). In SQL Server, pull the deadlock graph from the `system_health` Extended Events session or a trace — it lists each `process` with its `inputbuf` (the statement) and the `resource-list` of locks owned vs. requested. In MySQL/InnoDB, run `SHOW ENGINE INNODB STATUS` and read the `LATEST DETECTED DEADLOCK` section. This report is ground truth; the app's stack trace only tells you which transaction lost.
+2. **Reconstruct the cycle explicitly: who HELD what, who WANTED what.** Write it out as a two-column picture — `Txn A: holds <lock on resource 1>, waits for <lock on resource 2>` / `Txn B: holds <lock on resource 2>, waits for <lock on resource 1>`. Identify the exact resources (which rows/index ranges/tables) and the lock modes (row `FOR UPDATE`/exclusive vs. shared, gap locks in InnoDB, intent locks in SQL Server). A real deadlock is a closed cycle of waits; if it's not a cycle, it's lock contention or a lock-wait timeout (step 8), which has a different fix.
+3. **Find the inconsistent acquisition ORDER — the usual root cause.** Grep the codebase for every transaction that touches the resources in the cycle and trace the order each one locks them. The classic bug: one path does `UPDATE accounts WHERE id=1` then `id=2`, another does `id=2` then `id=1` (or two services lock tables `orders` then `inventory` vs. `inventory` then `orders`). Watch for ordering that's *hidden* — a `SELECT ... FOR UPDATE` with an unordered `IN (...)` or a join whose row-locking order depends on the plan, an ORM that emits writes in object-graph order, or a foreign-key check that takes a lock on the parent row you didn't write explicitly.
+4. **Fix the cause first: enforce ONE consistent lock-acquisition order across all transactions.** Make every code path acquire the shared resources in the same deterministic order — sort the ids before locking (`SELECT ... FOR UPDATE ... ORDER BY id`), always lock parent before child, always lock tables in a fixed documented sequence. Consistent ordering makes a cycle impossible: contenders queue instead of deadlocking. This is the only fix that actually removes the deadlock rather than reducing its odds.
+5. **Shrink the lock window so the race rarely opens.** Keep transactions short and narrow: acquire locks as late as possible, commit as early as possible, and lock only the rows you'll write. Never hold a transaction open across a network/RPC/third-party-API call or across user think-time — an external call inside the transaction stretches the lock-hold from milliseconds to seconds and turns rare contention into constant deadlocks. Do the slow work *before* `BEGIN` or *after* `COMMIT`.
+6. **Pick a deliberate lock strategy for the access pattern, and right-size isolation.** Where the same rows are contended, use pessimistic locking with `SELECT ... FOR UPDATE` in the consistent order from step 4. Where conflicts are *rare*, prefer optimistic concurrency — a `version`/`updated_at` column checked in the `WHERE` of the `UPDATE` and a conflict-retry, which takes no long-held locks. If the engine is over-locking (e.g. Serializable or InnoDB gap locks causing deadlocks on inserts/range scans), drop to the lowest isolation level that's still correct (often Read Committed) to acquire fewer locks.
+7. **Add the retry-the-victim safeguard — last, not first.** A deadlock victim's transaction is rolled back cleanly and is a *transient, safe-to-retry* error; the app should catch it specifically (Postgres `SQLSTATE 40P01`, MySQL `1213`, SQL Server `1205`) and retry the whole transaction with capped exponential backoff and jitter (e.g. 3–5 attempts). Retry the *entire* transaction from `BEGIN` — replaying half a rolled-back transaction corrupts state. This handles the deadlocks you can't design away; it does NOT substitute for steps 4–5.
+8. **Distinguish a true deadlock from plain lock contention before "fixing" the wrong thing.** If the report shows a lock-*wait timeout* rather than a detected cycle, there's no ordering bug — one transaction is simply holding a lock too long (a long-running write, an idle-in-transaction connection, a missing index forcing a wide row/range lock). The fix there is shortening the holder (step 5), adding the index so the lock is narrow (`query-plan-analyzer`), or killing idle-in-transaction sessions — not reordering locks.
+
+> [!WARNING]
+> Adding retries WITHOUT fixing the inconsistent lock order just papers over the bug. Under load, every retry re-enters the same cycle, so you trade one deadlock for a storm of rollbacks and re-runs: throughput craters, latency spikes, and the database burns work undoing transactions. Fix the ordering first; the retry is a net for the residual, not the cure.
+
+> [!WARNING]
+> A transaction that holds a lock across an external/API call (or user think-time) is the single most common way rare contention becomes constant deadlocks — the lock-hold goes from milliseconds to seconds, widening the race window enormously. Move every network call and slow computation outside the `BEGIN ... COMMIT`.
+
+> [!NOTE]
+> Lowering isolation reduces locking but changes correctness guarantees (Read Committed allows non-repeatable reads; dropping below Serializable can reintroduce write skew). Only lower it where the access pattern is provably safe — don't trade a deadlock for a silent data anomaly.
+
+## Output
+
+A short report with four parts:
+
+1. **The reconstructed cycle** — quoted from the engine's deadlock report: `Txn A holds <lock on R1>, wants <lock on R2>` / `Txn B holds <lock on R2>, wants <lock on R1>`, with the exact resources, lock modes, and the two offending statements.
+2. **The root cause** — the specific inconsistent lock-acquisition order (or over-long lock scope / over-strict isolation) behind the cycle, naming the two code paths and the resources they lock in conflicting order.
+3. **The fix** — one concrete change: the consistent ordering to enforce (with the exact `ORDER BY` / lock sequence), or the shortened-transaction change (what to move outside `BEGIN`), or the isolation-level / locking-strategy change — not a menu.
+4. **The retry safeguard** — the specific deadlock SQLSTATE/error code to catch and the backoff retry of the whole transaction, framed explicitly as the net for residual deadlocks, not the primary fix.

package/content/skills/feature-flag-retirer.md

@@ -0,0 +1,44 @@
+---
+name: "feature-flag-retirer"
+description: "Retire stale feature flags by confirming each flag's decided final state, then collapsing every conditional to the winning branch and deleting the loser plus the now-dead code it reached. Use when temporary flags have outlived their rollout, when flag conditionals clutter the code, or during a flag-debt cleanup."
+allowed-tools: "Read, Grep, Glob, Edit"
+version: 1.0.0
+---
+
+Feature flags are born temporary and die permanent. Once a flag is fully rolled out or quietly abandoned, the `if (flag)` it guards is just branching debt — two code paths where one is now unreachable. This skill retires a flag for real: it pins down which branch actually won, finds *every* reference (not just the obvious helper call), collapses each conditional to the winner, and deletes the loser along with any code only the dead branch reached — one flag at a time, with tests green after each.
+
+## When to use this skill
+
+- A flag meant to last a sprint has been at 100% (or 0%) for months and still litters the code with conditionals.
+- Flag checks have multiplied — nested `if (flagA && !flagB)` paths nobody can reason about — and you want to pay down the debt.
+- You're running a flag-debt cleanup and need each removal to be independently reviewable and revertible.
+
+> [!WARNING]
+> Verify the flag's *decided* final state before you collapse anything. "Currently 100%" is not "permanently on" — a flag mid-rollout, a kill-switch, or an experiment still gathering data must NOT be retired. Deleting the live branch ships or kills a feature: that's a production incident, not a cleanup. Confirm from the flag system/config AND a human owner that the decision is final, and which branch won.
+
+## Instructions
+
+1. **Pin down the decided final state — not the current value.** For the flag, answer one question: is it *permanently on* (fully rolled out, winner = enabled branch) or *abandoned* (will never ship, winner = disabled branch)? Read the flag config/dashboard, then confirm with the owner. Reject the flag from this pass if it's still rolling out, A/B testing, a kill-switch kept for emergencies, or used per-tenant/per-environment with different values — those are live, not stale.
+2. **Find every reference — grep the flag KEY, not just the helper.** A flag leaks far past its `if`. Search the whole repo for the literal flag key string and its identifier:
+   - the helper calls: `isEnabled("new_checkout")`, `flags.newCheckout`, `useFlag(...)`, `treatment(...)`;
+   - the flag *definition/registration* (the declarations file, defaults, env vars, IaC/config);
+   - tests, fixtures, and mocks that force the flag on or off;
+   - analytics/telemetry events fired only when on, and feature-gated schema/migrations/routes;
+   - string usages: config keys, JSON, YAML, query params, log lines, docs.
+   Grep both the key (`"new_checkout"`) and the symbol (`newCheckout`) — different layers spell it differently.
+3. **Collapse each conditional to the winning branch.** For every reference, rewrite the conditional to keep only the winner: fully-on → keep the `if` body, drop the `else`/fallback; abandoned → keep the `else`, delete the guarded body. Remove the now-constant condition entirely — no `if (true)`, no dead `else`. Flatten the indentation you just freed.
+4. **Delete the code only the dead branch reached.** A removed branch usually calls helpers, imports, components, or fires events that nothing else uses. Trace each symbol the loser referenced; if its only caller was the branch you just deleted, remove it too (and repeat transitively). This is where flag retirement leaves dangling dead code if you stop at the `if`.
+5. **Remove the flag's definition and its tests.** Delete the flag declaration/registration, its default value and env/config entries, and the tests/fixtures that existed solely to toggle it. Tests that asserted the *winning* behavior stay — but drop their flag-setup boilerplate so they test the now-unconditional path.
+6. **One flag at a time, tests green after each.** Never retire two flags in one pass. After each flag: run the build and test suite, confirm green, and keep it as a single commit. A revert then removes exactly one flag's worth of change with no collateral.
+
+> [!WARNING]
+> A flag almost always guards MORE than the obvious if-block — feature-gated helper functions, config defaults, DB columns or migrations, route registrations, and analytics events reachable only when on. Grep exhaustively (step 2) before deleting: stop at the `if` and you leave dangling dead code; over-trust a single grep and you delete a path the *winning* branch still uses. When in doubt whether a symbol is shared, keep it and flag it for review.
+
+## Output
+
+For each retired flag, a record an owner can rubber-stamp:
+
+- **Confirmed final state** — `permanently-on` or `abandoned`, with the source (flag dashboard value + owner sign-off) and the resulting winning branch.
+- **Reference inventory** — every match for the key and symbol, grouped by layer: conditionals, definition/config, tests/fixtures, analytics, schema/routes, docs/strings.
+- **Collapse plan** — per conditional: which branch wins, the resulting diff, and the list of now-dead symbols deleted because only the loser reached them.
+- **Verification** — confirmation the build and test suite pass after the removal, and that the change is a single self-contained commit. Anything ambiguous (shared symbol, public-API surface, flag still live elsewhere) is listed as a manual-review item rather than deleted.