Menú
Systematic debugging. Reproduce first, isolate second, fix third. Never guess.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
The operating system for Forward Deployed Engineers. 34 skills across 6 domains — from first meeting to final handoff. Tell it your situation, it routes to the right skill, does the work, and the engagement memory writes itself.
Taking over mid-engagement. Reads what exists, separates what works from what was assumed.
Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code.
End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it.
Generate a status dashboard across all active engagements from .fde/ data.
Find the real problem. Map the codebase. The brief is a hypothesis until evidence confirms it.
| name | fde-debug |
| description | Systematic debugging. Reproduce first, isolate second, fix third. Never guess. |
Debugging on an engagement is different from debugging your own code. You don't have full context, you don't know the history, and the pressure to just fix it is high. That pressure is the enemy. The engineers who guess-and-check under pressure cause the second incident. This skill enforces the right sequence.
Load context.md, terrain.md, and chaos-log.md only. Do not load decisions.md or delivery.md -- they add noise when you need focus. Pull specific module context only when you have isolated the failure to a specific area.
First nail down repro — "Can you break it on demand right now?" If not, that's the work before the fix: logging, narrowing, making it repeatable.
Get a consistent reproduction case before looking at any code. If you can't reproduce it, instrument first, add logging, not fixes. An unreproducible bug that gets "fixed" will be back.
Strip away everything that isn't the failure. If the bug is in a payment flow, does it happen with a single hard-coded test transaction? Smallest failing case means smallest context needed, and smallest blast radius when you fix it.
Before reading any code, answer: what changed in the last 2 hours, 24 hours, last deploy? This single question solves 70% of production bugs. Check chaos-log.md first, if this has happened before, the cause is probably the same.
Don't read the codebase like a book. Write a script that answers a specific question: "what files were modified in the last deploy?" One execution, one answer. That's the code-first analysis approach, don't read 50 files to find one changed line.
Not three. One. The most specific, most testable explanation for the failure. State it explicitly before doing anything:
"My hypothesis is X. If I'm right, then changing Y will fix it. If I'm wrong, the symptom will persist."
A hypothesis that can't be falsified is not a hypothesis.
The failure mode that surfaces is rarely the root cause. A 500 error is a symptom. An NPE is a symptom. The root cause is upstream. Fix upstream. If you patch the symptom, you'll be back here in a week.
After fixing: does the reproduction case pass? Does anything adjacent break? Run the smallest viable test suite, not the full suite if it takes 45 minutes, but the tests covering the changed code plus the downstream callers.
Define success before declaring done: repro case passes, named test command green, no new errors in logs for N minutes. Weak criteria ("seems fixed") require another cycle.
They'll ask for status before you have it. Coach tone and substance, not a script.
Give them: what's narrowed, what's ruled out, what's being tested next, when they'll hear from you again — specific time, not "soon."
Avoid sounding lost: "I'm not sure" without context spooks people. Partial clarity beats raw uncertainty.
Proactive updates if you're past your own deadline — don't make them chase you.
Phrases that hurt (tell the FDE to skip these): vague "might be…", "weird one", "never seen this", "shouldn't do that" — they add heat, not information.
Fix without root cause: stabilise honestly; don't close the incident story until you can explain why — offer that in normal language, not legalese.
After every debugging session, log in chaos-log.md:
This is not optional. The next FDE who hits this system needs to know.
chaos-log.md: root cause, fix applied, recurrence risk.
