Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
中文简介正在准备中。当前显示原文说明。
Detects and redirects scope creep during implementation — unrequested features, drive-by refactors, premature abstraction, and over-engineering. Use while implementing, especially when a change is growing beyond the original request.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
The best code is the code you don't write. Frontier coding models tend to over-build: extra configurability, defensive layers, helpers "for later." Stay on what was asked.
| Signal | Example | Response |
|---|---|---|
| Unrequested features | "While I'm here, let me add caching" | Was caching requested? |
| Premature abstraction | "Let me create a generic helper for this" | Is there a second caller today? |
| Gold plating | "Comprehensive error messages for every case" | Only at system boundaries |
| Drive-by refactor | "This function could be cleaner" | Not in this change |
| Over-engineering | "Let me make this configurable" | Does anyone need to configure it? |
| Defensive sprawl | Validation and fallbacks for states that can't occur | Trust internal invariants; validate at the boundary |
| Documentation creep | "Docstrings on all these functions" | Only on what you changed |
| Test over-expansion | "Test every possible input" | Test boundaries and behaviors, not permutations |
Three similar lines of code are better than a premature abstraction.
Before adding anything not explicitly requested:
When you detect scope creep:
This skill mostly changes behavior rather than producing output. When invoked explicitly:
Original request: [what was asked] Scope additions detected: X
| Addition | Requested? | Needed for correctness? | Action |
|---|---|---|---|
| [extra work] | No | No | Removed; suggested as follow-up |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
中文简介正在准备中。当前显示原文说明。
Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.
中文简介正在准备中。当前显示原文说明。
Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.
中文简介正在准备中。当前显示原文说明。
Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.
中文简介正在准备中。当前显示原文说明。
Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.
中文简介正在准备中。当前显示原文说明。
Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.
中文简介正在准备中。当前显示原文说明。