agentleFS
yaohuangguanyaohuangguan/agent-playbook/skills/orient-in-codebase/SKILL.md

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
  1. Distinctive:

    Check where you are: Run these and read the output:

    line 21
  2. Distinctive:

    If the branch is behind the default branch, note it.

    line 29
  3. Very specific:

    Read the project's instructions: Look for AGENTS.md, CLAUDE.md, GEMINI.md, CONTRIBUTING.md and README.md.

    line 32
  4. Very specific:

    Find the commands CI runs: Read .github/workflows/, .gitlab-ci.yml or the equivalent.

    line 48
  5. Distinctive:

    Record a baseline: Run the tests for the area you will change, before you change anything.

    line 52
  6. Distinctive:

    Find the code path: Search for a word from the task, such as a route, an error message or a UI label.

    line 56

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Check where you are. Run these and read the output:

    git status --short --branch
    git fetch origin
    git log --oneline -5

    If the branch is behind the default branch, note it. A search on a stale branch can miss code that exists.

  2. Read the project's instructions. Look for AGENTS.md, CLAUDE.md, GEMINI.md, CONTRIBUTING.md and README.md. They override your habits.
  3. Identify the stack from its manifest files.

    FileStackLook for commands in
    package.jsonJavaScript or TypeScriptscripts
    pyproject.toml, requirements.txtPython[tool.*], tox.ini, Makefile
    go.modGoMakefile, go test ./...
    Cargo.tomlRustcargo test
    pom.xml, build.gradleJava or Kotlinmvn test, ./gradlew test
    *.csproj, *.sln.NETdotnet test
    GemfileRubyRakefile, bin/rspec
    composer.jsonPHPscripts
  4. Find the commands CI runs. Read .github/workflows/, .gitlab-ci.yml or 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.
  5. 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.
  6. 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.
  7. 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 moveWhy it failsDo this instead
Guess npm test or pytestThe real command may differ or do lessRead the manifest and CI
Trust the README aloneIt may be out of dateConfirm with CI config and by running it
Skip the baselineOld failures look like yoursRun the tests first
Write a new helperOne probably existsSearch before you write
Say something does not exist after one searchThe name may differ or the branch may be staleFetch, 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>

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.