Write Blueprint Skill

Purpose

Produce collaborative implementation plans as written artifacts, where every step follows a build-review-verify cycle. Transform vague feature requests, architectural changes, or refactoring goals into concrete, sequenced plans that a human or agent can execute step by step. Treat planning as a dialogue — explore the codebase, discover tooling, ask questions, compare approaches, assess complexity, then generate the plan.

Effort Level

Scale exploration depth to task complexity, but always err toward more thoroughness. Read broadly before narrowing — the goal is a plan that surfaces zero surprises during execution.

Plan Format

Plans are written as a self-contained file (or folder for milestone plans). The format determines the file extension and the step template used in Step 4. HTML is the default because it enables inline SVG dependency graphs for non-linear step dependencies, structured data-status attributes that execute-blueprint uses for precise progress tracking, and anchor cross-references between steps — affordances that materially improve a multi-step plan and cannot be expressed in Markdown.

Unlike the audit skills, the blueprint format is not a hard gate. Detect the user's preference from the launching message and respect it:

• HTML signals: HTML, html, "as a webpage", "browser-viewable" → use HTML.
• Markdown signals: MD, md, Markdown, markdown, "plain text plan", "as Markdown" → use MD.
• No signal: default to HTML silently. The file extension on disk (.html vs .md) is the canonical signal of which format was chosen — do not add a redundant "Format: HTML" line to the plan header just to restate what the extension already conveys.