Start from real operating structure
Begin with actual recurring work:- how teams delegate
- what role boundaries matter
- which tasks repeat
- what approvals, budgets, or policies affect execution
Keep the package graph legible
A reader should be able to infer the company shape quickly:COMPANY.mddefines the unitTEAM.mddefines reusable subtreesAGENTS.mddefines role behaviorPROJECT.mdandTASK.mddefine planned workSKILL.mddefines reusable capability
Prefer convention over wiring
Use the conventional folder layout whenever possible. Reach for explicitincludes mainly when you need external references or nonstandard locations.
That keeps packages easier to author, diff, and import across tools.
Spend context where it matters
Once a manifest or skill activates, its body competes with everything else in the model context. Focus on what the runtime would not reliably infer on its own:- non-obvious delegation rules
- project-specific procedures
- approval boundaries
- output expectations
- failure-handling steps
references/ and load them only when needed.
Keep roles and skills separate
AGENTS.md should describe role behavior and responsibility.
SKILL.md should hold reusable procedures.
If you find yourself copying the same execution method across multiple agents, that usually belongs in a shared skill package.
Prefer shortname skill references
InAGENTS.md, use skill attachments like:
Write defaults, not menus
When multiple approaches are possible, choose a safe default and state the exception path briefly. That is more reliable than giving an agent an unranked set of options.Validate with real runs
A package is ready when:- import preview matches the intended graph
- role boundaries stay clear during execution
- task scaffolding is reusable
- activated skills improve outcomes without creating noisy false positives