deep-analyze
Deep Analyze
Trigger
- Keywords: deep analyze, deep analysis, deep dive, roadmap, deep-analyze
When NOT to Use
- Architecture advice only (use
/codex-architect) - Tech spec writing (use
/tech-spec) - Feasibility analysis (use
/feasibility-study)
Agent Dispatch
Agent({
description: "Deep-dive analysis with actionable roadmap and alternatives",
subagent_type: "solution-architect",
prompt: `Perform a deep analysis of the following initial proposal.
Follow the analysis framework and output format defined in this skill.`
})
Task
Input
$ARGUMENTS
Analysis Flow
Phase 1: Understand & Validate
- Extract the core objectives of the initial proposal
- Identify key assumptions (which may be wrong)
- List technical points that need verification
Phase 2: Code Deep Dive
Research the existing codebase thoroughly. Must verify:
- Naming conventions
- DI injection patterns
- Error handling patterns
- Implementation patterns of similar features
Phase 3: Roadmap Output
Based on the research, produce:
- Implementation steps (immediately actionable)
- Key pseudocode (only core 1-3 lines, omit if not necessary)
- Alternative comparison
Output
# [Proposal Name] Implementation Roadmap
## Proposal Validation
| Assumption | Verification Result | Impact |
## Code Research Summary
| Module | Existing Implementation | Reusable |
## Implementation Roadmap
### Step 1: [Title]
**Objective**: One sentence
**Files**: `src/xxx.ts` (modify/create)
## Alternatives
| Dimension | Option A (Recommended) | Option B |
## Risks & Mitigations
| Risk | Probability | Mitigation |
## Immediate Actions
1. [ ] First task
2. [ ] Second task
Examples
/deep-analyze "Use Redis to cache token prices with TTL 5 minutes"
/deep-analyze docs/features/xxx/tech-spec.md
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6project-audit
Project health audit with deterministic scoring. Use when: evaluating project quality, onboarding to new codebase, periodic health checks. Not for: runtime performance analysis, security-specific audits (use /codex-security). Output: 5-dimension score + actionable findings.
6