sdd-engineering

Plugin sdd-engineering from marketplace dev-digest-ai-marketplace in yamchinsky/dev-digest-ai-marketplace. Commands read from the repo's manifest — 1 month ago.

Skills (3)

• engineering-insights

  Use during any coding session whenever you uncover a non-obvious finding worth preserving — a failure mode that surprised you, a tool/library quirk, an architectural decision made for a non-obvious reason, a recurring error and its fix, or an open question you could not resolve. Appends a single dat

• run-plan

  Use to EXECUTE an Implementation Plan (`docs/plans/<feature>.md`) end-to-end in the main session: feature branch → implementer waves per the task DAG (or sequential steps in single-agent mode) → plan-verifier coverage gate (run inside a subagent) → capped gap-fix loop → architecture review gate with

• workflow-retro

  Use to run a MANUAL retrospective of a multi-agent run (the SDD pipeline or any session with subagents): computes token metrics (input / output / cache-read / cache-creation, cache-hit rate), tool-call counts, durations, and parallelism — INCLUDING nested subagents, whose usage the parent does not c

Subagents (4)

• implementation-planner

  Use proactively at the start of any non-trivial feature or change, before implementation — or when asked to plan, scope, decompose, or design an approach. Takes EXISTING requirements as input (from the request or a spec document), verifies them against the codebase, and recommends improvements. If r

• implementer

  Use proactively to execute ONE task of an Implementation Plan (docs/plans/<feature>.md) — backend or UI — and as several parallel instances, one per disjoint task. Works in the same branch/working tree it was launched in; owns only its task's paths. Returns a report: files changed, skills applied, a

• plan-verifier

  Use to verify that an implemented change satisfies every requirement and acceptance criterion of an Implementation Plan in `docs/plans/<feature>.md`. Maps every R-ID and measurable acceptance criterion to concrete evidence (file:line, test name, migration) and returns a coverage matrix with an ALL C

• spec-creator

  Use to write a Spec-Driven Development (SDD) feature specification BEFORE any planning or implementation — problem, goals/non-goals, user stories, EARS acceptance criteria, edge cases, input provenance. Grounds facts in the repository (docs, code search, and optional convention tools when the host p

Similar plugins