القائمة
测试驱动开发（TDD）。遵循红-绿-重构循环（Red-Green-Refactor）。适用于：用户要求 TDD、提到"单元测试"、"功能测试"、"红绿重构"、"确保功能正常"、"确保测试通过"或要求每次提交都附带测试时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在执行任务之前，主动识别无法从代码库或已有知识中获取的信息，逐步向用户追问，直到所有不确定点都明确为止，再开始实施。适用场景：需求模糊、缺少关键上下文、有多种截然不同的实现方向、涉及外部系统或用户私有逻辑、任务目标不清晰。当用户说「你需要问我什么」、「先确认一下」、「别急着写代码」、「不清楚的地方先问」、「有什么需要我提供的」、「不清楚的先问我」以及任何要求先澄清再动手的表达时使用。
Interactively grill the user about their plan or design through relentless, structured questioning until every branch of the decision tree is resolved. Use when user explicitly asks to be grilled, stress-tested, or challenged on a plan. Use when users request "grill me", "挑挑毛病", "过一下方案", "方案行不行", "方案靠谱吗", "你觉得怎么样".
Evaluates a single SKILL.md against Anthropic and agentskills.io best practices, producing a severity-based scorecard with per-dimension scores and actionable rewrite suggestions. Use when the user explicitly asks to review, audit, evaluate, score, or critique a SKILL.md file (for example "check if this SKILL follows best practices", "score this skill doc", "audit ~/.claude/skills/foo/SKILL.md", "is this skill well written?", "帮我评估一下这个 SKILL", "这个 SKILL 写得怎么样", "帮我看看这个 SKILL 有什么问题", "这个 SKILL 能打多少分").
Generate editorial-style diagrams in the Anthropic blog visual style as SVG files. Use this skill whenever the user wants to create a diagram, flowchart, architecture diagram, comparison chart, or any visual that should look like Anthropic's blog article illustrations. Trigger on prompts like "draw a diagram", "create a flowchart", "visualize this process", "make an architecture diagram", "画流程图", "画架构图", "帮我画", or any request to turn text/process descriptions into a visual. This skill produces the calm, editorial, publication-quality look characteristic of Anthropic's technical blog.
Safe disk space analysis and cleanup workflow for local machines. Use when asked to analyze full disks, identify large cache/log/temp/build artifacts, produce a cleanup report, run or simulate dry-runs, wait for user approval, and then clean only confirmed redundant files without affecting software functionality, user data, databases, models, projects, or developer toolchains. Also use for creating reusable disk cleanup SOPs or post-cleanup reports.
把一段需求 / 一段思考 / 一段会议纪要写成单页 HTML 格式的「技术方案 / Design Doc」（工程视角的"怎么做"，含背景、目标、技术方案、风险、影响范围、产研计划等模块；不是产品 PRD 的"做什么"），或者增量更新一份已有技术方案。新建场景：当用户说「写一份技术方案」「写个 design doc」「整理成 HTML 技术文档」「评审用的方案文档」「create tech spec」时使用。更新场景：当用户指向某份已有技术方案 HTML、说「评审完根据反馈调一下」「在风险章节加一条」「方案 A 改成 B」「补充某个章节」时也使用本 skill —— 走「最小化改动 + 保持文档稳定身份」的更新工作流而不是重写。
| name | tdd |
| description | 测试驱动开发（TDD）。遵循红-绿-重构循环（Red-Green-Refactor）。适用于：用户要求 TDD、提到"单元测试"、"功能测试"、"红绿重构"、"确保功能正常"、"确保测试通过"或要求每次提交都附带测试时触发。 |
测试验证行为，不验证实现细节。 代码内部可以完全重写，测试不应随之失效。
好的测试通过公共接口描述系统"做什么"，而非"怎么做"。一个好的测试读起来像规格说明——"用户可以用有效购物车完成结账"——明确表达了系统能力。
详见 tests.md 中的好坏测试对比，以及 mocking.md 中的 mock 使用规范。
不要先写完所有测试，再写所有实现。 这是"横向切片"——把 RED 阶段理解为"写所有测试"，GREEN 阶段理解为"写所有代码"。
这会产生劣质测试：
正确方式：垂直切片（追踪子弹）。一个测试 → 一个实现 → 循环。
错误（横向）：
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
正确（垂直）：
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
...
编写任何代码前：
不可能测试一切。 聚焦在关键路径和复杂逻辑上，不要追求每个边界条件。
每个测试必须：
命名模板：[场景/前置条件]_[操作]_[预期结果]
// 好的命名
test("有效购物车_结账_返回已确认状态")
test("空密码_登录_返回验证错误")
// 差的命名
test("测试结账功能")
test("登录测试")
写一个测试，验证系统端到端的一件事：
RED: 为第一个行为写测试 → 测试失败
GREEN: 写最少的代码让测试通过 → 测试通过
对每个剩余行为：
RED: 写下一个测试 → 失败
GREEN: 最少代码通过 → 通过
规则：
所有测试通过后，查找重构点（详见 refactoring.md）：
绝不在 RED 状态重构。先到 GREEN，再重构。
[ ] 测试描述行为，不描述实现
[ ] 测试只使用公共接口
[ ] 测试能在内部重构后继续通过
[ ] 实现代码是让测试通过的最少代码
[ ] 没有添加投机性功能