skills/code-investigate/SKILL.md
Dual-perspective code investigation. Use when: deep code analysis needing both Claude and Codex perspectives. Not for: quick exploration (use code-explore), code review (use codex-code-review). Output: integrated findings from dual analysis.
npx skillsauth add sd0xdev/sd0x-dev-flow code-investigateInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Codex must explore independently. Feeding Claude's conclusions to Codex is prohibited.
┌─────────────────┐ ┌─────────────────┐
│ Claude Explores │ │ Codex Explores │
│ Independently │ │ Independently │
│ (Phase 1-2) │ │ (Phase 3) │
└────────┬────────┘ └────────┬────────┘
│ │
▼ ▼
┌───────────┐ ┌───────────┐
│ Claude │ │ Codex │
│ Conclusion│ │ Conclusion│
└─────┬─────┘ └─────┬─────┘
│ │
└───────────┬───────────┘
▼
┌─────────────┐
│ Consolidated│
│ Report │
│ (Phase 4) │
└─────────────┘
| Phase | Name | Action | Output | | ----- | --------------- | ----------------------------------- | --------------------------- | | 1 | Claude Explore | Grep/Glob/Read to search code | Related files list | | 2 | Claude Conclude | Analyze logic, form understanding | Initial conclusion (internal)| | 3 | Codex Explore | Invoke Codex MCP to explore independently | Codex analysis report | | 4 | Integrate | Compare both perspectives, mark differences | Consolidated report |
| Parameter | Value | Description |
| ----------------- | ----------- | --------------- |
| sandbox | read-only | Force read-only |
| approval-policy | never | Auto-execute |
| cwd | Project root| Exploration start point |
mcp__codex__codex({
prompt: `# Code Investigation Task
## Question
${userQuestion}
## Project Info
- Path: ${cwd}
- Tech Stack: {FRAMEWORK} + TypeScript + {DATABASE}
Please **independently explore** the codebase and answer:
1. What files are related?
2. How does the core logic work?
3. What is the data flow?
4. What are the key dependencies?
Please grep/read and explore on your own, then provide your analysis.`,
cwd: '/path/to/project',
sandbox: 'read-only',
'approval-policy': 'never',
});
| Pattern | Problem | Example |
| ------------------ | --------------------------------- | ------------------------------------------- |
| Feeding conclusion | Claude's findings leak to Codex | Claude found these files: ${findings} |
| Leading question | Presupposes answer | I think the problem is in cache, verify |
| Scope restriction | Prevents independent exploration | Only look at src/service/ |
## Investigation Report
- **Claude findings**: <independent analysis>
- **Codex findings**: <independent analysis>
- **Integrated conclusion**: <merged findings>
- **Confidence**: High / Medium / Low
| Check | Standard | | ------------------------- | --------------------------------------------- | | Claude independent conclusion | Phase 2 forms conclusion, not output to user | | Codex prompt is clean | Contains only question + project path, no Claude findings | | Report perspectives separated | Claude / Codex conclusions presented separately | | Integration is complete | Marks agreement, differences, possible gaps |
| File | Purpose | When to Read |
| ------------------------------- | -------------------- | ------------------ |
| references/prompts.md | Codex prompt templates | Before Phase 3 |
| references/output-template.md | Report format | During Phase 4 |
Input: Investigate how order processing works
Phase 1: Grep "processOrder" -> Read src/service/order/*.ts
Phase 2: Form understanding: Controller -> Service -> Repository write
Phase 3: Codex explores independently (only given question + path)
Phase 4: Consolidated report -> mark both perspectives
Input: How does the API caching mechanism work?
Phase 1: Grep "cache" + "portfolio" -> Read related files
Phase 2: Understand Redis TTL + fallback mechanism
Phase 3: Codex investigates independently
Phase 4: Compare differences -> output consolidated report
Input: Why is token price sometimes null?
Phase 1: Search price-related logic + error handling
Phase 2: Identify possible fallback paths
Phase 3: Codex diagnoses independently
Phase 4: Synthesize both findings -> list possible causes
documentation
Rewrite the previous reply in Traditional Chinese
development
Monitor GitHub Actions CI runs until completion. Use when: watching CI after push, checking build status, monitoring PR checks, waiting for CI completion, user says 'watch CI', 'check CI', 'CI status', 'monitor build', or /watch-ci. Not for: pushing code (use push-ci), creating PRs (use create-pr). Output: per-run verdict (pass/fail/timeout).
development
Verification loop — lint -> typecheck -> unit -> integration -> e2e
development
Research current code state then update corresponding docs, ensuring docs stay in sync with code.