workbench-goal-mode

Original：🇺🇸 English

Translated

Goal-persistence execution wrapper for autonomous work that must continue across turns until the stated objective is actually satisfied.

4installs

Sourcefearvox/multica-ultimate-workbench

Added on2026-06-02

NPX Install

npx skill4agent add fearvox/multica-ultimate-workbench workbench-goal-mode

SKILL.md Content

View Translation Comparison →

Workbench Goal Mode

Use this skill when an issue contains

/goal

GOAL_MODE: yes

, asks for full autonomous completion, or asks an agent to keep working until a concrete outcome is achieved.

Goal Mode is an execution wrapper, not a permission override. It keeps the objective alive across turns, reruns, local fixes, and partial evidence, while preserving existing approval, safety, and review gates.

Activation

Before changing files or live resources, post a compact lock:

text

GOAL_LOCK:
objective:
owner:
non_goals:
closeout_gates:
operator_call_conditions:

```
objective
```
is the user-visible outcome, not a task list.
```
owner
```
is one assigned agent or human owner.
```
non_goals
```
prevents the agent from expanding into adjacent work.
```
closeout_gates
```
names the evidence required before claiming done.
```
operator_call_conditions
```
names the few cases where human input is needed.

Execution Rules

Build a checklist from the locked goal, then execute it.
Do not stop after a local fix if the broader goal remains unverified.
When a command, build, test, or smoke fails, investigate and repair before asking for help.
Treat repeated identical failures as a mechanism problem: change the probe or report the exact blocker instead of retrying the same action.
Use fresh reruns when context is stale, repo state changed, auth changed, or the previous run was bound to the wrong repo/resource.
Preserve issue-level scope, approval gates, secrets boundaries, and runtime ownership.
```
/goal
```
does not permit destructive cleanup, force pushes, hidden live mutations, broad repo reads, or credential handling.

Required Closeout Gates

For code, ops, or workflow-changing tasks, address every relevant gate before claiming completion:

```
build
```
: documented build or closest real startup/build smoke.
```
test
```
: targeted tests plus the smallest meaningful regression check.
```
help_smoke
```
: CLI help, startup, UI load, or endpoint smoke when command/user surfaces changed.
```
docs_report
```
: docs, changelog, handoff, or explicit "not needed" rationale.
```
git_status
```
: clean state or intentionally explained dirty state.
```
evidence
```
: exact commands, files, links, screenshots, issue IDs, run IDs, or artifact paths.

If a gate does not apply, say why. A skipped gate without rationale is

FLAG

Operator Call Conditions

Call the operator only for true external blockers:

missing credentials or approval that cannot be inferred from the issue;
unavailable third-party service or remote host;
destructive or irreversible operation approval;
repo/resource access failure that cannot be fixed inside the assigned context;
requirement conflict where continuing would change the user's goal.

The blocker report must include attempted fixes, exact evidence, and the smallest operator action needed.

Closeout Contract

Use this scaffold: