claude-dev-team

Implement the next task incrementally — build, test, verify, commit

Setup or cleanup for claude-dev-team. Default creates user-level symlinks so the personified agents (Hubert / Watson / Barb / Pepper / Negev) and their commands are accessible by short name in addition to the plugin-namespaced form. Use `--remove` to undo: removes those symlinks and prints `/plugin uninstall` guidance for full removal. Idempotent.

Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern.

Acceptance exploration specialist — verify a finished feature works end-to-end in a running system before it ships. Drives the system from a consumer's perspective (user clicking, operator running, service calling, main agent invoking) and returns a stage-appropriate pass/fail verdict with evidence. Works across browser, CLI, HTTP API, and agent/skill surfaces. Use when a feature is implemented and you need to verify it actually works — not just that tests pass. Does NOT write tests, review code, audit security, or apply fixes.

Senior code reviewer — evaluates proposed changes across correctness, readability, architecture, security, and performance before merge. Use when a change is ready for review and you need categorized findings (Critical / Important / Suggestion / Nit) and an APPROVE or REQUEST CHANGES verdict. Works on PRs, feature branches, agent-produced code, refactors, and bug fixes. Does NOT write tests, verify running features end-to-end, audit security deeply, or commit changes.

Git workflow specialist — stages, commits, branches, and curates history following the `git-workflow-and-versioning` skill. Use when the caller has changes to commit, wants a branch created, needs a messy working tree split into clean commits, or wants a pre-commit audit. Does NOT push, force-push, rebase published history, or run destructive ops (reset --hard, clean -f, branch -D) unless the caller explicitly authorizes it in the prompt.

Security auditor — review built code for exploitable vulnerabilities and return a severity-classified audit report. Use after implementation when you need a vulnerability assessment, threat review, or hardening recommendations on code that already exists. Covers OWASP Top 10, injection, auth/authz, data exposure, infrastructure hardening, and third-party integration risks. Produces a report with Critical/High/Medium/Low findings, proof-of-concept where applicable, and specific remediation guidance. Does NOT write tests, review code quality, verify feature behavior, apply fixes, or commit. For hardening *during* development, use the `security-and-hardening` skill directly.

QA engineer specialized in test strategy, test writing, and coverage analysis. Use for designing test suites, writing tests for existing code, writing reproduction tests for bugs (Prove-It Pattern), or evaluating test quality. Does NOT implement fixes, review code, or commit — hands back once the tests are in place.

Verify a finished feature works end-to-end before declaring done. Use after implementation and unit tests pass, when you need a pass/fail verdict on whether the feature actually works from a user's or caller's perspective — not just that tests are green. Works across browser apps, CLI tools, HTTP APIs, and agent/skill bundles at stage-appropriate depth (prototype / MVP / beta / GA). Produces a verdict with evidence (screenshots, transcripts, request logs). Do not use for writing tests (use test-driven-development), code review (use code-review-and-quality), or security audits (use security-and-hardening).

Verifies browser-rendered changes against live runtime via Chrome DevTools MCP. Use when building or debugging anything that renders in a browser, inspecting the DOM, capturing console errors, analyzing network requests, profiling Core Web Vitals, or verifying visual output with real runtime data. Do NOT use for backend-only changes, CLI tools, non-UI code, or when Pepper + test-driven-development already covers the scenario with automated tests.

Multi-axis code review before merge across correctness, readability, architecture, security, and performance. Use before merging any PR, after completing a feature, when evaluating code produced by another agent or model, during refactors, or after a bug fix (review both the fix and the regression test). Produces categorized findings (Critical / Important / Suggestion / Nit) and an APPROVE or REQUEST CHANGES verdict. Do not use for deep security audits (use security-and-hardening + Barb), for verifying a running feature end-to-end (use acceptance-exploration + Negev), for writing tests (use test-driven-development), or for committing curated changes (use git-workflow-and-versioning + Hubert).

Structure git workflow practices — atomic commits, trunk-based branching, descriptive messages, and change summaries. Use when making any code change that gets committed, when splitting a messy working tree, when naming a branch, when writing a commit message, or when cleaning up history. Invoked most often by the `hubert` agent, which layers persona-specific execution (secrets scanning, 70-char subject cap, result-line contract). Do not use for force-pushing, rebasing published history, or PR creation — those are out of scope.

Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.