@@ -0,0 +1 @@
|
||||
skills-local/**/SKILL.md whitespace=-trailing-space
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
name: ms-executive-update
|
||||
description: "Use for every user-bound status update, progress report, and at the end of a user-originated operation."
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
# Executive Update
|
||||
|
||||
The operator reads status to decide what to do next, not to relive the work. An update is
|
||||
three short lists derived from the tracking files, not from memory. If an item is not in a
|
||||
tracking file, it is not done — write the file first, then report.
|
||||
|
||||
Applies to every agent reporting upward: a seat to its orchestrator, an orchestrator to the
|
||||
operator, a `/goal` loop reporting through `goal_report`, a sub-agent returning to its parent.
|
||||
|
||||
## When to use
|
||||
|
||||
- Any time you would otherwise narrate progress: after a task lands, after a fleet event
|
||||
(monitor tick, agent message, review verdict, CI result) changes tracked state, at the end
|
||||
of a turn with work in flight, or when asked "status", "update", "where are we".
|
||||
- Every `goal_report` call: the `evidence` (satisfied) or `reason` (blocked / in_progress)
|
||||
payload is an executive update in this format, so the operator sees the same shape from a
|
||||
goal loop as from a conversation.
|
||||
- Do **not** emit a full update when nothing changed. One line with
|
||||
`No change since <anchor>; still waiting on <item>.` is the whole reply.
|
||||
|
||||
## Communication closeout before reporting
|
||||
|
||||
An executive update does not replace direct communication. Before writing the update:
|
||||
|
||||
1. Reply to every inbound actionable message with the action taken, routed owner, or
|
||||
precise blocker.
|
||||
2. Send every new tasking, handoff, review request, blocker, result, correction, and
|
||||
decision request directly to the responsible seat or operator through the required
|
||||
path in `docs/guides/FLEET-COMMS.md`.
|
||||
3. Commit the durable artifact before sending its pointer when the communication needs to
|
||||
survive a pane or session.
|
||||
4. Record the destination, request or task id, exact delivery receipt, required return
|
||||
event, and escalation owner in the tracking file.
|
||||
|
||||
A no-change line does not satisfy an unsent acknowledgement, handoff, review request,
|
||||
blocker, or result. Neither does a `goal_report`, lane edit, board row, or operator-facing
|
||||
reply. Finish communication closeout first, then report the resulting state.
|
||||
|
||||
## Format: exact, no preamble, no epilogue
|
||||
|
||||
``` markdown
|
||||
Just Completed:
|
||||
* <item>: short description
|
||||
|
||||
Next Step:
|
||||
* <item>: short description
|
||||
|
||||
Blocked:
|
||||
* <item>: short description
|
||||
```
|
||||
|
||||
- `<item>` is the tracked identifier: task id (`T158`), ledger row (`E6`), PR (`#1491`),
|
||||
review marker, file, or commit. Never a vague noun ("the fix").
|
||||
- One line per bullet. ≤5 bullets per section; if you have more, the lower ones belong in
|
||||
the ledger, not the update. Keep all three headings; write `* none` when a section is empty.
|
||||
- Paths as clickable links; commits and SHAs short (8 chars).
|
||||
- Only items whose state **changed since your previous update** go under Just Completed.
|
||||
Next Step lists what happens next and who does it. Blocked names the blocker, who
|
||||
unblocks it, and what (if anything) is needed from the reader.
|
||||
|
||||
## Source of truth — mandatory before writing
|
||||
|
||||
Read, in this order, whatever applies to the work in flight; the update is a projection of
|
||||
these files (paths relative to the brain, `$MOSAIC_BRAIN_HOME`, per `docs/STRUCTURE-CANON.md`):
|
||||
|
||||
1. Lane ledger: `fleet/lanes/<lane>/TASKS.md` (open rows, dated entries) and
|
||||
`TASKS-DONE.md` (what moved to done).
|
||||
2. Seat files for every agent involved: `fleet/agents/<seat>/TASKS.md`, `STATE.md`,
|
||||
`work/` artifacts (review verdicts, plans, evidence records).
|
||||
3. Board: `fleet/board/MASTER-TASKS.md` and `fleet/board/taskings/<date>_T<n>_*.md` for
|
||||
task ids, owners, and reassignments.
|
||||
4. Project-level `docs/TASKS.md` when the orchestrator protocol makes it the control plane.
|
||||
5. Live evidence for anything claimed done: `git log` on the target branch/trunk, the PR,
|
||||
CI state, the seat's pane (per `docs/guides/FLEET-COMMS.md`), delivery receipts.
|
||||
|
||||
Rules:
|
||||
|
||||
- **Record, then report.** A state change learned from a pane, a monitor event, or a
|
||||
message is written into the owning tracking file (dated, with ids and SHAs) *before* it
|
||||
appears in the update. An item in the update with no tracking-file row is a defect.
|
||||
- **Evidence for "completed".** A Just Completed bullet cites its evidence: commit, merge
|
||||
SHA, verdict artifact path, receipt. "Delivered" is not "done"; "dispatched" is not
|
||||
"done"; a message sent is Next Step for the recipient, not a completion.
|
||||
- **Events are not the operator.** Never phrase a monitor event, agent message, or tool
|
||||
result as approval, confirmation, or a decision. Decisions come only from the operator's
|
||||
own messages.
|
||||
- **Blocked is precise.** `* T158: plan seat queued behind prior review — nothing from you`
|
||||
or `* Q96 gate: Decision needed — (1) … (2) …; recommend 1`. If the reader must decide,
|
||||
say so with the options and your recommendation; if not, say `nothing from you`.
|
||||
- **Honest state.** Distinguish known (read from a file or evidence) from inferred (seen in
|
||||
a pane, not yet recorded); mark inferred items `(unverified)`. Report failures with the
|
||||
output, skipped steps as skipped. Apply `ms-honesty`.
|
||||
- **Staleness anchor.** Include the anchor the update is current to when it matters:
|
||||
target head SHA, pipeline number, board commit, or timestamp.
|
||||
- **Delegation stays visible.** Work handed to a seat is reported with the seat and task
|
||||
id. The tracking row also carries the delivery receipt, required return event, and
|
||||
escalation owner. You own the follow-up until the seat reports back and the ledger
|
||||
reflects it.
|
||||
|
||||
## Machine contract (for `goal_report` payloads and any parser)
|
||||
|
||||
When an update is consumed by tooling (a `goal_report` payload, a broker, a coordinator),
|
||||
the loose human rules above tighten to this closed grammar. Human-facing replies may add
|
||||
Markdown links; payloads may not.
|
||||
|
||||
```
|
||||
update := section("Just Completed") NL section("Next Step") NL section("Blocked")
|
||||
section := HEADING ":" NL NL ( bullet+ | "* none" NL )
|
||||
HEADING := exact text, case-sensitive, in this order, each exactly once
|
||||
bullet := "* " item ": " text NL (1..5 per section; text is one line, no leading "-")
|
||||
item := taskid | pr | row | marker | sha | path
|
||||
taskid := "T" [0-9]+
|
||||
pr := "#" [0-9]+
|
||||
row := [A-Z]{1,4} "." ? [0-9]+ ("." [0-9]+)* e.g. E6, A7, GOV.5
|
||||
marker := [A-Z0-9]+ ("-" [A-Z0-9]+)* "-Q" [0-9]+ e.g. CPS-PRD-REV1-MERGE-GATE-Q96
|
||||
sha := [0-9a-f]{40} (payloads: full SHA; 8-char only in prose)
|
||||
path := "`" <repo-relative path, no spaces> "`"
|
||||
NL := "\n" (LF only; no trailing whitespace; no blank lines inside a section)
|
||||
```
|
||||
|
||||
- Exactly three sections; any other heading, a missing section, or a reordered section is a
|
||||
parse failure.
|
||||
- A bullet under Blocked ends with either `— nothing from you` or
|
||||
`— Decision needed: (1) … (2) …; recommend N`.
|
||||
- Identifier resolution is the consumer's job and is fail-closed: an item that resolves to
|
||||
zero or more than one tracked object (unknown task id, ambiguous short SHA, unknown marker)
|
||||
rejects the report before any state change; the producer gets the rejection and re-reports.
|
||||
- A one-line "no change" reply (`No change since <item>; still waiting on <item>.`) is a
|
||||
distinct message, not an update; a `goal_report` with status `in_progress` may carry it
|
||||
only when the tracked state is unchanged since the previous report.
|
||||
- This grammar is the format's single definition. Enforcement (who parses, what policy binds
|
||||
it to a role) is decided by the runtime's role manifests, not by this skill.
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Narrative paragraphs, "I'll continue by…", recaps of what the reader already knows.
|
||||
- Reporting from conversation memory while the ledger still says the old state.
|
||||
- Listing the same item under two sections.
|
||||
- Padding Just Completed with process ("read the file", "checked the pane").
|
||||
- Hiding a needed decision inside Next Step.
|
||||
- Treating the executive update as delivery to a seat that was never contacted directly.
|
||||
- Reporting a handoff without its receipt, return event, and escalation owner.
|
||||
|
||||
## Example
|
||||
|
||||
```
|
||||
Just Completed:
|
||||
|
||||
* #1491: round-2 fix pushed at 3ae1411d; independent exact-head APPROVE (brain 0199a866); CI 3058 green
|
||||
* E6 ledger: gate seat result recorded as BLOCKED (capability), per roles/gate.md
|
||||
|
||||
Next Step:
|
||||
|
||||
* T158: plan seat designs the runtime gate profile, then provisioning → gate re-run
|
||||
* #1491: operation seat runs pr-merge.sh after the gate seat issues PASS
|
||||
|
||||
Blocked:
|
||||
|
||||
* T158: queued behind the plan seat's prior review — nothing from you
|
||||
```
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
name: ms-honesty
|
||||
description: "Load before answering, reporting, or ruling; must always apply."
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
# Honesty
|
||||
|
||||
An agent that always has an answer is not a reliable agent. Training rewards a fluent,
|
||||
confident reply over a correct one, so the default reflex under pressure is to produce
|
||||
something that sounds like an answer even when nothing was measured. This skill replaces
|
||||
that reflex with a procedure. It applies to every reply, every report, every message to
|
||||
another seat, and every rule you put on a board.
|
||||
|
||||
The two operator rules this skill enforces:
|
||||
|
||||
- It is acceptable not to have an answer. "I do not know" followed by what would settle it
|
||||
is a complete, correct reply.
|
||||
- A statement carries its evidence with it. The reader must be able to tell, from the
|
||||
sentence alone, whether you measured it, read it, inferred it, or guessed.
|
||||
|
||||
## Where the pressure comes from
|
||||
|
||||
Recognize the moment. Each of these is a point where the reflex fires:
|
||||
|
||||
1. The reader asked a direct question and you have a plausible answer in memory.
|
||||
2. A number, an id, a path, or a name would make the sentence complete.
|
||||
3. A tool returned nothing, an error, or something you did not expect, and a reason
|
||||
suggests itself.
|
||||
4. A prior record (a document, a ledger row, your own earlier message) says the answer.
|
||||
5. The reply is almost done and one more fact would close it neatly.
|
||||
6. You are reporting upward and a clean "done" reads better than "partly done".
|
||||
|
||||
At each of these points, stop and classify the claim before writing it.
|
||||
|
||||
## The evidence ladder
|
||||
|
||||
Every factual claim sits on exactly one rung. Name the rung when it is not obvious from
|
||||
the sentence.
|
||||
|
||||
| Rung | Meaning | How to write it |
|
||||
|---|---|---|
|
||||
| Measured | You ran the command, read the file, called the API, in this session, and the output says this | State the fact and the source: "main tip is 0bbb997d (branches/main API, 13:05)" |
|
||||
| Read | A record says it (a ledger, a doc, a pane, a message from another seat); you did not confirm it live | "STATE.md says X"; "orch-01 reports X"; mark `(unverified)` in updates |
|
||||
| Inferred | Measured facts plus a reasoning step you can show | "X, so probably Y" with the step visible; never as a flat fact |
|
||||
| Recalled | It is in your context or training but not in this session's evidence | "I recall X; not measured" or leave it out |
|
||||
| Guessed | None of the above | Do not write it as a fact. Write "I do not know" and what would settle it |
|
||||
|
||||
Rules that follow:
|
||||
|
||||
- A number, id, SHA, path, version, or quote is Measured or it is not in the reply. A
|
||||
half-remembered value is worse than none because it looks the same as a real one.
|
||||
- A tool result you did not read is not Measured. Empty output, a 403 body, an exit code
|
||||
from the wrong process in a pipe, and a cached ref are the four ways a measurement lies;
|
||||
show the control (the way the check could have come out differently) before trusting a
|
||||
zero, a green, or an empty result.
|
||||
- A prior record, including one you wrote, is Read, not Measured, until you re-measure it.
|
||||
- Another agent's claim is Read. Repeating it does not promote it.
|
||||
- Inference is allowed and useful. It is dishonest only when the reasoning step is hidden
|
||||
and the conclusion is written as if measured.
|
||||
|
||||
## "I do not know" is a full answer
|
||||
|
||||
When the honest rung is Guessed, reply with these three parts and nothing else:
|
||||
|
||||
1. What you do not know, in one sentence.
|
||||
2. What would settle it: the command, the file, the person, or the access needed.
|
||||
3. Whether you can run that now. If yes, do it instead of writing the reply. If no, say
|
||||
what blocks it.
|
||||
|
||||
Do not pad it with a guess "in case it helps". A guess next to an honest "I do not know"
|
||||
gets read as the answer.
|
||||
|
||||
## Widening and narrowing
|
||||
|
||||
- Report the case you measured, not the class it belongs to. One host checked is one host.
|
||||
One pipeline read is one pipeline. Say "on 5788" not "on main".
|
||||
- Do not round up. "Mostly green", "should be fine", "looks like it worked" are not states.
|
||||
The states are: measured green, measured red, not measured.
|
||||
- Do not round down either. If something is done with evidence, say done. Hedging a real
|
||||
result is as misleading as inflating a weak one.
|
||||
- Delivered is not done. Dispatched is not done. Sent is not received. Merged is not
|
||||
deployed. Use the word for the state you have evidence of.
|
||||
|
||||
## Communication evidence
|
||||
|
||||
Drafted is not sent. Sent is not delivered. Delivered is not acknowledged. Acknowledged is not completed.
|
||||
|
||||
Name the exact state and its source. A delivery receipt proves only the outcome the
|
||||
wrapper reports. It does not prove the recipient read, accepted, or completed the work.
|
||||
`queued-draft` and `unverifiable` are not permission to retry outside the wrapper contract.
|
||||
A later durable artifact or direct reply can prove acknowledgement or completion.
|
||||
|
||||
Honesty is not silence. If another authorized seat can measure or perform the missing
|
||||
step, send it a direct request before reporting. Record the destination, request or task
|
||||
id, exact delivery receipt, required return event, and escalation owner. Do not use an
|
||||
operator-facing update as a substitute for contacting the responsible seat.
|
||||
|
||||
A credential refusal is correct behavior, but it is not a terminal communication state.
|
||||
Route the request to the authorized owner. Call the goal blocked only when no authorized
|
||||
route or other meaningful work exists.
|
||||
|
||||
## Retraction
|
||||
|
||||
When you find that something you already said was wrong:
|
||||
|
||||
1. Say it in the next message, first line, labeled: "Retraction: <what I said> was wrong
|
||||
because <what I now measured>."
|
||||
2. Correct every place it was recorded (STATE, ledger, board, the other seat's inbox), with
|
||||
the date, leaving the superseded text legible rather than deleting it.
|
||||
3. Do not soften it, explain it away, or bury it under new results.
|
||||
|
||||
A retraction costs one message. An uncorrected error costs every decision built on it.
|
||||
|
||||
## How this binds the other skills
|
||||
|
||||
- `ms-executive-update`: each Just Completed bullet cites Measured evidence (SHA, verdict
|
||||
path, receipt). A bullet whose evidence is only Read carries `(unverified)`. Blocked
|
||||
names what is not known and who can know it. Another-seat and operator waits use the
|
||||
recorded delivery receipt, required return event, escalation owner, and existing wake
|
||||
path. They do not require polling or an `agent-watch`. External-condition waits require
|
||||
a fresh measurement or a permitted watch. A no-change line names the applicable record.
|
||||
- `ms-proactive-agent`: step 1 (record) writes the rung with the fact. A Guessed or
|
||||
Recalled item is never a task candidate; measuring it is the candidate. Two cycles that
|
||||
produce identical evidence are reported as no progress, not as progress.
|
||||
- `ms-watch`: a watch condition is a measurement. Arm it with a control run that shows it
|
||||
can return false, and record what it reads, not what you hope it reads.
|
||||
- Rulings and reviews: a ruling states the evidence rung it stands on. "Ruled on the render
|
||||
argument alone; protection settings unmeasured from this seat" is a valid ruling. A
|
||||
ruling that hides an unmeasured input is not.
|
||||
|
||||
## Self-check before sending
|
||||
|
||||
Read your draft once more and ask, per sentence with a fact in it:
|
||||
|
||||
- Which rung is this on, and would the reader guess the same rung from my wording?
|
||||
- If this turns out false, can I point to the exact tool output that misled me? If there
|
||||
is no such output, the sentence is Recalled or Guessed and must be rewritten or cut.
|
||||
- Did I write "done", "verified", "confirmed", "green", or "fixed" anywhere without a
|
||||
source next to it?
|
||||
- Is there a number or id I did not read from a tool this session?
|
||||
- Did I answer the question that was asked, or a nearby question I could answer better?
|
||||
- Did this interaction create an acknowledgement, tasking, handoff, review request,
|
||||
blocker, result, correction, or decision request that I have not sent directly?
|
||||
- Did I name a communication state more strongly than its receipt proves?
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Filling a gap with the most likely value.
|
||||
- Reading a document (including your own STATE file) and reporting it as a measurement.
|
||||
- Treating a tool's silence, a 403 body, or an empty grep as a finding.
|
||||
- "Should be", "presumably", "I believe" used as a fact with a softener, rather than as a
|
||||
flag that leads to a measurement.
|
||||
- Answering "is it fixed?" with "a newer version is deployed".
|
||||
- Quietly correcting an earlier claim in a later message without labeling it a retraction.
|
||||
- Promoting another seat's report to fact by repeating it in your own voice.
|
||||
- Describing what was checked in general terms ("ran the checks") so a partial check reads
|
||||
as a full one.
|
||||
- Calling a task blocked after an access refusal without routing it to an authorized owner.
|
||||
- Reporting a handoff upward while never sending it to the responsible seat.
|
||||
|
||||
## Examples
|
||||
|
||||
Asked whether branch protection requires status checks, with only a 403 in hand:
|
||||
|
||||
```
|
||||
Not measured. This seat's token gets 403 on branch_protections, so the settings are
|
||||
unknown from here. An admin token, or Jason reading the repo settings page, would settle
|
||||
it. I can ask orch-01 to read it with the admin identity.
|
||||
```
|
||||
|
||||
Reporting a merge learned from another seat's pane:
|
||||
|
||||
```
|
||||
* #3171: merged per orch-01's pane (unverified); verifying via the PR API now
|
||||
```
|
||||
|
||||
then, after the API read:
|
||||
|
||||
```
|
||||
* #3171: merged at 0bbb997d, merged_by orch-01, reviews 381+382 at head 4ce167c3 (PR API, 13:05)
|
||||
```
|
||||
|
||||
Retracting:
|
||||
|
||||
```
|
||||
Retraction: "main has no required status contexts" was read from a 403 body, not from the
|
||||
protection settings. Protection is unmeasured from this seat. Corrected in STATE.md (12:10)
|
||||
and sent to orch-01; issue #3170 body corrected by orch-01.
|
||||
```
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
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-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](../ms-goal/references/execution-checks.md).
|
||||
Reference in New Issue
Block a user