Ready-to-use skills for Claude Code. Save to ~/.claude/skills/ and invoke with /name.
/reviewer [pr-link]Reviews Pull Requests as a senior engineer — flags bugs, style issues, performance opportunities, and test coverage gaps. Before executing, shows the full prompt and waits for your confirmation.
~/.claude/skills/reviewer/SKILL.md--- name: reviewer description: Reviews PRs in GitHub Review style --- Before reviewing, show me the full prompt you will use and wait for my confirmation. Only proceed after I reply "go ahead". You are a senior engineer reviewing a Pull Request. Analyze the code and return comments in GitHub Review style, organized by file and line number when possible. For each issue found, use the format: **[FILE]** `path/to/file.ext` **[LINE]** 42 *(if applicable)* **[TYPE]** 🐛 Bug | ⚠️ Style | ⚡ Performance | 🧪 Tests **[SEVERITY]** Critical / Important / Suggestion **[COMMENT]** Description of the issue. **[SUGGESTION]** How to fix it. ### Review Summary - ✅ What looks good - 🔴 Critical (blocks merge) - 🟡 Important - 💡 Optional suggestions ### Verdict [ ] Approved [ ] Approved with comments [ ] Changes required Focus: bugs, style, performance, test coverage. PR: $ARGUMENTS
/create-pr [jira] [v1.0.0] [diff]console.log or debug code~/.claude/skills/create-pr/SKILL.md--- name: create-pr description: Generates PR title, SDD description and full checklist --- You are a senior engineer who writes clear, standardized PR descriptions. From the Jira link, milestone and diff, generate a complete PR. If any data is missing, ask before continuing. ## Title Format: [TYPE-0000] Short clear description · Milestone: vX.X.X Types: BUG | FEAT | CHORE ## Description ### 🎯 Context What motivated this change? Reference: [TYPE-0000](jira-link) ### 🛠️ What was done Objective bullet points of the main changes. ### 🔍 Technical decisions Trade-offs and discarded alternatives, if any. ### 📸 Evidence Screenshots, videos, Bugsnag/tracker links. ⚠️ Required if it affects UI or user-visible behavior. ## ✅ Checklist - [ ] Automated tests passing - [ ] Manually tested - [ ] Docs / MDs updated (if applicable) - [ ] Code quality / lint ok - [ ] Evidence included (when required) - [ ] No `console.log` or debug code After generating, confirm: Jira type/number, milestone, evidence. Content: $ARGUMENTS
/reply-pr [comment]Analyzes a code review comment and suggests the best reply — agreeing and fixing, arguing technically, or asking for more context. Always professional and direct.
~/.claude/skills/reply-pr/SKILL.md--- name: reply-pr description: Suggests replies to code review comments --- You are a senior engineer responding to a code review comment. Analyze the comment and suggest the best reply. **[TYPE]** - ✅ Agree → will fix - 🤔 Partially agree → will adapt - 💡 Disagree → have a technical argument - ❓ Need more context **[SUGGESTED REPLY]** Write the reply directly — professional and objective. If fixing, mention what will change. If arguing, cite references or justify technically. If needing context, ask a specific question. **[ACTION]** What needs to be done in the code (or no action needed). Keep a collaborative tone — code review is about the code, not the person. Comment: $ARGUMENTS
/open-pr [branch] [base]Opens the PR on GitHub via CLI using the title and description generated by /create-pr. Suggests labels and milestone based on the task type.
~/.claude/skills/open-pr/SKILL.md--- name: open-pr description: Opens PR on GitHub with title, description and metadata allowed-tools: Bash --- Use the title and description already generated by /create-pr. If not ready, run /create-pr first. ## Steps 1. Check authentication: `!gh auth status` 2. Confirm current branch: `!git branch --show-current` 3. Open the PR: ```bash gh pr create \ --title "[TYPE-0000] Change title" \ --body "$(cat pr-description.md)" \ --base main \ --milestone "vX.X.X" \ --label "bug|feature|chore" \ --assignee "@me" ``` 4. Display the link of the created PR. ## Labels by type FEAT → `feature` · BUG → `bug` · CHORE → `chore` If gh CLI is not installed: `brew install gh && gh auth login` Branch and base: $ARGUMENTS
/sdd-init [project]Initializes the SDD kit structure in the project. Replace the "Team-specific kit" block with your team's commands.
~/.claude/skills/sdd-init/SKILL.md--- name: sdd-init description: Initializes the SDD kit structure in the project allowed-tools: Bash, Write --- Initialize the base SDD structure for the given project. ## Structure to create ``` .sdd/ spec.md ← generated by /sdd-spec plan.md ← generated by /sdd-plan hub.md ← general index, generated by /sdd-hub decisions/ ← technical decision log (ADRs) risks.md ← risks and dependencies ``` ## Team-specific kit # ⚠️ Replace with your team's commands: # !your-init-command $ARGUMENTS ## After creating the structure - Confirm directories were created - Instruct to run /sdd-install next Project: $ARGUMENTS
/sdd-installInstalls the SDD kit dependencies. Replace the install block with your team's actual commands.
~/.claude/skills/sdd-install/SKILL.md--- name: sdd-install description: Installs SDD kit dependencies allowed-tools: Bash --- Install the dependencies required for the SDD kit. ## Pre-install checks 1. Confirm /sdd-init was run (.sdd/ exists) 2. Check the environment (node, python, etc. per kit) ## Kit installation # ⚠️ Replace with your team's actual commands: # !npm install your-sdd-kit # !your-cli install ## After installing - Confirm installation was successful - Instruct next step: /sdd-start - If there's an error, diagnose and suggest a fix
/sdd-start [idea]Entry point for the SDD flow. Receives the idea or problem in plain language, confirms understanding, and sets the stage for /sdd-spec.
~/.claude/skills/sdd-start/SKILL.md--- name: sdd-start description: Kicks off the SDD flow from an idea or problem --- You are a senior engineer starting a Software Design Document. Receive the idea and structure the beginning of the SDD. ## What to do 1. Paraphrase the problem to confirm understanding 2. Identify the work type: - New feature · Refactor · Recurring fix · Spike 3. Create `.sdd/hub.md` with the header: ```md # SDD — [Feature/Problem Name] **Status:** 🟡 In progress **Started:** [date] **Type:** feature | refactor | fix | spike ## Summary [Problem paraphrase in 2-3 lines] ## Next steps - [ ] /sdd-spec — gather specifications - [ ] /sdd-plan — plan execution - [ ] /sdd-build — develop ``` 4. Instruct next step: /sdd-spec Idea: $ARGUMENTS
/sdd-spec [context]Generates technical and non-technical specifications. Asks business questions to fill gaps before producing the final document.
~/.claude/skills/sdd-spec/SKILL.md--- name: sdd-spec description: Generates technical and non-technical specs, asks business questions --- Read `.sdd/hub.md` to understand the current context. ## Phase 1 — Business questions Before generating specs, ask up to 5 essential questions: - Who are the affected users? - What is the success criterion for this delivery? - Are there deadline constraints or external dependencies? - Is there a business decision that limits solutions? - What metrics will validate the result? Wait for answers before continuing. ## Phase 2 — Generate `.sdd/spec.md` ```md # Specifications — [Name] ## Context and Problem ## Non-Technical Requirements ## Technical Requirements ## Acceptance Criteria - [ ] [Verifiable behavior] ## Estimate - Complexity: S / M / L / XL - Effort: X days/sprints ``` After generating, instruct: /sdd-plan Context: $ARGUMENTS
/sdd-planReads the spec and generates the full execution plan — broken-down tasks, architecture decisions, trade-offs, and mapped risks.
~/.claude/skills/sdd-plan/SKILL.md--- name: sdd-plan description: Generates execution plan, tasks and architecture --- Read `.sdd/spec.md` and `.sdd/hub.md`. Generate `.sdd/plan.md`. ```md # Execution Plan — [Name] ## Solution Architecture [Technical approach + ASCII diagram if needed] ## Technical Decisions | Decision | Alternatives | Reason | |----------|-------------|--------| ## Tasks ### Phase 1 — [Name] - [ ] [TASK] Description · estimate: Xh ## Risks and Dependencies | Risk | Prob. | Impact | Mitigation | |------|-------|--------|------------| ## Execution order 1. ... ``` Update the hub and instruct: /sdd-build
/sdd-build [task]Starts development following the /sdd-plan. Executes task by task, updates the hub with progress, and flags blockers.
~/.claude/skills/sdd-build/SKILL.md--- name: sdd-build description: Starts development following the SDD plan allowed-tools: Read, Write, Bash, Grep, Glob --- Read `.sdd/plan.md` and `.sdd/spec.md` before starting. Execute tasks in the order defined in the plan. ## Before each task 1. Read the task and confirm understanding 2. Check that dependencies are complete ## During development - Follow project patterns (linting, naming, structure) - Write or update tests for each change - If you hit a blocker or an unplanned decision: → Document in `.sdd/decisions/YYYY-MM-DD-name.md` → Flag before proceeding ## After each task Update `.sdd/hub.md` marking progress. If a specific task is passed, focus only on it. Task: $ARGUMENTS
/sdd-hubDisplays and updates the SDD central index — status of each stage, decisions made, next steps, and links to all generated documents.
~/.claude/skills/sdd-hub/SKILL.md--- name: sdd-hub description: Displays and updates the SDD central index allowed-tools: Read, Write --- Read all files in `.sdd/` and update the hub. ```md # SDD Hub — [Project Name] **Overall status:** 🟡 In progress | ✅ Done | 🔴 Blocked **Last updated:** [date] ## Stages | Stage | Status | File | |------------|--------|--------------| | /sdd-spec | ✅ | .sdd/spec.md | | /sdd-plan | ✅ | .sdd/plan.md | | /sdd-build | 🟡 | — | ## Task progress [current checklist from plan.md] ## Logged decisions - [date] — [Decision] → .sdd/decisions/... ## Active risks [risks not yet mitigated] ## Next step → [clear instruction] ``` Display the hub and signal the next step.
/sdd-fix [problem]Fixes a specific problem found during or after /sdd-build. Logs the fix as a decision in the hub for traceability.
~/.claude/skills/sdd-fix/SKILL.md--- name: sdd-fix description: Fixes a specific problem and logs it in the SDD allowed-tools: Read, Write, Bash, Grep --- Read `.sdd/spec.md` and `.sdd/plan.md` before acting. ## Diagnosis 1. Understand the problem: where, when, impact 2. Identify the root cause (not the symptom) 3. Check if it was listed in risks 4. Confirm diagnosis before fixing ## Fix - Implement the minimal necessary fix - Do not refactor unrelated code - Add tests that cover the scenario - Verify it doesn't break other flows ## Log Create `.sdd/decisions/[date]-fix-[name].md`: ```md # Fix — [Name] **Problem:** ... **Root cause:** ... **Solution:** ... **Tests added:** yes/no ``` Problem: $ARGUMENTS