goal-creator

name	goal-creator
description	Use when creating /goal directives, reusable testable outcome-oriented success standards for agentic workflows. Use whenever the user asks to create a goal, write a /goal directive, define what good looks like, set success criteria for an agent, define a reusable instruction, create a quality standard, write acceptance criteria for an agent workflow, or specify done conditions.
metadata	{"author":"zebbern","version":"1.3"}

/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

Format	What It Specifies	/goal Difference
One-off prompt	A single task invocation	Durable standard, not transient
System instruction	How the agent should behave (identity, tone)	What the agent must achieve (outcome)
Checklist	Steps to execute	Success conditions to meet
Acceptance criteria	Verifiable conditions for one feature	Reusable standard for a class of work
User story	User need from product perspective	Agent responsibility from execution perspective
SOP	Procedural "how to" instructions	Outcome specification - "what done means"

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

Field	Purpose	Quality Bar
Objective	North star for the agent	Observable state, not process description
Success Criteria	Done checklist	Each criterion is pass/fail verifiable
Constraints	Guardrails	Quantified where possible, MUST NOT/MUST/LIMIT format
Output Specification	Delivery contract	Format + structure + required elements
Verification Method	Independent confirmation	Method an external checker can execute

Category Quick Reference

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

Category	Verb Family	Read This	Use When
EXPLORE	explore, investigate, research	references/categories.md	Gathering information, learning, discovering
DEFINE	define, scope, frame	references/categories.md	Setting boundaries, specifying requirements
PLAN	plan, design, architect	references/categories.md	Creating blueprints, selecting approaches
BUILD	implement, build, create	references/categories.md	Producing artifacts, writing code/content
VERIFY	verify, validate, test	references/categories.md	Checking correctness, quality assurance
DEPLOY	deploy, launch, release	references/categories.md	Shipping to production
MONITOR	monitor, maintain, improve	references/categories.md	Ongoing operations, optimization
REFLECT	reflect, evaluate, learn	references/categories.md	Post-hoc analysis, knowledge capture

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.

Anti-Pattern	Symptom	Fix
Vague Aspiration	"Create something good"	Add measurable criteria
Over-Specification	Prescribes every micro-step	Separate goal (outcome) from procedure (how)
Under-Specification	Missing output format	Add output contract section
Conflicting Signals	Multiple incompatible priorities	Explicit priority order
No Termination	Agent does not know when to stop	Add explicit stop conditions
Sycophancy Trap	Vague praise-seeking language	Replace with objective criteria

Workflow-Specific Guidance

Read the appropriate file when targeting a specific workflow type:

Workflow Type	Read This File
Website building (frontend, UI/UX)	references/workflow-guides.md
Software build/CI-CD	references/workflow-guides.md
Research and analysis	references/workflow-guides.md
Product development	references/workflow-guides.md

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