dhslegen
UserClaude Code plugin: superpowers discipline + toB delivery governance — 5-station spine (need→contract→implement→verify→deliver), Iron Law file-fact enforcement, SSoT accountability, ROI reporting. Zero deps.
Categories
Indexed Skills (18)
ddt-brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
ddt-design-checkpoint
Use after ddt-brainstorming and before ddt-writing-plans — the design landing gate. Each "yes" in the seven-item checklist binds to a real artifact (a file under docs/api,data,design or a decisions.jsonl deferral entry) that MUST exist before ddt-writing-plans starts. Writing a Q&A table at the end of a spec is NOT passing this gate; the artifacts have to be on disk.
ddt-design-source
Use BEFORE frontend implementation in any slice — the project's user-facing visual truth gate. Converge the aesthetics in an external AI design tool (v0/figma/claude-design) or LLM self-batch instead of picking a component library and coding per-slice. Design the frontend coherently as a batch (not per-slice, which fragments the look), produce a bundle under `docs/design/frontend/`, and have all slices implement against it. Batch granularity (whole frontend / per UI-domain / design-system-first) is a judgment call.
ddt-dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
ddt-executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
ddt-finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
ddt-receiving-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
ddt-requesting-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
ddt-subagent-driven
Use when executing implementation plans with independent tasks in the current session
ddt-systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
ddt-tdd
Use when implementing any feature or bugfix, before writing implementation code
ddt-using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
ddt-verification
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
ddt-writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
ddt-writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
using-ddt
Use at the start of every DDT session — establishes how to find and use the ddt-* skill family, requiring Skill tool invocation before ANY response including clarifying questions.
ddt-deliver
Use when work needs formal sign-off — toB acceptance, production deploy, data migration, customer handoff, multi-slice convergence, or contract (`docs/api,data,design`) changes that downstream consumers depend on. Produces verification records and delivery artifacts (deployment guide, demo script, customer handoff materials). Skip for small fixes / doc edits / test top-ups — those finish without needing this gate. The trigger is "the work needs handoff to someone or something downstream," not "I want to feel done."
ddt-large-requirement
You MUST use this BEFORE ddt-brainstorming whenever the input looks like a large requirement — multi-module scope, vague boundary, multi-collaborator handoff, or batch handoff materials (full feature lists / PRDs / meeting minutes / API doc dumps / customer specs). Decomposes the large requirement into `docs/requirements/` (scope acceptance) + bite-size `docs/briefs/` (slice list) + `docs/design/` global-layer design artifacts (architecture, cross-slice business flows, cross-slice sequence diagrams, hard-problem algorithms, selection ADRs — whatever can't be read off the code) + global decisions in `.ddt/decisions.jsonl`, so each brief can then run the standard ddt-brainstorming → ddt-design-checkpoint → ddt-writing-plans subchain independently. Skipping this skill for a large requirement leads to a giant spec covering everything, which the rest of the toolchain cannot consume.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.