scope-lock

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From lynchypin/project-onboard, MIT.

More from lynchypin/project-onboard