@brijeshc2049/quiver
v2.0.0
Published
A curated quiver of composable skills for Claude Code: interviews, audits (security, design, UX, a11y), deep review, debugging, testing, perf, plain-language explanations, and a full anti-generic design suite. Installs skill folders into your Claude Code
Maintainers
Readme
🏹 Quiver
A curated quiver of skills for Claude Code. Every arrow has a purpose.
Quiver is a set of 31 sharply-scoped, composable skills that make Claude Code interview like a senior engineer, audit like a skeptic, debug like a scientist, and design like it has taste. Version 2.0 rebuilds the whole collection on a strict authoring contract: shared procedure cores, thin domain wrappers, and a no-op test that deletes every sentence that doesn't change the agent's behavior.
You: /ask-me a billing export feature
Claude: Walk me through the moment a user needs this export.
What were they doing right before? …
→ writes SPEC.md you both agree on
You: /design-audit src/
Claude: → scope, hunt, verify, report: the 3 structural moves
that unlock the most, ranked by leverageWhy Quiver exists
Most skills collections suffer the same three problems: skills that are vague ("makes your code better"), overlapping (four flavors of code review), and bloated (walls of prose the agent skims). Quiver fixes all three:
- Every skill is a contract. Its description says exactly when it triggers; its body says exactly what procedure runs and what deliverable you get.
- Zero overlap by design. Audits sweep the codebase, reviews judge the diff, and every name encodes its scope. You always know which arrow to draw.
- Nothing is bloated. Wrapper bodies stay under ~150 words, cores under ~300; depth lives in reference files loaded only when needed. The rules are public in docs/WRITING-SKILLS.md.
Install in 60 seconds
Option A - npm (one cross-platform command):
npx @brijeshc2049/quiver install # all skills -> ~/.claude/skills
npx @brijeshc2049/quiver install --project # -> ./.claude/skills (share with your team)
npx @brijeshc2049/quiver install ask-me deep-review # just a few; required cores are pulled inOption B - plugin marketplace (native, versioned, no file copying):
/plugin marketplace add brijeshc/quiver
/plugin install quiver@quiverSkills are namespaced as /quiver:ask-me and update with /plugin marketplace update quiver.
Start (or restart) Claude Code, type /, and you'll see the skills.
Manual git clone + copy, subset rules, and troubleshooting: see docs/INSTALL.md.
The architecture: cores + wrappers
Two core skills hold the procedures; thin wrappers point a domain lens at them.
| Core | The loop | Its wrappers |
|---|---|---|
| interviewing | one question at a time → saturation → deliverable | ask-me, design-discussion |
| auditing | scope → hunt → verify → report | security-audit, design-audit, ux-audit, a11y-audit |
A wrapper is ~100 words: "run the core with this lens, produce this deliverable."
Its checklist lives in a lens.md beside it.
Install a wrapper and its core together; a wrapper without its core fails visibly instead of degrading.
The quiver
Interviews - settle it before building
| Skill | Draw it when… | What you get |
|---|---|---|
| /ask-me | starting anything ambiguous | An interview (one question at a time) → a SPEC.md you both agree on |
| /design-discussion | weighing architecture choices | Sparring with trade-offs and recommendations → an ADR per decision (or a session DESIGN.md) |
Audits - sweep the existing code
| Skill | Draw it when… | What you get |
|---|---|---|
| /security-audit | touching auth, input, or going to production | Untrusted-data walk: injection, authz, secrets - severity, source→sink, fixes |
| /design-audit | code feels hard to change | Structural findings ranked by leverage, each naming the change it makes expensive |
| /ux-audit | users say it's hard to use | Flow walk: the moments users are confused, blocked, or misled |
| /a11y-audit | building or auditing any UI | WCAG 2.2 AA pass: keyboard walk, semantics, contrast computed not eyeballed |
Workflow - build, verify, ship
| Skill | Draw it when… | What you get |
|---|---|---|
| /deep-review | a diff/branch/PR needs judgment before merge | Real bugs with evidence and severity, never style nitpicks |
| /root-cause | something is broken or flaky | Reproduce → isolate → prove → fix + regression test |
| /write-tests | coverage is missing or hollow | Behavior-focused tests that survive refactoring, run and shown passing |
| /perf | something is slow | Profile → fix the proven bottleneck → before/after numbers |
| /refactor | structure blocks the next feature | Behavior-preserving steps, tests green after every one |
| /readable | code works but humans struggle | Naming/structure/comment pass, behavior untouched |
| /simply-explained | anything needs explaining | Plain words, one analogy, one mermaid diagram, exportable to markdown |
| /document | docs are missing or stale | READMEs/API docs/docstrings/ADRs for a named reader, examples executed |
| /api-design | designing any interface others call | Caller-first design: example code → contract → evolution plan |
| /ship | work is done, tree is messy | Atomic commits with honest messages; optional reviewable PR |
Design suite - the anti-generic system
Start with the foundation, then layer a register:
| Skill | The register |
|---|---|
| /design-dna | Foundation - banned generic tells, identity derivation, type/color/space/motion contract |
| /design-scholarly | A university press monograph |
| /design-minimal | Rams-era Braun, Swiss typography |
| /design-expressive | A magazine cover, a concert poster |
| /design-brutalist | Béton brut, early-web, gig flyers |
| /design-luxe | A flagship boutique at midnight |
| /design-playful | Great toy design |
| /design-mood <emotion> | Emotion → full system: 10 recipes in moods.md |
| /design-scene <scene> | Lived moment → full system: 10 recipes in scenes.md |
Meta - run the quiver itself
| Skill | Draw it when… | What you get |
|---|---|---|
| /which-arrow | unsure which skill fits | One recommendation with the exact command, or the full chain |
| /handoff | parking work or switching sessions | HANDOFF.md: state, decisions, gotchas, next steps - verified against the tree |
| /to-issues | a spec needs to become tracker work | Vertical-slice issues with acceptance criteria, via gh or as files |
| /to-prd | a discussion settled what to build | PRD.md distilled from the conversation, gaps marked as open questions |
How skills work (30-second primer)
A skill is a folder with a SKILL.md - instructions Claude loads only when needed.
Two ways a skill fires:
- You invoke it: type
/readable src/billing/- explicit, with optional arguments. - Claude invokes it: say "this function is impossible to follow" and Claude loads
readableon its own.
Six Quiver skills are deliberately manual-only (/ask-me, /design-discussion, /ship, /handoff, /to-issues, /to-prd) - interviews, commits, and published artifacts happen on your schedule, never Claude's.
Skills compose. A typical feature, end to end:
/ask-me payments retry logic → SPEC.md agreed
/design-discussion queue vs cron → ADR 0007 recorded
/to-issues → 4 vertical slices
…build against the spec…
/write-tests → behavior coverage, run green
/deep-review → 1 blocker found and fixed
/ship pr → atomic commits + reviewable PRMore chains in docs/USAGE.md.
Documentation
| Doc | What's in it | |---|---| | docs/INSTALL.md | All three install methods, per-OS commands, verification, updating, troubleshooting | | docs/USAGE.md | Which skill when, chaining recipes, design-suite decision guide | | docs/WRITING-SKILLS.md | The authoring contract every Quiver skill is built to - write your own to the same bar | | docs/TESTING.md | The live-fire test log: how each skill is verified, with results |
FAQ
Do these conflict with Claude Code's bundled skills (/code-review, /security-review)?
No - Quiver names avoid every bundled name (deep-review not code-review, security-audit not security-review).
That's a rule in the authoring contract, not a coincidence.
Can I install just one skill?
Standalone skills (workflow, design, meta): yes, copy the folder.
Wrappers need their core too: ask-me/design-discussion need interviewing; the four *-audit skills need auditing.
The pairs are listed in docs/INSTALL.md.
What happened to /harden and /a11y?
Renamed in 2.0: /harden became /security-audit and /a11y became /a11y-audit, joining the audit family on the shared core.
Delete the old folders when updating a 1.x install.
Claude triggers a skill when I don't want it.
Add disable-model-invocation: true to that skill's frontmatter, or set it to "off" under skillOverrides in your settings.
Why are the SKILL.md files so opinionated? Vague instructions produce average output, and average is the problem. Disagree with an opinion? Edit the file - it's markdown, and it's yours after install.
License
MIT - see LICENSE.
