goal-creator

# `/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. ```markdown ## /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**