sdlc

Plugin sdlc from marketplace sdlc-marketplace in douglance/sdlc-plugin. Commands read from the repo's manifest — 1 month ago.

Skills (30)

• 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-with-docs

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

• interrogate

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

• 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.

Subagents (12)

• architect

  Design specialist — produces precise technical design covering interfaces, contracts, file structure, and trade-offs. Use to settle how a non-trivial change will be built. - api-and-interface-design - performance-optimization - find-simplifying-insight

• engineer

  Implementation specialist — builds production code test-first with incremental delivery. Use when code must be written, a feature built, or a bug fixed. - incremental-implementation - test-driven-development - git-workflow-and-versioning

• graphic-designer

  Graphic designer — designs and verifies the user-facing surface: layout, visual hierarchy, composition, states, and accessibility. Use for any UI/visual work, and to confirm a rendered change actually looks right. - frontend-design

• maintainer

  Maintenance specialist — removes dead code, simplifies, and reduces complexity without changing behavior. Use for cleanup and refactors. - Read - Glob - Grep - Edit - Write - Bash - deslop - find-simplifying-insight

• product-owner

  Requirements specialist — interrogates and falsifies requirements relentlessly, turning a vague request into a clear, scoped spec. Use when a request is ambiguous, high-blast-radius, or hard to reverse. - spec-driven-development - interrogate - interrogate-with-docs - find-simplifying-insight

• project-manager

  Planning specialist — breaks validated requirements into a high-level plan of milestones with dependencies, risks, and an explicit out-of-scope set. Use to structure a non-trivial change before building. - planning-and-task-breakdown - find-simplifying-insight

• quality-engineer

  Quality specialist — assures a change through verification & validation, review/inspection, and quality-attribute checks (performance, security, reliability, usability). Use to judge whether a change is good, not just whether tests pass. - security-and-hardening - performance-optimization

• release-engineer

  Deployment specialist — ships built-and-tested code safely with rollout, smoke checks, and rollback. Use when a change is ready to deploy or release. - Read - Glob - Grep - Edit - Write - Bash - git-workflow-and-versioning - security-and-hardening

• researcher

  Feasibility & analysis specialist — scouts a problem space for existing solutions, patterns, constraints, and trade-offs, and reports viable options. Use when mapping unfamiliar tech or evaluating approaches before committing. - find-simplifying-insight

• sre

  Site reliability engineer (SRE) — runs shipped software in production: observability, incident response, runbooks, and continuity. Use to monitor a live service, handle or post-mortem an incident, or close the loop from production back to the backlog. - debugging-and-error-recovery - performance-opt

• technical-writer

  Documentation specialist — documents what shipped: READMEs, API docs, ADRs, and usage. Use when a feature lands, an interface changes, or a decision needs recording. - Read - Glob - Grep - Edit - Write - Bash - documentation-and-adrs

• tester

  Testing specialist — dynamically validates a change by trying to break it: edge cases, scale, malformed input, security, and contradictions. Use to find defects by executing the system before shipping. - test-driven-development - debugging-and-error-recovery

Similar plugins