native-code

name	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.

Native Code

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. The injected form is the card at hooks/cards/native-code.md.

The rules

1. Grep before adding a construct. Comment, docstring, try/catch, log line, validation guard: grep the file for it first. Zero hits → zero in your diff.
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; never justification aimed at a reviewer.
3. No defensive bloat: no guard for a state the callers already exclude, no logging/config/flags nobody asked for. A contract worth enforcing is a test or a boundary assertion — its own change.
4. Don't narrate your restraint. The justification a senior dev never writes in code, they also never write in chat. 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 from the codebase's existing vocabulary.

Rationalizations

Thought	Reality
"A doc comment helps the next reader"	The file's owner trusted the signature; trust it too.
"Extra validation can't hurt"	A guard for an impossible state suggests the state is possible.
"I'll leave a TODO for the edge case"	Handle it, or surface it in your report.

Done when

Your diff adds no construct the file greps zero of; nothing narrates the change.