workbench-goal-mode
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:
GOAL_LOCK:
objective:
owner:
non_goals:
closeout_gates:
operator_call_conditions:
objectiveis the user-visible outcome, not a task list.owneris one assigned agent or human owner.non_goalsprevents the agent from expanding into adjacent work.closeout_gatesnames the evidence required before claiming done.operator_call_conditionsnames 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.
/goaldoes 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:
GOAL_LOCK:
WHAT_CHANGED:
VERIFICATION:
DOCS_REPORT:
GIT_STATUS:
RESIDUAL_RISK:
OPERATOR_NEEDED: yes/no
VERDICT: PASS | FLAG | BLOCK
PASS means the locked objective is achieved and every relevant closeout gate
has evidence. FLAG means useful progress remains reviewable but a gate or risk
is unresolved. BLOCK means the objective cannot be safely completed without an
operator or upstream fix.
More from fearvox/multica-ultimate-workbench
workbench-conductor
Two-ring orchestration, routing, issue and comment discipline, and role boundaries for the Multica Workbench.
5workbench-sdd
Specification-driven development from raw requirement to product design, technical design, task list, execution, and verification.
5workbench-self-awareness-infra
Capability discovery and current-state verification for Heavy Path, ambiguous repo/runtime ownership, and runtime-dependent Standard Path work.
5workbench-design-docs
Product design, technical design documents, user-facing copy, specs, diagrams, and handoff documentation.
5workbench-token-context-discipline
Compact context, cache-aware execution, scoped evidence reads, and role-specific skill attachment discipline.
4workbench-product-brainstorming
Bounded product ideation, workflow design, ambition checks, tradeoffs, and smallest-test shaping.
4