メニュー
Use when implementing a feature, refactor, direct hotfix, or scoped behavior change before writing production code. For bug reports that need root-cause investigation, use dev-fix instead; dev-fix already owns failing regression tests.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
UI image to code methodology. Use when the user provides a UI screenshot, design mock, app screen, dashboard image, mobile screen, web page image, or says "UI图生成代码", "看图写页面", "根据设计图实现", "screenshot to code", "image to code", or asks Codex to implement a frontend from an image. Requires a UI image plus a design size when available, forces clarification for every uncertainty, then reconstructs the UI in the target project or a runnable standalone app with browser screenshot verification and visual diff evidence.
Use when reviewing uncommitted or staged git changes before commit. Trigger on: 帮我 commit, 我要 commit, commit 一下, 准备提交, pre-commit, 提交前检查, 看下这次修改, commit 前看一下, I want to commit, let's commit, review my changes. Checks conventions, functional correctness, security/reliability/performance hotspots, wiring, comments, and dead code; emits a commit message only when READY. Does not mutate the working tree. Route to dev-commit-writer only when the user explicitly asks to skip review or wants only a commit message.
Primary intake for fuzzy feature/product requirements before coding; prefer this over dev-spec for requirement alignment. Use when the user says or implies: 需求还不清楚, 先别写代码, 先帮我梳理/收敛/对齐/拆一下需求, 先问我问题, 明确范围/边界/验收标准, 写 PRD/spec/设计文档, 帮我设计, 写个方案, 这个需求怎么做, design this, scope this out. Also trigger on dev-grill-docs, grill-with-docs, 拷问需求, 拷问方案, 压测方案, 术语沉淀. Reads existing docs/code first, asks one focused question at a time, produces .claude/artifacts/designs/<feature>.md, and may update CONTEXT.md or docs/adr/ for durable terms/decisions. Does not implement code, fix bugs, or write implementation plans.
Use only after a spec or clearly scoped requirement exists and the user wants a concrete implementation plan before coding. Trigger on explicit implementation-planning requests such as 基于这个 spec 出 plan, 需求已经清楚了给实施方案, 技术实施方案, 出个 plan, 做个实施方案, plan this, make a plan, consensus plan, ralplan. If the user says 写个方案, 给我个方案, 怎么做这件事, 帮我设计, or the requirement is still fuzzy, route to dev-grill-docs first. Produces a RALPLAN-DR plan with principles, decision drivers, viable options, ADR, and Planner-Architect-Critic validation. Does not gather requirements, fix bugs, review code, or write code.
Compatibility alias for dev-grill-docs spec-only mode. Assists dev-grill-docs by running its spec-only path. Use only when the user explicitly says dev-spec, asks to preserve an old dev-spec workflow, or explicitly wants spec-only output without CONTEXT.md / ADR updates. For natural requirement-alignment requests such as 先帮我梳理需求, 帮我设计, 写个方案, spec 一下, 设计文档, design this, or scope this out, prefer dev-grill-docs. Do not maintain a separate workflow here: load dev-grill-docs and follow it with --spec-only.
Use ONLY when the user explicitly wants end-to-end guided workflow through the dev-skills toolchain. Triggers on phrases like "用 dev-auto / 帮我串起来 / 从需求到 commit / 完整跑 / end to end / 走完整流程 / 下一步该做什么 / what's next". Reads `.claude/artifacts/{designs,plans,fixes}/` and `.design-context.md` existence to detect current phase (no deep parsing) and recommends next step across dev-design-context, dev-grill-docs, dev-plan, dev-tdd, dev-fix, dev-verify, dev-code-review, dev-commit-writer, and dev-finish. Does NOT invoke other skills, write code, or produce artifacts. Optional arguments — `[slug]`; `--status [slug]`; `--next [slug]`; `--recover [slug]`.
| name | dev-tdd |
| description | Use when implementing a feature, refactor, direct hotfix, or scoped behavior change before writing production code. For bug reports that need root-cause investigation, use dev-fix instead; dev-fix already owns failing regression tests. |
Implementation workflow for behavior-changing code. The goal is to prevent "tests after" from becoming optimistic coverage that never proved it could catch the bug.
This skill only governs the coding loop. It does not gather requirements (dev-grill-docs; dev-spec is a compatibility alias), design implementation strategy (dev-plan), investigate root cause (dev-fix), or review the final diff (dev-code-review).
执行前先加载 references/dev-baseline.md。不假设、最小代码、外科手术式改动、可验证成功标准 全程生效。
baseline 与本 skill 的关联:
默认适用:
不要用于需要 root cause investigation 的 bug 报告。那条路径走 dev-fix,因为 dev-fix 已经内置 failing regression test、root-cause fix 和 red→green→red 验证。
可跳过,但必须在输出里说明原因:
如果用户要求跳过 TDD,只在他们明确接受风险时跳过,并把后续验证升级为 dev-verify 的完整检查。
把当前任务切成最小行为单元。每轮只选一个:
Behavior: <一句话说明>
Expected: <可断言的结果>
Test target: <测试文件 / 测试命令>
Production target: <实现文件>
如果写不出 Expected,说明需求还没清楚,回 dev-grill-docs 或向用户澄清。
如果存在匹配的 .claude/artifacts/designs/<slug>.md 或 .claude/artifacts/plans/<slug>.md,本轮 behavior 应从其中一个来源选择:
输出时标明 Source: spec/<slug> AC-<n> 或 Source: plan/<slug> step <n>。如果没有 artifact,用用户当前请求作为 source,但不要把未确认的范围扩成额外行为。
先写测试,不要写生产代码。
测试要求:
运行最窄命令:
<test command for the specific test>
必须确认:
只写让当前 RED 测试通过的最小生产代码。
禁止:
运行:
<same narrow test command>
必须确认当前测试通过。若失败,修实现,不是先改测试。
仅在测试已通过后整理:
每次整理后重新运行同一测试。不要在 refactor 阶段加入新行为。
当前行为通过后,根据风险扩大验证:
| 改动范围 | 追加验证 |
|---|---|
| 单函数 / 单模块 | 相关测试文件 |
| 多文件协作 | 相关测试目录 / package test |
| 公开 API / 数据迁移 / 鉴权 / 支付 | 单测 + 集成测试 + 项目标准 lint/build |
| regression / hotfix | red → green → 临时反转实现确认 test 会再 fail → 恢复 green |
输出时列明运行过的命令和结果。不能只说“应该通过”。
全部行为实现后:
dev-verify 做完成前证据门禁。dev-code-review 做提交前评审。dev-finish。dev-verify 补齐。Recommended agent_type: worker
Use when:
Do:
../../docs/multi-agent-policy.md.Do not:
Output: