trace▌
yeachan-heo/oh-my-claudecode · updated Apr 8, 2026
MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.
Use this skill for ambiguous, causal, evidence-heavy questions where the goal is to explain why an observed result happened, not to jump directly into fixing or rewriting code.
Trace Skill
Use this skill for ambiguous, causal, evidence-heavy questions where the goal is to explain why an observed result happened, not to jump directly into fixing or rewriting code.
This is the orchestration layer on top of the built-in tracer agent. The goal is to make tracing feel like a reusable OMC operating lane: restate the observation, generate competing explanations, gather evidence in parallel, rank the explanations, and propose the next probe that would collapse uncertainty fastest.
Good entry cases
Use /oh-my-claudecode:trace when the problem is:
- ambiguous
- causal
- evidence-heavy
- best answered by exploring competing explanations in parallel
Examples:
- runtime bugs and regressions
- performance / latency / resource behavior
- architecture / premortem / postmortem analysis
- scientific or experimental result tracing
- config / routing / orchestration behavior explanation
- “given this output, trace back the likely causes”
Core tracing contract
Always preserve these distinctions:
- Observation -- what was actually observed
- Hypotheses -- competing explanations
- Evidence For -- what supports each explanation
- Evidence Against / Gaps -- what contradicts it or is still missing
- Current Best Explanation -- the leading explanation right now
- Critical Unknown -- the missing fact keeping the top explanations apart
- Discriminating Probe -- the highest-value next step to collapse uncertainty
Do not collapse into:
- a generic fix-it coding loop
- a generic debugger summary
- a raw dump of worker output
- fake certainty when evidence is incomplete
Evidence strength hierarchy
Treat evidence as ranked, not flat.
From strongest to weakest:
- Controlled reproductions / direct experiments / uniquely discriminating artifacts
- Primary source artifacts with tight provenance (trace events, logs, metrics, benchmark outputs, configs, git history, file:line behavior)
- Multiple independent sources converging on the same explanation
- Single-source code-path or behavioral inference
- Weak circumstantial clues (timing, naming, stack order, resemblance to prior bugs)
- Intuition / analogy / speculation
Explicitly down-rank hypotheses that depend mostly on lower tiers when stronger contradictory evidence exists.
Strong falsification / disconfirmation rules
Every serious /trace run must try to falsify its own favorite explanation.
For each top hypothesis:
- collect evidence for it
- collect evidence against it
- state what distinctive prediction it makes
- state what observation would be hard to reconcile with it
- identify the cheapest probe that would discriminate it from the next-best alternative
Down-rank a hypothesis when:
- direct evidence contradicts it
- it survives only by adding new unverified assumptions
- it makes no distinctive prediction compared with rivals
- a stronger alternative explains the same facts with fewer assumptions
- its support is mostly circumstantial while the rival has stronger evidence tiers
Team-mode orchestration shape
Use Claude built-in team mode for /trace.
The lead should:
- Restate the observed result or “why” question precisely
- Extract the tracing target
- Generate multiple deliberately different candidate hypotheses
- Spawn 3 tracer lanes by default in team mode
- Assign one tracer worker per lane
- Instruct each tracer worker to gather evidence for and against its lane
- Run a rebuttal round between the leading hypothesis and the strongest remaining alternative
- Detect whether the top lanes genuinely differ or actually converge on the same root cause
- Merge findings into a ranked synthesis with an explicit critical unknown and discriminating probe
Important: workers should pursue deliberately different explanations, not the same explanation in parallel.
Default hypothesis lanes for v1
Unless the prompt strongly suggests a better partition, use these 3 default lanes:
- Code-path / implementation cause
- Config / environment / orchestration cause
- Measurement / artifact / assumption mismatch cause
These defaults are intentionally broad so the first slice works across bug, performance, architecture, and experiment tracing.
Mandatory cross-check lenses
After the initial evidence pass, pressure-test the leaders with these lenses when relevant:
- Systems lens -- queues, retries, backpressure, feedback loops, upstream/downstream dependencies, boundary failures, coordination effects
- Premortem lens -- assume the current best explanation is incomplete or wrong; what failure mode would embarrass the trace later?
- Science lens -- controls, confounders, measurement bias, alternative variables, falsifiable predictions
These lenses are not filler. Use them when they can surface a missed explanation, hidden dependency, or weak inference.
Worker contract
Each worker should be a tracer lane owner, not a generic executor.
Each worker must:
- own exactly one hypothesis lane
- restate its lane hypothesis explicitly
- gather evidence for the lane
- gather evidence against the lane
- rank the evidence strength behind its case
- call out missing evidence, failed predictions, and remaining uncertainty
- name the critical unknown for the lane
- recommend the best lane-specific discriminating probe
- avoid collapsing into implementation unless explicitly told to do so
Useful evidence sources include:
- relevant code, tests, configs, docs, logs, outputs, and benchmark artifacts
- existing trace artifacts via
trace_timeline - existing aggregate trace evidence via
trace_summary
Recommended worker return structure:
- Lane
- Hypothesis
- Evidence For
- Evidence Against / Gaps
- Evidence Strength
- Critical Unknown
- Best Discriminating Probe
- Confidence
Leader synthesis contract
The final /trace answer should synthesize, not just concatenate.
Return:
- Observed Result
- Ranked Hypotheses
- Evidence Summary by Hypothesis
- Evidence Against / Missing Evidence
- Rebuttal Round
- Convergence / Separation Notes
- Most Likely Explanation
- Critical Unknown
- Recommended Discriminating Probe
- Additional Trace Lanes (optional, only if uncertainty remains high)
Preserve a ranked shortlist even if one explanation is currently dominant.
Rebuttal round and convergence detection
Before closing the trace:
- let the strongest non-leading lane present its best rebuttal to the current leader
- force the leader to answer the rebuttal with evidence, not assertion
- if the rebuttal materially weakens the leader, re-rank the table
- if two “different” hypotheses reduce to the same underlying mechanism, merge them and say so explicitly
- if two hypotheses still imply different next probes, keep them separate even if they sound similar
Do not claim convergence just because multiple workers use similar language. Convergence requires either:
- the same root causal mechanism, or
- independent evidence streams pointing to the same explanation
Explicit down-ranking guidance
The lead should explicitly say why a hypothesis moved down:
- contradicted by stronger evidence
- lacks the observation it predicted
- requires extra ad hoc assumptions
- explains fewer facts than the leader
- lost the rebuttal round
- converged into a stronger parent explanation
This is important because /trace should teach the reader why one explanation outranks another, not just present a final table.
Suggested lead prompt skeleton
Use a team-oriented orchestration prompt along these lines:
- “Restate the observation exactly.”
- “Generate 3 deliberately different hypotheses.”
- “Create one tracer lane per hypothesis using Claude built-in team mode.”
- “For each lane, gather evidence for and against, rank evidence strength, and name the critical unknown plus best discriminating probe.”
- “Apply systems, premortem, and science lenses to the leaders if useful.”
- “Run a rebuttal round between the top two explanations.”
- “Return a ranked explanation table, convergence notes, the critical unknown, and the single best discriminating probe.”
Output quality bar
Good /trace output is:
- evidence-backed
- concise but rigorous
- skeptical of premature certainty
- explicit about missing evidence
- practical about the next action
- explicit about why weaker explanations were down-ranked
Example final synthesis shape
Observed Result
[What happened]
Ranked Hypotheses
| Rank | Hypothesis | Confidence | Evidence Strength | Why it leads |
|---|---|---|---|---|
| 1 | ... | High / Medium / Low | Strong / Moderate / Weak | ... |
Evidence Summary by Hypothesis
- Hypothesis 1: ...
- Hypothesis 2: ...
- Hypothesis 3: ...
Evidence Against / Missing Evidence
- Hypothesis 1: ...
- Hypothesis 2: ...
- Hypothesis 3: ...
Rebuttal Round
- Best rebuttal to leader: ...
- Why leader held / failed: ...
Convergence / Separation Notes
- ...
Most Likely Explanation
[Current best explanation]
Critical Unknown
[Single missing fact keeping uncertainty open]
Recommended Discriminating Probe
[Single next probe]
Additional Trace Lanes
[Only if uncertainty remains high]
How to use trace on Cursor
AI-first code editor with Composer
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
- ›Cursor installed and configured on your development machine
- ›Node.js version 16.0+ with npm package manager (verify with
node --version) - ›Active project directory or workspace where you want to add trace
Execute installation command
Execute the skills CLI command in your project's root directory to begin installation:
The skills CLI fetches trace from GitHub repository yeachan-heo/oh-my-claudecode and configures it for Cursor.
Select Cursor when prompted
The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:
Verify installation
Confirm successful installation by checking the skill directory location:
Reload or restart Cursor to activate trace. Access the skill through slash commands (e.g., /trace) or your agent's skill management interface.
Security & Verification Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.
List & Monetize Your Skill
Submit your Claude Code skill and start earning
Use Cases▌
User Story & Requirements Generation
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Competitive Analysis
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Roadmap Prioritization
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Implementation Guide▌
Prerequisites
- ›Claude Desktop or compatible AI client
- ›Access to product documentation and roadmap tools (Jira, Notion, etc.)
- ›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
- ›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Installation Steps
- 1.Install product management skill
- 2.Start with user story generation for known feature
- 3.Progress to competitive analysis: research 2-3 competitors
- 4.Use for roadmap prioritization: apply RICE/ICE scoring
- 5.Draft stakeholder communications and refine based on feedback
- 6.Build template library for recurring PM tasks
- 7.Share effective prompts with product team
Common Pitfalls
- ⚠Not validating competitive research—verify facts before sharing
- ⚠Accepting user stories without involving engineering team
- ⚠Over-relying on frameworks without qualitative judgment
- ⚠Not customizing outputs to company culture and communication style
- ⚠Skipping stakeholder validation of generated requirements
Best Practices▌
✓ Do
- +Validate research and competitive analysis with real data
- +Collaborate with engineering when generating technical requirements
- +Customize frameworks and templates to your company context
- +Use skill for first drafts, refine with stakeholder input
- +Document successful prompt patterns for PM tasks
- +Combine AI efficiency with human judgment and intuition
✗ Don't
- −Don't publish competitive analysis without fact-checking
- −Don't finalize user stories without engineering review
- −Don't make prioritization decisions solely on AI scoring
- −Don't skip customer validation of generated requirements
- −Don't ignore company-specific context and culture
💡 Pro Tips
- ★Provide context: company goals, constraints, customer feedback
- ★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
- ★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
- ★Use skill for 70% generation + 30% customization to company needs
When to Use This▌
✓ Use When
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid When
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path▌
- 1Basic: user stories, feature specs, status updates
- 2Intermediate: competitive analysis, prioritization frameworks, PRDs
- 3Advanced: product strategy, go-to-market planning, OKR setting
- 4Expert: product vision, market positioning, business model innovation
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.5★★★★★28 reviews- ★★★★★Aditi Anderson· Dec 20, 2024
trace reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Chaitanya Patil· Dec 12, 2024
Registry listing for trace matched our evaluation — installs cleanly and behaves as described in the markdown.
- ★★★★★Charlotte Kim· Dec 12, 2024
We added trace from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Piyush G· Nov 3, 2024
Solid pick for teams standardizing on skills: trace is focused, and the summary matches what you get after install.
- ★★★★★Aanya Huang· Nov 3, 2024
trace fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Shikha Mishra· Oct 22, 2024
I recommend trace for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Aanya Martinez· Oct 22, 2024
trace has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Alexander Martin· Sep 9, 2024
I recommend trace for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Yash Thakker· Sep 1, 2024
trace fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Alexander Yang· Aug 28, 2024
Solid pick for teams standardizing on skills: trace is focused, and the summary matches what you get after install.
showing 1-10 of 28