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.

skills/ms-proactive-agent/SKILL.md

@@ -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).