Give a coding agent a monorepo task without loading the whole monorepo

Give the agent a small starting map, then expand its context along actual dependencies. Keep the files it should read separate from the projects you must verify. A narrow task can need little source context and still require tests in several consumers.

Take a hypothetical monorepo containing apps/storefront, apps/admin and packages/money. The task is to fix how money rounds a tax total. Reading every admin component would waste attention. Testing only the changed function could miss a caller that depended on its previous return type. The useful boundary follows the contract being changed, not the nearest folder name.

This guide proposes a workflow using documented instruction loading and build-tool selection. It does not claim that repository maps are complete, that agents obey every rule or that affected-only tests guarantee correctness.

Expand scope through dependencies

Prepare a task map, not a repository dump

Reddit user u/Nice_Storage613 described moving iOS, Android, backend and homepage projects into a monorepo after repeated cross-project handoffs. A reply offered an alternative: give a session access to multiple directories. That July discussion describes a coordination problem, not proof that repository migration is necessary. ^[1]

Before editing, ask for the implementation entry point, the relevant public contract, existing tests and direct consumers. Provide the task's expected behavior and constraints. Keep architecture documents as links to inspect when needed rather than pasting every page into the opening message.

For the tax example, the initial map might contain the rounding function, its package exports, the failing test and the checkout calculation that calls it. Add a rule explaining when the agent should expand the map: a changed public type, an unfamiliar generated file or a dependency outside the declared package.

This is NO FEED's proposed brief. It should remain short enough to review. “Only edit this directory” can be a task constraint, but it is not proof that changes there have no external effects.

Check how your client loads package instructions

The same directory layout does not imply identical loading behavior across agents. Codex documents a startup instruction chain from the project root to the current working directory, with per-directory precedence and a size limit. Starting at the repository root does not automatically place every package instruction in that initial chain. ^[2]

Claude Code loads ancestor instruction files at launch and discovers deeper instructions when it reads, writes or edits files in those directories. The files are concatenated; contradictory guidance can remain contradictory. ^[3]

Boris Cherny described that lazy loading on X in January. Current documentation corroborates the mechanism, but the vendor explanation supplies no measured token saving or success rate. The docs also distinguish additional directory access from loading that directory's memory files. ^{[4] [3]}

Cursor project rules use .mdc files with metadata controlling inclusion. File-pattern rules attach when a matching file is in context; a referenced file is not automatically inlined into the rule text. ^[5]

Keep repository-wide conventions at the root and package-specific commands near the package, using the client's supported mechanism. Ask the agent to identify which instructions apply to the tax function before it edits. Treat its answer as a diagnostic aid, and inspect documented loading signals where available; the answer alone cannot prove that every instruction reached the model.

If the task moves into a different package, revisit that package's guidance. A smaller context remains useful only while it contains the rules required for the current work. Our earlier instruction-loading analysis^[6] explains why a committed file and an effective instruction are different observations.

Let the graph propose the test set

Nx's affected command combines changed files with its project graph to find projects and their dependents. Use a meaningful base/head comparison. By default, it selects whole projects; opt-in task-level selection (NX_LEGACY_AFFECTED=false) also depends on declared inputs and outputs. ^[7]

For the example, inspect whether storefront and admin appear as consumers of money. If the graph omits a known caller, investigate the configuration before accepting a small affected set. The graph is useful because it makes the selection inspectable; it does not remove the need to understand what it represents.

pnpm makes dependency direction explicit in its filters: a trailing ellipsis selects a package and its dependencies, while a leading ellipsis selects it and its dependents. Its --fail-if-no-match option can expose an empty selection. ^[8] Confusing those directions can run tests for what money uses while omitting applications that use money.

Turborepo offers --affected for changed tasks and documents a conservative fallback when history is too shallow: all packages may be treated as changed. ^[9] Keep that fallback visible. A broad run caused by insufficient history is an environment observation, not evidence that the patch changed every application.

These are alternatives within an existing toolchain. Do not add three orchestrators to obtain three versions of the same answer.

Broaden checks when the contract broadens

NO FEED proposes four reasons to expand beyond the initial package check: a public interface changed; a shared dependency or lockfile changed; generated output changed; or a known consumer is absent from the selected set. Explain the reason beside the additional check.

In the tax example, a rounding correction that preserves the return type still deserves a consumer case showing the displayed invoice total. A changed return type requires callers to be inspected as well. A new dependency introduces installation behavior that a pure arithmetic unit test cannot exercise. The test scope follows the actual patch after editing, not only the original request.

Separate “not selected,” “selected but not run” and “passed.” Keep the selected projects, commands and results with the patch. If setup prevents a consumer test, report that gap instead of inferring success from the package's own suite.

Stop expanding when the evidence answers the task

A monorepo task needs enough context to explain its change and enough verification to challenge its consequences. It does not require a tour of the entire repository. When an agent finds unrelated cleanup, record it separately rather than silently enlarging the patch and invalidating the original scope.

For your next shared-package edit, write down one expected consumer before running the affected command. Compare that expectation with the selected set. Resolving a missing consumer is more useful than increasing the context window and hoping the agent notices the dependency itself.