v2.0.3 to v2.1.0

- version: "2.0.3"

- Read **this file only** by default. Load **at most one** reference.

- 3. Determine whether the user or system explicitly requested a Goal action, then pick one Decision from the Auto-Set table and emit one `Goal Gate` block per selected runtime.

- 4. If `set-now`, execute the compact runtime action in the table. Load `references/runtime-actions.md` only when that row is not enough to act.

- 5. Load `references/copy-ready-goals.md` only when drafting a user-copyable prompt. Load `references/examples.md` only when a worked example is needed.

- Do not load two references in the same turn. Do not invent goal APIs.

- Never borrow one runtime's fields for another. If the user explicitly requests both a slash prompt and a tooling action, or requests multiple runtimes, emit one independently usable block per requested runtime.

- Prefer a goal when all are true: the task is larger than one normal turn; it has one durable end state; completion can be verified from evidence the agent can surface in the transcript; the agent can make useful progress without frequent human steering; stop or ask conditions can be stated before work starts.

- Avoid a goal for single-step lookups, typo fixes, small edits, or commit-message work; open-ended exploration with no measurable stopping condition; product or architecture choices that still need `grilling` (Route: Challenge, widening or named-option convergence); destructive, irreversible, billing, auth, production-data, or schema-breaking work before explicit human approval; a loose backlog of unrelated tasks.

- - Destructive, irreversible, billing, auth, production-data, or schema-breaking action whose concrete scope is not yet authorized. Check the action and existing approval, not domain keywords alone: read-only diagnosis and explicitly authorized isolated local tests can proceed. Prior approval applies only to its stated paths, environment and effects; a new production target, security change or expanded effect needs its own gate.

- - A goal is already active **and** the new objective conflicts with it, or the user has not chosen how to handle it. Never replace or mutate that goal silently; ask whether to continue, complete, block, pause, clear, or replace it, and emit `Decision: defer`. Same-Goal management includes both an exact objective match and a contained checkpoint when the active Goal's objective, frozen scope, and Done condition explicitly include that checkpoint and the user already authorized the parent pipeline. Verify this relationship from evidence; compatible containment never permits scope expansion or narrowing the parent's Done condition.

- - The objective still needs a design or scoping decision that `grilling` (Route: Challenge, widening or named-option convergence) should resolve.

- - Verification cannot run, so completion could never be proven from evidence.

-

- The gate exists because an auto-started goal hands the agent a long leash. That leash is only safe when the end state is reversible-or-approved, unambiguous, and checkable. When in doubt, fall back to `suggest` — the cost of asking once is small next to a goal that runs off in the wrong direction.

-

- High-risk work can still receive a goal draft, but the draft must be discovery-first or approval-first. Do not present a production write, destructive migration, auth rewrite, billing change, or regulated-domain decision as an immediately executable action.

-

- ## Goal authorization

-

- Creating, replacing, completing, or blocking a native product Goal is a separate state change from doing the underlying task. Treat it as authorized only when the user or system explicitly asks to use, set, create, continue, complete, or block a Goal; invokes `$goal-gate` or `/goal-gate`; or invokes a parent workflow whose declared contract explicitly owns a Goal. A merely large, autonomous, or high-fit task does **not** authorize `create_goal`, `update_goal`, or a user-run `/goal` by itself.

- When work is authorized but native Goal state is not, adopt the checkable contract in the current transcript and continue the work. Report `Decision: suggest` with `Next: adopt goal and continue`; do not stop for a redundant approval round and do not claim product Goal state became Active.

- ## Auto-Set

- When the safety gate is clear and goal fit is `high`, start the authorized work under a transcript contract. This does not by itself authorize native Goal state. For `medium` fit, suggest the contract without creating native Goal state; continue already authorized task work while the user considers it. Goal fit is not a second permission gate for the underlying work. `low` fit is `none`.

