App Debugging

This is an OMH app-debugging workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).

Why This Exists

app-debugging exists because a wrong result in application code had no owner: native-debugging covers native binaries, build-failure-triage covers red builds, and agent-debug covers agent misbehaviour, so the most common debugging request dispatched straight to an execution lane that skipped the diagnosis.

First Steps

• Ask for, or plan, the one command that shows the wrong behaviour, and record its observed output before naming a cause.
• Refuse to prepare a fix while the reproduction reads not_observed; plan the observation that would establish it instead.

Do Not Use When

• The fault is a crash, memory corruption, or core dump in a compiled native binary that needs a debugger session; use omh-native-debugging.
• The build, compile, or CI job fails the same way on every run; use omh-build-failure-triage.
• The subject is an agent or workflow run that misbehaved rather than the application code; use omh-agent-debug.
• The cause is already demonstrated and the request is to judge whether the fix is proven; use omh-verification-gate.

Examples

Good example:

• Prompt: a test fails one run in five in CI, how do I find out why
• Expected behavior: Prepare reproduction_record/v1 with the loop that measures the failure rate, competing_hypotheses/v1 across ordering, shared state, timing, and environment, and the cheapest observation that splits them; no fix yet.
• Why: The failure is intermittent, so the first deliverable is a measured reproduction rather than a patch.

Bad example:

• Prompt: add a sleep before the assertion so the flaky test passes
• Expected behavior: Record the sleep as a symptom mask, keep root cause open, and plan the observation that names the race.
• Why: A timing change that hides the failure leaves the fault in place and removes the reproduction.