/goal

What It's For

Use /goal for work that spans more than one session: a feature, a migration, a refactor with several parts. You agree on the outcomes once. The agent then plans, builds, and tests in its own loop, and each outcome gets an independent review before it's ticked.

Usage

In Codex, use $goal. Only one goal is status: active at a time; others are paused or done. ContextKit's AGENTS.md tells every tool to read the active goal before starting work.

The Goal File

Goals live in .contextkit/goals/<slug>.md. The template is .contextkit/templates/goal.md:

---
status: active
created: [DATE]
---

# Goal: [TITLE]

## Goal

[2–3 sentences: what we're building and why.]

## Outcomes

<!-- Human-owned. 3–7 checkable, user-side results. Change only with the user's OK. -->

- [ ] O1: [A user can …]
- [ ] O2: [...]

## Checks

<!-- Agent-owned. Detailed criteria per outcome, refined while building. -->

- O1: [...]

## Constraints / Non-goals

- [Must not break …]
- [Out of scope: …]

## Open Decisions

<!-- Waiting on the human. Always give options; mark the recommended one. -->

## Changes

<!-- Dated log of every change to Outcomes or Checks, with the reason. -->

## Progress

- **Done:**
- **Next:**
- **Blocked:**

Kickoff

1. The agent reads the project context (AGENTS.md, CLAUDE.md, index.md) and enough code to understand the area.
2. It drafts the goal file: Goal, Outcomes, Constraints and Non-goals.
3. If something blocks a good draft, it asks at most 4 multiple-choice questions per round, recommended option first. Claude Code uses AskUserQuestion, Codex uses request_user_input, and other tools list lettered options so you can reply 1b, 2a.
4. You approve the Outcomes. From then on they only change with your OK.

The Build Loop

The agent works outcome by outcome, in its own loop. No role handoffs.

Re-read goal file (every session, after compaction)
    │
    ▼
Plan → edit → run tests → fix   (repeat)
    │
    ├── internal change to Checks  →  decide, log under Changes
    ├── user-visible change         →  ask first, with options
    │   (scope, UX, dropping or weakening an outcome)
    │
    ▼
Outcome looks done  →  Milestone review  →  commit  →  next outcome

• Every change to Outcomes or Checks is logged: YYYY-MM-DD — O2 check changed: X, because Y.
• Progress stays current so a new session, or a compacted one, can continue.

Milestone Review

When an outcome looks done:

1. Run the project's tests and quality checks.
2. Spawn a review subagent in a fresh context, on the same model. It gets only the goal file path, the outcome ID, and the diff for that outcome, never the builder's own account of the work. It returns pass or a numbered list of problems. Without subagents, the agent reviews the goal file and diff as if someone else wrote it.
3. Problems get fixed and reviewed again, up to 3 rounds. After that, the agent asks you.
4. On pass: tick the outcome, update Progress, and commit, e.g. feat(reports): users can export CSV. Hooks are not skipped.

When every outcome is ticked, the goal is set to status: done and you get a short summary: outcomes, notable changes from the log, and anything skipped.

Install

ck install includes /goal. To use it in projects without ContextKit, install it globally to ~/.claude/skills/, or use the Claude Code plugin:

Why This Replaced Squad

Squad split work across fixed roles with handoff files. Strong models plan, build, and test best in their own loop. What they still need is a durable goal, checkable done criteria, and an independent check. /goal keeps exactly those three and drops the role handoffs.