@amsterdamdatalabs/enact-extensions 0.1.12 → 0.1.25

package/extensions/enact-operator/skills/setup/SKILL.md

@@ -1,91 +0,0 @@
----
-name: enact-operator-setup
-description: "Initialize the Enact Operator control-plane: install the enact-operator CLI if needed, then install hooks and agents and verify the runtime is healthy."
----
-
-# Enact Operator Setup
-
-## Runtime Prerequisite
-
-Before running the workflow, make sure the `enact-operator` CLI exists:
-
-```bash
-which enact-operator || bash scripts/install.sh
-```
-
-## Purpose
-Bootstraps a project to use Enact Operator by laying out the `.enact/operator/` directory tree and installing Operator hooks and agents. Plugin installation and host registry ownership belongs to enact-extensions.
-
-## Use When
-- First-time installation of enact-operator in a project
-- Reinstalling after a version bump or broken hook state
-- Validating that an existing installation is coherent before running team or staged review workflows
-
-## Execution Policy
-
-- start from the repo and `.enact/operator/` truth, not chat memory
-- if `operator_*` tools are not visible yet, load/search the Enact Operator MCP namespace before running setup/readiness checks
-- drive setup through MCP tools when running inside Codex; CLI commands are the equivalent operator surface
-- keep state current as you go — confirm each step before advancing
-
-## Workflow
-1. Run the top-level installer:
-   - MCP: `operator_setup`
-   - CLI: `enact-operator setup`
-2. Install Claude Code hooks (pre/post tool hooks that integrate with the operator runtime):
-   - No MCP tool for hooks install — use CLI: `enact-operator hooks install`
-3. Check hook registration status:
-   - MCP: `operator_hooks_status`
-   - CLI: `enact-operator hooks status`
-4. Install the Core 7 Codex agent roster into the project:
-   - MCP: `operator_agents_pack_install`
-   - CLI: `enact-operator agents install-pack`
-5. Validate the plugin bundle source is coherent (skills, hooks, agents all present):
-   - MCP: `operator_plugin_validate`
-   - CLI: `enact-operator plugins validate`
-6. Check the install registry for operator-owned hooks and agents:
-   - MCP: `operator_install_registry`
-   - CLI: (no direct equivalent — use `operator_install_registry`)
-7. Run the doctor to confirm runtime health:
-   - MCP: `operator_doctor`
-   - CLI: `enact-operator doctor`
-8. Check replacement-readiness to confirm Operator is ready to take over provider roles:
-   - MCP: `operator_audit_replacement_readiness`
-   - CLI: `enact-operator audit replacement-readiness`
-
-## State Contract
-- Reads: project root, existing `.claude/settings.json`, existing hook files
-- Writes: `.enact/operator/` directory tree (`cache`, `jobs`, `logs`, `memory`, `plans`, `reports`, `research`, `sessions`, `state`, `team`, `ultragoal`, `metrics.json`), hook entries in `.claude/settings.json`
-
-## MCP Tools
-
-- `operator_setup` — run the top-level installer
-- `operator_hooks_status` — verify hook registration state
-- `operator_agents_install` — install individual agent templates
-- `operator_agents_pack_install` — install the full Core 7 Codex agent roster
-- `operator_plugin_validate` — check plugin bundle source coherence
-- `operator_install_registry` — read the install registry
-- `operator_doctor` — confirm runtime health
-- `operator_audit_replacement_readiness` — confirm Operator is ready to take over provider roles
-
-Note: hooks install has no MCP equivalent — use `enact-operator hooks install` via CLI.
-
-## Commands
-```
-enact-operator setup
-enact-operator hooks install
-enact-operator hooks status
-enact-operator agents install-pack
-enact-operator plugins validate
-enact-operator doctor
-enact-operator audit replacement-readiness
-```
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.
-## Final Check
-- `operator_doctor` (or `enact-operator doctor`) reports no errors
-- `operator_plugin_validate` reports the enact-operator source bundle is valid
-- `operator_hooks_status` shows all required hooks registered
-- `.enact/operator/` directory exists with expected subdirectories

