Copying the last repo's agent setup into a new one worked at first. It also copied product-specific assumptions. Once I had several active projects...
For further actions, you may consider blocking this person and/or reporting abuse
This boundary feels right to me. Repo-local agent rules are good for product facts, but planning habits want the same treatment as editorconfig or a shared CI template. Copyable, inspectable, and boring enough that a new repo can disagree without deploying a service.
I like the shared CI analogy. The ability for a repo to deliberately disagree is an important part of the boundary too. The shared layer gives me the default methodology, while repo-local state stays explicit when the product genuinely needs something different. That feels much healthier than copying the whole harness and slowly losing track of which differences were intentional.
We drew the same line between shared tools and reusable procedures, with one boundary placed differently: our procedures load only when a task matches them, never always-on, on the assumption that anything present on every turn is also paid for on turns that do not need it. The README-instead-of-AGENTS.md slip is the part I recognise — our fix was not a better prompt either, but a commit-gate test that fails when the instructions point at a file that is not there. Bootstrap ordering is the piece I have not solved: whatever runs first sits outside the thing it configures, so it gets trusted rather than checked.
I agree with the task-matched loading point too. That was part of what made the MCP-shaped approach feel increasingly wrong for this. I would have been exposing a shared tool surface broadly when much of the methodology only needs to exist for the repos or tasks that use it.
I suspect my current plugin is still a coarser packaging boundary than the eventual one. It could decompose into skills that are enabled only where they are useful. Bootstrap can disappear once it has materialized the repo mechanics, while something like planning can remain as a thin reusable procedure.
That last point is interesting to me too. I ended up at almost the same place after the cold-start failure. If bootstrap is responsible for establishing an invariant, checking for it afterwards is weaker than making the bootstrap deterministic enough that the invariant is true by construction. I like your commit-gate example too. It turns a missing instruction from something the agent has to notice into something the repo can reject.
I hit this on PZERO too. The client is portable. Leftover daily capacity is not. It dies at UTC midnight.
I do not keep leftover offers loaded like always-on tools. I quote the live row when I have a job. Thin book, I shrink the job. Same client in a new repo does not mean the capacity is still there.
"Planning standards and merge-safe workflows are agent policy and procedure. They are not remote resources waiting behind a tool boundary." That line earns the whole post. We watch a large catalog of agent skills daily, and the ecosystem is converging on exactly your four-scope split: thin always-on rules, external MCP for genuinely external systems, installable skills for procedures, and repo files for product truth.
Your "several places it could drift" problem has one more level though: once staged-planning ships as an installable skill across repos, each installed copy ages independently, and you are back to no canonical source one step down. Curious how you handle that: reinstall on a cadence, pin to a tag, or treat the user-level copy as the only source and never vendor it into repos?
Good catch. I think there are a few different lifecycles hiding inside "installed copy."
Today, things like
/planning-methodologyand/repo-bootstrapstay at user/plugin scope. The always-on rules point at the procedure rather than vendoring it into every repo, so there isn't an independently ageing planning copy in each repo. When the procedure changes, I version the plugin and merge to the marketplace repo. With the marketplace connected, that propagates to my IDE and Cloud Agents without vendoring a copy into each product repo.Bootstrap is different. It materializes stable repo mechanics like hooks, CI, a minimal
AGENTS.md, and environment lifecycle, then stops. Those are snapshots by design. Existing repos only pick up later changes when I explicitly migrate them. Product knowledge and product-specific skills can evolve in-repo afterward, and that divergence is intentional.The always-on policy has different semantics again. I deliberately keep it thin and separate from the plugin, so plugin procedure updates propagate through the marketplace while policy updates only propagate when I refresh the User Rules.
There's also a fourth lifecycle I haven't really formalized yet. If something needs to stay centrally defined, shouldn't be locally modified, and needs controlled upgrades, I'd probably treat it like a normal versioned dependency. Pin it, then let the repo owner choose the upgrade cadence, potentially with Renovate-style automation. Some of the mechanics I materialize today are an awkward middle case because they're snapshots rather than a live subscription.
So the scope split isn't just about where something lives. It also determines how changes propagate: plugin procedures from the marketplace upstream, policy when I refresh User Rules, repo mechanics through bootstrap or explicit migration, and potentially shared dependencies through normal version upgrades.
The “wrong boundary” realization really resonated with me.
A really good reflection, and I’m glad you wrote it down and shared it. These are the kinds of lessons that are easy to overlook when you’re in the middle of building things.👍️
Thanks, really appreciate that. This one took a while to get to the actual lesson. I kept thinking the problem was “how do I centralize this?”, when it was really “which things should propagate, which should be installed once, and which should live with the repo.” Glad the “wrong boundary” framing resonated.
Sometimes a change in perspective makes everything click. That moment when you finally see the real problem is pretty satisfying. 👊
This maps to a risk I keep seeing with agent setups. The expensive boundary is not where the tool call lives. It is where policy changes propagate without dragging along old product assumptions. Treating bootstrap as deterministic repo mechanics, and methodology as user-level procedure, seems like the right split.
Exactly. I think the propagation behavior is the part I was underweighting at first. Once I separated “should update everywhere” from “should be materialized into the repo once,” the ownership boundaries became much easier to reason about. Glad that distinction landed.
Your approach to identifying and separating the different scopes within your architecture is insightful, especially the emphasis on treating agent policies as internal methodologies rather than external tools. This distinction can greatly reduce complexity and enhance maintainability across your projects. Have you considered implementing automated checks to enforce the boundaries you've established? If you're looking for help in refining these scopes or further developing the architecture, I'd be happy to discuss a paid collaboration.
Yes. That became the next step after separating the scopes. I’m moving stable repo mechanics toward deterministic bootstrap and checks rather than relying on the agent to remember or reinvent the boundary. The interview was useful here because it exposed exactly where instructions alone weren’t enough.
Every one of the four scopes holds something a person authored. There's a class of knowledge the agent produces while working in a repo, and it's the class that goes missing: we tried X here and dropped it because Y. It isn't policy, it isn't a procedure, and it's too product-specific to leave the repo.
Your update semantics line is where it gets interesting, because this class has a third one. It doesn't flow across existing repos and it isn't a baseline for new ones. It gets written once, in the repo where it happened, and the next person into that code has to read it whether they're on Claude Code or Cursor, so it can't sit in either tool's config format.