菜单
Package a completed change - its plan, implementation notes, and verification evidence - into a shareable buy-in doc published as an Artifact. Use once implementation is done and the change needs buy-in or visibility beyond the author, not for trivial one-line fixes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Execute the tasks of a plan at .dev/{plan-name}/, test-first across unit/integration/e2e, running independent tasks in parallel and looping until every task is done and the e2e suite passes. Use when the user asks to implement a plan or its tasks, work through task files, or wants red-green TDD with an e2e report.
Turn a feature request, spec, or problem statement into a reviewable plan at .dev/{plan-name}/plan.md. Use when the user wants work planned before implementation.
Run the pre-implementation moves that reduce unknowns before planning starts - a blind spot pass over unfamiliar territory, a brainstorm/prototype pass for an undecided shape, and a one-question-at-a-time interview for ambiguities that would change architecture. Use before to-plan when the request touches unfamiliar code, an undecided UX/architecture direction, or open ambiguities; skip straight to to-plan when the work is already well understood.
Concern-based fan-out review of a branch or PR where every finding is adversarially verified before it is reported, producing .dev/{plan-name}/review_N.md. Use when the user asks for a code review of their changes or before opening a PR.
Split a plan at .dev/{plan-name}/plan.md into numbered task files (task_1.md, task_2.md, ...) sized for individual implementation. Use after to-plan when execution spans multiple tasks, or to break an existing plan into tasks.
Render a context/intuition/what-was-done doc with a graded comprehension quiz on finished work, published as an Artifact for a reviewer or author to read before merging. Use when the user wants a comprehension check on a change before it merges.
| name | to-pitch |
| description | Package a completed change - its plan, implementation notes, and verification evidence - into a shareable buy-in doc published as an Artifact. Use once implementation is done and the change needs buy-in or visibility beyond the author, not for trivial one-line fixes. |
| disable-model-invocation | true |
Turn finished work into a doc that gets someone else to say yes: demo first, then the reasoning, then the evidence. This is purely presentational - it never gates anything and never implies otherwise.
A one-line fix or an internal refactor with no visible behavior change doesn't warrant buy-in. Say so and skip rather than manufacture ceremony.
.dev/{plan-name}/ slug, the same convention to-tasks uses.
Ask which plan only if more than one is a plausible match; otherwise proceed without waiting for clarification..dev/{plan-name}/plan.md and any task_N.md - Goal, Success criteria, before/after.~/tmp/{project-slug}/reports/{topic-slug}-discovery-notes.md (from discover), if this plan started there - the chosen direction and any mockups..dev/{plan-name}/implementation-notes.md (from implement) - what was done, and any Deviations.~/tmp/{project-slug}/reports/{plan-name}-e2e-report.html's data block - the scenario summary, as verification evidence.run skill (invoked directly via the Skill tool, the same exception implement uses for its e2e pass), then record a short clip of the change working with claude-in-chrome's gif_creator. For non-UI changes, skip the GIF and lead with the clearest before/after example instead.PITCH_DATA per references/data-schema.md, rendered into templates/pitch.html in this section order: Demo, Why, What changed, How we verified it, Deviations (omit the section entirely when none were logged), Try it yourself.
Before first authoring or restyling the template, load the artifact-design skill; a plain data refresh on an existing template doesn't need it again.~/tmp/{project-slug}/reports/{plan-name}-pitch.html, replacing only the data block between the markers - the rendering engine below them is generic, don't touch it.
Publish it with the Artifact tool using that file_path: a stable rocket favicon across every pitch this skill produces, a title and one-sentence description from the plan.
Resuming a plan in a later session and updating the same artifact needs the url parameter instead - find it with Artifact({action: "list"}) if you don't already have it.
Tell the user both the local path and the published URL, and that the URL is private by default until they choose to share it.implementation-notes.md logged any - what edge case forced the conservative call, and why it still holds.