package/extensions/enact-operator/skills/setup/scripts/install.sh

@@ -1,50 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-PACKAGE_NAME="@amsterdamdatalabs/enact-operator"
-BIN_NAME="enact-operator"
-
-already_installed() {
-    command -v "${BIN_NAME}" >/dev/null 2>&1
-}
-
-require_npm() {
-    if command -v npm >/dev/null 2>&1; then
-        return 0
-    fi
-
-    echo "ERROR: npm is required to install ${PACKAGE_NAME}." >&2
-    echo "Install Node.js + npm from https://nodejs.org/ and rerun this script." >&2
-    exit 1
-}
-
-install_cli() {
-    echo "Installing ${PACKAGE_NAME} via npm..."
-    npm install -g "${PACKAGE_NAME}"
-}
-
-main() {
-    if already_installed; then
-        local current
-        current="$(${BIN_NAME} --version 2>/dev/null | head -1 || echo 'unknown')"
-        echo "${BIN_NAME} already installed: ${current}"
-        echo "Run '${BIN_NAME} setup' in your repo to initialize Operator state."
-        exit 0
-    fi
-
-    require_npm
-    install_cli
-
-    if ! already_installed; then
-        echo "ERROR: ${BIN_NAME} was installed but is not on PATH." >&2
-        echo "Open a new shell or update your npm global bin PATH, then rerun '${BIN_NAME} --version'." >&2
-        exit 1
-    fi
-
-    local current
-    current="$(${BIN_NAME} --version 2>/dev/null | head -1 || echo 'unknown')"
-    echo "${BIN_NAME} installed: ${current}"
-    echo "Next step: run '${BIN_NAME} setup' in the target workspace."
-}
-
-main "$@"

package/extensions/enact-operator/skills/skill/SKILL.md

@@ -1,82 +0,0 @@
----
-name: skill
-description: "Meta-skill: list, discover, and route to available Operator skills. Use when the operator wants to know what skills exist or which skill handles a given task."
----
-
-# Skill
-
-## Purpose
-Provides a navigable index of all skills available in the enact-operator plugin. When the operator asks "what can Operator do?" or "which skill should I use for X?", this skill answers by listing the catalog and routing to the correct skill. It does not execute work itself.
-
-## Use When
-- The operator wants to see all available Operator skills
-- Choosing between skills for a given task type
-- Checking whether a skill exists before invoking it
-- Auditing the plugin's skill surface for completeness
-
-## Execution Policy
-
-- start from the repo and `.enact/operator/` truth, not chat memory
-- drive discovery through MCP tools when running inside Codex; CLI commands are the equivalent operator surface
-- this skill is read-only — it writes nothing
-
-## Workflow
-1. List all source skills in the operator bundle:
-   - MCP: `operator_plugin_list`
-   - CLI: `ls enact-operator/extensions/skills/`
-
-   Plugin installation and host registry state are owned by enact-extensions.
-
-2. For a raw directory listing of skill names:
-   ```
-   ls enact-operator/extensions/skills/
-   ```
-
-3. To validate that all skill files are well-formed:
-   ```
-   enact-operator plugins validate
-   ```
-
-4. To read a specific skill's playbook, open its `SKILL.md` directly:
-   ```
-   enact-operator/extensions/skills/<skill-name>/SKILL.md
-   ```
-
-5. Route the operator to the correct skill based on their task:
-
-   | Task type | Skill |
-   |-----------|-------|
-   | First-time install or reinstall | `$setup` |
-   | Durable multi-executor implementation flow | `$team` |
-   | Single executor execution lane | `$executor` |
-   | Long-horizon multi-session goal | `$ultragoal` |
-   | QA cycling with hard-stop gates | `$ultraqa` |
-   | Remove TODO/placeholder noise | `$ai-slop-cleaner` |
-   | Read-only investigation | `$analyze` |
-   | Specific factual question | `$ask` |
-   | Research anchored to a goal | `$autoresearch-goal` |
-   | Stop all active modes | `$cancel` |
-   | Findings-first review | `$review` |
-   | Notification preferences | `$configure-notifications` |
-   | Wiki/reference lookup | `$wiki` |
-
-## State Contract
-- Reads: `enact-operator/extensions/skills/` directory, `operator_plugin_list` output
-- Writes: nothing
-
-## MCP Tools
-
-- `operator_plugin_list` — list local operator plugin bundle sources
-
-## Commands
-```
-enact-operator plugins validate
-```
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.
-## Final Check
-- All skills listed in the routing table are present in `enact-operator/extensions/skills/`
-- `enact-operator plugins validate` passes with no errors
-- The operator was routed to a specific skill, not left with a general answer

