claude-bholzer

Drive a task DAG to completion by dispatching a coder subagent then a validator subagent for each eligible task, in serial. Use this skill whenever the user asks to "run the tasks", "execute the DAG", "drain the task queue", "start the autonomous coding session", "work through the plan", or similar phrasings that mean "actually do the work the task files describe." Trigger on phrases like "run the tasks in plans/<slug>/", "execute the DAG at …", "kick off the autopilot for …", "start coding the tasks", "drain plans/<slug>/tasks/". This is the step *after* `task-specs` — it assumes the task files are already fleshed out with full bodies (acceptance criteria, files to touch, etc.) and walks the DAG until completion or until something needs human attention.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Generate a Product Requirements Document (PRD) as a markdown file. Use this skill whenever the user asks for a PRD, product spec, product requirements doc, feature brief, or wants to "write up" / "draft" / "spec out" a feature or product. Trigger even when the user doesn't say the literal word "PRD" — phrases like "draft a spec for X", "write requirements for the new onboarding flow", or "I need a doc that explains what we're building and why" all qualify.

Decompose a technical design document into a DAG (directed acyclic graph) of work tasks. Use this skill whenever the user asks to "break down" / "decompose" / "split up" a design into tasks, create a task DAG, sequence the work, or build a task list with dependencies. Trigger on phrases like "decompose the design at … into tasks", "break this design into a task DAG", "create the task list with dependencies", "what's the work breakdown for this design", "sequence the tasks for …", "decompose into a DAG", "build the work plan for the design". This is the step *after* a technical design — it produces a human-reviewable DAG (index.md with Mermaid + table) plus skeleton task files (one per task, with frontmatter), which the `task-specs` skill later fleshes out into full per-task specs.

Flesh out the skeleton task files from a task DAG into full self-contained task specifications that stateless coding agents can execute. Use this skill whenever the user asks to "spec out the tasks", "flesh out the task specs", "write the task specs for the DAG", "make the tasks executable", "expand the task skeletons", or "finalize the tasks for the coding agents". Trigger on phrases like "spec out the tasks in plans/<slug>/", "write specs for the DAG at …", "fill in the tasks", "make the tasks ready for execution", "task-spec the DAG". This is the step *after* `task-dag` — it reads each skeleton task file and replaces the 1-line body with a complete spec (files to touch, interface contracts, acceptance criteria, test plan, patterns to reuse), so a coding agent picking up a single task file has everything it needs without reading siblings.

Generate a technical design document as a markdown file, given a PRD (or PRD-shaped description). Use this skill whenever the user asks for a tech design, technical design doc, architecture doc, implementation design, engineering design, RFC, or wants to "design the implementation of" / "figure out how we'd build" / "spec out the architecture for" a feature. Trigger on phrases like "write a tech design for the PRD at …", "design the implementation of X", "how would we architect this", "turn this PRD into a design". This is the step *after* a PRD — it converts product intent into engineering specifics (components with real file paths, data model, API contracts, existing patterns to reuse). It is *not* the right fit for product/requirements docs (use `prd-generator`) or for breaking work into tasks (use `task-dag`).