fullsend-ai · ralphbean · Apr 29, 2026
@@ -0,0 +1,83 @@
+# Triage Strategy: OMC Deep Interview (adapted from oh-my-claudecode)
+
+Source: [Yeachan-Heo/oh-my-claudecode](https://github.com/Yeachan-Heo/oh-my-claudecode) `/deep-interview` skill
+
+## Approach
+
+Adapts oh-my-claudecode's deep-interview skill for issue triage. The original
+skill uses mathematical ambiguity gating with weighted clarity dimensions and
+Socratic questioning. It scores clarity after each answer and targets the
+weakest dimension with each question. It also deploys "challenge agent modes"
+at specific round thresholds to break out of local optima.
+
+For issue triage, we adapt the clarity dimensions from feature design to bug
+investigation.
+
+## Clarity dimensions (adapted for bug triage)
+
+Score each dimension 0.0-1.0 after every exchange:
+
+| Dimension | Weight | What it measures |
+|-----------|--------|------------------|
+| Symptom Clarity | 35% | Do we know exactly what goes wrong? (error, crash, wrong output, performance) |
+| Cause Clarity | 30% | Do we have a plausible hypothesis for why? (trigger, conditions, root cause) |
+| Reproduction Clarity | 20% | Could a developer reproduce this from the information given? |
+| Impact Clarity | 15% | How severe is this? Who/what is affected? Is there a workaround? |
+
+## Ambiguity calculation
+
+```
+ambiguity = 1 - (symptom * 0.35 + cause * 0.30 + reproduction * 0.20 + impact * 0.15)
+```
+
+**Target: ambiguity <= 0.20** (i.e., 80% clarity)
+
+## Questioning rules
+
+1. **ONE question per turn.** Target the dimension with the lowest clarity score.
+2. **State which dimension you're targeting and why** in your internal reasoning,
+   but ask the question naturally (don't tell the reporter about dimensions).
+3. **Score clarity dimensions after each answer.** Track how clarity evolves.
+4. **Challenge modes** fire at specific rounds (see below).
+
+## Challenge agent modes
+
+Borrow oh-my-claudecode's challenge modes to break out of surface-level questioning:
+
+- **Round 3+ (Contrarian):** Consider the opposite of what the reporter claims.
+  "You say it crashes on save — does it also happen on auto-save, or only
+  manual save? What about 'save as'?"
+- **Round 4+ (Simplifier):** "What's the simplest scenario where this still
+  breaks? Can you reproduce it with a blank document?"
+- **Round 5+ (Ontologist):** Only if ambiguity > 0.3. Question fundamental
+  assumptions. "When you say 'save,' what exactly happens in the app? Does it
+  save to disk, to cloud, or both?"
+
+Each mode fires at most once.
+
+## Sufficiency criteria
+
+Resolve when:
+- Ambiguity <= 0.20, OR
+- All four dimensions are >= 0.7 individually, OR
+- You've reached round 5 and ambiguity <= 0.30 (good enough to act on)
+
+## When to stop asking
+
+Stop asking and resolve when sufficiency criteria are met. Include your final
+clarity scores in the triage summary.
+
+## Output format
+
+When resolving, include a "clarity_scores" field in your triage summary:
+```json
+{
+  "clarity_scores": {
+    "symptom": 0.9,
+    "cause": 0.8,
+    "reproduction": 0.85,
+    "impact": 0.75,
+    "overall_ambiguity": 0.15
+  }
+}
+```
@@ -0,0 +1,85 @@
+# Triage Strategy: OMO Prometheus (adapted from oh-my-openagent)
+
+Source: [code-yeongyu/oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent) Prometheus planner / ultrawork mode
+
+## Approach
+
+Adapts oh-my-openagent's Prometheus planner approach for issue triage. Prometheus
+acts as a "strategic planner that interviews like a real engineer" — it identifies
+scope and ambiguities before committing to a plan. The ultrawork philosophy
+emphasizes persistence: the agent does not stop until the task is done.
+
+For issue triage, this translates to: interview the reporter as a senior engineer
+would interview a user during incident response. Be thorough, structured, and
+direct. Don't accept vague answers — push for specifics.
+
+## Interview structure
+
+Follow this phased approach, adapted from Prometheus's planning interview:
+
+### Phase 1: Scope identification (first 1-2 questions)
+- Establish what component/feature is affected
+- Determine if this is a regression, new bug, or misunderstanding
+- Ask: "When did this start happening? Was it working before?"
+
+### Phase 2: Deep investigation (questions 2-4)
+- Drill into the specific failure mode
+- Ask for exact steps, exact error messages, exact context
+- Push back on vague answers: "You said 'it crashes' — what exactly happens?
+  Does the app close? Do you see an error dialog? Does it freeze?"
+- Cross-reference: "You mentioned you're on version X — can you confirm that
+  by checking [specific menu/command]?"
+
+### Phase 3: Hypothesis testing (questions 4-5)
+- Propose your working theory and ask the reporter to validate
+- "Based on what you've described, I think [hypothesis]. Does that match what
+  you're seeing?"
+- If the reporter pushes back, return to Phase 2 for the contested point
+
+### Phase 4: Resolution
+- Produce a triage summary with engineer-level detail
+- Include a clear "next steps" section
+- Rate confidence in the root cause hypothesis
+
+## Questioning rules
+
+1. **ONE question per turn.** Be direct and specific.
+2. **Do not accept vague answers.** If the reporter says "it doesn't work," ask
+   what specifically doesn't work. Push for concrete details.
+3. **Think like a senior engineer doing incident response.** What would you ask
+   if you were paged at 2am about this?
+4. **Reference prior answers.** "You mentioned X in your first response — can
+   you elaborate on that?"
+5. **Be empathetic but efficient.** Acknowledge the reporter's frustration but
+   stay focused on extracting actionable information.
+
+## Sufficiency criteria
+
+Resolve when you have:
+- A clear reproduction path (even if not step-by-step, at least "this happens
+  when doing X under conditions Y")
+- A root cause hypothesis with medium-to-high confidence
+- Enough context that a developer could start investigating without contacting
+  the reporter again
+- Severity assessment (who's affected, how badly, is there a workaround)
+
+## When to stop asking
+
+Stop when:
+- You have sufficient information per the criteria above, OR
+- The reporter cannot provide more detail (they've shared everything they know), OR
+- You're in Phase 3 and your hypothesis is confirmed or you have a good
+  alternative hypothesis
+
+## Confidence rating
+
+Include a confidence field in your resolution:
+```json
+{
+  "confidence": {
+    "root_cause": "high|medium|low",
+    "reproduction": "high|medium|low",
+    "severity_assessment": "high|medium|low"
+  }
+}
+```
@@ -0,0 +1,56 @@
+# Triage Strategy: Socratic Refinement
+
+Source: Custom — inspired by Socratic method combined with elements from
+superpowers brainstorming and general bug investigation techniques.
+
+## Approach
+
+Open-ended Socratic probing that starts from the reporter's intent and works
+inward. Rather than checking boxes, this strategy follows the thread of the
+conversation, asking deeper questions based on each answer.
+
+The goal is to discover information the reporter doesn't realize is relevant,
+by exploring the context around the bug rather than just its symptoms.
+
+## Questioning flow
+
+1. **Start with intent.** "What were you trying to accomplish when this happened?"
+   Understanding the task gives context that a symptom description alone misses.
+2. **Follow the thread.** Each answer suggests the next question. If the reporter
+   says "I was trying to save a large document," follow up on "large" — how large?
+   What kind of document? Did it work with smaller ones?
+3. **Probe assumptions.** The reporter may assume things ("it was working fine
+   before") — ask when "before" was. What changed? Did they update, reconfigure,
+   or change their usage pattern?
+4. **Explore the periphery.** Ask about what happened just before and just after
+   the problem. "What were you doing right before the crash? Did anything else
+   seem different?"
+5. **Synthesize and confirm.** After 2-3 questions, state your understanding back
+   to the reporter and ask if it's accurate. This catches misunderstandings early.
+
+## Questioning rules
+
+1. **One question per turn**, but it can be multi-part if the parts are closely
+   related (e.g., "Did it work before? If so, when did it stop working?").
+2. **Never ask a question the reporter has already answered.** Read all prior
+   comments carefully.
+3. **Prefer open-ended questions** that invite narrative ("tell me more about
+   what happened when...") over closed questions ("yes/no").
+4. **Be curious, not interrogating.** Frame questions as collaborative exploration,
+   not as demanding information.
+
+## Sufficiency criteria
+
+You have enough when you can tell a coherent story:
+- What the reporter was doing, and why
+- What went wrong, from their perspective
+- What's likely happening under the hood
+- What a developer should investigate or fix
+
+## When to stop asking
+
+Stop when:
+- You can tell the coherent story above, OR
+- The reporter's answers are becoming circular (they're sharing the same
+  information rephrased), OR
+- You've explored the key threads and additional questions would be tangential
@@ -0,0 +1,45 @@
+# Triage Strategy: Structured Triage (checklist baseline)
+
+Source: Custom baseline — represents the traditional "issue template" approach.
+
+## Approach
+
+A methodical checklist approach. Check whether each required piece of information
+is present. Ask for the first missing item. Move on when all items are present.
+
+This is the control group: it represents what a well-designed issue template
+would enforce, applied retroactively by an agent.
+
+## Required information checklist
+
+Check for each of these in the issue body and comments. Ask for the first
+missing item, in this priority order:
+
+1. **Expected behavior** — What did the reporter expect to happen?
+2. **Actual behavior** — What actually happened? (error message, incorrect output, crash, etc.)
+3. **Reproduction steps** — Step-by-step instructions to reproduce the issue.
+4. **Environment** — OS, browser, app version, relevant configuration.
+5. **Error messages / logs** — Any error output, stack traces, or log entries.
+6. **Frequency** — Does this happen every time, intermittently, or only under specific conditions?
+
+## Questioning rules
+
+1. Ask for ONE missing item per turn.
+2. Be specific about what you need. Instead of "can you provide more details?",
+   ask "what error message did you see when the app crashed?"
+3. If the reporter provides partial information, acknowledge what they gave
+   and ask specifically for the missing part.
+4. Do not re-ask for information already provided.
+
+## Sufficiency criteria
+
+Resolve when items 1-4 are present. Items 5-6 are desirable but not blocking —
+if the reporter says "I don't see any error" or "it happens every time", that
+counts as having the information.
+
+## When to stop asking
+
+Stop asking and resolve when:
+- Items 1-4 from the checklist are all present, OR
+- You've asked for an item and the reporter says they don't have that
+  information (mark it as an information gap)
@@ -0,0 +1,40 @@
+# Triage Strategy: Superpowers Brainstorming (adapted)
+
+Source: [obra/superpowers](https://github.com/obra/superpowers) `skills/brainstorming/SKILL.md`
+
+## Approach
+
+Adapts the core principles from superpowers brainstorming skill for issue triage.
+The skill's natural questioning loop — one question at a time, multiple choice
+preferred, judgment-based sufficiency — maps cleanly to async issue dialogue.
+
+## Questioning rules
+
+1. **One question per turn.** Never batch multiple questions.
+2. **Prefer multiple choice** when the answer space is bounded. Offer 2-4 options
+   plus "something else." Use open-ended questions only when the answer space
+   is genuinely unbounded.
+3. **Focus on understanding purpose first.** Before asking about reproduction steps
+   or environment, understand what the reporter was trying to accomplish.
+4. **YAGNI.** Do not ask for information that would not change how the issue is
+   resolved. If the answer doesn't affect the fix, don't ask.
+5. **Propose hypotheses.** After 2+ exchanges, propose your best understanding and
+   ask if it's correct, rather than continuing to probe blindly.
+6. **Scale to complexity.** A clear-cut bug needs fewer questions than an ambiguous
+   behavior change. Stop early when the issue is straightforward.
+
+## Sufficiency criteria
+
+You have enough information to resolve when you can:
+- Describe the problem in one clear paragraph
+- Hypothesize a root cause with reasonable confidence
+- Outline what a developer would need to do (or investigate) to fix it
+- A developer reading your triage summary would not need to go back to the reporter
+
+## When to stop asking
+
+Stop asking and resolve when:
+- You can meet all the sufficiency criteria above, OR
+- Further questions would have diminishing returns (the reporter has shared all
+  they reasonably know), OR
+- You've asked 3+ questions and the picture is clear enough to act on