douglance/sdlc-plugin - Page 2

maintenance

Use to remove dead code, duplication, indirection, or unnecessary complexity while preserving behavior.

operations

Use when a live service needs observability, incident response, SLOs, runbooks, or continuity work.

planning

Use when a validated nontrivial change needs milestones, dependencies, risks, and an explicit out-of-scope boundary.

quality

Use for independent verification, validation, inspection, and quality judgment beyond whether tests pass.

requirements-gathering

Use when a request is ambiguous, high-blast-radius, difficult to reverse, or missing a material product decision.

testing

Use after implementation to probe edge cases, failure modes, malformed input, scale, security, and contradictions.

visual-design

Use when creating or reviewing a user-facing layout, state, illustration, document, slide, motion treatment, or rendered visual result.

actionable-communication

Use for consequential handoffs, blockers, completion reports, requirements, procedures, interface content, or formal documentation that must be easy to act on.

actionable-communication

Use for consequential handoffs, blockers, completion reports, requirements, procedures, interface content, or formal documentation that must be easy to act on.

api-and-interface-design

Use when designing a public API, schema, module boundary, or frontend-backend contract.

debugging-and-error-recovery

Use when a failure's cause is unknown, evidence conflicts, or an initial fix did not solve the problem.

deployment

Use when tested code must be released with versioning, rollout, smoke checks, and a rollback path.

design

Use when a nontrivial change has unsettled interfaces, contracts, file structure, trade-offs, or verification boundaries.

deslop

Use to remove unnecessary generated patterns from the current diff without changing behavior.

documentation-and-adrs

Use when a consequential decision, public contract, or durable rationale must be recorded for future maintainers.

documentation

Use after behavior ships or an interface changes when documentation must be created, corrected, or verified against the source.

feasibility-analysis

Use when unfamiliar technology or constraints require sourced options and feasibility evidence before choosing an approach.

find-simplifying-insight

Use when proliferating rules, exceptions, adapters, or workarounds suggest the underlying model may be wrong and a falsifiable simpler model is needed.

frontend-design

Use when building or restyling a user-facing web interface where art direction and production-quality visual execution matter.

git-workflow-and-versioning

Use for commits, branching, merge conflicts, versioning, or integration across parallel workstreams.

implementation

Use when requirements are clear and code must be added, changed, or fixed against an observable success criterion.

incremental-implementation

Use when implementation should be split into multiple independently verifiable slices or commits.

interrogate

Use when the user explicitly wants a plan, design, specification, approach, or decision stress-tested through disciplined questions.

interrogate-with-docs

Use when the user wants a proposal stress-tested against the domain model while terminology and project decision records are updated.

lifecycle-documentation

Use to create or review a formal, traceable lifecycle artifact or phase handoff that another person or system must consume.

maintenance

Use to remove dead code, duplication, indirection, or unnecessary complexity while preserving behavior.

operations

Use when a live service needs observability, incident response, SLOs, runbooks, or continuity work.

performance-optimization

Use when a measured regression, explicit performance target, or profiler evidence identifies work to optimize.

planning-and-task-breakdown

Use when an accepted specification or plan must become ordered tasks, vertical slices, atomic commits, or parallel work boundaries.

planning

Use when a validated nontrivial change needs milestones, dependencies, risks, and an explicit out-of-scope boundary.

quality

Use for independent verification, validation, inspection, and quality judgment beyond whether tests pass.

requirements-gathering

Use when a request is ambiguous, high-blast-radius, difficult to reverse, or missing a material product decision.

sdlc-flow

Use when a request spans multiple lifecycle phases or the correct next phase is unclear.

security-and-hardening

Use for authentication, authorization, secrets, untrusted input, sensitive storage, or an explicit security review.

spec-driven-development

Use when a significant change needs a durable specification before implementation can begin safely.

test-driven-development

Use when a behavior change or defect is best defined and protected by a failing test before implementation.

testing

Use after implementation to probe edge cases, failure modes, malformed input, scale, security, and contradictions.

visual-design

Use when creating or reviewing a user-facing layout, state, illustration, document, slide, motion treatment, or rendered visual result.