Package scaffolding for monorepos.
After installing monorepo-extras, adding a new package to your monorepo runs through `new-package` — a structured scaffold that produces the correct directory layout, AGENTS.md, build configuration, and test wiring in one step. The alternative is doing it by hand from a peer package, which consistently misses the build system wiring.
new-package1 gateScaffolds a new package in a monorepo with the correct structure, AGENTS.md, and build configuration — wired to the project's existing conventions.
You decide to add a new package to the monorepo and describe its purpose. The agent activates new-package, asks for the package name and a brief description, and checks whether any existing packages in the repo serve as the closest structural analogue.
You: Name the package precisely — using the project’s naming convention (kebab-case, domain-qualified, etc.). Describe the package’s role in one sentence: what it does and who uses it. If the agent suggests looking at an existing package as a template, confirm whether that package is actually the right model or just the closest match.
The agent produces the package skeleton: directory structure, package.json (or equivalent), AGENTS.md, build configuration, and test directory. It populates the AGENTS.md with the package name, a description, and the correct build and test commands.
You: Review the scaffolded package at the G-review gate. The two things most likely to be wrong: the AGENTS.md still has placeholder text, and the test command points to the wrong root. Both are easy to catch and easy to fix at this gate; neither is easy to fix after other packages have extended the scaffolded pattern.
After the review gate passes, the agent commits the scaffold, pushes the branch, and verifies that CI runs the new package’s tests correctly.
You: Watch the CI run complete. If the new package’s tests don’t appear in the CI output, the test wiring is incomplete — the CI configuration doesn’t know about the new package. Add the explicit CI step if needed. The most common cause: the CI config uses a hard-coded list of packages rather than a glob.
For each gate, everything you need to make a confident decision.
A package that builds from its own root, has a meaningful AGENTS.md, and follows the naming and layout conventions of the existing packages in the monorepo.
A package whose AGENTS.md still reads 'TODO: describe this package.' Or a package whose test command runs the wrong test suite because the `jest.config.js` points to the wrong root. These are the two most common post-scaffold defects.
A scaffold that passes the G-review gate and then fails the first real build is the most expensive outcome — you've committed structural debt to the repo. The review gate is five minutes; fixing structural wiring after the first three PRs have extended the scaffolded pattern is much more expensive.
agentbundle install --pack monorepo-extras