Get Help

get-help — multi-model parallel consultation

When to use

Reach for this skill when:

• You've already tried the obvious fix and it didn't work. Iterating blindly burns time and trust.
• The problem is iOS/Metal/MLX/audio/codec/protocol-level and likely has documented upstream issues you haven't found yet.
• The user says something like "stop guessing", "this has to be definitive", "go and research", "I want more research, less testing", or you sense they're losing patience with churn.
• The bug pattern looks specific enough that someone else has hit it (e.g. a precise frequency, a specific tensor shape, a chip-generation symptom, a numeric signature like NaN-at-step-N).
• You're about to do something irreversible or expensive (rewrite an architecture, ship a workaround) and want a sanity check.

Do NOT use for trivial bugs you can fix faster than a CLI round-trip — this is for hard cases.

Pick your peers (don't consult yourself)

First, detect which CLI you're running in, then consult the OTHER two. Asking yourself the same question twice produces no new signal.

Cheap detection: check $CLAUDECODE (set inside Claude Code), $CODEX_* env vars, or the originating process. If genuinely unsure, default to assuming you're in Claude Code and consulting codex + gemini.

Available tools on this machine

Verify with which claude gemini codex before calling. All expected at /opt/homebrew/bin/ (or ~/.claude/local/claude for the Claude CLI).

• `claude -p "<prompt>"` — Anthropic Claude CLI (one-shot, non-interactive). Strong at synthesis and at refusing to speculate when grounding is thin. Use as a peer when you are NOT already running inside Claude Code. Inside Claude Code, skip this — you'd just be talking to yourself. Heads up: claude --print from inside a Claude Code session needs env.pop("CLAUDECODE", None) or it fails; the skill caller is responsible for stripping it.
• `gemini -p "<prompt>"` — Google Gemini CLI. Verbose, sometimes speculative, occasionally inventive in unhelpful ways. Treat its claims as hypotheses to verify, not facts. Quality is best on broad architectural questions and code-base scans.
• `codex exec --skip-git-repo-check - < /tmp/prompt.txt` — OpenAI Codex CLI. Reads stdin. Heavier emphasis on grounding in real upstream sources (GitHub issues, PRs, official docs). Empirically more reliable when the question is "is there a known bug?". Always pass --skip-git-repo-check unless you're inside a trusted git repo.
• `WebSearch` / `WebFetch` — built-in. Use for direct hits on GitHub issues, Apple developer forum, Stack Overflow. Especially search Reddit — append site:reddit.com or reddit to at least one of your queries. Reddit threads (especially r/programming, r/MachineLearning, r/iOSProgramming, hardware-specific subs, and game-engine subs) frequently contain the only discussion of niche bugs that never made it to an official issue tracker.
• `gh search issues`, `gh issue view`, `gh pr view` — for repo-specific bug archaeology. Almost always faster than web search once you know which repo.

The pattern

1. Write ONE shared prompt to disk first. All three (gemini / codex / WebSearch) get the same input. This makes their disagreements interpretable.

cat > /tmp/help_prompt.txt <<'EOF'
[Concrete context: stack, OS version, hardware]
[Precise symptom — measurements, not adjectives]
[What you've already ruled out — so they don't suggest those again]
[Specific question(s) — not "what should I do" but "what causes X?"]
[What kind of answer you want — pointer to prior art, falsifiable hypothesis, specific upstream issue]
EOF

The prompt quality dominates the response quality. Spend real time on this. The single most important sentence is usually "I do NOT want 'try X' advice — I want a root cause grounded in documented prior art."

2. Fire all calls in a single message (parallel tool calls), not sequentially. This is critical — round-trips are slow. Send the same prompt to your TWO peer CLIs (see the host-detection table above) plus two web searches. The pattern, assuming you're running in Claude Code (peers = codex + gemini):

[parallel block]
  WebSearch  query="<symptom> site:reddit.com"   (Reddit-targeted — do this one always)
  WebSearch  query="..."                          (second, narrower angle on GitHub/SO/forums)
  Bash       gemini -p "$(cat /tmp/help_prompt.txt)"
  Bash       codex exec --skip-git-repo-check - < /tmp/help_prompt.txt
[/parallel block]

If you're running in Codex, swap the codex call for claude -p "$(cat /tmp/help_prompt.txt)". If you're running in Gemini, swap the gemini call for claude -p .... The rule is simple: never call the CLI you're already inside.

Codex regularly hits rate limits — wrap it in a retry loop or be ready to re-issue. If it fails entirely, note the failure and proceed with the other sources.

3. Synthesize, don't relay. When the responses come back:

• Citation-grounded peer first (usually Codex, or Claude when run from a non-Claude host) — read its citations. Real GitHub PR/issue numbers? Real Apple TN references? Those are anchorable claims you can verify.
• Gemini second — read past its confident-sounding framing. Look for specific, falsifiable predictions. Discard the rest.
• WebSearch third — and read the Reddit hits carefully. Reddit threads often contain the lived-experience workaround that no AI cited and no official issue tracker recorded. Check for any source neither peer mentioned.
• Note where they AGREE (that's your high-confidence direction) and where they DISAGREE (that's where YOU need to make the call).
• Verify the top 1–2 cited sources directly with gh or WebFetch before acting. AIs hallucinate issue numbers regularly.

4. Report findings before acting. Show the user the actual cited sources. Quote the relevant text. Then propose the specific change. The user should never have to wonder whether you actually read the linked issue.

What good output looks like

"Codex + Gemini both pointed at `mlx-swift#344` — `ConvTransposed1d` produces wrong output on iOS for T > 8000. Verified via `gh issue view`: documented FAIL list includes T=12,640 and T=50,560 (matches our chunk sizes). Fixed in mlx 3092, released in mlx-swift 0.30.6. We're pinned to 0.30.2 in `Package.resolved`. Bumping the pin is a documented one-line fix; PR #29 in `mlalma/kokoro-ios` is the same change against the same dependency. Want me to apply it?"

That's a complete handoff: source, verification, change, ask. No guessing.

What bad output looks like

"Gemini suggests it could be an MLX kernel bug. Codex thinks it might be ConvTransposed1d. I'll try increasing the LayerNorm epsilon to see if that helps."

This is what you wrote BEFORE consulting them, dressed up with their names. Two failure modes here: synthesizing nothing, and proposing a speculative change anyway.

Anti-patterns

• Calling them sequentially. Always one message with all calls.
• Asking different questions. Same prompt to all three; differences are the signal.
• Trusting citations without verification. Codex once mentioned mlx-swift#344 — that issue is real. Gemini once mentioned mlx-swift#354 for an unrelated fix — that PR is also real but for a different bug. Always gh issue view / gh pr view to confirm.
• Pasting their full reply to the user. The user wants the answer, not a transcript of two LLMs talking. Synthesize.
• Using this for trivial bugs. A round-trip costs ~30–60s. If you can fix it in 30s, just fix it.
• Asking "what should I do?" Ask "what causes X?" or "is there a known issue Y?". Action questions get speculation; diagnostic questions get citations.

Prompt-writing checklist

Before sending, your prompt should contain:

• [ ] Stack/runtime (e.g. "iOS 26.5, iPhone 17 Pro Max, MLX-Swift 0.30.2")
• [ ] Exact symptom (measurements, frequencies, byte counts, error messages — not adjectives)
• [ ] Determinism statement (deterministic? flaky? environment-specific?)
• [ ] What you ruled out (list the obvious wrong directions so they skip them)
• [ ] One concrete question, not three vague ones
• [ ] Requested output form (cited prior art, falsifiable hypothesis, etc.)
• [ ] Explicit "no speculative try X advice" guardrail

If you can't fill these in, you don't know the problem well enough yet — keep diagnosing locally first.


get-help

A skill for Claude Code (and other AI CLIs) that enables multi-model parallel consultation when you're stuck on a hard, ambiguous, or research-grade problem. Instead of guessing and iterating blindly, get-help queries multiple independent AI models and web sources simultaneously to produce a definitive, citation-grounded answer.

---

Purpose

When debugging complex issues — especially ones involving niche platform bugs, upstream library issues, or domain-specific behaviour — guessing wastes time and trust. get-help solves this by:

• Consulting two peer AI CLIs in parallel for independent second opinions
• Running targeted web searches (including Reddit) at the same time
• Synthesizing the results into a single, citation-grounded recommendation

The goal is a real answer backed by documented prior art, not another guess.

---

When to Use It

Use get-help when:

• You've already tried the obvious fix and it didn't work
• The problem is low-level (iOS, Metal, MLX, audio, codec, protocol) and likely has upstream precedent
• The user is losing patience with speculative fixes ("stop guessing", "this has to be definitive", "go and research")
• The bug pattern is specific enough that someone else has hit it (e.g. a precise frequency, a specific tensor shape, a numeric signature like NaN-at-step-N)
• You're about to do something irreversible or expensive and want a sanity check

Do not use for trivial bugs you can fix faster than a CLI round-trip.

---

Installation

No separate installation is required. This is a Claude Code skill that is loaded automatically when present in your project or global skills directory.

The skill relies on the following peer CLI tools being available on your machine. Verify with:

which claude gemini codex

Expected locations: /opt/homebrew/bin/ (or ~/.claude/local/claude for the Claude CLI).

Install any missing peers via their respective setup instructions before using this skill.

---

How to Use

Step 1 — Trigger the skill

Ask Claude Code to consult peers on your hard problem. You can invoke it explicitly or Claude Code will apply it automatically when the situation warrants it.

Example prompts that trigger this skill:

This is still broken. Stop guessing and go research whether there's a known upstream issue.

I need a definitive answer on why CoreAudio drops frames at exactly 44100 Hz on M3. Go consult your peers.

I want more research, less testing. Find documented prior art for this NaN-at-step-47 pattern in MLX.

Step 2 — The skill writes a shared prompt

Claude Code writes one concrete, well-formed prompt to /tmp/help_prompt.txt covering:

• Stack/runtime details (OS version, hardware, library versions)
• Exact symptom (measurements, error messages — not adjectives)
• What has already been ruled out
• A single, specific diagnostic question
• The requested output form (cited prior art, falsifiable hypothesis, etc.)

Step 3 — Parallel consultation fires

All peer calls go out in a single parallel block — no sequential round-trips. For a Claude Code session this looks like:

[parallel]
  WebSearch  → "<symptom> site:reddit.com"
  WebSearch  → "<symptom> site:github.com OR stackoverflow.com"
  Bash       → gemini -p "$(cat /tmp/help_prompt.txt)"
  Bash       → codex exec --skip-git-repo-check - < /tmp/help_prompt.txt
[/parallel]

Step 4 — Synthesized findings are reported

Claude Code synthesizes the responses and reports back with:

• The specific source(s) that grounded the answer (GitHub issue numbers, Reddit threads, Apple TN references)
• Direct quotes from those sources
• A concrete proposed change or next action
• A clear ask before taking any irreversible action

---

Examples

Example 1 — Known upstream library bug

You say:

Audio output is corrupted at T > 8000 on iPhone 15 Pro. I've ruled out sample rate mismatch and buffer sizing. Go research this.

get-help returns:

Codex + Gemini both pointed at mlx-swift#344 — ConvTransposed1d produces wrong
output on iOS for T > 8000. Verified via `gh issue view`: documented FAIL list
includes T=12,640 and T=50,560 (matches our chunk sizes). Fixed in mlx 3092,
released in mlx-swift 0.30.6. We're pinned to 0.30.2 in Package.resolved.
Bumping the pin is a documented one-line fix; PR #29 in mlalma/kokoro-ios is the
same change against the same dependency. Want me to apply it?

Example 2 — Niche platform behaviour with Reddit prior art

You say:

NaN appears at exactly step 47 during fine-tuning on M2 Ultra. Deterministic. Not a learning-rate issue. Research this before we touch anything.

get-help returns:

Reddit thread r/MachineLearning (6 months ago) + a Gemini citation both describe
a deterministic NaN at step 47–52 tied to the Metal shader compiler on M2 when
accumulating bf16 gradients past a certain tensor rank. The Reddit OP confirmed
disabling Metal Performance Shaders fallback resolved it. Codex linked
apple/ml-stable-diffusion#501 which documents the same symptom. No official fix
yet. Proposed workaround: force fp32 accumulation for the affected layer. Want me
to add that flag?

Example 3 — Architecture sanity check before a rewrite

You say:

I'm about to replace the streaming decoder with a batch approach to fix latency. Get a second opinion first.

get-help returns:

Gemini and Codex agree: the latency issue is not in the decoder architecture —
both cite a known AVAudioEngine scheduling jitter on iOS 17.4 (Apple Developer
Forums thread #1109823, April 2024). Switching to batch decoding would add 200–400ms
of buffering and likely make latency worse. The documented fix is pinning the
audio session IO buffer duration to 256 frames. Strongly recommend against the
rewrite. Want me to apply the IO buffer pin instead?

---

Peer Selection Reference

The skill automatically picks the right peers based on which CLI host it's running inside:

This ensures you never consult the same model you're already running in — asking yourself twice produces no new signal.