agent-introspection-debugging

Name: agent-introspection-debugging
Author: affaan-m

1.2kinstalls35kforks

How to install agent-introspection-debugging?

affaan-m/ecc/agent-introspection-debugging

$npx -y skills add affaan-m/ECC --skill agent-introspection-debugging

Installs into the current project.

Summary

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.

Files · 1

View on GitHub

SKILL.md

1	# Agent Introspection Debugging
2
3	Use this skill when an agent run is failing repeatedly, consuming tokens without progress, looping on the same tools, or drifting away from the intended task.
4
5	This is a workflow skill, not a hidden runtime. It teaches the agent to debug itself systematically before escalating to a human.
6
7	## When to Activate
8
9	- Maximum tool call / loop-limit failures
10	- Repeated retries with no forward progress
11	- Context growth or prompt drift that starts degrading output quality
12	- File-system or environment state mismatch between expectation and reality
13	- Tool failures that are likely recoverable with diagnosis and a smaller corrective action
14
15	## Scope Boundaries
16
17	Activate this skill for:
18	- capturing failure state before retrying blindly
19	- diagnosing common agent-specific failure patterns
20	- applying contained recovery actions
21	- producing a structured human-readable debug report
22
23	Do not use this skill as the primary source for:
24	- feature verification after code changes; use `verification-loop`
25	- framework-specific debugging when a narrower ECC skill already exists
26	- runtime promises the current harness cannot enforce automatically
27
28	## Four-Phase Loop
29
30	### Phase 1: Failure Capture
31
32	Before trying to recover, record the failure precisely.
33
34	Capture:
35	- error type, message, and stack trace when available
36	- last meaningful tool call sequence
37	- what the agent was trying to do
38	- current context pressure: repeated prompts, oversized pasted logs, duplicated plans, or runaway notes
39	- current environment assumptions: cwd, branch, relevant service state, expected files
40
41	Minimum capture template:
42
43	```markdown
44	## Failure Capture
45	- Session / task:
46	- Goal in progress:
47	- Error:
48	- Last successful step:
49	- Last failed tool / command:
50	- Repeated pattern seen:
51	- Environment assumptions to verify:
52	```
53
54	### Phase 2: Root-Cause Diagnosis
55
56	Match the failure to a known pattern before changing anything.
57
58	\| Pattern \| Likely Cause \| Check \|
59	\| --- \| --- \| --- \|
60	\| Maximum tool calls / repeated same command \| loop or no-exit observer path \| inspect the last N tool calls for repetition \|
61	\| Context overflow / degraded reasoning \| unbounded notes, repeated plans, oversized logs \| inspect recent context for duplication and low-signal bulk \|
62	\| `ECONNREFUSED` / timeout \| service unavailable or wrong port \| verify service health, URL, and port assumptions \|
63	\| `429` / quota exhaustion \| retry storm or missing backoff \| count repeated calls and inspect retry spacing \|
64	\| file missing after write / stale diff \| race, wrong cwd, or branch drift \| re-check path, cwd, git status, and actual file existence \|
65	\| tests still failing after “fix” \| wrong hypothesis \| isolate the exact failing test and re-derive the bug \|
66
67	Diagnosis questions:
68	- is this a logic failure, state failure, environment failure, or policy failure?
69	- did the agent lose the real objective and start optimizing the wrong subtask?
70	- is the failure deterministic or transient?
71	- what is the smallest reversible action that would validate the diagnosis?
72
73	### Phase 3: Contained Recovery
74
75	Recover with the smallest action that changes the diagnosis surface.
76
77	Safe recovery actions:
78	- stop repeated retries and restate the hypothesis
79	- trim low-signal context and keep only the active goal, blockers, and evidence
80	- re-check the actual filesystem / branch / process state
81	- narrow the task to one failing command, one file, or one test
82	- switch from speculative reasoning to direct observation
83	- escalate to a human when the failure is high-risk or externally blocked
84
85	Do not claim unsupported auto-healing actions like “reset agent state” or “update harness config” unless you are actually doing them through real tools in the current environment.
86
87	Contained recovery checklist:
88
89	```markdown
90	## Recovery Action
91	- Diagnosis chosen:
92	- Smallest action taken:
93	- Why this is safe:
94	- What evidence would prove the fix worked:
95	```
96
97	### Phase 4: Introspection Report
98
99	End with a report that makes the recovery legible to the next agent or human.
100
101	```markdown
102	## Agent Self-Debug Report
103	- Session / task:
104	- Failure:
105	- Root cause:
106	- Recovery action:
107	- Result: success \| partial \| blocked
108	- Token / time burn risk:
109	- Follow-up needed:
110	- Preventive change to encode later:
111	```
112
113	## Recovery Heuristics
114
115	Prefer these interventions in order:
116
117	1. Restate the real objective in one sentence.
118	2. Verify the world state instead of trusting memory.
119	3. Shrink the failing scope.
120	4. Run one discriminating check.
121	5. Only then retry.
122
123	Bad pattern:
124	- retrying the same action three times with slightly different wording
125
126	Good pattern:
127	- capture failure
128	- classify the pattern
129	- run one direct check
130	- change the plan only if the check supports it
131
132	## Integration with ECC
133
134	- Use `verification-loop` after recovery if code was changed.
135	- Use `continuous-l

People who liked this also viewed

6 picks

Type

azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026472k1.3k
systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026197k259k
safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026161k507
explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026161k507
minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026161k507
insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 202618k31

agent-introspection-debugging

1.2kinstalls35kforks

View on GitHub

How to install agent-introspection-debugging?

affaan-m/ecc/agent-introspection-debugging

$npx -y skills add affaan-m/ECC --skill agent-introspection-debugging

Installs into the current project.

Summary

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.

Files · 1

View on GitHub

SKILL.md

1	# Agent Introspection Debugging
2
3	Use this skill when an agent run is failing repeatedly, consuming tokens without progress, looping on the same tools, or drifting away from the intended task.
4
5	This is a workflow skill, not a hidden runtime. It teaches the agent to debug itself systematically before escalating to a human.
6
7	## When to Activate
8
9	- Maximum tool call / loop-limit failures
10	- Repeated retries with no forward progress
11	- Context growth or prompt drift that starts degrading output quality
12	- File-system or environment state mismatch between expectation and reality
13	- Tool failures that are likely recoverable with diagnosis and a smaller corrective action
14
15	## Scope Boundaries
16
17	Activate this skill for:
18	- capturing failure state before retrying blindly
19	- diagnosing common agent-specific failure patterns
20	- applying contained recovery actions
21	- producing a structured human-readable debug report
22
23	Do not use this skill as the primary source for:
24	- feature verification after code changes; use `verification-loop`
25	- framework-specific debugging when a narrower ECC skill already exists
26	- runtime promises the current harness cannot enforce automatically
27
28	## Four-Phase Loop
29
30	### Phase 1: Failure Capture
31
32	Before trying to recover, record the failure precisely.
33
34	Capture:
35	- error type, message, and stack trace when available
36	- last meaningful tool call sequence
37	- what the agent was trying to do
38	- current context pressure: repeated prompts, oversized pasted logs, duplicated plans, or runaway notes
39	- current environment assumptions: cwd, branch, relevant service state, expected files
40
41	Minimum capture template:
42
43	```markdown
44	## Failure Capture
45	- Session / task:
46	- Goal in progress:
47	- Error:
48	- Last successful step:
49	- Last failed tool / command:
50	- Repeated pattern seen:
51	- Environment assumptions to verify:
52	```
53
54	### Phase 2: Root-Cause Diagnosis
55
56	Match the failure to a known pattern before changing anything.
57
58	\| Pattern \| Likely Cause \| Check \|
59	\| --- \| --- \| --- \|
60	\| Maximum tool calls / repeated same command \| loop or no-exit observer path \| inspect the last N tool calls for repetition \|
61	\| Context overflow / degraded reasoning \| unbounded notes, repeated plans, oversized logs \| inspect recent context for duplication and low-signal bulk \|
62	\| `ECONNREFUSED` / timeout \| service unavailable or wrong port \| verify service health, URL, and port assumptions \|
63	\| `429` / quota exhaustion \| retry storm or missing backoff \| count repeated calls and inspect retry spacing \|
64	\| file missing after write / stale diff \| race, wrong cwd, or branch drift \| re-check path, cwd, git status, and actual file existence \|
65	\| tests still failing after “fix” \| wrong hypothesis \| isolate the exact failing test and re-derive the bug \|
66
67	Diagnosis questions:
68	- is this a logic failure, state failure, environment failure, or policy failure?
69	- did the agent lose the real objective and start optimizing the wrong subtask?
70	- is the failure deterministic or transient?
71	- what is the smallest reversible action that would validate the diagnosis?
72
73	### Phase 3: Contained Recovery
74
75	Recover with the smallest action that changes the diagnosis surface.
76
77	Safe recovery actions:
78	- stop repeated retries and restate the hypothesis
79	- trim low-signal context and keep only the active goal, blockers, and evidence
80	- re-check the actual filesystem / branch / process state
81	- narrow the task to one failing command, one file, or one test
82	- switch from speculative reasoning to direct observation
83	- escalate to a human when the failure is high-risk or externally blocked
84
85	Do not claim unsupported auto-healing actions like “reset agent state” or “update harness config” unless you are actually doing them through real tools in the current environment.
86
87	Contained recovery checklist:
88
89	```markdown
90	## Recovery Action
91	- Diagnosis chosen:
92	- Smallest action taken:
93	- Why this is safe:
94	- What evidence would prove the fix worked:
95	```
96
97	### Phase 4: Introspection Report
98
99	End with a report that makes the recovery legible to the next agent or human.
100
101	```markdown
102	## Agent Self-Debug Report
103	- Session / task:
104	- Failure:
105	- Root cause:
106	- Recovery action:
107	- Result: success \| partial \| blocked
108	- Token / time burn risk:
109	- Follow-up needed:
110	- Preventive change to encode later:
111	```
112
113	## Recovery Heuristics
114
115	Prefer these interventions in order:
116
117	1. Restate the real objective in one sentence.
118	2. Verify the world state instead of trusting memory.
119	3. Shrink the failing scope.
120	4. Run one discriminating check.
121	5. Only then retry.
122
123	Bad pattern:
124	- retrying the same action three times with slightly different wording
125
126	Good pattern:
127	- capture failure
128	- classify the pattern
129	- run one direct check
130	- change the plan only if the check supports it
131
132	## Integration with ECC
133
134	- Use `verification-loop` after recovery if code was changed.
135	- Use `continuous-l

People who liked this also viewed

6 picks

Type