package/extensions/enact-operator/skills/tdd/SKILL.md

@@ -1,59 +0,0 @@
----
-name: tdd
-description: "Red-green-refactor mode for behavior with clear inputs, outputs, and regression value."
----
-
-# TDD
-
-## Purpose
-
-Use `$tdd` when behavior can be specified before implementation. TDD is for design pressure and regression safety, not for ritual.
-
-## Good TDD Candidates
-
-- business rules
-- API contracts
-- parsing, formatting, or validation
-- state transitions
-- algorithms and utility behavior
-
-## Skip TDD For
-
-- pure layout and styling work
-- config-only changes
-- trivial glue code
-- exploratory prototypes where behavior is not yet known
-
-## Iron Law
-
-No production code without a failing test first.
-
-## Cycle
-
-1. Red
-   - write the smallest failing test for the next behavior
-   - run it and prove it fails for the right reason
-2. Green
-   - write the minimum code to make it pass
-   - rerun the test and the relevant suite
-3. Refactor
-   - clean up only after green
-   - keep the suite green after every change
-
-## Rules
-
-- one behavior per cycle
-- do not batch multiple features into one red-green pass
-- prefer regression tests for changed behavior
-- record the verify command in the plan or task notes
-
-## Output Standard
-
-- what behavior the test locked in
-- the failing signal
-- the minimal implementation
-- the final verification command
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.

package/extensions/enact-operator/skills/team/SKILL.md

