Denarrate

Restating the obvious — narrating what the reader can already see:

• # Load the config above load_config()
• # Initialize the database above db.init()
• # Return the result above return result

Cover the comment. Can the reader still understand the code? If yes, the comment is narration.

Dangling presupposition — narrative context that doesn't resolve:

• "Unlike the old implementation..." — what old implementation?
• "This replaces the previous approach" — what approach?
• "For historical reasons..." — either explain the constraint or don't

Hedging as narration — telling the story of the code's uncertainty:

• "This is a temporary workaround" — file an issue or fix it
• "TODO: clean up after migration" — the migration is over or it isn't
• "Might not be needed anymore" — find out

What Survives

Not every comment is a target. These are in-register:

• Intent: "Retry with backoff because the upstream API rate-limits"
• Constraints: "Must stay sorted — binary search depends on it"
• Non-obvious behavior: "Returns None on timeout, not an error"
• Warnings: "Not thread-safe — caller must hold the lock"

These describe atemporal properties of the code. They'd be true yesterday, today, and tomorrow. That's the test.

On Activation

1. Resolve targets — if args are file paths, read them. If "staged", read git diff --staged. If a directory, find source files in it. If no args, ask.
2. Extract every comment from the target files.
3. Evaluate each — is it descriptive (in-register) or narrative (out-of-register)?
4. Present issues — file, line, the comment, which narrative signal it triggers, and the fix (revised wording or deletion).
5. Ask before applying.
6. Apply — edit files, show the diff.