- Native `set-now` requires explicit Goal authorization or an already-authorized exact-same / compatible-contained continuation. A high-fit task without that authorization uses `suggest` plus `adopt goal and continue` on a native-capable runtime; transcript-only runtimes may use `set-now` because no product state is mutated. Both start the task without claiming a native Goal became Active. A contained checkpoint reports progress but leaves completion to the parent Goal owner. Same-goal complete/block uses `Next: report via update_goal` only after its terminal preconditions are proven. If an active goal conflicts with a new objective or the desired action is unclear, emit `Decision: defer` and ask; never call either runtime's completion action or tell the user to clear a goal merely to make replacement convenient.

- | Explicit Goal action, high fit, safety clear | `set-now` | Runtime action below |

- | Runtime | Next | Do now |

- | -------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

- | `cursor-cli` | `adopt goal and continue`; same-chat resume → `continue adopted goal` | No `/goal`. No `get_goal` / `create_goal` / `update_goal`. Work in this chat; report evidence in the transcript. Resume commands restore chat context only (see Runtime Detection). Prompt-only → `suggest` / `provide prompt` with a plain prompt. Ask/Plan are read-only — surface the mode constraint instead of claiming writes started. |

- | `grok-tooling` (not Active, explicit Goal) | `wait for user /goal` | Emit the block and a full copy-ready `/goal` first, then **stop**. No implementation. No `update_goal`. `/goal-gate` ≠ `/goal`. Without explicit Goal authorization → `suggest` / `adopt goal and continue`, still no `update_goal` until Active. |

- | `grok-tooling` (Active, same/contained) | `continue active goal` | Work the contract. Checkpoint with Grok `message`. Do not emit a second `/goal`. Do not invent `create_goal` / `get_goal`. `completed: true` only after the full parent Done condition is proven. |

- | `grok-tooling` (Active, Done proven) | `report via update_goal` | Grok `completed: true` plus a concise evidence `message`. Never Codex `status`. |

- | `grok-slash` | usually `provide prompt` | Copy-ready `/goal`. Soft-adopt only if the user also authorized execution without durable mode. |

- | `codex-tooling` (no active, explicit Goal) | `create goal` | `get_goal` then `create_goal` with the `Objective`. No token budget unless the user asked. Without explicit Goal authorization → `suggest` / `adopt goal and continue`; do not call `create_goal`. |

- | `codex-tooling` (same/contained, not done) | `continue active goal` | Keep working. No `create_goal`, no replacement, no terminal `update_goal`. A contained checkpoint cannot complete the parent. |

- | `codex-tooling` (Done proven / 3-turn block) | `report via update_goal` | Codex `status: "complete"` after evidence, or `status: "blocked"` only after the same blocker persists ≥3 consecutive goal turns. Never Grok `message` / `completed` / `blocked_reason`. |

- | `claude-code-slash` / `codex-slash` | `adopt goal and continue` | Self-adopt and keep working. Still emit `/goal` for reuse. Claude: surface verification in the transcript — the evaluator does not independently read files or run commands. |

- | `unknown` | `ask approval` | Portable contract only. |

- Why an explicitly requested Grok Goal waits: Codex `create_goal` can activate from the agent; Grok cannot. A false Active session is what produces `Goal is not Active` failures.

- For any prompt or contract that a user may copy, make the first executable draft complete. Do not leave placeholders such as `[path]`, `TODO`, or `TBD` unless the user explicitly asked for a template.

-

- A strong goal includes: one concrete outcome; verification evidence (commands, logs, screenshots, files, URLs, API checks, artifact paths); constraints that protect unrelated behavior, data, secrets, default branches, and public contracts; write boundaries and forbidden paths; an execution strategy that assesses whether subagents help without weakening ownership or verification; bounded iteration; a done condition that proves completion; pause conditions for credentials, payments, production data, destructive actions, legal/medical/financial judgment, copyrighted assets, unclear ownership, or repeated blockers.

-

