feat(skills): six new ms-* skills
ms-archify (evidence-based architectural mapping), ms-sdlc, ms-proactive-agent, ms-goal, ms-grill-me, ms-frontend-design.
This commit is contained in:
@@ -0,0 +1,126 @@
|
||||
---
|
||||
name: ms-goal
|
||||
description: Maintain a durable goal, acceptance criteria, task pointers, and pause/resume state for an authorized continuing Mosaic assignment. Use with ms-proactive-agent for dev testing before the goal extension is integrated; this skill provides no automatic wake mechanism.
|
||||
---
|
||||
|
||||
# Mosaic Goal
|
||||
|
||||
Manage the work record for a continuing assignment. Use
|
||||
[ms-proactive-agent](../ms-proactive-agent/SKILL.md) to select and execute its tasks.
|
||||
This is a file-based instruction protocol, not an implemented Stack API or project schema.
|
||||
It does not register `/goal`, supply `goal_report`, launch agents, or force another turn.
|
||||
Use ordinary requests such as "continue this goal" or "pause this goal" in dev tests.
|
||||
|
||||
## Establish or recover a goal
|
||||
|
||||
1. Use the user's authorized assignment and applicable mission constraints. Do not create
|
||||
a standing goal from a role description, casual question, or review of this skill.
|
||||
Preserve existing authorization; make reasonable implementation choices within it.
|
||||
2. Resolve the workspace and its authoritative work records before writing. Reuse an
|
||||
existing goal/task system rather than creating a competing source of truth. A separate
|
||||
test goal must not replace the repository's queued project work.
|
||||
3. For a dev fixture with no declared records, use `work/goals/<goal-id>/` beneath the
|
||||
explicitly selected writable workspace. Check for existing records first. Create
|
||||
`GOAL.md`, `TASKS.md`, and append-only `HISTORY.md` there; this is a local test convention,
|
||||
not a claim that workspace registration or isolation has been implemented. Give the
|
||||
user the goal path so a later conversation can find it. Do not guess among multiple
|
||||
goals or reuse another workspace's goal.
|
||||
4. Establish observable acceptance criteria, completion owner, allowed scope, exclusions,
|
||||
applicable approvals, budget, and initial next action. Derive these from the request
|
||||
when clear; ask only for missing decisions that materially change execution. Ordinary
|
||||
task acceptance can use the request's criteria; preserve explicit human sign-off.
|
||||
5. On resume, read the goal, relevant tasks, history since the last checkpoint, and linked
|
||||
approvals. Verify workspace, ownership, current permissions, budget, and live outcomes.
|
||||
If a known record is missing or corrupt, report a recovery blocker; absence does not
|
||||
authorize a replacement goal or a fresh budget.
|
||||
|
||||
## State transitions
|
||||
|
||||
| State | Meaning and next transition |
|
||||
|---|---|
|
||||
| `active` | Authorized work can proceed. Continue in the same turn through useful checkpoints. |
|
||||
| `waiting` | No ready work; a named dependency or decision is pending. Record automatic or manual wake and the exact return condition. A matching event permits reconciliation, then `active` if work is ready. |
|
||||
| `paused` | User stop, budget limit, or another explicit hold. Preserve the goal and reason. Only authorized resumption that resolves the hold permits `active`. |
|
||||
| `blocked` | No ready work and no usable current route to resolve a required capability, invalid state, or unknown outcome. Record the blocker, owner if known, and recovery condition. Reconcile supplied recovery evidence before returning to `active`. |
|
||||
| `satisfied` | Every acceptance criterion has verified evidence and all required acceptance owners have approved. Preserve the record and stop selecting work for this goal. |
|
||||
| `canceled` | The user ended the assignment. Preserve evidence and obligations; do not restart without explicit authorization. |
|
||||
|
||||
A task may wait while the overall goal stays active because another task can proceed.
|
||||
Goal state and task state are separate. Preserve pauses through compaction and restart.
|
||||
An unrelated message, receipt, or wake event never lifts a pause or cancellation. A status
|
||||
request is read-only with respect to control state. Scope corrections change only the
|
||||
affected work; they do not silently replace the goal or revoke unrelated authorization.
|
||||
A satisfied goal stays closed unless the user authorizes follow-up work or new evidence
|
||||
invalidates its acceptance; record the reason and recheck authority before reopening.
|
||||
|
||||
On pause/cancel, stop initiating work promptly. Reconcile already-running actions when
|
||||
possible and report any still running or unknown. Retire owned watches and delegated work
|
||||
only through authorized cancellation mechanisms; never claim that changing this file
|
||||
canceled a process, message, or external operation.
|
||||
|
||||
## Minimal durable record
|
||||
|
||||
Use existing schema fields when available. For the dev convention, `GOAL.md` contains:
|
||||
|
||||
```yaml
|
||||
id: <stable id>
|
||||
revision: <monotonically increasing record revision>
|
||||
context: <agent, declared project if any, absolute workspace, execution/session if known>
|
||||
objective: <authorized outcome>
|
||||
authorization: <user request/mission/decision reference and relevant scope>
|
||||
scope: <allowed work and exclusions>
|
||||
acceptance: <criterion ids, observable checks, evidence pointers, completion owner>
|
||||
state: <active|waiting|paused|blocked|satisfied|canceled>
|
||||
state_reason: <why, and the condition/authority needed for the next transition>
|
||||
tasks: <authoritative task record path>
|
||||
ownership: <assigned writer, coordinator claim reference if available>
|
||||
budget: <limits, consumed/remaining, measurement source or labeled estimate/unavailable>
|
||||
checkpoint: <last verified result and evidence pointers>
|
||||
next_action: <task id and concrete action, or none with reason>
|
||||
obligations: <open request ids and their durable record pointers, or none>
|
||||
wait: <condition, last observation, auto/manual wake, owner, deadline and escalation or none>
|
||||
uncertain_actions: <action/request ids requiring reconciliation, or none>
|
||||
updated_at: <timestamp>
|
||||
history: <durable transition/action history path>
|
||||
```
|
||||
|
||||
Each task records id, goal criterion, owner, dependencies, status, next action, and evidence.
|
||||
Use `ready`, `in-flight`, `waiting`, `blocked`, `done`, or `canceled`; retain historical
|
||||
tasks and the reason for cancellation. Goal acceptance must still be checked independently
|
||||
of task statuses. The next-action field is a checkpoint, not a scheduling instruction.
|
||||
|
||||
History records changed decisions, transitions, and action intent/results with timestamp,
|
||||
task/action id, relevant revision, evidence, and reason. Record intent before an external
|
||||
effect and its result afterward. If interrupted between them, mark the outcome unknown and
|
||||
reconcile against the live system before retrying. Do not invent exactly-once guarantees.
|
||||
|
||||
Use the runtime's authoritative transaction/claim mechanism if present. The Markdown
|
||||
fallback requires one assigned writer; a revision field alone does not enforce exclusion.
|
||||
Before replacing a snapshot, check that its read revision/content has not changed and use
|
||||
an atomic file replacement where supported. Append history first and record the matching
|
||||
revision in the snapshot. After interruption, reconcile any mismatch before new effects.
|
||||
This reduces torn writes; it is not a multi-file transaction or concurrency guarantee.
|
||||
If safe recording or exclusive ownership cannot be established, block affected mutations.
|
||||
Preserve history and unresolved obligations when compacting snapshots.
|
||||
|
||||
## Completion and handoff
|
||||
|
||||
An empty queue is not evidence of satisfaction. Check each acceptance criterion against
|
||||
the actual artifacts/system and required owner verdicts. Missing necessary work is a
|
||||
planning input to ms-proactive-agent; missing acceptance is a wait. Completion evidence
|
||||
must match the delivered revision or resource, not an earlier successful check.
|
||||
|
||||
For a wait without a scheduler, record `manual` and tell the user the unresolved condition
|
||||
and the goal path to resume. Do not spin, poll a person, or emit repeated progress reports.
|
||||
For an involuntary turn limit, preserve incomplete state and the next action; explain
|
||||
whether a user invocation or a verified runtime continuation will resume it.
|
||||
|
||||
## Future extension integration
|
||||
|
||||
Do not call unavailable goal tools or edit an extension's private state. When a supported
|
||||
extension is integrated, first establish its actual API, context binding, pause semantics,
|
||||
wait suspension, restart recovery, and budget behavior. Choose one authoritative lifecycle
|
||||
record and explicitly reconcile existing file goals; do not silently run two goal loops.
|
||||
Map states only through supported operations. An `in_progress` report alone does not prove
|
||||
that the runtime suspends checks while waiting. Keep file mode until the target integration
|
||||
passes the [execution checks](references/execution-checks.md).
|
||||
Reference in New Issue
Block a user