goal_refine
Record a goal's objective after a refinement session to capture what is actually being achieved, so workers can tell whether a feature serves it.
Instructions
Record a goal's objective after a refinement session with the principal. A goal carrying only a name and a priority is a filing label: nothing in it says what is being attempted, so a worker cannot judge whether a feature actually serves it. Do NOT call this mid-discussion — record once, when consensus is reached.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Directory identifying the project and the tree. Defaults to this session's working directory, which in a git worktree is that worktree. | |
| name | Yes | ||
| actor | No | ||
| status | No | ||
| doc_ref | No | Where the objective was lifted from — file plus heading, e.g. "docs/feature_tracking.md#go-live-gates-glg". Record it even when the document was thin, so a later reader can tell a lifted objective from an invented one, and so the next pass reads one section instead of re-grepping the whole file. | |
| priority | No | Lower is worked first. | |
| non_goals | No | What is deliberately excluded. The part people skip and the part that matters: goal drift is rarely someone pursuing the wrong objective, it is someone pursuing a defensible neighbouring one. | |
| objective | No | What is actually being achieved, in the principal's terms, not the code's. | |
| rationale | No | Why it matters, and what happens if it is not done. | |
| done_means | No | How anyone can tell the goal is finished rather than merely worked on. | |
| constraints | No | What must hold — budget, latency, compatibility. |