Direct answer
Route each task from the repository root to one owned package and its affected dependents. Load root rules plus directory-specific instructions, provide only the relevant dependency and build context, restrict edits to declared paths, and verify the changed package together with consumers selected by the repository’s own dependency tooling.
Key takeaways
- Root instructions define global policy; package instructions define local commands and conventions.
- Context should follow the dependency path, not the entire repository tree.
- Allowed edit paths and generated-file rules must be explicit before implementation.
- Verification includes affected dependents, not only the package that changed.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Hierarchical instructions | Codex supports AGENTS.md guidance scoped through repository directories. | View source |
| Project memory | Claude Code memory supports project and directory context with documented scope behavior. | View source |
| Large codebase workflow | Claude Code documents targeted exploration patterns for large codebases. | View source |
| Execution boundary | Codex security settings separate read access, workspace writes, approvals, and sandbox behavior. | View source |
What this guide helps you solve
Design a coding-agent workflow that respects monorepo ownership, dependency, and validation boundaries.
Verification scope and limits
- Evidence basis
- Official documentationLocal verification
- Verification scope
- Covers task routing, hierarchical instructions, context selection, edit scope, dependency-aware checks, and cross-package review.
- Limits and invalidation conditions
- - Dependency selection commands differ by monorepo build system and must come from the repository.
- - Static dependency graphs may not capture runtime, deployment, data, or ownership coupling.
Route the task to an owned package boundary
Start with the requested behavior, owning team, package, entry point, and likely consumers. Ask the agent to confirm the repository layout and dependency path before proposing changes. A task that spans multiple owners should expose those decision points before editing.
Record generated directories, vendored code, lockfiles, and shared schemas that require special handling. Do not let broad search-and-replace cross package boundaries without a reviewed migration plan.
Layer global and package-specific instructions
Keep security, dependency, release, and cross-repository rules at the root. Put language commands, package layout, test targets, and generated-file instructions near the package they govern. Avoid duplicating the same rule across many directories because copies drift.
- Name the working directory for every command.
- Identify package owners and approval-required files.
- Describe generated artifacts and their source files.
- Point to shared architecture documentation instead of copying it.
Build context around symbols and dependencies
Let the agent search for definitions, callers, tests, and configuration along the relevant path. Summarize large generated or repetitive files instead of loading them in full. Keep durable repository facts in maintained instructions and one-time acceptance criteria in the task.
When context becomes uncertain or contradictory, reset with a short state summary rather than continuing from an overloaded session.
Constrain edits and cross-package contracts
Provide an allowlist of packages and files. Changes to shared schemas, APIs, build graph definitions, dependency versions, or release configuration require an explicit plan and the affected owners. The agent should stop when a necessary change exceeds the approved boundary.
Run dependency-aware verification
Run focused checks for the changed package, then use the repository’s maintained affected-target mechanism or documented consumer list. Include shared type generation, contract checks, and builds when the changed boundary requires them. Capture commands from the correct working directories.
- 01Changed packageRun its formatter, type checks, and focused tests.
- 02Shared boundaryRegenerate and compare maintained artifacts when required.
- 03DependentsRun checks selected by the repository dependency graph.
- 04IntegrationExercise the smallest cross-package path that observes the contract.
Review by ownership and update repository context
Request reviews from owners of changed and shared boundaries. Update scoped instructions when commands or package responsibilities move. A successful task should leave the monorepo easier to navigate for the next maintainer and agent, not add undocumented exceptions.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology