From codex-collab
This skill should be used when the user wants to "investigate a bug", "debug an issue", "figure out why something is happening", "find the root cause", "troubleshoot", "強い推論で調査", "仮説を立てて検証", "原因を特定", "バグの原因調査", "なぜ動かないか調べて", "問題を切り分け", "原因不明", "デバッグ", or mentions systematic hypothesis-driven debugging. NOTE: Use this for investigating UNKNOWN causes, not for validating design proposals (use devils-advocate for that).
npx claudepluginhub masup9/codex-collab --plugin codex-collabThis skill uses the workspace's default tool permissions.
Apply the "Strong Inference" methodology to investigate problems systematically through competing hypotheses and decisive experiments.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Apply the "Strong Inference" methodology to investigate problems systematically through competing hypotheses and decisive experiments.
Strong Inference is a scientific method that accelerates problem-solving by:
This skill helps developers investigate bugs, performance issues, and unexpected behaviors using a structured, hypothesis-driven approach.
Key Feature: In codex mode, this skill can optionally leverage Codex for hypothesis generation and review while Claude handles verification execution.
codex exec)When the user presents a problem:
Collect information:
Clarify scope:
Generate 2-4 competing hypotheses that are:
Example hypotheses for "API returns 500 intermittently":
H1: Database connection pool exhausted under load
H2: Race condition in cache update causing stale data
H3: External service timeout not handled properly
H4: Memory leak causing OOM conditions
For each hypothesis, design a "killer experiment" that:
Prioritize experiments by:
Execute verifications in priority order:
Safety guards:
After each verification:
[X] Eliminated (evidence contradicts)[?] Pending (not yet tested)[!] Supported (evidence aligns)When one hypothesis has strong supporting evidence:
| Mode | Hypothesis Gen | Verification Design | Execution | Review |
|---|---|---|---|---|
codex | Codex | Claude | Claude | Codex |
claude-only | Claude | Claude | Claude | Claude |
codex (when Codex CLI available)claude-only (automatic when Codex unavailable)Investigation state is persisted to tmp/strong-inference/<task-id>.md:
---
schema: strong-inference/v1
task_id: abc123
created: 2026-02-02T12:00:00Z
problem: "API returns 500 intermittently"
mode: codex
---
# Investigation: API returns 500 intermittently
## Hypotheses
### H1: Database connection pool exhausted
- Status: [X] Eliminated
- Evidence: Connection count stable at 5/20 during error window
- Verified: 2026-02-02T12:15:00Z
### H2: Race condition in cache update
- Status: [?] Pending
- Test: Add mutex logging to CacheManager.update()
- Priority: High (matches timing pattern)
### H3: External service timeout
- Status: [!] Supported
- Evidence: Errors correlate with ExternalAPI latency spikes
- Next: Verify timeout handling in ApiClient.fetch()
## Verification Log
| Time | Action | Result |
|------|--------|--------|
| 12:05 | Read db/pool.go | Found pool size config |
| 12:10 | Check connection metrics | Stable at 5/20 |
| 12:15 | Eliminated H1 | Evidence contradicts |
Before executing verification commands:
Stop conditions:
max_iterations reached (default: 10)Strong Inference Investigation
==============================
Problem: API returns 500 error intermittently
Hypotheses:
[X] H1: Database connection pool exhausted
Evidence: Connection count normal (eliminated)
[!] H2: Race condition in cache update
Evidence: Timing matches error pattern (supported)
[?] H3: External service timeout
Evidence: Pending verification
Current: Designing test for H2
Investigation Complete
======================
Problem: API returns 500 error intermittently
Root Cause: Race condition in CacheManager.update()
Confidence: High (3 supporting evidence points)
Evidence Trail:
1. Errors occur only during cache refresh window
2. Adding mutex eliminated the error
3. Race condition visible in thread dump
Recommended Fix:
- Add mutex lock in CacheManager.update() line 45
- Consider using sync.RWMutex for better concurrency
Prevention:
- Add race detector to CI pipeline
- Review other cache operations for similar patterns
Use the /strong-inference command:
# Basic usage - investigate a problem
/strong-inference API sometimes returns 500 errors
# With mode selection
/strong-inference --mode claude-only Why is the test flaky?
# Japanese
/strong-inference このバグの原因を調査して
Detailed templates in references/:
hypothesis-template.md - Template for Codex hypothesis generationverification-patterns.md - Common verification strategies