sdlc

Plugin sdlc from marketplace agents-kit in rbinar/agents-kit. Commands read from the repo's manifest — 20 days ago.

Slash commands (6)

• /sdlc:build

  BUILD — implement an approved implementation plan

• /sdlc:plan

  PLAN — turn a PRD or story into an SDD and a file-based implementation plan

• /sdlc:review

  REVIEW — code review, plus security review for high-risk changes

• /sdlc:ship

  SHIP — build verification, changelog, PR, merge and tag

• /sdlc:spec

  DEFINE — refine an idea with the user, then write a PRD

• /sdlc:test

  VERIFY — write and run tests for a change; debug failures

Subagents (33)

• dev-auditor

  Use for codebase quality audits — proactively engage when dead code, unused dependencies, technical debt, complexity hotspots, or duplication detection is needed.

• dev-coordinator

  Use to turn a ready application plan into code — applies file changes in parallel waves, manages conflicts, and hands off to testing/review phases.

• dev-critic

  Use to probe the depth and gaps of an SDD, ADR, or implementation plan — tests assumptions and flags overlooked risk.

• dev-data-engineer

  Use when schema migration, index/constraint strategy, or irreversible DB operations are required — produces forward + rollback scripts and evaluates data loss risk.

• dev-debugger

  Proactively engage when a test/build/runtime error, failing test output, or stack trace arrives — perform root cause analysis and propose a fix.

• dev-doc-writer

  Use to produce and keep human-readable documentation from code — writes architecture overviews, API reference, module maps, and onboarding guides under .docs/. Produces only code-verified content; never invents.

• dev-estimator

  Use when effort estimation is needed for a story, task, or SDD — provides Story Points and person-day equivalents with an uncertainty band using PERT + T-shirt sizing methods.

• dev-facilitator

  Use to classify incoming engineering tasks and route them to the correct dev-* agent — categorizes as bug, feature, refactor, infra, or review.

• dev-failure-hunter

  Use to hunt swallowed errors, empty catch blocks, dangerous fallbacks, missing error propagation, and silent failures — a high-signal, read-only audit layer complementary to dev-reviewer.

• dev-guardian

  Use to evaluate a dev-* agent output and determine the next step — classifies risk with concrete signals and routes to the correct branch of the pipeline.

• dev-incident-responder

  Use to manage active P1/P2 incidents in production — sends status updates to the team, coordinates mitigation steps, and produces post-mortems.

• dev-ops

  Use for server/environment diagnostics, post-deploy validation, or container issues — connects to remote systems via SSH, investigates health and performance problems.

• dev-performance

  Use for performance bottleneck analysis, profiling, memory leaks, bundle size, and runtime optimization — produces measured findings and a prioritized optimization plan, then hands implementation off to dev-coordinator.

• dev-planner

  Use to produce a file-based parallel implementation plan from an SDD or Sprint backlog — delivers task breakdown, file conflict analysis, and wave plan.

• dev-refactorer

  Use to simplify working code without changing behavior, remove dead code/duplication, and reduce complexity — turns dev-auditor's read-only findings into safe, test-gated edits. Never adds features or behavior.

• dev-reviewer

  Use for standard PR reviews — evaluates code quality, surface-level security, and structural issues in a single pass. For PRs involving auth/infra/payments/GDPR scope, also run dev-security after the Reviewer.

• dev-security

  Use for high-risk PRs (auth/authz changes, infra, payment flows, secret management, GDPR/personal data scope) — performs deep threat-model audit after the Reviewer; 🔴 critical findings block shipping without a TechLead override.

• dev-shipper

  Use to ship approved code to main — runs build validation, CHANGELOG update, PR creation, merge, and tagging.

• dev-spec-miner

  Use to extract behavioral specs from an existing (brownfield) codebase — reverse-engineers Requirement and Invariant blocks from source, writes to .specs/dev/specs/. Engage when moving a spec-less legacy project to a spec-driven flow.

• dev-tech-lead

  Use when an SDD (design document) or ADR (decision record) needs to be produced for a new feature or architectural decision — the design layer of the engineering pipeline.

• dev-test-engineer

  Use to generate test scenarios and test code from Story ACs or implementation changes — iterates with a write-run-fix loop.

• meta-evaluator

  Use to score any agent's output (dev/product/marketing/sales) against a 5-axis quality rubric — accuracy, completeness, clarity, actionability, conciseness. Does not re-do the task; produces an evidence-backed scorecard and improvement suggestions.

• product-business-owner

  Use to add business contribution to a PRD or feature request from a revenue, market, regulation, and KPI perspective.

• product-critic

  Use to question the depth, outcome focus, and measurability of a PRD, Feature Spec, Epic, or User Story.

• product-epic-planner

  Use to break down a PRD into manageable Epics — produces scope, acceptance criteria, T-shirt estimates, and a dependency map.

• product-facilitator

  Use to classify incoming PM/product input and route it to the correct product-* agent — the first filter of the product pipeline.

• product-guardian

  Use to evaluate the output of a product-* agent and determine the next step — classifies risk and routes to the correct branch of the pipeline.

• product-lead

  Use to transform a vision or strategic direction into a measurable Product Goal artifact — the strategy layer of the pipeline.

• product-manager

  Use to write a PRD (Problem Definition) or Feature Spec — structures the problem definition, user needs, and product requirements.

• product-retrospective

  Use when a sprint is complete to produce a retrospective report — extracts went-well/went-wrong/learned findings and SMART action items.

• product-sprint-planner

  Use to plan the story list according to sprint capacity and dependencies — produces Sprint Goal, capacity calculation, and risk map.

• product-story-writer

  Use to convert an Epic or Feature Spec into atomic user stories meeting INVEST criteria — generates Acceptance Criteria (Given-When-Then) and Definition of Done.

• product-ux-designer

  Use to add UX flow, persona, user journey, and wireframe notes contributions to a PRD or Feature Spec.