Menu
Accumulated debugging patterns learned from real failures. Consulted by health-fix before attempting fixes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
THE dev loop — handles both greenfield (analyst → discovery → build) and brownfield (deep project immersion → lean spec → build). Replaces work-loop as the single entry point for all Hermes dev work.
Progress-aware error resolution with web research escalation and solution learning. Fixes lint/TS/build errors without arbitrary iteration limits. Called by work-loop and vibe-loop.
Auto-detect project software stack and write a machine-readable stack context block into AGENTS.md. Runs during work-loop health check so Pi always knows the correct test runner, build tool, and conventions.
Based on SOC occupation classification
| name | learned-fixes |
| description | Accumulated debugging patterns learned from real failures. Consulted by health-fix before attempting fixes. |
| version | 1.0.0 |
| metadata | {"hermes":{"tags":["debugging","patterns","learned","knowledge-base"],"related_skills":["dev-team/health-fix","dev-team/work-loop"]}} |
These patterns were learned from real failures during development. Health-fix and work-loop should consult these BEFORE attempting to fix an error — the solution may already be known.
Signal: The exact same test failure message appears after 3+ different fix attempts.
Wrong approach: Keep modifying the code that seems related to the error message.
Right approach: The error message is misleading. The bug is likely in a DIFFERENT part of the code than what the error message points to. Stop. Read the full code path from test input to error output. Trace the actual execution flow, not what the error message suggests.
Example: recipeImportRecovery.ts — test expected strategyUsed: MICRODATA but got MANUAL_FALLBACK. 60 iterations were spent rewriting the microdata regex pattern. The actual bug was match[1] (tag name) instead of match[2] (content) — a capture group index error, not a regex pattern error. The regex was fine all along.
Rule: If the same error persists after 3 genuinely different regex/pattern fixes, the bug is NOT in the pattern. Check array indices, capture group numbers, variable names, and data flow.
Signal: Regex test tools show the pattern matches correctly, but the code still fails.
Check: Are you reading match[1] when you should be reading match[2]? Count the capture groups in the regex:
match[0] = full matchmatch[1] = first (...) groupmatch[2] = second (...) groupExample: /<(tag).*?>(content)<\/\1>/ has TWO groups. Group 1 is the tag name, Group 2 is the content. Reading match[1] gives you "div", not the HTML content.
Signal: expect(obj.field).toBe(something) fails because obj.field is undefined.
Check in order:
field?:) in the interface? If yes, the code path may not set it.userContext vs user_context vs context)Example: userContext was undefined in escalation calls because handleNovelError() didn't include it in the object passed to notifyEscalation(). The interface allowed it (optional ?), the caller provided it, but one function in the chain didn't forward it.
Signal: health-fix THRASH detection fires — same file edited 3+ times.
Right approach: Stop patching. Read the ENTIRE file from top to bottom. Understand the full control flow. The bug is in the logic flow, not in the line you keep editing. Write out the execution path as comments before making another change.