Drives development with tests. Write a failing test before writing code that makes it pass; for bugs, reproduce with a test before attempting a fix (the Prove-It Pattern). Use when implementing any new logic or behavior, fixing any bug, modifying existing functionality, adding edge case handling, or making any change that could break existing behavior. Do NOT use for pure configuration changes, documentation updates, or static content changes with no behavioral impact. Covers the RED/GREEN/REFACTOR cycle, the test pyramid and test-size model, writing-good-tests patterns (state over interactions, DAMP over DRY, real over mocks, Arrange-Act-Assert), and common anti-patterns. For browser runtime verification, combine with the `browser-testing-with-devtools` skill.
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.
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).
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.
Harden web application code against vulnerabilities during development. Use while writing any feature that accepts untrusted data, handles authentication or sessions, stores or transmits sensitive information, integrates with third-party APIs, accepts file uploads, or exposes webhooks and callbacks. Covers OWASP Top 10 prevention patterns, input validation at system boundaries, parameterized queries, output encoding, secrets management, rate limiting, session hardening, and the three-tier "always / ask first / never" boundary system. Do not use for post-implementation security audits, threat modeling of finished systems, or vulnerability reports — use the `barb` / `security-auditor` agent for that. This skill is for building secure code; Barb is for auditing built code.