stack/skills/ms-proactive-agent/SKILL.md

name, description

name	description
ms-proactive-agent	Continue an authorized Mosaic assignment through planning, execution, verification, and recovery while useful work remains. Use for ongoing work and continuation requests, not to turn a question or review into an open-ended mission.

Proactive Agent

Complete the authorized outcome, not just the first task. At each meaningful checkpoint, select and execute the next necessary action in the same turn while scope, authority, dependencies, and budget permit. A plan, task dispatch, or status report is not completion.

This skill governs work selection. ms-goal governs durable goal state, pause/resume, and completion; load it when establishing or recovering a continuing assignment. The dev Stack does not yet integrate the /goal extension. Neither skill creates a scheduler, background process, tool, or automatic follow-up turn.

Establish execution context

Before writing state or choosing work:

1. Resolve the assignment from the user request, launch context, and applicable repository/mission instructions. Record agent identity, workspace root, project if declared, and execution/session identifier if supplied. Mark unavailable identifiers as unavailable; do not infer a workspace from the agent's identity.
2. Locate the authoritative goal, tasks, approvals, and recovery checkpoint. Use existing declared paths. For example, this skill's source repository uses docs/plans/CURRENT.md for queued project work; an explicit user request can authorize a separate bounded task. Do not advance unrelated queued phases or overwrite their owner-controlled records. Fleet paths and a seat's general purpose are not default assignments.
3. Check writable state locations and required tools. Discover communication, claim, and wake mechanisms when needed. Optional reporting or watch skills must not block ordinary local work. If a required capability is missing, record the precise limitation and continue independent authorized work where possible. If ms-goal is unavailable, use an existing authoritative goal protocol; do not fabricate its tools or claim durable continuation without accessible records.
4. Identify ownership. Use the coordinator's claim operation when provided. A Markdown owner field is not a lock. Without enforced claims, work only under an established single-writer assignment; conflicting ownership stops the affected task.

Explicit scope and authorization persist. Do not ask again for routine actions already covered by them. Role capabilities constrain execution; they do not authorize a new mission, another owner's work, or new external communications. Preserve phase approvals, acceptance ownership, and budget limits. Silence, task creation, and elapsed time grant no additional authority.

Run the loop

Run on assignment start/recovery, a substantive checkpoint, an actionable message, or a matching wake event. Bookkeeping tool results and reports do not recursively trigger it.

1. Reconcile and record. Read relevant current records and verify the live fact needed for the next action. Preserve unrelated changes. Resolve actions with unknown outcomes before retrying them. Persist changed task status, evidence, and obligations before reporting; do not rewrite unchanged state merely to manufacture activity.
2. Check control state. Follow ms-goal. Paused or canceled work does not resume on an ordinary tool result, compaction, or unrelated message. Apply user steering promptly; a status question does not cancel work. Reconcile scope changes with remaining tasks before executing them.
3. Select useful work. Finish an owned in-flight task that can proceed, then an owned blocker you can resolve, then ready assigned work. Claim other necessary work only within delegated assignment authority. Respect dependencies and explicit priority; prefer smaller reversible steps when candidates otherwise have equal priority.
4. Fill a planning gap. If an acceptance criterion is unmet and no task covers it, decompose the authorized outcome into bounded tasks with dependencies and evidence requirements, record them, and take the first ready task. A new goal can start with an empty queue. Necessary fixes and verification belong in scope; unrelated improvements remain proposals. If decomposition exposes a new scope decision, route it and continue any independent work already authorized.
5. Execute and verify. Take the task to a meaningful checkpoint. Run checks appropriate to its acceptance criteria, inspect the results, and correct in-scope failures. Persist a resumable checkpoint before a risky action, context limit, or handoff. Do not mark a task done because it was started, delegated, or merely produced an artifact.
6. Close communication obligations. Use the procedure below. Update the goal record with the next action and actual evidence. If ready work remains, return to step 1 in this turn. Report significant results without making the report an artificial stop.
7. When nothing can run, classify honestly. Verify satisfaction against acceptance criteria, not queue emptiness. Otherwise record waiting, paused, or blocked with the unresolved gate and exact resumption condition, using ms-goal.

Failure and budget handling

• Diagnose failures before retrying. Retry transient failures only under the tool's documented bounded retry contract or with a concrete changed input. For an uncertain external side effect, reconcile its request/action identifier first.
• Repeated actions producing no new task evidence require a different justified approach or a recorded blocker. An unchanged registered wait is not a failed attempt; it should yield instead of generating more reports.
• Track actual usage when available; label estimates and unavailable measurements. Stay within explicit limits and reserve capacity for verification and a checkpoint. Budget exhaustion pauses work; it does not establish completion. Never reset usage by resuming or splitting a task. Ask for an extension only when one is actually needed.
• If recording fails, preserve recoverable evidence and report the failure. Do not start further effects that require a durable record or claim they were checkpointed.

Communication and waits

For authorized inbound work, record the change and acknowledge the sender through the available approved transport. A reaction or receipt alone does not require another reply. For authorized tasking, handoffs, review requests, or decisions, persist any required artifact before sending its pointer. Durable storage does not necessarily mean a Git commit; follow the repository's commit authority and workflow.

Record request/task id, destination and workspace, exact receipt, expected return event, and follow-up owner. Distinguish drafted, queued, delivered, acknowledged, and completed. Unknown delivery is not permission to resend; reconcile or follow the transport's retry contract. A report to the user is not delivery to another agent. If no transport is available, record the unsent request and route the missing capability to the user.

For a wait, record the last observation, condition that ends it, wake mechanism, and any deadline plus its escalation owner/action. Verify the mechanism exists. An owner name, file entry, or queued draft does not prove that another turn will occur.

• Use existing message delivery for another agent's response. Do not poll its private files or pane. Use an available coordinator's timeout mechanism for overdue requests.
• Use ms-agent-watch only when installed, supported, and authorized, for external conditions with no existing wake owner. Verify a known-false control and the actual condition, distinguishing pending from errors; handle an already-met condition now. Verify registration, bind to the exact resource/version and destination, and record timeout/delivery behavior. Reuse valid existing watches and retire obsolete ones.
• Without automatic wake support, a wait is explicitly manual: state who must send what reply or resume instruction. A deadline is checked on the next invocation unless an actual timer/coordinator owns it. Do not promise unattended escalation or resumption.

Checkpoints and reporting

Persist current task, completed evidence, remaining acceptance gates, next concrete action, outstanding communication/wait records, ownership, budget, and uncertain outcomes in their authoritative records. Keep a compact checkpoint pointing to them; retain unresolved obligations and durable history regardless of checkpoint trimming.

Report what changed, its evidence, what happens next, and any decision needed. Use an installed reporting format only when the applicable environment requires it. No special reporting skill or goal_report tool is required in dev mode. Do not repeat unchanged reports unless asked or a scheduled check produces information that matters.

End normally only at verified satisfaction, explicit pause/cancellation, a genuine blocker, or a registered automatic/manual wait with no ready work. If execution is forced to end while work remains, checkpoint it as incomplete and name the actual resume path; never imply that writing next scheduled that action.

For bounded dev testing, use ms-goal's execution checks.