orient-in-codebase
Skill1 starsChanged 2 days agoMITView on GitHub
Learn an unfamiliar repository before changing it, including its real build and test commands, conventions and current health. Use this at the start of work in any repository you have not read in this session, or whenever you do not yet know how to run its tests, even if the task looks small.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 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.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Check where you are: Run these and read the output:
- Distinctive: line 29
If the branch is behind the default branch, note it.
- Very specific: line 32
Read the project's instructions: Look for AGENTS.md, CLAUDE.md, GEMINI.md, CONTRIBUTING.md and README.md.
- Very specific: line 48
Find the commands CI runs: Read .github/workflows/, .gitlab-ci.yml or the equivalent.
- Distinctive: line 52
Record a baseline: Run the tests for the area you will change, before you change anything.
- Distinctive: line 56
Find the code path: Search for a word from the task, such as a route, an error message or a UI label.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Orient in a codebase
Most bad changes start with a wrong assumption about the repository. A few minutes here prevents guessed commands, duplicated helpers and confusion over failures that already existed.
When to use
- First task in a repository, or in an area you have not read.
- You do not know how tests run, or which branch is current.
Skip this if you already did it for this area in the current session.
Steps
Check where you are. Run these and read the output:
git status --short --branch git fetch origin git log --oneline -5If the branch is behind the default branch, note it. A search on a stale branch can miss code that exists.
- Read the project's instructions. Look for
AGENTS.md,CLAUDE.md,GEMINI.md,CONTRIBUTING.mdandREADME.md. They override your habits. Identify the stack from its manifest files.
File Stack Look for commands in package.jsonJavaScript or TypeScript scriptspyproject.toml,requirements.txtPython [tool.*],tox.ini,Makefilego.modGo Makefile,go test ./...Cargo.tomlRust cargo testpom.xml,build.gradleJava or Kotlin mvn test,./gradlew test*.csproj,*.sln.NET dotnet testGemfileRuby Rakefile,bin/rspeccomposer.jsonPHP scripts- Find the commands CI runs. Read
.github/workflows/,.gitlab-ci.ymlor the equivalent. CI is the real definition of passing, and docs are often out of date. Note the commands for tests, lint, type checks and build. - Record a baseline. Run the tests for the area you will change, before you change anything. Write down what fails now. Without this, you cannot tell whether you caused a failure.
- Find the code path. Search for a word from the task, such as a route, an error message or a UI label. Follow it from the entry point to storage. Read callers as well as the function itself.
- Find the nearest example. Open the closest similar feature and its test. Copy their naming, structure, helpers and error handling.
Stop and ask when
- The task description does not match what the code does.
- The baseline is broken in a way that blocks your work.
- You cannot find how to run the tests after checking the manifest and CI.
Common mistakes
| Tempting move | Why it fails | Do this instead |
Guess npm test or pytest | The real command may differ or do less | Read the manifest and CI |
| Trust the README alone | It may be out of date | Confirm with CI config and by running it |
| Skip the baseline | Old failures look like yours | Run the tests first |
| Write a new helper | One probably exists | Search before you write |
| Say something does not exist after one search | The name may differ or the branch may be stale | Fetch, try other terms, then state what you searched |
Report
Branch: <name>, <ahead/behind default branch>
Stack: <languages and frameworks>
Commands: test `<cmd>`, lint `<cmd>`, types `<cmd>`, build `<cmd>`
Baseline: <what passes, what already fails>
Code path: <entry point> -> <main files>
Pattern to follow: <nearest similar file>Other versions2 projects use a version of this.
Word for word · 2
- Remote-Arc/remote-arc★ 5100% same
- yaohuangguan/remote-arc★ 5100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
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 repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- audit-test-suiteSkill
- change-data-safelySkill
- debug-failureSkill
- fix-flaky-testSkill
- hand-off-workSkill
- implement-changeSkill
- refactor-safelySkill
- review-codeSkill
- secure-changeSkill
- use-external-apiSkill
- verify-and-reportSkill
- write-pull-requestSkill
- write-testsSkill
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.

