# Claude Dev Toolkit
**Generic development standards for Claude Code, packaged as skills.** Backend, frontend, Git/GitHub, spec-driven planning and end-to-end flow validation, written once and kept free of any company's names. Your team's own rules plug in through **standards slots** that each project declares in its `CLAUDE.md`, so the same skills serve any team.
It works on its own, and it is the skill set the [Claude Maestro](https://github.com/iagopadilha/claude-maestro) agents load.
## Skills
| Skill | What it does | Reads slot |
|---|---|---|
| `backend-dev` | .NET and Node.js (NestJS): layers, naming, SOLID, DI, structured logs, generic repository, behavior regression | `backend`, `app-map` |
| `frontend-dev` | React + Vite + TypeScript (and Next.js): Component → Hook → Query → Service, forms, toasts, grids, UI review | `frontend`, `app-map` |
| `github` | Git and GitHub (`gh`): what needs confirmation, what is never allowed, feature branches, PRs, local cleanup | `git` |
| `tlc-spec-driven` | Planning in 4 adaptive phases: Specify, Design, Tasks, Execute, with requirement traceability | none of its own: from Specify onwards it loads `backend-dev` or `frontend-dev`, which read theirs |
| `flow-validator` | Validates a flow against the running app: API routes with curl, UI with Playwright. Reports PASS, FAIL or UNVERIFIED per step | `app-map`, `observability` |
| `playwright-cli` | Browser automation for tests, E2E checks and screenshots, headless by default | none |
| `playwright-component-testing` | Component tests with Playwright | none |
| `playwright-trace` | Reading and debugging Playwright traces | none |
## Standards slots
A generic skill never names a company. It only knows the **name of a slot**. The project says which skill fills that slot. This is dependency inversion: the generic skill depends on the slot, a company skill implements it, and the project's `CLAUDE.md` binds the two.
| Slot | What the bound skill provides | Read by |
|---|---|---|
| `git` | organization, protected branches, branch and PR flow | `github` |
| `backend` | base URLs, mandatory libraries, real examples, backend rules that win over the generic ones | `backend-dev` |
| `frontend` | design system: typography, colors, components, ready-made code models | `frontend-dev` |
| `app-map` | which app does what, URLs, local ports and folders | `backend-dev`, `frontend-dev`, `flow-validator` |
| `observability` | where to read logs and metrics of the running apps | `flow-validator`; Claude Maestro's planning and spec agents |
Bind them in the project's `CLAUDE.md`:
```markdown
## Standards
git: acme-git-standards
backend: acme-backend-standards
frontend: acme-design-system
app-map: acme-app-map
observability: acme-grafana
```
How the section is read (exact details in [docs/STANDARDS.md](docs/STANDARDS.md)): one `slot: value` line per slot, no bullets, backticks or `=`; a line starting with `#` ends the section; slot names are lower-cased; for a duplicate slot the last line wins; a tool may rewrite the section, so comments inside it are lost. The five slots, in one line each: `git` (organization, protected branches, PR flow), `backend` (rules and examples that win over `backend-dev`), `frontend` (design system for `frontend-dev`), `app-map` (which app does what, ports and URLs), `observability` (where to read logs and metrics).
Rules:
1. **No binding, no company rule.** A slot that is missing or empty means the generic skill uses only its own defaults.
2. **The bound skill wins.** Where it conflicts with the generic skill, the bound skill's rule is the one followed.
3. **A standards skill holds only the delta.** It never repeats the generic text. A `git` standards skill can be ten lines: the organization, the protected branches and the PR flow.
4. **A value is a skill name.** A bare name (`acme-git-standards`) or a plugin-qualified one (`acme:acme-git-standards`; Claude Maestro's parser drops the prefix when it resolves the skill). A bound skill that is not installed (the Skill tool does not find it) is reported, and the generic default is used.
5. **Generic skills never name a standards skill.** The only place a company name appears is the company's own plugin and the project's `CLAUDE.md`.
### Writing your company's standards plugin
- Put every standards skill in your own plugin, never in this one.
- Prefix each skill with the company name (`acme-git-standards`, `acme-design-system`), so it is clear what is company-specific.
- Write only what differs from the generic skill. If you find yourself copying a section, the generic skill is missing an extension point: open an issue here instead.
- Add the `## Standards` section to the `CLAUDE.md` template your company uses for new repositories.
## Install
Requires Claude Code and **Python 3.8+** (standard library only, nothing to `pip install`). Every script command in the skills is written with `python`. On a system where only `python3` exists, replace `python` by `python3` (or add an alias). On Windows, `testenv.py exec` also needs Git Bash (Git for Windows).
```
/plugin marketplace add iagopadilha/claude-dev-toolkit
/plugin install claude-dev-toolkit@claude-dev-toolkit
```
The skills then show up as `claude-dev-toolkit:<skill>`. Then add the `## Standards` section to the `CLAUDE.md` of each project that has company rules.
## With Claude Maestro
[Claude Maestro](https://github.com/iagopadilha/claude-maestro) runs a planned, guarded loop of Claude Code subagents. Its executors, spec writer and verifiers load the skills of this toolkit, so **Maestro requires this plugin**:
- Maestro's installer writes the `## Standards` section next to the `Conformance` block it already keeps in each repo's `CLAUDE.md`.
- In the isolated loop, Maestro bundles the toolkit skills and the skills bound to the project's slots, and adds both to its per-profile skill allowlist.
- `harness.py doctor` reports a missing toolkit and any slot bound to a skill that is not installed.
This toolkit never depends on Maestro: every skill works in a plain Claude Code session.
## Optional companions
Skills and tools that the generic skills use when they are installed, and skip otherwise. None is required; without them the skill follows its own text.
| Companion | Used by | Fallback when absent |
|---|---|---|
| `refactoring-guru-techniques` | `backend-dev`, `frontend-dev` (refactoring) | the smell/technique/pattern table in the shared core. Not bundled: its text follows Refactoring.Guru's own content usage policy |
| `safe-refactor`, `surgical-patch`, `lean-build`, `investigate-first`, `migration`, `verify-and-stop` | `backend-dev`, `frontend-dev` (working mode, N6) | the rules written in the shared core |
| `mermaid-studio` | `tlc-spec-driven` (diagrams in design) | plain Mermaid blocks written by hand |
| `codenavi` | `tlc-spec-driven` (brownfield mapping) | `Grep` and `Glob` exploration |
| Context7 MCP | `tlc-spec-driven` (library research) | the project docs, then a web search; flag what stays uncertain |
## Layout
```
.claude-plugin/marketplace.json
LICENSE
docs/STANDARDS.md the slot contract (this README's "Standards slots", in full)
plugin/
.claude-plugin/plugin.json
skills/<skill>/SKILL.md one folder per skill (references/ beside it)
shared/ files shared by the skills, reached as ${CLAUDE_PLUGIN_ROOT}/shared/<folder>/<file>.
Convention: lowercase names; kebab-case for .md, snake_case for .py
rules/core-dev.md the common dev core injected into backend-dev and frontend-dev
templates/project-claude-md.md template of a project's CLAUDE.md (reuse map, conformance)
templates/regression-script.md template of a behavior-regression script
templates/test-environment.md, network.example.json, env-test.example flow-validator setup files (names only, fake values)
scripts/sync_core.py injects rules/core-dev.md into both SKILL.md files (--check to verify)
scripts/verify.py (exit 0 PASS, 1 FAIL, 3 UNVERIFIED), regression_diff.py, classify_structure.py, map_reuse.py deterministic helpers
scripts/testenv.py test credentials convention (values only in .env files); `init --project <root>` sets it up
tests/ network_contract.json + test_testenv_contract.py (stdlib unittest: `python plugin/shared/tests/test_testenv_contract.py`)
```
## License
MIT, see `LICENSE`. Third-party:
- `tlc-spec-driven`: based on work by [Felipe Rodrigues](https://github.com/felipfr) of the [Tech Lead's Club](https://github.com/tech-leads-club), CC-BY-4.0, modified here.
- `playwright-cli`: from [microsoft/playwright-cli](https://github.com/microsoft/playwright-cli), Apache-2.0, modified here. Its license is in that folder.