Deep Analysis Mode
Perform a comprehensive analysis using multi-phase investigation and structured synthesis.
HARD CONSTRAINTS (NON-NEGOTIABLE)
- READ-ONLY MODE — This skill is for analysis, not implementation
- NO CODE WRITING — Do not write, edit, or modify any source code
- NO IMPLEMENTATION — Do not implement features, fix bugs, or make changes
- OUTPUT IS DOCUMENTATION — Your deliverable is analysis/plan documents only
If you find yourself wanting to write code, STOP. Analysis produces documents, not software.
When to Use This Skill
- Before major refactoring or architectural changes
- When evaluating unfamiliar code for risks or technical debt
- During security or performance audits
- When making build-vs-buy or technology decisions
- To produce a documented assessment for stakeholder review
- As the
/analyzecommand to produce implementation plans for/implement
Workflow
Phase 1: Reconnaissance
Explore the target area to build context:
-
Map the structure:
- Identify relevant files, modules, and their relationships
- Understand the dependency graph and data flow
-
Find patterns:
- Look for recurring code patterns (both good and concerning)
- Identify conventions and deviations from them
-
Gather context:
- Review git history for recent changes and contributors
- Check for related documentation, comments, or TODOs
Phase 2: Domain Analysis
Analyze the target across these dimensions:
| Domain | Focus Areas |
|---|---|
| Architecture | System design, data flow, component dependencies |
| Security | Vulnerabilities, threat model, input validation |
| Reliability | Scalability, failure modes, error handling |
| Performance | Bottlenecks, complexity, resource usage |
| Code Quality | Patterns, anti-patterns, maintainability |
Phase 3: Deep Dive
Examine comprehensively:
- Edge cases and potential failure modes
- Performance implications under load
- Security attack surface
- Error handling completeness
- Testability and test coverage gaps
- Technical debt and maintenance burden
Phase 4: Synthesis
Combine findings into a structured report following the template in references/analysis-report-template.md.
The report should include:
- Executive Summary - Key findings and top recommendation
- Detailed Analysis - By domain (architecture, security, performance, code quality)
- Issues Found - Prioritized as Critical (P0), High (P1), Medium (P2)
- Recommendations - Immediate actions, short-term improvements, long-term considerations
- Trade-offs - Analysis of different approaches with pros/cons
Analysis Focus Areas
| Area | What to Examine |
|---|---|
| Correctness | Logic errors, edge cases, assumptions |
| Security | Input validation, auth, data protection |
| Performance | Complexity, caching, resource usage |
| Reliability | Error handling, failure modes, recovery |
| Maintainability | Readability, coupling, documentation |
| Testability | Coverage, mocking, isolation |
Output Requirements
When used via /analyze command:
- Save plan to:
working/plans/<ticket-id>-plan.mdin Obsidian vault - If Obsidian write fails, output full plan in chat and report error
Constraints
- Read-only — analyze code, do not modify it
- Be thorough but focused - analyze deeply but stay scoped to the target area
- Prioritize findings - not all issues are equal; use P0/P1/P2 consistently
- Support claims with evidence - reference specific files, lines, or patterns
- Provide actionable recommendations - vague advice is not useful
Begin by performing reconnaissance on the target area before conducting domain analysis.
Remember: Your output is documentation. Do not write code.