# Omh App Debugging

[omh] Application code misbehaves -- a wrong value, a flaky test, a lost update...

- Repository: https://github.com/rlaope/oh-my-hermes (5004 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rlaope/oh-my-hermes --skill omh-app-debugging -g -a claude-code -y`
Codex: `npx skills add rlaope/oh-my-hermes --skill omh-app-debugging -g -a codex -y`
Cursor: `npx skills add rlaope/oh-my-hermes --skill omh-app-debugging -g -a cursor -y`
Gemini CLI: `npx skills add rlaope/oh-my-hermes --skill omh-app-debugging -g -a gemini-cli -y`

## Description

[omh] Application code misbehaves -- a wrong value, a flaky test, a lost update: reproduce it first, form competing hypotheses, discriminate them with the cheapest observation, and only then fix the demonstrated root cause. Use when the user says: app-debugging, app debugging, application debugging, root cause, root-cause, find the root cause, root cause analysis, flaky test.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/rlaope/oh-my-hermes/blob/HEAD/agent-skills/omh-app-debugging/SKILL.md