Record a session goal as a dated file with items plus evidence, keep its status current, then answer "what's left" in under 100 words: achieved, parked, still open. Use when the user states a session goal, asks what's left, what's outstanding, what's still open, whether the goal is met, are we done, where the session got to. Also use to park an item, to promote an overgrown goal into a plan, to close a goal out.
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Write down the one thing this session is for, keep it honest as work lands, and answer "what's left" without reconstructing it from memory.
An unevidenced status is worse than no status. A goal claiming an item is done, with nothing anyone can point at, turns an open question into a false answer and the reader stops checking. Trade convenience for provability everywhere.
Keep trust asymmetric. Close work done inside the repository yourself, since anyone can re-check it. Leave work that left the repository for its owner to close.
create-context-file instead.done. Park unconfirmed outside work at awaiting.promoted. Never as completed.Run the clarity test first. Use socratic-method for a goal with no verifiable end state,
and guided-interview when its items hinge on an unmade choice. Otherwise draft it:
./scripts/goal.sh new "Rotate the exposed token and unblock Phase 1"Pass --session <id> (or GOAL_SESSION) when conversations share the repository.
Check the draft with the user. Start work only once they confirm or correct it.
Set goal-status: in-progress on the first item to gain evidence. Write that evidence in the
same turn the item closes. Add a dated log line on every change, and save the file in that
turn where the next session reads it, such as the main branch. Keep discovered work as a
follow-up unless the end state is unreachable without it.
Run park, then file what it prints:
./scripts/goal.sh park 3 "Andy is on leave until Monday"Run status and report its summary verbatim. Offer the path; never expand it:
$ ./scripts/goal.sh status
Next: Finish Phase 1 steps 4 to 8
Goal: Rotate the exposed token (in-progress, 1 of 3 done).
Awaiting your confirmation: Send both drafts to Andy.
File: goals/2026-09-14-rotate-the-exposed-token.mdPromote on any trigger: more than five items, a second worktree, or wave structure. Pass the
end state and items to plan-create, carrying existing evidence across as completed tasks.
Close out only when the check exits zero:
./scripts/goal.sh checkKeep the goal active on a wrap-up with items open. Write a handover with
handover-document-creator and link it from the log.
NEVER start work on a goal the user has not confirmed. WHY: the goal is then the agent's reading of the request, and every later "what's left" answer inherits the misreading.
NEVER close an outside-reach item on your own observation. WHY: a tool call can succeed while the world disagrees, and nothing re-checks it later.
BAD | 1 | Raise the P1 ticket | done | outside | ticket created successfully |
GOOD | 1 | Raise the P1 ticket | awaiting | outside | PROJ-4821, needs your confirm |NEVER defer evidence to a later turn. WHY: the intention does not survive a context reset, and the row then reads as deliberately evidenced.
NEVER admit discovered work by default. WHY: a goal that absorbs everything never closes, and "what's left" decays into a second backlog.
NEVER paraphrase the rendered summary. WHY: the cap and the ordering are the product.
NEVER mark a promoted goal completed. WHY: promotion means too large, not finished.
Keep the two status fields paired:
status: active # done once goal-status is completed or promoted
goal-status: new # new | in-progress | completed | promotedThen confirm each of these:
status: active.done item has evidence; every outside one cites a dated user confirmation../scripts/goal.sh check --session <id> exits zero. Run it before flipping the goal to status: done; once closed, it still checks the session's latest goal, but an un-scoped check has nothing active to inspect.pantheon-org/tekhne
c8416e9
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.