144 lines
9.3 KiB
Markdown
144 lines
9.3 KiB
Markdown
---
|
|
name: ms-proactive-agent
|
|
description: 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](../ms-goal/SKILL.md) 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-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](../ms-goal/references/execution-checks.md).
|