菜单
Use when implementing any feature or bugfix, before writing implementation code
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The skill for "is this AI-written?" or "make this sound more human." Use whenever a specific text sample is in question and the core concern is AI authenticity — student submissions suspected of AI authorship, blog/wiki drafts that feel off, PR commit messages that smell like boilerplate, cover letters that sound robotic, paragraphs an editor flagged. Detects copula avoidance, ChatGPT vocabulary, significance inflation, and 30+ other documented AI tells. Also rewrites flagged sections. Not for grammar checks, summarization, or style edits where AI detection is not the concern.
Chain extract-research-questions into objective-codebase-research. Convenience wrapper for the Q+R phases of QRSPI.
Draft a structured design discussion from research findings. Interactive — presents understanding for corrections before finalizing.
Create a structure outline with vertical slices from a design discussion document. Enforces vertical decomposition over horizontal layers.
Extract 5-10 codebase research questions from a ticket or description. Questions only — no answers or opinions.
Conduct problem-aware, solution-blind codebase research. Outputs factual findings only — no opinions or suggestions.
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Always: New features, bug fixes, refactoring, behavior changes.
Exceptions (require human permission): Throwaway prototypes, generated code, configuration-only changes.
No production code without a failing test first.
Wrote code before the test? Delete it. Start over. No "reference", no "adapting".
Write one minimal test showing what should happen:
Run the test. Confirm:
Write the simplest code that makes the test pass.
Run the test. Confirm:
Test fails? Fix code, not test. Other tests fail? Fix now.
Only after green:
Keep tests green throughout. Don't add behavior.
Next failing test for next behavior.
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = skip" | Hard to test = hard to use. Listen to the test. |
| "Already manually tested" | Ad-hoc != systematic. No record, can't re-run. |
| Problem | Solution |
|---|---|
| Don't know how to test | Write the assertion first. Design the API you wish existed. |
| Test too complicated | Design too complicated. Simplify the interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
| Test setup huge | Extract helpers. Still complex? Simplify design. |
When introducing mocks or test helpers, watch for: testing mock behavior instead of real behavior, adding test-only methods to production classes, mocking without understanding the dependency.
Before marking work complete:
