read-before-edit
Skill2 starsChanged 4 months agoMITView on GitHub
Forces context-gathering before code mutation. Reads the file, finds call sites, reads adjacent tests, and checks config before any non-trivial edit.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- kartykk/agent-readytheir own version, first seen Sep 21, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- kartykk/agent-ready★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository3 other files it gives its agents.
- AGENTS.mdAGENTS.md
- loop-failure-triageSkill
- verify-before-doneSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Before any non-trivial edit:
- Distinctive: line 18
Read the closest test file: If one exists, the tests document the contract.
- Distinctive: line 19
Check the config: If behavior is configurable, find where the config is loaded and what the defaults are.
- Distinctive: line 34
Not ceremony. Not "read everything in the repo." Bounded, purposeful reading: file, callers, tests, config.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Read Before Edit
The article's third lesson: most engineering is reading. The model that patches fastest is rarely the one you want; the one that builds enough context first usually produces a smaller, correct diff with fewer follow-ups.
The rule
Before any non-trivial edit:
- Read the file you intend to change, end to end if it is small (under 300 lines), or the relevant section plus its imports otherwise.
- Find the call sites. Grep for the function or symbol you are touching to see who calls it and what they expect.
- Read the closest test file. If one exists, the tests document the contract. Edits that break tests usually break the contract.
- Check the config. If behavior is configurable, find where the config is loaded and what the defaults are.
What counts as non-trivial
- Adding a new branch to a conditional
- Changing a function signature or return type
- Modifying error handling
- Touching shared state, caches, or globals
- Editing migrations, schemas, or types
- Anything in code you did not write today
A pure rename, a typo fix in a string, or adding a missing comma is trivial. Edit freely.
What this is not
Not ceremony. Not "read everything in the repo." Bounded, purposeful reading: file, callers, tests, config. Usually four to ten reads. Stop when you have enough mental model to predict what your edit will do and what tests it will affect.
When to invoke
Trigger this skill whenever:
- You are about to call Edit or Write on a file you have not yet read in this session
- You catch yourself drafting an edit from memory or pattern-matching from a similar codebase
- You are touching a function whose call sites or tests you cannot name
- You are tempted to "fix" surrounding code that was not part of the original task
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.