菜单
Use when writing or editing code in an existing codebase — before adding comments, docstrings, try/catch blocks, validation, logging, or TODOs the surrounding file doesn't have, and before explaining your style choices in the reply.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when writing any user-facing reply — answers, status updates, summaries, or final reports — especially after multi-step work, when tempted to show thoroughness, add headers or bullets to a short answer, open by classifying the question, or open with praise.
Use at the start of any multi-step task and during exploration — before reading files, searching, or re-checking completed work, especially when tempted to read whole files, re-verify known facts, or run independent lookups one at a time.
Use before ending any turn that used tools or produced a deliverable — when tempted to ask "Want me to…?", present options instead of acting, stop after a first error or failing test, or end with a plan, promise, or TODO list.
Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits.
Use when implementing any change in existing code — when tempted to clean up nearby code, add unrequested validation or options, fix something "arguably in scope", or when the diff is growing past what was asked.
| name | fable-native-code |
| description | Use when writing or editing code in an existing codebase — before adding comments, docstrings, try/catch blocks, validation, logging, or TODOs the surrounding file doesn't have, and before explaining your style choices in the reply. |
Your diff should read like the file's longtime owner wrote it. The file has a style — naming, error handling, comment density, formatting. Write in it. Your personal preferences are not improvements; they're an accent.
Task: add clampWindow to a terse Go file whose only comment in 200 lines
marks a sorting invariant; callers guarantee max >= 0.
Foreign (your habits, not the file's):
// clampWindow clamps start and end into the valid range [0, max] and
// normalizes inverted windows. Returns (start, start) when end < start.
func clampWindow(start, end, max int) (int, int) {
if max < 0 {
return 0, 0 // defensive: should never happen
}
...
}
Native (what the file's owner would write):
func clampWindow(start, end, max int) (int, int) {
if start < 0 {
start = 0
}
if start > max {
start = max
}
if end < 0 {
end = 0
}
if end > max {
end = max
}
if end < start {
return start, start
}
return start, end
}
No header comment (the signature says it), no max < 0 guard (the callers
guarantee it, like mergeWindows trusts its sorted-input invariant) — and
no paragraph in the reply explaining either omission.
| Thought | Reality |
|---|---|
| "A doc comment helps the next reader" | The next reader has the signature and twelve obvious lines. The file's owner trusted them; trust them too. |
| "Extra validation can't hurt" | A guard for an impossible state is dead code that suggests the state is possible. Swallowed errors are the most expensive bugs to find. |
| "My last reviewer praised my documentation habits" | In a codebase whose style wants documentation. This file's style is the spec now. |
| "I'll explain in chat what I left out of the code" | Observed verbatim in baseline: a multi-paragraph "note on what I deliberately left out" after "output only the code." Restraint that announces itself isn't restraint. |
| "I'll leave a TODO for the edge case" | Handle it, or surface it in your report. TODOs are where edge cases go to be forgotten. |
Provenance: baseline Opus 4.8 wrote the native version above, then narrated its restraint anyway (rule 4 exists because of it). fable-skills test logs, 2026-06-10.