sdlc-plugin

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Start here to ship built-and-tested code to its target safely — release steps, rollout, smoke checks, and rollback.

Start here to settle how a non-trivial change will be built — interfaces, contracts, file-level structure, and trade-offs.

Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

Start here to document what shipped — READMEs, API docs, ADRs, and usage — once a feature lands or an interface changes.

Start here to scout an unfamiliar problem space — research existing solutions, patterns, anti-patterns, constraints, and technical feasibility before committing to an approach.

Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.

Start here to build code against a clear success criterion — test-first, incremental, one work unit per fork.

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Interrogate the user relentlessly about any plan, design, spec, approach, or decision until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test, critique, pressure-test, or interrogate a plan, design, spec, or approach.

Interrogation session that challenges your plan, design, spec, or approach against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when you want terminology sharpened and project docs updated while you defend a plan against its documented domain model.

Start here to clean up the codebase — remove dead code, simplify, and reduce complexity without changing behavior.

Start here to run software in production after it ships — observability, incident response, and operational continuity. Use to monitor a live service, handle an incident, write a runbook, or close the loop from production back to the backlog.

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.

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Start here to structure a non-trivial change into a high-level, phased plan with dependencies, risks, and an explicit out-of-scope boundary.

Start here to assure a change is good — verification & validation, review/inspection, and the quality attributes (performance, security, reliability, usability) — beyond whether tests pass.

Start here to turn a vague, ambiguous, or high-blast-radius request into a clear, falsified spec through relentless questioning.

The map of the SDLC lifecycle — which phase skill to reach for and what comes next. Use when starting work and unsure where to begin, going from an idea to shipped code, or deciding which phase fits the situation.

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.

Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

Start here to adversarially validate a change — edge cases, failure modes, and security — and try to break it before shipping.

Start here for user-facing UI/visual work — layout, visual hierarchy, composition, states, and accessibility — and to verify a rendered change actually looks right.