@@ -1,199 +0,0 @@
----
-name: team
-description: "Durable multi-executor orchestration with queueing, claims, inbox, review gates, and tmux-aware lifecycle control."
-lane: true
-mcpToolPrefix: operator_team_
----
-
-# Team
-
-## Purpose
-
-`$team` is the durable execution mode. Use it when you need a shared queue, executor leases, review handoffs, and a runtime that survives beyond one reasoning burst.
-
-## Team vs Native Fanout
-
-- use native subagents for small, in-session parallelism
-- use `$team` when the work needs durable state, tmux executors, inbox coordination, resumability, or explicit review gates
-
-## Use When
-
-- the work splits into parallel slices
-- one operator needs durable coordination and review history
-- tasks need claims, heartbeats, inbox messages, and resumable state
-
-## Do Not Use When
-
-- the task is sequential and small
-- there is no meaningful slice boundary
-- the cost of queueing and review would exceed the value of parallelism
-
-## Preconditions
-
-Before launching team mode:
-
-1. the current task has a clear objective
-2. the first slices are identifiable
-3. the likely file areas are known
-4. there is a verify path
-
-If those are missing, run `$deep-interview`, `$trace`, or `$plan` first.
-
-## Runtime Contract
-
-- if `operator_*` tools are not visible yet, load/search the Enact Operator MCP namespace before doing team work
-- initialize with `operator_team_init`
-- queue work with `operator_team_queue`
-- claim with executor ids via `operator_team_claim`
-- complete into review with `operator_team_complete`, never straight to done
-- record review decisions with `operator_team_review`
-- use `operator_team_inbox`, `operator_team_logs`, `operator_team_status`, and `operator_hud` to monitor real progress
-- shut down only after terminal state or explicit abort via `operator_team_shutdown`
-- for every `operator_team_*` call, `root` means the repository root that owns `.enact/operator`
-  - it is **not** the task subdirectory
-  - task subdirectories are for code edits and verification only
-- during bootstrap, use sequential MCP calls
-  - first confirm `operator_team_status`
-  - then `operator_team_init` if absent
-  - only after that move to queue / claim / complete / review
-- when no external `taskId` exists, local Operator task discipline is mandatory
-  - queue or bootstrap the first local task immediately
-  - claim, review, and close by local `taskId`
-- current MCP note: some lifecycle calls still carry that local task id in a `taskId` field
-  - do not defer tracker ownership to AzDo
-- executor semantics are team-internal and are not a separate callable skill:
-  - executor is the team-internal execution lane, not a root skill
-  - executor claims exactly one task at a time
-  - executor sends regular heartbeats while active
-  - executor reports completion with non-empty summary
-  - blocked work must be reported explicitly (`BLOCKED: ...`)
-
-## Proof And Closure
-
-- `$team` is a current operator lane and should use real Operator proof
-  surfaces when its work contributes to closure:
-  - `operator_contract_parity_run`
-  - `operator_workflow_reconcile`
-  - `operator_operator_snapshot`
-  - `operator_hud`
-- `contract-parity` should be read from the real gate output, not inferred from
-  queue state or reviewer prose alone.
-- Provider note: Operator may use its adapter over the running
-  `enact-context` server for proof. That is expected and preferable to
-  duplicating analysis in team-local logic.
-
-## Lifecycle
-
-1. Launch the runtime and inspect backend health.
-2. Queue explicit slices, not vague goals.
-3. Ensure every local task claim maps to a real executor id.
-4. Keep heartbeats and logs current.
-5. Move completions into review with a concrete handoff note.
-6. Monitor:
-   - MCP only: `operator_team_init`, `operator_team_status`, `operator_team_spawn`, `operator_team_claim`, `operator_team_heartbeat`, `operator_team_complete`, `operator_team_review`, `operator_team_inbox`, `operator_team_logs`, `operator_team_resume`, `operator_team_shutdown`, `operator_hud`
-7. Shutdown only when active work is terminal or the user wants an abort.
-
-## Closure Protocol
-
-Use this exact closeout order with the current live `operator_team_*` MCP tools:
-
-1. Confirm no in-flight executor work:
-   - `operator_team_status`
-2. Verify task queue is terminal (no `queued` or `claimed` tasks remain):
-   - `operator_team_task_list`
-3. Ensure task completions and reviewer notes are persisted:
-   - `operator_team_complete`
-   - `operator_team_review`
-4. Run shutdown:
-   - `operator_team_shutdown`
-5. Re-check there is no active team:
-   - `operator_team_status`
-
-Do not use non-existent shutdown lifecycle tools (for example `shutdown_request`, `shutdown_approve`, or `shutdown_delete`). The active shutdown surface is `operator_team_shutdown`.
-
-## Root semantics
-
-When the task says “work inside `<path>`”, separate two concepts:
-
-1. **Operator root**
-   - the repository root that owns `.enact/operator`
-   - this is the value passed as `root` to `operator_team_*`
-2. **Task workspace**
-   - the subdirectory where code changes happen
-   - this is where file reads/edits and verification commands should run
-
-Do not point `operator_team_status`, `operator_team_init`, or any other
-`operator_team_*` call at the task subdirectory unless that subdirectory itself
-owns a separate `.enact/operator`.
-
-## Degraded Mode
-
-If tmux is missing, the runtime may fall back to mock mode. That is acceptable for state flow and testing, not as proof of real detached-executor behavior.
-
-## Rules
-
-- no silent completions
-- no review without a readable result note
-- no shutdown while work is still active unless aborting
-- no CLI fallback for lifecycle operations; use the `operator_team_*` MCP surface
-- prefer runtime/state MCP tools over ad-hoc pane hacking
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. When no external `taskId` exists, the injected note also means local Operator task discipline is mandatory: queue the first local task immediately and keep queue/review state authoritative in Operator. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.
-
-Team-driven activation is a separate path: observe/MCP should start the runtime directly with `operator_team_init`, not through `operator_operator_activate`.
-
-
-# Executor (team-internal role)
-
-This page captures the in-team **executor** semantics for the `team` runtime.
-It is reference-only documentation and **not** a standalone callable skill.
-
-Within `$team`, executor-capable work is carried by claimed executor lanes and
-coordinated by team mechanics (spawn, claim, heartbeat, acknowledge, complete).
-
-## Purpose
-
-An executor is the in-team assignee for a single task slice inside a team session.
-The executor claims one task at a time, maintains heartbeat cadence, and
-reports completion or explicit blockage.
-
-## Workflow
-
-1. Check available tasks:
-   - `operator_team_status`
-2. Claim a task:
-   - `operator_team_claim`
-3. Keep heartbeat cadence (typically every 60 seconds):
-   - `operator_team_heartbeat`
-4. Report for clarification or status updates:
-   - `operator_team_message`
-5. Acknowledge injected instructions after applying them:
-   - `operator_team_message_ack`
-6. Complete with summary:
-   - `operator_team_complete`
-7. Report blocked work explicitly:
-   - `operator_team_complete` with a `BLOCKED: ...` summary
-8. Check inbox for operator instructions:
-   - `operator_team_inbox`
-9. Check execution context:
-   - `operator_team_logs`
-
-Example acknowledgement call:
-
-```json
-{
-  "tool": "operator_team_message_ack",
-  "root": "/path/to/repo-root",
-  "executorId": "executor",
-  "messageId": "msg_123"
-}
-```
-
-## Contract checks
-
-- claimed tasks stay in claimed state only with recent heartbeat
-- completed tasks include a non-empty summary
-- blocked completions include a specific reason
-- no second claim without completing or unblocking the first task

