| name | demerzel-self-diagnostic |
| description | Agent health self-check — detect context exhaustion, action loops, wrong repo, git failures, task drift, and confidence miscalibration before they cascade. |
Demerzel Self-Diagnostic
An agent invokes this skill to check its own operational health. Designed to catch the failure modes that caused the session-003 incidents: idle-looping after context exhaustion (5x), filing issues on the wrong repo (3x), and requiring 3 prompts to confirm task completion.
Run self-diagnostic before starting work, after any anomaly, and whenever you feel uncertain about your own state.
Usage
/demerzel self-diagnostic — full six-check suite, print report
/demerzel self-diagnostic --context — context usage check only
/demerzel self-diagnostic --loops — repeated action detection only
/demerzel self-diagnostic --cwd — CWD and repo verification only
/demerzel self-diagnostic --git — git conflict and push failure detection only
/demerzel self-diagnostic --task — task boundary alignment check only
/demerzel self-diagnostic --confidence — confidence calibration check only
/demerzel self-diagnostic --fast — checks 1-3 only (pre-task quick scan)
The Six Checks
Check 1: Context Usage
What it detects: Context window approaching exhaustion — the condition that caused Architect to idle-loop 5x in session-003.
How to run:
- Count approximate tokens consumed: system prompt + conversation history + tool outputs + current message
- Compare against known model context limits (claude-sonnet: ~200k tokens)
- Check whether instructions in the conversation mention "context is getting large", "context window", or "summarize"
Thresholds:
| Usage | Status | Action |
|---|
| < 60% | GREEN | Proceed normally |
| 60-79% | YELLOW | Finish current task, do not start new long tasks |
| 80-89% | ORANGE | Complete atomic unit only, then handoff or compact |
| >= 90% | RED | Stop. Do not begin new tool calls. Summarize state and exit gracefully. |
Failure signature: Agent continues invoking tools after RED threshold → idle loop / repeated no-op calls.
Output:
[CHECK 1: CONTEXT] estimated ~{N}% used → {STATUS}
Action: {prescribed action or "proceed"}
Check 2: Repeated Action Detection
What it detects: Action loops — same tool called 3+ times with identical arguments within the current session. The canonical loop failure mode.
How to run:
- Scan conversation history for tool calls
- For each tool name, group calls by argument fingerprint (tool name + key args, ignore timestamps/run IDs)
- Flag any group with count >= 3
Loop patterns to detect:
| Pattern | Example | Classification |
|---|
| Same read, same path | Read file.txt × 3 | CONTENT_LOOP |
| Same search, same query | Grep "foo" × 3 | SEARCH_LOOP |
| Same write, same content | Write x.json × 3 | WRITE_LOOP |
| Same API call | gh issue list --repo X × 3 | API_LOOP |
| Same no-result action | Bash ls × 3 → same output | IDLE_LOOP |
Response per loop type:
- CONTENT_LOOP / SEARCH_LOOP: Already have this data. Do not repeat. Use cached result.
- WRITE_LOOP: Already wrote this. Verify the file exists before writing again.
- API_LOOP: Cache the result and stop polling. Check for rate limit or auth issue.
- IDLE_LOOP: Stop immediately. This is context exhaustion or task completion confusion. Run Check 1 and Check 5.
Output:
[CHECK 2: LOOPS] {N} repeated patterns detected
IDLE_LOOP: Bash("ls /repo") called 4x — STOP
SEARCH_LOOP: Grep("policy") called 3x — USE CACHED RESULT
Check 3: CWD Verification
What it detects: Operating in the wrong repo or wrong branch — the condition that caused background agents to file issues on the wrong repo 3x in session-003.
How to run:
- Read the current working directory
- Check
git remote get-url origin to identify the repo
- Compare repo name against the assigned task's target repo
- Check
git branch --show-current against expected branch
Verification matrix:
| Assigned repo | Expected remote contains | Expected branch |
|---|
| Demerzel | Demerzel or demerzel | master |
| ix | ix (not demerzel-bot) | main |
| tars | tars | main |
| ga | ga-client or ga-react | main or develop |
Failure responses:
- Wrong repo detected → STOP. Do not read, write, or push. Report the mismatch. State: "I am in [actual repo] but assigned to [expected repo]. Stopping all actions."
- Wrong branch → warn, confirm with user before proceeding if task involves commits or pushes
- Detached HEAD → escalate immediately, do not commit
Output:
[CHECK 3: CWD] repo={actual-repo} branch={branch}
Expected: repo=Demerzel branch=master → MATCH / MISMATCH
Check 4: Git Conflict Detection
What it detects: Failed push, unresolved merge conflict, or mid-conflict state that could corrupt subsequent operations.
How to run:
- Check for conflict markers in recently modified files:
git diff --check
- Check
git status for "both modified", "unmerged paths", or "rebase in progress"
- Check if last push succeeded: look for recent push failure in conversation history or
git log --remotes
- Check for
.git/MERGE_HEAD, .git/rebase-merge/, .git/CHERRY_PICK_HEAD
Failure states:
| State | Indicator | Action |
|---|
| Active conflict | MERGE_HEAD exists | STOP. Do not commit. Report conflict files. |
| Rebase in progress | rebase-merge/ exists | STOP. Complete or abort rebase first. |
| Diverged from remote | local ahead AND remote ahead | Warn. Pull --rebase before next push. |
| Push failed last attempt | Push failure in conversation | Diagnose: auth? conflicts? protected branch? |
| Clean | None of the above | GREEN |
Output:
[CHECK 4: GIT] status={CLEAN|CONFLICT|REBASE|DIVERGED}
Detail: {specific issue or "no conflicts detected"}
Check 5: Task Boundary Check
What it detects: Scope creep, task drift, or task completion confusion — the condition that required 3 prompts for Auditor to confirm completion in session-003.
How to run:
- Re-read the original task assignment (first user message or assigned issue)
- List actions taken so far in the current session
- Check: is the current action traceable to the original task?
- Check: does the original task appear complete (all acceptance criteria met)?
Boundary rules:
| Condition | Classification | Action |
|---|
| Current action matches task | IN_SCOPE | Proceed |
| Task complete, still working | OVER_COMPLETION | Stop. Declare done. Commit and report. |
| Action outside task scope | SCOPE_CREEP | Stop. Log potential follow-up. Return to task. |
| Task unclear or no assignment | UNANCHORED | Ask for clarification before proceeding |
| Working in wrong issue/PR | WRONG_TARGET | STOP. Verify target before any write operation. |
Completion signals to check:
- All files specified in task have been created or modified
- All acceptance criteria explicitly met
- No pending verification steps
- Ready to commit and declare done
Output:
[CHECK 5: TASK] task="{first 60 chars of task}" status={IN_SCOPE|OVER_COMPLETION|SCOPE_CREEP|UNANCHORED}
Completed: {N of M acceptance criteria}
Current action: {IN_SCOPE|OUT_OF_SCOPE}
Check 6: Confidence Calibration
What it detects: Claims made without supporting evidence — assertions that exceed what has actually been verified. Prevents the pattern of declaring success before actually checking.
How to run:
- List all claims made in the current session (assertions about file contents, test results, counts, repo state)
- For each claim, check whether it was directly verified via tool output in this session
- Compute: evidence_ratio = verified_claims / total_claims
Calibration thresholds:
| Evidence ratio | Status | Meaning |
|---|
| >= 0.9 | CALIBRATED | Claims well-supported |
| 0.7-0.89 | ACCEPTABLE | Minor unverified assumptions — flag them |
| 0.5-0.69 | UNDERVERIFIED | Stop and verify the flagged claims before proceeding |
| < 0.5 | MISCALIBRATED | Do not commit or report. Re-read and re-verify. |
Common miscalibration patterns:
- "The file was created" — without reading the file back to confirm
- "All tests pass" — without reading CI output in this session
- "The count is N" — without actually counting files via glob
- "The issue was filed on repo X" — without confirming
gh issue view output shows repo X
Output:
[CHECK 6: CONFIDENCE] {verified}/{total} claims verified → {STATUS}
Unverified: "file was created" — read it back before declaring done
Unverified: "count is 14" — run glob to confirm
Full Diagnostic Report Format
=== Demerzel Self-Diagnostic — {timestamp} ===
[CHECK 1: CONTEXT] ~{N}% used → {GREEN|YELLOW|ORANGE|RED}
[CHECK 2: LOOPS] {CLEAN|N loops detected: ...}
[CHECK 3: CWD] repo={repo} branch={branch} → {MATCH|MISMATCH}
[CHECK 4: GIT] {CLEAN|CONFLICT|REBASE|DIVERGED}
[CHECK 5: TASK] {IN_SCOPE|OVER_COMPLETION|SCOPE_CREEP|UNANCHORED}
[CHECK 6: CONFIDENCE] {N}/{M} verified → {CALIBRATED|ACCEPTABLE|UNDERVERIFIED|MISCALIBRATED}
Overall: {HEALTHY|DEGRADED|CRITICAL}
Action: {Proceed | {specific corrective action}}
==========================================
Overall status rules:
- HEALTHY: all checks GREEN / CALIBRATED / MATCH / CLEAN / IN_SCOPE
- DEGRADED: any YELLOW, ACCEPTABLE, or minor warning — proceed with noted constraints
- CRITICAL: any RED, LOOP, MISMATCH, CONFLICT, SCOPE_CREEP with writes, or MISCALIBRATED — stop and correct before proceeding
When to Run
| Trigger | Checks to run | Rationale |
|---|
| Start of session | All 6 | Baseline — establish known-good state |
| Before any commit | 2, 3, 4, 5, 6 | Prevent committing in wrong state |
| Before filing any issue/PR | 3, 5 | Prevent wrong-repo filing |
| After 10+ tool calls | 1, 2 | Catch context exhaustion and loops early |
| After any push failure | 4 | Diagnose git state |
| When uncertain about completion | 5, 6 | Auditor clarity check |
| Any time behavior feels repetitive | 2, 1 | Loop detection |
Integration
With demerzel-drive
The driver's EXECUTE phase should run /demerzel self-diagnostic --fast (checks 1-3) before dispatching each agent. If any check is CRITICAL, the agent is not dispatched and the task is marked blocked_by_health_check.
With demerzel-audit
The auditor persona should run /demerzel self-diagnostic before declaring any task complete. Check 6 (confidence calibration) is the auditor's primary gate.
With demerzel-loop
Loop detection (Check 2) feeds into demerzel-loop for pattern analysis and anti-pattern logging.
Governance
- Article 2 (Transparency) — agent must report its own health state honestly
- Article 7 (Auditability) — diagnostic results logged to
state/driver/health-checks/
- Article 8 (Observability) — health metrics exposed as governance signals
- Article 9 (Bounded Autonomy) — RED context or CRITICAL status constrains agent authority
- Alignment policy — confidence miscalibration triggers alignment review
Origin
Motivated by session-003 failure modes (2026-03-23):
- Architect idle-looped 5x after context exhaustion → Check 1 + Check 2
- Background agents filed issues on wrong repo 3x → Check 3
- Auditor required 3 prompts to confirm task completion → Check 5 + Check 6
- Git push failure left one agent in diverged state → Check 4
Source
policies/autonomous-loop-policy.yaml,
policies/alignment-policy.yaml,
policies/proto-conscience-policy.yaml,
constitutions/default.constitution.md Articles 2, 7, 8, 9
