en un clic
claude-skills
claude-skills contient 18 skills collectées depuis Code-Shock, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Expert guidance for ffuf web fuzzing during penetration testing, including authenticated fuzzing with raw requests, auto-calibration, and result analysis
Catch up on uncommitted work — read all uncommitted git changes (staged, unstaged, untracked) into the conversation to establish context. Use when resuming work or when the user runs /catchup.
Bring a JavaScript repo up to the standard Code Quality Playbook baseline (Prettier, ESLint ratchet, husky + lint-staged, CI lint gate, optional JSDoc typecheck) idempotently — present pieces are skipped, missing ones are added — then optionally migrate the repo from npm to pnpm (lockfile import, packageManager pin, build-script allow-list, Firebase functions-framework fix, npm cleanup). Manual, global. Use only when the user runs /code-quality.
Create git commits for staged and unstaged changes using the emoji commit-message format, with optional push. Use when the user wants to commit or check in changes, or runs /commit.
Execute one complete unit of work end-to-end through tight feedback loops — understand it, plan it, build it, validate it, commit it — never advancing a phase until its feedback signal is green. Manual and global: runs only when the user invokes /do-work or another skill explicitly hands it a scoped unit of work. Use to "do the work", "execute this task/plan/issue", "build and validate and commit", or as the execution engine other planning skills delegate to.
Set up Playwright E2E testing framework for any project — auto-detects stack, auth, routes, and selectors
Generate a structured development epic through an interactive, phase-by-phase approval workflow that breaks a large piece of work into tasks. Use to create an epic, break down a large feature, or when the user runs /epic.
Set up git guardrails — a Claude Code PreToolUse hook that intercepts and blocks dangerous git commands such as force-push and hard reset before they run. Use to install git safety hooks or when the user runs /git-guardrails.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Work through open GitHub issues one at a time, each executed as a complete unit of work through a feedback loop (TDD then validate, never advancing on red) behind an enforced lint-staged and Prettier quality gate, then shipped as a feature branch and PR. Use to grind issues or when the user runs /grind.
Break a PRD into independently-grabbable GitHub issues using vertical slices (tracer bullets). Use to convert a PRD or spec into actionable issues or when the user runs /prd-to-issues.
Turn a PRD into a phased implementation plan using tracer-bullet vertical slices, saved as a Markdown file in ./plans/. Use to plan implementation from a PRD or when the user runs /prd-to-plan.
Rapidly file one or more well-structured, agent-friendly GitHub issues in the current repo. Use to quickly capture bugs or tasks as issues or when the user runs /qa.
Run accessibility and visual design review
Build features or fix bugs using red-green-refactor TDD with vertical slices, where tests verify behavior through public interfaces. Use for test-driven development or when the user runs /tdd.
Build and maintain a project's ubiquitous language — a CONTEXT.md glossary (plus ADRs and, for multi-repo projects, a context map). Interviews you to sharpen terminology, grounds terms in the code, and keeps the docs a living, drift-checked source of truth. Use to bootstrap or audit domain terminology, or when the user says "/terms".
Investigate a reported problem, find its root cause, and file a GitHub issue with a TDD fix plan — a mostly hands-off workflow. Use to triage a bug or diagnose root cause, or when the user runs /triage-issue.
Create a Product Requirements Document through an interactive interview, then file it as a GitHub issue. Use to write a PRD or spec or when the user runs /write-prd.