[FEATURE] Keep development history out of code comments/docstrings by default (put it in git, not the file)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code writes or edits code, it frequently records development history inside comments and docstrings instead of in version control. The information is useful — it's just in the wrong place, and it accumulates as noise for the next person reading the code. Three patterns recur:

1. Docstrings that narrate development — describing how an issue was found, who raised it, or when it changed, rather than the function's inputs, outputs, and contract. It reads like a commit message living inside the docstring.
2. "Code obituary" comments — explaining what a file or module used to contain and why it's gone (the previous approach, retired constants and their old values). The diff already records this.
3. Refactor narration — when a large file is split, the code carries a note explaining why it was split and where each piece moved. That rationale belongs in the commit, not the file.

The core issue: git blame already records who and when, the commit message records what changed and why, and the diff records what was removed. Code is clearest when it describes what it does today. A useful test: would this sentence still make sense to someone who never saw the previous version? If not, it's history and belongs in git — yet the narration appears by default.

I've encoded this as a project rule (comment/docstring style guidance with examples and grep checks). It helps, but the narration still surfaces by default, so per-project rules don't fully resolve it.

Proposed Solution

Make "history lives in git; code describes the present" a stronger default in Claude Code. Options, roughly in order of preference:

1. Default model behavior — when generating or editing code, describe the function/module as it stands now. Route the why-it-changed, what-was-removed, and where-it-moved narrative into the commit message (or PR description) instead of into comments/docstrings.
2. A first-party setting (e.g. a settings.json flag or a shipped rule/skill) that teams can enable, so this doesn't have to be re-authored in every repo.
3. The self-check test as a built-in guardrail — before writing a comment/docstring, apply: would this still make sense to someone who never saw the previous version? If not, move it to the commit message.

The goal is that clean code with history in version control is something teams can rely on by default, rather than continually reinforcing it project by project.

Alternative Solutions

1. Per-project rules / CLAUDE.md guidance — implemented, with examples and grep checks. Reduces the behavior but doesn't eliminate it, and every team has to re-author it.
2. Manual cleanup in review — works but is recurring toil and easy to miss.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

_No response_

Additional Context

Sharing this in the spirit of improving an already excellent tool. Happy to provide concrete before/after code examples if useful