package/extensions/enact-operator/skills/trace/SKILL.md

@@ -1,41 +0,0 @@
----
-name: trace
-description: "Execution-path mapping for entry points, data flow, side effects, and blast radius before risky work."
----
-
-# Trace
-
-## Purpose
-
-Use `$trace` before a risky edit or review when you need to know what code path actually runs, what it touches, and what could break downstream.
-
-## Workflow
-
-1. Find the entry points.
-2. Follow data flow through the changed or targeted path.
-3. Map side effects:
-   - storage writes
-   - network calls
-   - UI state changes
-   - background work
-4. Identify risky branches and missing guards.
-5. Name the concrete files the next pass should touch.
-
-## Suggested Tools
-
-- `ctx_search` for symbol and path discovery
-- `ctx_read` for call-path confirmation
-- `ctx_semantic_search` or `ctx_graph` when lexical search is not enough
-- `operator_hud` when runtime state matters to the path
-
-## Output Standard
-
-- entry points
-- downstream side effects
-- risky branches
-- likely blast radius
-- recommended edit boundary
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.

package/extensions/enact-operator/skills/ultragoal/SKILL.md

@@ -1,99 +0,0 @@
----
-name: ultragoal
-description: "Long-horizon goal mode that manages cross-session continuity for a durable objective, using ultrawork for each individual session."
-lane: true
-mcpToolPrefix: operator_ultragoal_
----
-
-# Ultragoal
-
-## Purpose
-
-Wraps a multi-session, long-running objective that cannot be completed in a single context window. Ultragoal continuity lives in reviewable artifacts under `.enact/operator/ultragoal/`, while each individual execution burst is tracked through the real Operator runtime state (`$ultrawork`, and when needed `$autopilot`, `$ralph`, or `$team`).
-
-## Use When
-
-- a goal spans multiple days or context-window boundaries
-- you need cross-session continuity for a complex engineering objective
-- individual `$ultrawork` sessions should contribute to a shared, durable goal artifact
-- you need one authoritative goal artifact listing remaining vs completed slices across sessions
-
-## Workflow
-
-1. Define the goal and create or update the goal artifact in `.enact/operator/ultragoal/<goalId>.json`.
-   - Prefer MCP: `operator_ultragoal_update`
-   - Record at least: `title`, `goal`, `planPath`, `status`, `remainingPbis`, `completedPbis`, `updatedAt`
-2. Start or refresh the current session:
-   - MCP: `operator_session_start`
-   - CLI fallback: `enact-operator session start`
-3. Start ultrawork for the current execution burst:
-   - MCP: `operator_ultrawork_start`
-   - CLI fallback: `enact-operator ultrawork start "<goal>"`
-   - Do not depend on custom `activationMetadata` shapes for continuity.
-     Goal-level continuity belongs in the ultragoal artifact itself; runtime
-     activation metadata is only optional provenance.
-4. Link the relevant plan ids and external task ids into ultrawork state when those
-   concrete ids exist:
-    - MCP: `operator_ultrawork_link_plan`, `operator_ultrawork_link_task`
-    - CLI fallback: `enact-operator ultrawork link-plan <planId>`
-    - The linked external identifier parameter is `taskId`.
-5. Within each burst, run tasks using `$ultrawork` and keep the ultragoal
-   artifact updated as slices move from `remainingPbis` to `completedPbis`.
-6. At natural stopping points, record verified progress:
-   - MCP: `operator_ultrawork_verify`
-   - CLI fallback: `enact-operator ultrawork verify "<evidence>"`
-7. For closure-sensitive goals, also keep the real parity/hygiene surfaces in
-   view across sessions:
-   - `operator_contract_parity_run`
-   - `operator_operator_snapshot`
-   - `operator_hud`
-   - `operator_workflow_reconcile`
-8. On the next session, resume by reading:
-   - `.enact/operator/ultragoal/<goalId>.json`
-   - `operator_ultrawork_status`
-   - `operator_session_status`
-   - `operator_hud`
-9. When the goal is fully achieved:
-   - complete the active runtime burst (`operator_ultrawork_complete`)
-   - update the ultragoal artifact to `status: completed`
-   - ensure no dangling active runtime remains in HUD/state
-
-## State Contract
-
-- reads:
-  - `.enact/operator/ultragoal/<goalId>.json`
-  - plan files
-  - session / ultrawork / HUD state
-- writes:
-  - `.enact/operator/ultragoal/<goalId>.json`
-  - linked ultrawork state via `operator_ultrawork_*`
-  - optional parity evidence via `operator_contract_parity_run`
-
-## Commands
-
-```
-enact-operator session start
-enact-operator ultragoal status <goalId>
-enact-operator ultragoal update <goalId>
-enact-operator ultrawork start "<goal>"
-enact-operator ultrawork status
-enact-operator ultrawork verify "<evidence>"
-enact-operator ultrawork link-plan <planId>
-enact-operator ultrawork link-task <taskId>
-enact-operator ultrawork complete "<summary>"
-enact-operator ultrawork abort "<reason>"
-enact-operator session status
-```
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.
-## Final Check
-
-- `.enact/operator/ultragoal/<goalId>.json` reflects current progress after each session
-- `remainingPbis` and `completedPbis` stay truthful to the codebase
-- no session ends without either verification evidence or a completion summary
-- plan files stay in sync with actual completed work
-- when the goal is done, ultrawork is completed and no dangling execution session remains
-- if closure criteria exist, use the real `contract-parity` gate rather than a
-  purely narrative reviewer summary