Verified against Claude Code · 2026-07-22
Keep Claude Code inside one monorepo package instead of reaching across it
A scope-lock prompt for monorepo work that names the exact package boundary in play, treats a shared-package edit as a decision requiring explicit surfacing rather than a silent side effect, and distinguishes a genuine cross-boundary need from a workaround for a problem that actually belongs inside the target package.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are working inside packages/invoice-pdf of a a pnpm workspaces monorepo managed with Turborepo monorepo. Every edit in this task should stay inside that package's own directory unless this prompt explicitly says otherwise — a monorepo's whole point is that packages have a boundary, and treating that boundary as optional the moment it is inconvenient defeats it for everyone else depending on the packages you would silently cross into. TASK Add a per-line-item tax breakdown to the generated invoice PDF, using data already present on the Invoice type. SHARED PACKAGES THAT ARE HANDS-OFF FOR THIS TASK packages/shared-types and packages/design-system are both consumed by four other apps in this monorepo and are hands-off for this task. HOW A GENUINE CROSS-BOUNDARY NEED SHOULD BE HANDLED Stop and describe the specific field or export needed, then wait for explicit approval before touching packages/shared-types — do not make the change unilaterally even if it looks small. PACKAGE MANIFEST AND DEPENDENCIES TO CONFIRM AGAINST packages/invoice-pdf/package.json for its own dependencies, and a workspace-wide grep for '@repo/invoice-pdf' to see who consumes it. BEFORE EDITING 1. Read packages/invoice-pdf/package.json for its own dependencies, and a workspace-wide grep for '@repo/invoice-pdf' to see who consumes it. to confirm exactly what packages/invoice-pdf already depends on and what already depends on it — a change inside this package that alters its exported shape can break every consumer named there, even without touching a single file outside this package's own directory. 2. If completing the task as described appears to require changing something inside a package listed in packages/shared-types and packages/design-system are both consumed by four other apps in this monorepo and are hands-off for this task., stop before making that change. State specifically why the task cannot be completed without it, and follow Stop and describe the specific field or export needed, then wait for explicit approval before touching packages/shared-types — do not make the change unilaterally even if it looks small. rather than making the shared-package edit and explaining it afterward. 3. Distinguish a genuine cross-boundary requirement from a workaround for something that actually belongs inside packages/invoice-pdf — if a shared type needs a new field only this package will ever populate, the more correct fix is very often extending packages/invoice-pdf's own local type or adding an adapter at the boundary, not widening a type every other consumer of the shared package now also carries. WHILE WORKING - Do not add a new dependency from packages/invoice-pdf on another package in this monorepo without stating it explicitly, even if that package is already present elsewhere in the workspace — a new internal dependency edge changes this package's build graph and its allowed publish order, and that is a structural decision, not an implementation detail. - Do not modify a shared package's test fixtures to make this package's tests pass; if this package's own tests fail against a shared package's current behavior, that is a signal to look at, not a fixture to edit around. - Do not run a build or a test command scoped to the whole monorepo when a pnpm workspaces monorepo managed with Turborepo supports scoping it to packages/invoice-pdf alone — a whole-workspace command is slower, and a failure it surfaces in an unrelated package can be mistaken for a regression this task actually caused when it is not. IF THE TASK GENUINELY CANNOT BE FINISHED WITHOUT CROSSING THE BOUNDARY Say so explicitly before writing any cross-boundary edit, name the exact file and export involved, and wait for the exception process above to actually approve it — do not treat a self-judged 'this one is obviously fine' as equivalent to that approval, since that judgment is precisely what the exception process exists to check independently rather than leave to whichever session happens to be inside the boundary at the time. OUTPUT The change, scoped to packages/invoice-pdf unless an exception was explicitly approved through the process above, and a one-line confirmation of exactly which packages, if any beyond the target, were touched and why.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A monorepo's package boundary is a real dependency-graph fact, not a folder convention — a change to a shared package's exported shape can break every consumer listed in the workspace's own dependency graph, and that graph is exactly the kind of structural fact a model can actually check by reading manifest files and searching for import sites, rather than something it can reason about from general software principles alone, which is why requiring the manifest check before any edit is not boilerplate, it is the one step that turns 'this package boundary exists' from an assumption into a verified fact about this specific workspace. The distinction between a genuine cross-boundary need and a workaround for a problem that actually belongs inside the target package matters because the two look identical from inside a single task: widening a shared type to add a field only one package will ever populate is the path of least resistance in the moment, and it is also exactly the kind of change that turns a shared package into a dumping ground of increasingly specific, package-specific concessions that every other consumer now silently carries forward regardless of whether they use that field at all. Naming the exception process explicitly, rather than leaving cross-boundary changes to individual judgment, matters because a shared package's actual risk is cumulative across many separate tasks, each of which might reasonably conclude in isolation that one small shared edit is fine — the individual decision is rarely wrong on its own terms, but a shared package that has absorbed a dozen such individually-reasonable edits from a dozen different tasks, none of which went through the same review, has usually drifted far from what any single reviewer would have approved if asked to evaluate the sum of them at once. Refusing to edit a shared package's test fixtures to make the target package's own tests pass targets a specific and easy-to-miss form of scope creep: a failing test against a shared package's current, correct behavior is information about a real incompatibility, and editing the fixture to make it pass does not resolve that incompatibility, it just hides the evidence of it from whichever test suite happens to run next.
Verified against
Claude Code Sonnet 4.6 · 2026-07-22
Changelog
- 2026-07-22 — Initial publish, verified against Claude Code in a pnpm/Turborepo monorepo (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
