/goal Creator

Create reusable, testable, outcome-oriented success standards that guide agents across repeated runs. A /goal is not a one-off prompt - it is a durable operating instruction that defines what good execution looks like.

Core Workflow

Creating a /goal follows these steps:

1. Define the outcome - what does success look like in observable terms?
2. Select category - which workflow stage is this for? (see categories below)
3. Apply a template - fill in the master template or select an alternate
4. Add constraints - what must NOT happen? what boundaries apply?
5. Define verification - how will an independent checker confirm success?
6. Run quality audit - apply the pre-flight checklist before delivering

What a /goal Is

A /goal directive is a declarative, outcome-oriented specification of what success looks like - independent of execution path. It is:

• Enduring - reusable across multiple sessions, not one-off
• Evaluable - an independent checker can verify achievement
• Decomposable - can be broken into sub-goals with dependencies
• Role-anchored - tied to a specific agent responsibility

What a /goal Is Not

Rule of thumb: Use a /goal when you need a reusable success standard. Use other formats for one-time tasks, identity definition, procedure lists, or feature-level verification.

Master Template

Fill every /goal using this template. All fields marked * are required.

## /goal: [Short Name]

**Category**: [EXPLORE / DEFINE / PLAN / BUILD / VERIFY / DEPLOY / MONITOR / REFLECT]
**Scope**: [One-line: what this goal covers and excludes]

### Objective*
[Single declarative sentence: what success looks like in observable terms]

### Success Criteria* (verify ALL before returning)
- [Criterion 1: measurable, pass/fail verifiable condition]
- [Criterion 2: measurable, pass/fail verifiable condition]
- [Criterion 3: measurable, pass/fail verifiable condition]

### Constraints* (hard boundaries)
- MUST NOT: [forbidden action or output characteristic]
- MUST: [required characteristic every output must have]
- LIMIT: [quantified bound - time, length, count, etc.]

### Output Specification*
[Exact expected output: format, structure, required sections, naming conventions]

### Verification Method*
[How an independent checker confirms success without re-doing the work]

### Failure Modes to Prevent
- [Specific failure mode 1]: [prevention strategy]
- [Specific failure mode 2]: [prevention strategy]

### Context (optional)
[Domain assumptions, prerequisite state, related goals]

### Examples (optional)
**Good output example:** [brief illustration]
**Bad output example:** [brief illustration with why it fails]

Required Fields Reference

Category Quick Reference

Each workflow stage has a different goal category. Read the appropriate reference file for detailed templates, examples, and stage-specific guidance.

Gold Patterns (High-Impact)

Read references/patterns.md for full details with examples. The top 5:

1. End-State-First - Define "done" in verifiable terms before describing process
2. Structured Output Contract - Specify exact output format as an interface contract
3. Constraint-First Safety - Define what NOT to do before what to do
4. Second-Agent Test - A different agent can verify success from the output alone
5. BDD-Style Verification - Use Given/When/Then for complex multi-step goals

Anti-Patterns (Avoid These)

Read references/patterns.md for the full catalog with before/after corrections.

Workflow-Specific Guidance

Read the appropriate file when targeting a specific workflow type:

Pre-Flight Quality Checklist

Before delivering any /goal directive, confirm ALL of the following. Any item marked [VETO] failing blocks delivery regardless of other quality.

A. Clarity

• Objective states an observable outcome, not a process
• Success criteria use pass/fail language (no "should" or "try to")
• Output format is specified with required sections/fields
• Constraints use MUST NOT / MUST / LIMIT format

B. Verifiability

• Second-agent test: a different agent could verify success from output alone
• Each success criterion is independently checkable
• Verification method does not require re-doing the work

C. Safety [VETO items - any failure blocks delivery]

• At least one MUST NOT constraint prevents harmful output
• No instruction conflicts with safety or compliance requirements
• Goal explicitly forbids fabricating data, sources, or credentials
• Stop conditions prevent infinite loops or runaway execution

D. Completeness

• Category is assigned (EXPLORE/DEFINE/PLAN/BUILD/VERIFY/DEPLOY/MONITOR/REFLECT)
• Scope boundaries are explicit (what is included AND excluded)
• At least 2 specific failure modes are listed with prevention strategies
• Examples are provided for non-trivial goals

E. Reusability

• Goal is parameterized (uses placeholders for context-specific values)
• No hardcoded dates, names, or one-time references
• Goal can guide multiple runs without modification

F. Actionability

• Agent receiving this goal knows exactly what to produce
• Agent receiving this goal knows when to stop
• Agent receiving this goal knows what to avoid

Minimum passing score: 10/12 items from sections A, B, D, E, F + ALL section C