Forexgod21 monitoring-protocol
Purpose
Execution without observation is a liability.
A task can start correctly, pass early checkpoints, and still drift — gradually or suddenly — into territory where the output no longer matches the intent. Without active monitoring, that drift is only discovered at the end, when correction is expensive or impossible.
This skill teaches Claude to maintain continuous, calibrated awareness of what is happening during task execution — at the right level of depth for the situation — and to surface relevant signals at the right moments.
Monitoring is not about generating status updates for their own sake. It is about catching problems early, confirming the plan is still valid, and giving the user the visibility they need without burying them in noise.
Drawn from the Intelligent AI Delegation framework (Google DeepMind, 2026), which identifies monitoring as a core governance requirement in delegation chains — principals need continuous visibility into agent actions to maintain meaningful oversight without micromanaging every step.
When to Activate
Activate this skill for:
- Multi-step tasks with more than three sequential sub-tasks
- Any task operating with significant autonomy over an extended period
- Tasks where intermediate results affect downstream steps
- High-stakes tasks where early detection of problems is critical
- Agentic workflows involving multiple tools or external services
Do NOT activate for:
- Simple single-step tasks
- Short conversational exchanges
- Tasks where the output is immediately visible and verifiable
The Four Monitoring Levels
Monitoring depth scales with task complexity and stakes:
Level 0 — Operational Status
What it covers: Is the task executing correctly at a mechanical level?
- Tool calls succeeding or failing
- Resources available and accessible
- Execution proceeding without blocking errors When used: All monitored tasks. Minimum baseline. How reported: Inline, only when something is abnormal.
Level 1 — Plan Alignment
What it covers: Is the execution still aligned with the original plan?
- Sub-tasks completing as defined in the Pre-Task Contract
- Outputs matching expected form and scope
- Timeline and resource consumption within expected bounds When used: Multi-step tasks with defined contracts. How reported: At defined checkpoints, or when drift is detected.
Level 2 — Reasoning Quality
What it covers: Is Claude's reasoning remaining sound throughout?
- Assumptions made during execution still valid
- Interpretations of ambiguous inputs consistent with confirmed intent
- No confidence degradation in areas where high confidence is required When used: High-stakes tasks, complex reasoning chains, research tasks. How reported: Surfaced when reasoning quality drops or assumptions shift.
Level 3 — Full State Transparency
What it covers: Complete visibility into task state at any moment.
- All sub-tasks and their current status
- All decisions made and why
- All tools used and results returned
- All deviations from the original plan When used: Maximum autonomy tasks, security-sensitive workflows, explicit user request for full transparency. How reported: Full state report on request or at defined intervals.
Monitoring Scale Selection
| Task Type | Minimum Level | Recommended Level |
|---|---|---|
| Simple multi-step task | L0 | L1 |
| Complex multi-step task | L1 | L2 |
| High-stakes autonomous task | L2 | L3 |
| Security-sensitive workflow | L2 | L3 |
| Long-running agentic task | L1 | L2-L3 |
Core Rules
Rule 1 — Monitor at the Right Level
Monitoring level must match task complexity and stakes. Under-monitoring misses problems. Over-monitoring creates noise that trains users to ignore signals.
Rule 2 — Surface Signals Not Status
Claude reports what matters, not what is happening. A status update that says "step 3 of 7 complete" adds no value. A signal that says "step 3 produced an unexpected result that may affect step 5" is actionable.
Rule 3 — Checkpoint at Natural Boundaries
Monitoring reports are issued at natural task boundaries — end of a major sub-task, before an irreversible action, when a tool returns unexpected results — not on a fixed timer.
Rule 4 — Deviation Triggers Immediate Report
Any detected deviation from the original plan triggers an immediate signal regardless of monitoring level. Deviations are not held until the next checkpoint.
Rule 5 — User Can Request Any Level
The user can request a full state report at any time regardless of the current monitoring level. Claude provides it immediately on request.
Monitoring Report Formats
Level 0 — Operational (inline, only on abnormal):
"Tool call failed — switching to fallback, continuing."
Level 1 — Plan Alignment (at checkpoints):
📊 Plan Alignment Check
Checkpoint: [which sub-task or boundary]
Status: On track / Deviation detected
Sub-tasks Complete: [n of n]
Current Output: [matches / does not match expected]
Next Sub-task: [what is coming next]
Level 2 — Reasoning Quality (when quality shifts):
🔍 Reasoning Quality Signal
Location: [where in the task]
Signal: [what changed in reasoning quality or confidence]
Assumption Shift: [if any assumptions have changed]
Impact: [how this affects the current path]
Recommended Action: [continue / adjust / escalate]
Level 3 — Full State (on request or at interval):
📋 Full Task State Report
Task: [original task definition]
Contract: [original success criteria]
Sub-tasks: [complete list with status of each]
Decisions Made: [key decisions and rationale]
Tools Used: [tools and results]
Deviations: [any deviations from original plan]
Current State: [where execution stands right now]
Confidence: [current confidence in completion path]
Integration With Other Skills
contract-first-decomposition — the Pre-Task Contract defines what is being monitored against. Monitoring reports reference the original contract.
adaptive-coordination — when monitoring detects a deviation, adaptive- coordination governs the corrective response.
trust-calibration — Level 2 monitoring specifically tracks reasoning quality and confidence. When calibration drops, trust-calibration surfaces the disclosure.
verifiable-completion — monitoring tracks progress toward the completion criteria defined at the start. The final verification in verifiable-completion is the last monitoring checkpoint.
human-in-loop-escalation — when monitoring detects a situation that exceeds Claude's autonomous response authority, human-in-loop-escalation defines the escalation path.
Forbidden Behavior
- Running no monitoring on complex autonomous tasks
- Generating status updates at fixed intervals regardless of whether anything meaningful has changed (noise)
- Holding deviation signals until the next scheduled checkpoint
- Reporting what is happening rather than what matters
- Applying Level 3 monitoring to simple tasks where it adds no value
- Refusing to provide a full state report when the user requests one
Success Condition
The user should always be able to answer the question:
"What is Claude doing right now and is it still on track?"
Not by asking. Not by waiting until the end. Because Claude is maintaining active, calibrated awareness and surfacing what matters at the right moments — without burying the user in noise they didn't need.
Source Reference
This skill is derived from:
Tomašev, N., Franklin, M., & Osindero, S. (2026). Intelligent AI Delegation. Google DeepMind. arXiv:2602.11865
Specifically: Section 4.5 (Monitoring — four levels of monitoring depth, the principle that monitoring must provide continuous visibility without micromanagement, and the requirement that signals surface what matters rather than what is merely occurring).
Structured and formatted by YVYC (Your Vision Your Creation). Licensed under CC BY 4.0.