openlore-debug

openlore: Debug

When to use this skill

Trigger this skill when the user reports a bug or unexpected behaviour on a codebase that has openlore analysis available, with phrasings like:

• "this is broken"
• "X is not working"
• "something is wrong with Y"
• "debug this"
• explicit command /openlore-debug

The rule: form an explicit hypothesis before reading any code. Do not browse files speculatively.

Prerequisite: openlore analysis must exist (openlore analyze has been run). If orient returns "error": "no cache" → run analyze_codebase first, then retry.

---

Step 1 — Reproduce

Ask the user for:

1. Steps to reproduce — minimal sequence that triggers the bug
2. Expected behaviour — what should happen
3. Observed behaviour — what actually happens
4. $PROJECT_ROOT — project root directory

Do not proceed to Step 2 until all four are known.

If the user cannot reproduce the bug reliably, note it and proceed anyway — but flag that the fix may be speculative until reproduction is confirmed.

Capture:

• $BUG_DESCRIPTION — one-line summary of the symptom (e.g. "payment retry does not reset counter after success")
• $REPRO_STEPS — reproduction sequence

---

Step 2 — Orient

Call the openlore MCP tool orient with:

{
  "directory": "$PROJECT_ROOT",
  "task": "$BUG_DESCRIPTION",
  "limit": 7
}

Extract:

• $CANDIDATE_FUNCTIONS — top 3–5 functions structurally related to the symptom
• $DOMAINS_AFFECTED — spec domains involved
• $CALL_PATHS — call chains relevant to the symptom

---

Step 3 — Search specs

If openspec/specs/ exists:

Call the openlore MCP tool search_specs with:

{
  "directory": "$PROJECT_ROOT",
  "query": "$BUG_DESCRIPTION",
  "limit": 5
}

Look for:

• Documented constraints that the buggy behaviour violates
• Requirements that define what "correct" means for $DOMAINS_AFFECTED
• Known edge cases documented in the spec that may explain the symptom