Style shadowing

Shadow the user while they hand-edit code the agent just wrote, and distill their edits into style choices for future work. Use when the user says "keep an eye on what I'm doing", "learn my style from this", "watch my edits", or asks why their manual cleanup keeps repeating.

Overview

Visibility
public
Updated
16h ago
Built from
0 sessions

Install

An Agent Skill is a SKILL.md plus its files, zipped as .skill. Pick an agent — it activates when its description matches your request.

Download style-shadowing.skillstyle-shadowing/SKILL.md

User-level (~/.claude/skills/)

unzip ~/Downloads/style-shadowing.skill -d ~/.claude/skills/

Project-level (.claude/skills/, run from repo root)

unzip ~/Downloads/style-shadowing.skill -d .claude/skills/
SKILL.md

Style shadowing

The user works at both ends of the coding life cycle: they write the trait definitions and interfaces up front, the agent fills in the blanks, and then they pass back over the result changing aesthetic things: an if chain becomes .then().map(), a scattered condition becomes a match, a variable gets renamed so it can be tracked. Those passes are the ground truth of their style. Shadowing means capturing them so the next generation pass needs no cleanup.

Shadowing a session

  1. Stay hands-off while they edit. When the user takes their manual aesthetic pass, do not touch the files, suggest edits, or run formatters. Your only job is to observe. Done when the user says they are finished editing.
  2. Diff what they changed. Diff your version against theirs (git diff, or re-read the files you touched). Done when you can list every hunk the user changed by hand.
  3. Extrapolate the choice, not the instance. For each hunk, state the general rule it implies: "prefers combinator chains over nested ifs in Rust", "keeps early returns, hates else blocks", "error messages name the failing input". Skip one-off fixes (typos, actual bugs); a style choice is a preference that would apply again elsewhere. Done when every recurring hunk maps to a named rule.
  4. Generalize the rules. Collapse related hunks into the broadest rule that still holds, and phrase each so it applies beyond the file it came from. Done when no two rules overlap and each stands on its own.
  5. Memorize the rules. Append the generalized rules to the project's agent instructions file (AGENTS.md or CLAUDE.md, whichever the project uses) under a "Style choices" heading, each rule with a one-line before/after example drawn from the actual diff. Done when the file contains every rule from step 4.
  6. Hunt down violations. Review and refactor the existing codebase for places that break the new rules, and fix them so the codebase is consistent with the style you just recorded. Done when a fresh scan for each rule finds no remaining violations.

Applying the rules

When writing new code in this project, read the "Style choices" section first and write to it directly, so the user's aesthetic pass finds nothing to change.