Read before edit
Skill buildmoonshot/skillpacks/skills/engineering/beginner/read-before-edit
A beginner-to-expert curriculum of drop-in skills for Claude Code, Codex, and any coding agent. Copy-paste ready, tested, not a link farm.
npx -y skills add buildmoonshot/skillpacks --skill read-before-editAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when about to modify code in a file or function you haven't actually read yet — making a change in an unfamiliar or existing part of the codebase. Makes the agent read the surrounding code first so the edit matches existing patterns and doesn't break nearby logic.
SKILL.md
1.7 KB, as published. Nobody here has run it
Read Before You Edit
Before changing existing code, read enough of it to understand what you're touching. Editing blind is how agents break working software.
What to do
-
Read the function/section you're changing — and the code immediately around it. Understand what it does and what depends on it before you touch a line.
-
Find the existing patterns. How does this file name things, handle errors, structure logic? Match that, don't impose your own style.
-
Check who calls it. A quick look at where a function is used tells you what you might break. Changing a signature or return value without checking callers is a classic self-inflicted bug.
-
Reuse what's there. If the codebase already has a helper, a utility, or a pattern for what you need, use it instead of writing a parallel one. New code should look like it belongs.
The trap to avoid
Don't pattern-match on the name of a function and assume it does what you'd expect. Open it and confirm. The function called validateUser might also mutate state, log, or throw — assumptions about unread code are where bugs hide.
Why this matters
Most agent-introduced bugs aren't bad logic — they're good logic that didn't fit the existing code, broke an unseen caller, or duplicated something already there. Two minutes of reading prevents the kind of bug that takes an hour to trace.