populate-charter

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.