feat(goal): support guided goal authoring#839
Conversation
The skill told the model to print '/goal <objective>' text for the user to paste rather than starting the goal itself, so an approved draft never became an active goal until the user manually invoked the tool. Once the user approves the wording, call CreateGoal directly; a final confirmation still runs before the goal begins.
The contract template, examples, and stop rule all told the model to add a turn cap, so it baked 'stop after N turns' into objectives and set a budget unprompted. Drop the default cap, separate the honest stop/blocked rule from spending limits, and add guidance to suggest a budget only when useful, framed on token cost, and to warn on oversized values.
turnWorker read goal status once at turn launch and only handed off to the continuation driver when the goal was already active, or was paused/blocked and resumed. A goal created mid-turn via the CreateGoal tool became active during an ordinary turn, so the driver never engaged and the run stopped after the turn that started it. Broaden the post-turn gate to drive whenever the goal is active after a clean turn.
A model-issued CreateGoal showed a plain Approve/Reject prompt, so an approved goal began under whatever mode happened to be active. Mirror the ExitPlanMode pattern: a new goal_start display kind carries the objective and current mode, a dedicated ask policy intercepts CreateGoal in manual/yolo and applies the chosen permission mode before the goal is created, and the TUI approval panel renders the same auto/yolo/manual/ decline options as the /goal command. auto mode still auto-approves.
CreateGoal and GetGoal serialized the full snapshot, including the random goalId, so the model could echo it to the user as if it were meaningful. No goal tool takes an id, so strip it from the model-facing tool output while keeping it on GoalSnapshot for the TUI/SDK.
The approval panel rendered choices as labels only, so the CreateGoal start menu dropped the per-option descriptions the /goal command shows. Add an optional description to ApprovalPanelChoice, populate it from the shared /goal options, and render it dim beneath the label. Choices without a description render exactly as before.
Add the skill loader and register it alongside the other builtins. The SKILL.md body landed in earlier commits but its wrapper and registration were missed, so the skill was not actually discoverable until now.
|
commit: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2985236ced
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const goalBecameActive = this.agent.goal.getGoal().goal?.status === 'active'; | ||
| if ( | ||
| resumedFromPausedOrBlocked && | ||
| currentGoalStatus === 'active' && | ||
| goalBecameActive && |
There was a problem hiding this comment.
When CreateGoal makes a previously non-goal turn active, this broadened branch now enters driveGoal after runOneTurn(..., true) has already cleared activeTurn. The continuation loop then runs with hasActiveTurn === false, so user steering can launch a concurrent turn and cancel() cannot abort the original controller/signal for the autonomous goal run. This affects the new guided/model-authored goal path; keep the active turn alive (as the already-active goal path does) before starting these continuations.
Useful? React with 👍 / 👎.
1 participant
Summary
Adds a
write-goalbuiltin skill that helps users turn a rough intention into a well-specified/goalobjective, and fixes the goal-mode machinery so a model-authored goal actually starts and runs end-to-end. Together these make "help me write and start a goal" a smooth, guided flow.What's included
The
write-goalskillcustom-theme,update-config) teaching how to write good goals as a completion contract: end state, proof, boundaries, iteration loop, and an honest stop/blocked rule — distilled from real public/goalcases.CreateGoaldirectly (rather than printing paste-text).Goal-mode fixes that make model-initiated goals work
CreateGoalnow drives continuation turns instead of stopping after the turn that created it. PreviouslyturnWorkeronly entered the driver for goals already active (or paused/blocked) at turn launch.CreateGoalapproval reuses the same menu as/goal(Switch to Auto / YOLO / Start in Manual / Don't start), applying the chosen permission mode before the goal is created. Mirrors theExitPlanModepattern via a newgoal_startdisplay kind + a dedicated ask policy.automode still auto-approves.descriptiononApprovalPanelChoice), so theCreateGoalmenu shows the same descriptions as/goal. Choices without a description render exactly as before.CreateGoal/GetGoalno longer serialize the internal goalId to the model, so it can't echo a meaningless UUID to the user. The id stays onGoalSnapshotfor the TUI/SDK.Testing
agent-corefull suite green; new tests for the mid-turn continuation, thegoal-start-review-askpolicy, the goalId redaction, the approval adapter menus, and the panel description rendering.agent-core,kimi-code, andprotocoltypecheck clean; lint clean on changed files.Note for reviewers
Non-TUI approval clients (e.g. ACP) receive the new
goal_startdisplay kind and fall back to generic rendering, same asplan_review. First-class handling there would be a follow-up.🤖 Generated with Claude Code