← ClaudeAtlas

fable-native-codelisted

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.
DizzyMii/fable-skills · ★ 1 · AI & Automation · score 67
Install: claude install-skill DizzyMii/fable-skills
# Native Code ## Overview 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. ## Rules 1. **Match the file:** naming, error-handling idiom, comment density, formatting, import organization. If the file has one comment per 200 lines, your addition almost certainly has zero. 2. **Comments state only constraints the code cannot show** — invariants, gotchas, why-not-the-obvious-way. Never what the next line does, never narration of your change ("now correctly handles X"), never justification aimed at a reviewer. Test: after the PR merges, is this comment information or noise? 3. **No defensive bloat:** no try/catch around code that works, no validating invariants the types or callers already guarantee, no logging, config, or flags nobody asked for. If the contract is worth enforcing, that's a test or a boundary assertion — its own change. 4. **Don't narrate your restraint.** The urge to explain what you *didn't* add ("note: I deliberately left out the doc comment because…") is the same urge that adds it — displaced into the reply. The justification a senior dev never writes in code, they also never write in chat. Deliver the code; mention style only if the user asks. 5. **Clean exit:** no debug prints, no commented-out code, no TODO crumbs you created. 6. **Names come fr