Software engineering discipline grounded in named primary standards (OWASP, ITIL, IETF RFCs, ISO, BABOK, SBAR, and more), shipped as a Claude Code plugin and an MCP server.
API design discipline grounded in the Microsoft/Google REST guidelines, resource and URL conventions, a chosen versioning strategy, what counts as a backward-compatible vs breaking change, and consumer-driven contract testing. Use when designing a new API endpoint, changing an existing API's request/response shape…
Produce a software architecture diagram at the right level of zoom, using diagram as code so it can be shown inline, saved, or committed as the user or active workflow authorizes. Use when the user wants to draw, extract, or visualize a project's architecture, a component or request flow, a data flow, or a decision…
Code review discipline: the approval bar is "improves code health," not "perfect," Fowler's code-smell catalog gives design/complexity concerns a name instead of a vague feeling, and small PRs keep review depth from degrading. Use when reviewing a pull request or diff, requesting a review, deciding whether a change is…
Discipline for code style and static analysis, adopt the ecosystem's established formatter as the non-negotiable source of truth, enforce it at pre-commit and CI rather than in review, and treat linting (real defects) as a separate concern from formatting (appearance). Use when setting up a new project's tooling, when…
Module design discipline from John Ousterhout's A Philosophy of Software Design, depth as the metric (a lot of functionality behind a simple interface), information hiding vs. leakage, the concrete red flags that mark a shallow module, and comparing at least two designs before committing. Use when designing a new…
Discipline for keeping dependencies current and deprecating capabilities safely, an inventory (SBOM) of what's actually shipped, security patches on a fast lane separate from routine/major upgrades, and a stated deprecation window (Sunset/Deprecation headers, N-2 support) before removing anything consumers rely on.…
Systematic debugging discipline based on David Agans' nine rules, understand the system, reproduce reliably, bisect the search space, change one variable at a time, keep an audit trail, and never declare a fix done until it's verified against the original failure. Use when the user reports something broken, throwing…
Domain-Driven Design discipline, build a ubiquitous language shared by code and conversation, draw explicit bounded contexts where a term's meaning holds, and record significant decisions as one-page Architecture Decision Records. Use when project vocabulary is inconsistent or ambiguous, when the same word means…
Default to explaining technical work in plain language for a non-technical audience, using an existing project glossary only when a persistent document is already in scope. Use whenever an explanation is aimed at someone outside the technical team, or whenever jargon would otherwise go unexplained. Distinct from…
Interview the user relentlessly, in rounds, to close the gap between what's known and what's needed before acting on a plan, decision, or idea. Use when the user wants to stress-test their thinking, a plan has unstated assumptions, or a decision keeps getting acted on before it's actually been made.
Hand off in-progress work, an on-call shift, or an open incident to another person or agent using a fixed four-part structure, so nothing load-bearing is lost between one owner and the next. Use when work needs to change hands mid-flight, an on-call rotation is ending, or a session needs to brief whoever picks this up…
Scan a codebase (or a named area of one) for architectural friction, classify each finding by how it was incurred, and propose deepening opportunities in priority order. Use when the user wants an architecture review, asks where the design is causing pain, wants technical debt surfaced and prioritized, or asks what to…
Discipline for the full incident lifecycle, declaring and sizing an incident by severity, separating the incident-commander/comms/ops roles, mitigating before root-causing, and writing a blameless postmortem that investigates the system rather than a person. Use when a production incident is happening or just…
Discipline for making a service's health answerable without reading its code, structured logging, the four golden signals (latency, errors, traffic, saturation), and an SLI/SLO/error-budget definition with alerts that link a runbook. Use when adding logging to a service, instrumenting metrics or tracing, defining what…
Check an existing draft specification or README against a fixed set of quality characteristics, batch only the genuinely blocking gaps into one round of questions, and write each resolved decision into the source document plus the repository's existing decision-recording artifact when one exists. Use when a draft spec…
Build a throwaway spike solution to answer one design or technical question before committing to an approach. Use when the user wants to sanity-check whether a state model, logic, or UI direction feels right, is unsure an approach will work, or wants to explore options before writing production code.
Discipline for release classification, version bumps, and changelogs, Conventional Commits classify the release range, SemVer computes the version from those commits, Keep a Changelog renders the result. Use when the user asks to cut a release, bump a version, write a changelog, decide if a change is a…
Audit and enable a GitHub repository's own recommended security settings, confirming with the maintainer which ones actually apply before turning anything on. Use when the user wants a repo hardened, asks to enable secret scanning or branch protection, wants a SECURITY.md written, or references GitHub's maintainer…
Split existing repository work into commits by intent as it happens, or give a new repository its name, visibility, description, and topics at creation. Use the matching path when work is about to be committed or pushed, before a push that would otherwise land as one large commit, or when a new repository is being…
Investigate a technical question against primary sources and capture the findings, with citations, as a file in the repo. Use when the user wants a topic researched, docs or API facts gathered, a claim verified before it's relied on, or reading legwork delegated to a background agent.
Discipline for resolving an in-progress git merge or rebase conflict, a conflict marker names two divergent intents from a shared ancestor, resolved by tracing each side back to what it was trying to accomplish, never by blindly picking one side's raw text. Use when a merge or rebase has stopped with conflict markers…
Discipline for shipping changes reversibly, decouple deploy (code reaches production) from release (users see it) with feature flags, roll out progressively, and define the automated rollback trigger before shipping, not during the incident. Use when the user asks how to deploy a risky change, choose between…
Secure-coding discipline mapped to the OWASP Top 10, checked at the point of writing code, not after. Covers input validation and injection classes, broken access control, secrets handling, dependency/supply-chain risk, and safe error handling/logging. Use when writing code that crosses a trust boundary (handles user…
Turns an already-discussed plan into a written spec and a set of tracer-bullet tickets, synthesizing rather than re-interviewing, slicing work end-to-end rather than by layer, and gating entry/exit with a written Definition of Ready and Definition of Done rather than by feel. Use when the user asks to turn a…