atryum: Skill for Codex

Populate Charter

Workflow

1. Read the user's instructional prompt and identify the agent's job, users, connected systems, recurring cadence, autonomous actions, approval boundaries, and expected outputs.
2. Load assets/charter-template.md when the exact output structure is needed.
3. If the prompt is underspecified, make conservative assumptions and mark them with bracketed placeholders such as [Owner], [Review cadence], or [Confirm system].
4. Populate the foundational sections and add scenario-specific sections where the prompt needs more operational detail. Do not leave generic filler; write concrete rules derived from the prompt.
5. Preserve the charter style: concise, operational, safety-forward, and written as binding instructions for the future agent and the tool-use governance system mediating it.
6. Add a one-row change log with today's date unless the user provides another date.

Drafting Rules

• Use a specific title: # CHARTER.md - {Agent Name}.
• Keep Purpose to one or two paragraphs plus a concrete Success looks like sentence.
• Define Scope with three subsections: In scope, Out of scope, and Handoff conditions.
• Define permission tiers as Auto, Notify, Approve, and Never, even if some tiers are sparse.
• Treat write actions, destructive actions, external communications, privacy-sensitive reads, and cross-system side effects as approval-sensitive unless explicitly safe in the prompt.
• Include prompt-injection rules whenever the agent reads untrusted text, user-generated content, documents, code, tickets, calendar descriptions, emails, CRM notes, webpages, or external feeds.
• Include failure defaults that bias toward surfacing uncertainty rather than silently acting.
• After Safety & ethics, add only the scenario-specific sections that make the agent's autonomous behavior more governable, auditable, or predictable.
• Add an output format section only when the agent produces recurring reports, tickets, PRs, messages, summaries, or other user-visible artifacts.
• Use scenario-specific sections for policies that do not belong cleanly in the foundation, such as severity/SLA tables, customer-state rules, ranking algorithms, report schemas, ticket templates, approval matrices, deduplication rules, or monitoring metrics.