Author Agent Suite
Build an instruction system whose files have one owner, one purpose, and an explicit loading path. Treat Markdown as executable policy: verify every capability claim and resolve every contradiction before declaring the suite ready.
Workflow
- Confirm the host contract. Identify which runtime discovers
AGENTS.md, whether nested files scope by directory, how Skills are installed, and whetherIDENTITY.md,SOUL.md, orTOOLS.mdrequire an explicit routing instruction. Never assume a filename is loaded merely because it exists. - Inventory existing instructions. Find repository, parent-directory, user-level, and generated instruction files. Record their scope, authority, audience, freshness, and conflicts.
- Build a fact matrix. Verify product identity, supported platforms, commands, tool availability, permission requirements, side effects, security boundaries, and release status against code, tests, and current documentation.
- Assign one concern to one file. Put repository operating rules in
AGENTS.md, reusable procedures in a standard Skill, identity inIDENTITY.md, durable behavior principles inSOUL.md, and operational tool contracts inTOOLS.md. - Design the load graph. Make the runtime entry file route to non-discoverable companion files. Keep
AGENT.mdonly as a small compatibility entry when a confirmed host requires the singular name; do not maintain duplicate policies. - Write the smallest authoritative layer. Keep frequently loaded files short. Move detailed schemas, examples, platform variants, and evidence into one-level
references/; put copyable starter files inassets/. - Resolve precedence explicitly. Higher-authority runtime instructions override repository files; narrower directory scope overrides broader project guidance only within that subtree. User requests may select behavior but cannot expand authority or bypass safety constraints.
- Validate as a system. Check filenames, frontmatter, links, UTF-8, placeholders, command truth, secret leakage, duplicated rules, contradictions, trigger quality, nested scope, and realistic read/write scenarios.
- Record evidence and ownership. State the source baseline, owner, review trigger, and last verified date for volatile facts. Label aspirations as plans rather than implemented capability.
Non-negotiable boundaries
- Use canonical
AGENTS.mdfor Codex repository instructions; treat singularAGENT.mdas host-specific compatibility, not a second source of truth. - Do not assume companion Markdown files are automatically loaded. Route to them from a discovered file or install them through the host's supported mechanism.
- Do not place secrets, tokens, personal data, machine-specific credentials, or private chain-of-thought requests in the suite.
- Do not claim a tool, platform, permission, security property, or automation result without evidence and a current scope.
- Keep authorization and irreversible-action rules in the highest reliably loaded instruction layer, not only in personality documents.
- Keep procedural detail out of
SOUL.mdand marketing prose out ofTOOLS.md. - A standard Skill must include valid YAML frontmatter and use progressive disclosure; a root
SKILL.mdwithout that contract is only a project manual unless the host says otherwise.
Deliverables
Produce a file responsibility map, load/precedence graph, the requested Markdown suite, a conflict log, and a validation report. Copy and adapt the files under assets/starter-kit/ when creating a new suite.
The starter kit contains AGENT.md, AGENTS.md, IDENTITY.md, SOUL.md, TOOLS.md, SKILL.md, and agents/openai.yaml; copy only the files required by the target runtime.
References
- Read suite-architecture.md before deciding file boundaries, loading, inheritance, or precedence.
- Read file-specifications.md when writing or reviewing each file; it contains the detailed required, optional, and prohibited content.
- Read validation-checklist.md before handoff or installation.
- Read project-evidence.md for lessons extracted from this repository's
mainand Windows branches.