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.