- For Chinese-first users, write the primary copy-ready prompt in Chinese. Keep the executable command prefix `/goal` only for verified slash runtimes; for Cursor CLI, provide a plain prompt without `/goal`. Include a concise default reason when you made assumptions. Add numbered options only when a choice would materially change scope, risk, or direction. Include an English-compatible mirror only when the user asks for portability, English, Claude/Codex cross-use, or a complete bilingual draft.

-

- For unfamiliar or specialized domains, do not invent domain rules. Write a discovery-first goal that makes the agent inspect project docs, sample data, official references, and runtime evidence before implementation.

- ## Delegation Policy

- For every executable goal, require the main agent to assess the execution strategy before implementation. Judge task complexity together with dependency order, shared context or state, write overlap, output volume, independently verifiable subtasks, coordination cost, and runtime support. Do not delegate merely because a task is large.

- - Prefer one agent for quick targeted changes, tightly coupled work, sequential dependencies, or work that needs frequent shared-context refinement.

- - Consider subagents for bounded self-contained tasks, high-volume read-only research or test/log analysis, or two or more independent problem domains.

- - Parallelize only when tasks have no sequential dependency, shared mutable state, or conflicting write surface.

- - Prefer an installed orchestration skill when one fits, such as `subagent-driven-development` for independent tasks in an implementation plan or `dispatching-parallel-agents` for independent problem domains. Treat these as optional capabilities, not hard dependencies.

- - Keep the main agent accountable for the aggregate goal: pass down relevant constraints, review returned work and diffs, resolve conflicts, and run final integration verification. Subagents must not broaden scope or declare the whole goal complete.

- - Fall back to single-agent execution when subagents are unavailable or their coordination cost exceeds the expected benefit.

- If a slash-runtime `/goal` is saved to a file or the user asks to validate one, run `scripts/lint-goal-prompt.py <file>` and fix any missing labels, placeholders, unsafe vague wording, or thin verification. The linter is not for Cursor CLI's plain prompt: apply `references/copy-ready-goals.md` § Quality Checks directly, and never add `/goal` merely to satisfy the script.

- Emit this block:

- - Execution strategy: <how to assess single-agent vs delegated vs parallel execution, or n/a>

- Keep the block concise. If the prompt is longer than one short line, put `Prompt: see Recommended /goal below`, then emit the copy-ready prompt immediately below the block.

-

- On Grok when `Next: wait for user /goal`, put the copy-ready `/goal` first in the user-visible reply (right under the block), then stop.

- When emitting a copy-ready prompt for a Chinese-first user, use this order as needed:

- 1. `推荐执行版（中文，可直接复制）`

- 2. `默认选择理由`

- 3. `可选调整`

- 4. `你可以直接回复`

- 5. `Goal Draft (English-compatible)` when requested or useful for portability

- Every executable copy-ready prompt must include an `执行编排：` or `Execution strategy:` line that carries the Delegation Policy. Keep it shorter than the task-specific outcome and verification unless delegation is the main risk.

- `workflow-gate` is optional. If a `Workflow Gate` block is available:

-

- - Treat `Route: Plan`, `Route: Architecture` with `architecture-hardening-loop` plus explicit implement/harden intent, long-running `Light + systematic-debugging`, and broad `verification-before-completion` as stronger goal-fit signals.

- - Treat unresolved `Route: Challenge` as `Decision: defer`, `Goal fit: low`, and finish the thesis/spec decision first. Treat diagnose-only `Architecture` without an explicit goal request as `Decision: none`, `Goal fit: low`, and preserve stop-after-report. Re-evaluate after Challenge resolves or an architecture report becomes a scoped implementation. `Route: Direct`, small `Light`, and `Review-Handoff` are otherwise weaker signals unless the user explicitly wants a compatible goal.

- - Preserve `workflow-gate` as the workflow router; do not rewrite its route.

-

- If the user is actually asking which workflow to use, emit `Decision: defer` and `Next: route elsewhere`.