Find Something — Technical Investigation Skill

Pick at least 2 categories. A finding confirmed by only one source is a lead; confirmed by 2+ sources is a finding.

Web Fetch Fallback Rule

If 3 web fetch attempts fail or return truncated content, stop trying. Fall back to local source code — grep through the relevant codebase (e.g., CUTLASS for NVIDIA hardware questions). This is almost always faster and more reliable than fighting with web fetches.

Step 3: Investigate

Search your planned sources. For each finding:

1. Record the exact location: file path with line number, or command that produced the output
2. Quote the relevant content: don't paraphrase — include the actual text, code, or value
3. Note what it means: one sentence interpreting the finding in context of the question

When you find something surprising or contradictory, that's a signal to dig deeper, not to pick the more convenient answer. Cross-reference against another source.

Step 4: Write the Findings Document

Save to findings/YYYY-MM-DD-[descriptive-slug].md (or docs/findings/ if the project uses that convention). Create the directory if needed.

The format depends on what you found. Use the structure that fits:

For comparisons across versions/implementations:

# [What's Being Compared]

[One paragraph of context: what, why, methodology]

## Comparison Table

| Dimension | Variant A | Variant B | Variant C |
|-----------|-----------|-----------|-----------|
| [aspect]  | [value] — `file:line` | [value] — `file:line` | ... |

## Key Differences
1. **[Difference]** — [evidence]
2. **[Difference]** — [evidence]

Use input × input → accumulator notation for dtype/GEMM tables (e.g., FP8 × FP8 → FP32).

For hardware/software constraint investigations:

# [Component] — [Constraint Type] Reference

**Date:** YYYY-MM-DD
**Source:** [primary source files]

## Summary
[2-3 sentences: what the constraint is, why it matters]

## Evidence
1. **[Source 1]:** `file:line` — [what it shows]
2. **[Source 2]:** `file:line` — [what it confirms]

## Implications
[What this means for the project]

For "why does X differ from Y" investigations:

# [Question]

## Methodology
[What sources were checked, in what order]

## Findings
1. **[Root cause]** — [evidence with sources]

## Conclusion
[Direct answer to the original question]

## Open Questions
[What wasn't resolved]

General rules for all formats:

• Every factual claim needs a source. file:line, command output, or document reference.
• Skip sections that are empty. Don't write "N/A" — just omit.
• Include Open Questions if anything remains unresolved. Future sessions need to know what's left.
• Save to disk, not just stdout. The whole point is producing a referenceable document.

Step 5: Verify Before Finishing

Before declaring the investigation done, re-read your findings document and check:

• Does every claim cite a specific source?
• Did you cross-reference at least one key finding against a second source?
• Is the document saved to disk at a sensible path?
• Would someone reading this in 2 weeks know exactly where to look to verify each claim?

If any check fails, fix it.