coding-skills

A collection of Claude Code skills for software development — reusable behavioral modules that load specialist mindsets, enforce discipline, and structure complex workflows.

What's a Skill?

A Claude Code skill is a Markdown file (or directory) with a SKILL.md at the root. The file starts with a YAML header declaring a name and description. Claude Code loads it on demand via the /skill-name slash command, injecting focused instructions for a specific domain.

Skills

Skill	What it does
addressing-findings	Walks an analyze-code report or a PR's review comments one finding at a time — explain, propose options, recommend, ask. Nothing changes until you approve, and it never posts to the PR — it hands you the reply text.
analyze-code	Multi-lens audit of existing code across architecture, quality, performance, security, and style. Produces a prioritized findings report — a deep review, not a gate decision.
brainstorm	Turns vague ideas into concrete, validated specs through Socratic dialogue — one question at a time. No implementation until the design is approved.
coding-discipline	Names the six most common LLM coding failure modes (silent assumption, scope creep, speculative complexity, hallucination, drift, parallel solution) and the counter-move for each.
designing-interfaces	Makes interface width visible before the implementation is written. Requires a four-line contract — what the caller must learn, what the module hides, where the seam is, what the test calls — and sends the design back when nothing is hidden. Counterweights coding-discipline's minimality bias, which on its own selects for the shallower design.
guiding-manual-testing	Walks you through verifying a change by hand on a real environment (local or staging) with real data — one step at a time, you run it and paste the output back. Enforces a matched pair (the case that must change and the case that must not), predictions written before execution, and a restore point before any mutation. Report-only; never touches the environment itself.
knowledge-base	User-curated, agent-maintained project wiki for system surfaces (entities, interfaces, jobs, dependencies, events, business rules), implementation plans, and plain-language operator manuals. Queryable on its own; the wiki and plans are consulted by brainstorm, using-software-specialists, and analyze-code when a kb_path is configured.
research	Answers questions about your own codebase — endpoints, event payloads, "what happens when X?", "how do I run X?" — by reading the actual source (serena + the KB), never from memory. Brings a sourced, cited answer instead of interrogating you; effort scales from a one-line lookup to a full traced investigation. External / best-practice questions are handed off to the deep-research-agent specialist. The inverse of brainstorm.
style-checker	Reviews code against Google's official style guidelines. Produces a structured violation report grouped by severity (Critical / High / Medium / Low). Supports Go, Java, Python, JavaScript, TypeScript, Shell, and Markdown.
test-driven-development	Enforces the Red→Green→Refactor cycle before any production code is written. Covers the full TDD workflow: writing a failing test first, minimal implementation, and safe refactoring with a green suite.
using-software-specialists	Routes software tasks to the right specialist mindset (security engineer, architect, tester, DBA, etc.) at the right phase. Includes a phase model, a task-routing table, and a "Validate Before Done" gate.
writing-unit-tests	Guides unit test authorship in any language — scenario identification across four quadrants, FIRST-U principles, Arrange–Act–Assert structure, mocking strategy, and language-specific references.

Installation

Copy the skill directories you want into your Claude Code skills folder:

cp -r addressing-findings analyze-code brainstorm coding-discipline designing-interfaces guiding-manual-testing knowledge-base research style-checker test-driven-development using-software-specialists writing-unit-tests ~/.claude/skills/

Skills are then available as slash commands in any Claude Code session:

/addressing-findings
/analyze-code
/brainstorm
/coding-discipline
/designing-interfaces
/guiding-manual-testing
/knowledge-base
/research
/style-checker
/test-driven-development
/using-software-specialists
/writing-unit-tests

Usage

Invoke a skill by typing its slash command, optionally followed by a description of your task:

/research do we have an endpoint for password reset, and what's its payload?
/brainstorm I want to build a rate limiter for our API
/style-checker review the auth module
/using-software-specialists add OAuth support to the backend

See each skill's own README.md for detailed usage, file structure, and examples.

