agentleFS
lynchypinlynchypin/project-onboard/skills/scope-lock/SKILL.md

scope-lock

Skill0 starsChanged 3 months agoMITView on GitHub

Produces a short context manifest of which files and directories are in-bounds for the current task on a medium or large existing codebase. Keeps subsequent reading inside that boundary unless explicitly widened. Prevents context bloat.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before researching anything in a codebase big enough that reading all of it would be wasteful, decide what's in bounds and write it down.

    line 8
  2. Distinctive:

    Start from whatever's already known: If the user or wayfinder already named a specific area ("the payments module", "the login flow"), …

    line 13
  3. Very specific:

    Hold the boundary: Treat anything outside the manifest as out-of-bounds for Read/Grep/Glob.

    line 30
  4. Distinctive:

    Never read an entire large repository before scoping.

    line 40
  5. Distinctive:

    Never lock scope without at least one confirmation from the user.

    line 41
  6. Distinctive:

    Never treat the manifest as permanent across unrelated tasks.

    line 42

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

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

Scope-lock

Before researching anything in a codebase big enough that reading all of it would be wasteful, decide what's in bounds and write it down.

Process

  1. Start from whatever's already known. If the user or wayfinder already named a specific area ("the payments module", "the login flow"), that's the starting point.
  2. If nothing specific has been named, do a cheap structural pass: top-level directory listing, README/root CLAUDE.md if present, git log --stat -20 for recently-active areas, and any subdirectory CLAUDE.md files near likely locations. Do not read full file contents broadly — structure and names are enough.
  3. Propose a boundary. State it back to the user: "This looks like it lives mostly in src/checkout/ and touches src/payments/ — I'll focus there." One confirmation is enough.
  4. Write the manifest. Record the in-bounds paths in .agent/state.json (add a context_manifest field if needed).
  5. Hold the boundary. Treat anything outside the manifest as out-of-bounds for Read/Grep/Glob. If the boundary proves too narrow, say so and widen explicitly. If the research pass was substantial and handoff is detected, use it to compact before continuing.
  6. Re-scope per task, not per project. A manifest set for one feature doesn't carry to an unrelated task in the same repo.

What this skill must never do

  • Never read an entire large repository before scoping.
  • Never lock scope without at least one confirmation from the user.
  • Never treat the manifest as permanent across unrelated tasks.

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.