tower-goal

name	tower-goal
description	Enter "unattended goal mode" mid-run — set a goal and let the current task run toward it on its own, pushing blockers/decisions to the human (via tower-ask) when stuck so nothing is lost while you're away. Activate when the user says things like "/tower-goal", "start the loop", "go unattended", "I'm leaving, let it finish on its own", "set a goal and run autonomously", or "run it while I'm away".

tower-goal — unattended goal mode (activated at run time)

A plain goal's flaw: it stalls the moment it gets stuck, and with nobody watching it just dies unnoticed. tower-goal fixes that gap — run toward the goal on your own, and when you hit a wall push a message to the human via a channel; if they're away, park and wait, and pick up when they reply.

This skill lets you switch into the mode partway through a run (e.g. the user says "finish this, I'm leaving"). Unattended isn't a property of the task or something the backend decides — the user activating this skill IS the judgment and the authorization.

Activation = authorization

The user activating tower-goal = authorizing you to do whatever the goal needs, in this task, without asking step by step:

• You may create tasks: if the goal is large, use Tower MCP (create_task) to split it into child tasks and dispatch them.
• You are the hub: when a child task finishes, its stop hook pushes back to this parent task automatically (you receive its result as a new message); you schedule / dispatch the next step from that. Child tasks don't worry about unattended themselves — you're unattended, so the whole chain is unattended: they just execute what you dispatch, push problems back to you, and you (the hub) decide whether to ask the human via tower-ask.
• You may use any capability in service of the goal (edit code, create tasks, query the knowledge base, orchestrate the hub…).

The only hard boundary is under "Iron rules" below — risky/irreversible actions still need sign-off first.

Activation = commitment

On activation the user gives you a goal ("finish the login refactor"). Note it, then:

1. Self-check the channel FIRST (before flipping any flag)

tower-goal is the "off-hours, reach the owner" case, so it uses the unattended channel class. Call list_notify_targets({ scope: "unattended", taskId }) (taskId = env TOWER_TASK_ID) to confirm an active channel exists:

• Present → note the gateway/downstream, continue to step 2.
• noChannelConfigured: true → tell the user "before running unattended, please configure a channel under Settings → Notifications → unattended column and mark it active, otherwise I can't push out when I hit a wall", and do NOT enter the mode (do not call set_goal_mode).

2. Set the goal-mode flag (only once a channel exists)

Now call set_goal_mode(taskId, true). It marks this task as goal mode and persists it — so even if your context is later compacted, or park/resume/a new session makes you "forget you're looping", list_notify_targets still resolves the default channel to unattended (reach the owner), and you won't misroute or fail to send when you hit a wall.

The flag is auto-cleared when the task leaves the active loop (you Stop the terminal, or the task moves to DONE/CANCELLED/IN_REVIEW), so you rarely close it by hand.

3. Advance autonomously, silently

Work toward the goal; decide anything you can decide yourself. Don't report progress proactively — not even milestones; run quietly. Only speak up in the two moments below.

4. Speak up only when "stuck" or "done"

On these two cases, use the tower-ask skill (scope: "unattended") to push a message to the owner and park. For Hermes/OpenClaw-backed channels this means push_to_human(..., expectReply: true). Stop after the park (terminal stays open; task status untouched):

• Truly stuck: a decision that needs the human, missing key info, an ambiguous requirement, or sign-off before a risky/irreversible action (drop a DB, force-push, publish externally — required even if the terminal has permissions wide open).
• Goal reached: push the result + wrap-up to the human, then likewise ask_human park and stop.

5. Reply → continue; no reply → leave it

• Human replies → the platform bridge injects it via reply_to_ask as your next message → continue per the reply.
• No reply → it just stays parked, harmless (recorded in the /harness panel, unconsumed). The user will handle it themselves; don't poll, don't nag.

Iron rules

• All outbound goes through tower-ask: every "send a message to a human" in goal mode follows tower-ask's rules. Hermes/OpenClaw use push_to_human (send + record/park atomically).
• Sign-off via ask_human before any risky/irreversible action, no exceptions.
• End your turn immediately after calling ask_human — don't keep working; it parks the task and closes the terminal to save resources, and resumes automatically when the human replies.
• Don't change task status or close the terminal on your own — even "done" just parks and stops; let the user review/close it.
• taskId comes from env TOWER_TASK_ID.

One line

Run silently toward the goal; when stuck or done, push to the human via tower-ask and park; reply → continue, no reply → leave it.