I use AI agents to work across several software projects. For larger changes, I give them a Markdown plan that breaks the work into smaller pieces, with clear instructions about what each piece should deliver and when the agent needs to stop for review.
These plans live alongside the code, so each repository can manage its own work. A plan can contain multiple slices, each describing a chunk of work and where human review should kick in. Slices don't map directly to pull requests; several can ship together or span more than one. Some repositories also keep a boilerplate template so new plans start from the same outline.
For a concrete example, here's an archived plan from a vector retrieval experiment.
In an earlier post, I described how I moved our planning methodology to a shared, portable implementation so every repository could point at the same rules instead of copying them by hand. That answered how to distribute the methodology. It did not answer how to know each repo's plans still matched it.
I deliberately kept those repositories separate. Some are public, some are private, and each needs to ship on its own timeline without negotiating every planning edit with the others. We share conventions through the methodology; we do not share a monorepo.
I still assumed shared conventions were enough on their own. Plans read fine in review; nobody was checking mechanical consistency at scale.
Language models are good at reasoning about how to divide work and what trade-offs belong in the plan. They are not a cheap way to confirm that every heading, todo id, and required section lines up with the rules. I wanted ordinary code for that: fast, repeatable checks in local runs and CI, with no second model pass.
Active plans guide what agents actually execute: the work to complete, the instructions for each step, when to stop for review, and how to verify the result. The validator checks that those elements are present and consistently structured. It doesn't guarantee that an agent will follow the plan, only that the required instructions are in place.
A repository can follow the shared methodology without installing the validator. I added a small deterministic checker through a reusable GitHub workflow where I wanted structure enforced in CI. It judges mechanical shape only, not whether a plan is wise, complete, or safe to merge.
The first workflow pass validated active plans only. During rollout, a smoke run in one repository passed while the log still showed the boilerplate template as unchecked, so we updated the reusable workflow to run both paths wherever a boilerplate template exists.
Repository adopts optional plan validation
→ Active plans
→ Structural checks on executable plans
→ Local template (if present)
→ Strict checks on the starting template
→ CI flags structural violations before merge
Across six repositories, the validator caught problems in plans that agents were already using. In one plan, section headings didn't match the work items they were supposed to represent. Other sections were missing required labels for verification or rationale. The plans looked fine when read normally, but their structure didn't match the shared rules.
The templates revealed a similar problem. Three of the six repositories kept their own starting templates, and all three failed validation. Some used a different structure from the shared rules; others contained example instructions that the validator interpreted as real ones. These were small differences that had accumulated as the repositories evolved independently.
The individual fixes were small, but they showed that sharing a methodology hadn't kept the plans structurally consistent. CI now checks for those mismatches as plans change, rather than relying on reviewers to notice them.
Takeaway: Let LLMs reason about the work, but verify the plans agents execute from with deterministic checks so required instructions and boundaries are structurally present before execution starts.
Implementation: I've published the plan validator source I use across my projects. It's part of my agent planning workflow, but the implementation is public if you're interested in how I approached the problem.