In Short
- Problem: agent rules can quickly spread across
AGENTS.md, skills, hooks, scripts, and project memory. - What I looked at: available Codex surfaces, Project Pezzos habits, and the first move of article/lab workflows into skills.
- Result: the split is becoming clearer, but I do not yet have proof that it improves the final output.
- Lesson: judge rule placement on a real diff, not on the elegance of the system.
Why I Keep This Question
The interesting topic around coding agents is not “agents will change everything”. It is more mechanical: how can an agent move fast without losing the evidence, checks, and limits that let a human take back control?
In Project Pezzos, several surfaces already overlap:
AGENTS.mdfor local project constraints;- skills for reusable workflows;
- hooks and scripts for checks that should not depend on memory;
- maintainer memory for facts that matter when work resumes.
That is useful, but it can also become confusing. If every rule is repeated everywhere, the system becomes noisy. If every rule is hidden in a reusable skill, the local project loses context.
The risk is to mistake a tidy instruction architecture for a better result. A rule can
move from AGENTS.md to a skill, or from prose to a hook, without making the next diff
cleaner, easier to resume, or better validated.
The Current Split
I would keep AGENTS.md close to the repo. It should describe the local shape of the
work: what the repository is for, what must be read before touching it, which checks are
expected, and which production actions require approval.
I would use skills when the workflow is repeatable beyond one file. Article drafting, publication gates, lab planning, and evidence capture are good candidates because they have phases, stop conditions, and recurring review needs.
I would leave hooks and scripts for checks that should run even when nobody remembers the instruction. If a rule can be validated mechanically, it should eventually become a check instead of staying only in prose.
What Is Still Unproven
The split feels cleaner, but that is not enough. The real question is whether it improves the work:
- fewer missed validations;
- less duplicated process text;
- clearer resumes after interruptions;
- better article/lab separation;
- fewer accidental production or public-resource mistakes.
Those are empirical questions. The answer should come from future diffs, not from the architecture of the instruction system itself.
The missing test is close to the Stax note: run comparable variants on the same data pack, keep the reports and diffs blind for scoring, then look at quality, traceability, clarifications, and review cost before naming the winning surface.
What I Would Reuse
For now, the reusable rule is simple: keep local constraints local, reusable workflows in skills, and mechanical guarantees in scripts.
Then judge the split only when a real task becomes easier to resume, validate, or
review. Until that exists, a clean AGENTS.md / skill / harness boundary is still only
an instruction architecture that looks elegant.