Workflows

A typical feature-development loop using these skills:

0. Research (whenever you have questions, not a goal) — /research brings a sourced, cited answer about your own codebase ("do we have an endpoint for X?", "what's the payload of event X?", "what happens when X?") by reading the source with serena + the KB, never from memory. Effort scales — a one-line lookup stays ceremony-free; a deep trace gets confidence levels and named gaps. Its findings make brainstorm's intent questions answerable; for an already-clear path it can hand straight to using-software-specialists. (External / best-practice questions go to the deep-research-agent specialist, not here.)
1. Define — /brainstorm scopes the change through Socratic dialogue and produces an approved spec, then hands off to the Project Planner specialist, which turns the spec into an execution plan. The plan is saved into the KB under <kb_path>/plans/ (or docs/specs/ when no kb_path is configured), so it persists across sessions and — for cross-repo work — can be referenced from any repo.
2. Build — /using-software-specialists ingests the plan, validates it against the Plan-phase done-criteria, and implements. The Implementation phase loads designing-interfaces, coding-discipline, and test-driven-development (which pulls in writing-unit-tests) before any code is written.
3. Audit — /analyze-code reviews the result and produces a severity-ranked findings report with a Suggested Next Actions block that routes each finding cluster back to the right specialist.

The loop then closes through one of three back-edges:

• Findings to apply → /addressing-findings walks the report one finding at a time, loading the specialist each finding names. The same walk handles review comments on a PR.
• Plan needs changes → re-enter /brainstorm against the existing plan file. It enters revision mode — diffs the requested change, asks only about the deltas, and updates the plan in place.
• Bug surfaced during testing → re-enter /using-software-specialists starting with Troubleshooter.

/guiding-manual-testing is invoked on demand, when you want to confirm a change behaves correctly against real data before merging or releasing. It runs nothing itself — it proposes one action at a time, reads the output you paste back, and interprets it. A failed verification or an unexpected finding feeds the same back-edges as an audit.

/designing-interfaces is loaded twice in the loop: during Implementation, before any interface is written, and again as part of the Quality lens of every /analyze-code run, where the same depth check is applied to interfaces the change already introduced.

/style-checker is invoked on demand, or as the Style lens of every /analyze-code run (independent of whatever linter the project ships, which analyze-code runs separately as configured tooling).

/knowledge-base sits underneath the loop as a shared substrate when kb_path is configured: brainstorm reads the wiki for system context, and the Project Planner it hands off to writes the resulting plan into plans/; using-software-specialists loads it during Implementation to read the matching plan and the repo's Helpers / Patterns; analyze-code reads it during Frame and surfaces wiki↔code disagreements as findings. The user invokes /knowledge-base directly to query, ingest, update, or lint.

flowchart TD
    Q([A question, not a goal]) --> RS[research]
    Idea([A vague idea]) --> BS[brainstorm]
    PR([PR review comments]) --> AF[addressing-findings]

    RS -->|sourced findings| BS
    RS -.->|clear path| USS

    BS -->|approved plan file| USS[using-software-specialists]
    USS -->|implemented| AC[analyze-code]

    AC -->|findings to apply| AF
    AF -->|approved fix| USS
    AC -->|plan needs changes| BS
    AC -->|bug during testing| USS
    AC -->|clean| Ship([Ship])

    USS -.->|on request| GT[guiding-manual-testing]
    GT -->|bug proven| USS

    subgraph during [During the Implementation phase]
        DI[designing-interfaces]
        CD[coding-discipline]
        TDD[test-driven-development] --> WUT[writing-unit-tests]
    end
    USS -.loads.-> during

    KB[(knowledge-base)] -.->|context| BS
    KB -.->|plan + helpers/patterns| USS
    KB -.->|drift findings| AC

    AC -.->|style lens| SC[style-checker]
    AC -.->|quality lens| DI

Loading

License

MIT — see LICENSE.