Goal Definition

Contents

• •Mental Model - Why goals exist, Goodhart's Law mitigation
• •When to Use - Goal vs task distinction, trigger patterns
• •Outcome Categories - Concrete, Agent-to-define, Deferred
• •Goal File Format - Standard structure for goal files
• •Anti-Goals - Defining what must NOT happen
• •Action Router - Navigate to correct workflow
• •Workflows - Links to define, investigate, complete

Mental Model

Goals solve the Goodhart's Law problem in AI agent orchestration:

"When a measure becomes a target, it ceases to be a good measure."

The Problem

When agents define their own success criteria, they gravitate toward:

• •Easily measurable things (not necessarily important)
• •Things they can achieve (not necessarily valuable)
• •Narrow interpretations that technically satisfy criteria while missing the point

The Solution

Goals enforce structural guardrails:

Separation of Concerns

DEFINE phase: Agent proposes → User approves criteria
IMPLEMENT phase: Agent executes against approved criteria
VERIFY phase: Check against pre-approved criteria (no moving goalposts)

When to Use

Use /goal When

• •Multi-faceted outcome - Success requires multiple orthogonal criteria
• •Evidence-grounded problem - Specific data points identify the issue
• •High stakes - Wrong implementation could cause downstream harm
• •Investigation needed - Can't specify success criteria without research first
• •Anti-goals critical - Important to define what must NOT happen

Use /todo When

• •Clear deliverables - Specific files to create/modify
• •Well-understood scope - No investigation needed
• •Single-agent work - Focused task without multi-phase coordination
• •Low risk - Failure doesn't cascade to other systems

Keyword Triggers

Goal skill applies when user mentions:

• •"success criteria", "expected outcome", "anti-goals"
• •"how will we know", "verification", "measurable"
• •"root cause", "evidence", "grounded"
• •"what must not happen", "constraints", "guardrails"

Outcome Categories

Every goal has an Outcome Category that determines its workflow:

Identifying the Category

Concrete:

• •Evidence exists showing the problem
• •Measurable criteria can be derived from that evidence
• •Example: "22 mega-clusters exist" → "dissolve 22 mega-clusters"

Agent-to-define:

• •Problem is observed but root cause unclear
• •Need investigation before knowing what success looks like
• •Example: "Performance is slow" → investigate first → then define criteria

Deferred:

• •External blocker prevents progress
• •Document what's needed and wait
• •Example: "Need API access from vendor"

Goal File Format

Goals live in docs/todos/goals/ with this structure:

# [Goal Title]

[1-2 sentence description grounded in evidence]

## Meta

| Field | Value |
|-------|-------|
| Status | pending / investigating / approved / active / done |
| Outcome Category | Concrete / Agent-to-define / Deferred |
| Confidence | HIGH / MEDIUM / LOW |
| Created | YYYY-MM-DD |

## Problem Statement

### Evidence

- [Specific data point 1]
- [Specific data point 2]

### Root Cause

| Field | Value |
|-------|-------|
| Hypothesis | [What we think is causing this] |
| Confidence | HIGH / MEDIUM / LOW |
| Evidence | [What supports this] |
| Gaps | [What we don't know] |

## Success Definition

### Success Criteria

1. [Measurable criterion derived from evidence]
2. [Second orthogonal criterion]

### Anti-Goals

- Must NOT [constraint 1]
- Must NOT [constraint 2]

## Verification Protocol

1. [How to verify criterion 1]
2. [How to verify criterion 2]

## Work Breakdown

(Added when goal is decomposed into tasks)

- [ ] [Task 1](../tasks/task-1.md)
- [ ] [Task 2](../tasks/task-2.md)

Status Values

Anti-Goals

Anti-goals are required for all non-trivial goals. They define what the solution must NOT do.

Purpose

Good Anti-Goals

### Anti-Goals

- Must NOT break legitimate entity linkages (false negatives)
- Must NOT increase processing time by more than 10%
- Must NOT require schema changes to downstream consumers
- Must NOT remove data that valid use cases depend on

Bad Anti-Goals

### Anti-Goals

- Must NOT be bad  ← Too vague
- Must NOT have bugs  ← Aspirational, not measurable
- Must NOT take too long  ← No threshold

Deriving Anti-Goals

Ask these questions:

1. •What would a malicious implementation do to "succeed" while causing harm?
2. •What side effects would make this solution worse than no solution?
3. •What existing functionality must be preserved?
4. •What downstream systems depend on current behavior?

Action Router

List Goals

1. •Read docs/todos/goals/ directory
2. •For each goal file, read Meta section
3. •Display summary:

## Goals

| Status | Goal | Category | Tasks |
|--------|------|----------|-------|
| investigating | [Goal A](goals/goal-a.md) | Agent-to-define | - |
| active | [Goal B](goals/goal-b.md) | Concrete | 2/4 |
| pending | [Goal C](goals/goal-c.md) | Deferred | - |

Goal Status

1. •Read goal file
2. •Display full details including:
   • •Meta (status, category, confidence)
   • •Problem Statement (evidence, root cause)
   • •Success Criteria and Anti-Goals
   • •Work Breakdown progress (if has tasks)

Workflows

Detailed workflows for goal lifecycle:

• •workflows/define.md - Creating new goals with evidence grounding
• •workflows/investigate.md - Agent-to-define investigation protocol
• •workflows/complete.md - Goal verification and archival

Critical Constraints

1. No Work Before Goal Approval

2. Evidence Grounding

Success criteria MUST reference specific evidence:

3. Multi-Dimensional Criteria

Single-metric goals are Goodhart bait. Require orthogonal criteria:

## Success Criteria

1. 22 mega-clusters dissolved  ← Primary metric
2. ownership_concentration fires <25%  ← Secondary measure
3. Top 10 officers are actual owners, not RA services  ← Quality check

4. Verification Separation

The entity that defines success criteria must NOT be the same one that evaluates:

Phase 1: Agent investigates, proposes criteria
Phase 2: User reviews, approves/modifies criteria
Phase 3: Agent implements against APPROVED criteria
Phase 4: Verification against pre-approved criteria (no changing)

Integration with TODO Skill

Goals decompose into tasks. The relationship:

Goal (outcome definition)
├── Success Criteria (what must be true)
├── Anti-Goals (what must NOT happen)
└── Tasks (how to get there)
    ├── Task A → addresses criteria 1, 2
    └── Task B → addresses criteria 3

Tasks reference their parent goal:

## Goal Reference

| Field | Value |
|-------|-------|
| Parent Goal | [Goal Title](../goals/goal-file.md) |
| Success Criteria | Criteria 1, 2 |
| Anti-Goals | Anti-goal 1 |

See /todo skill for task management workflows.