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
/analyze command 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.md in 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.
1---2name: analyze-53description: Deep analysis mode - thorough multi-phase investigation with expert consultation for complex problems requiring careful examination4license: MIT5---6
7# Deep Analysis Mode
8
9Perform a comprehensive analysis using multi-phase investigation and structured synthesis.
10
11## HARD CONSTRAINTS (NON-NEGOTIABLE)
12
13- **READ-ONLY MODE** — This skill is for analysis, not implementation
14- **NO CODE WRITING** — Do not write, edit, or modify any source code
15- **NO IMPLEMENTATION** — Do not implement features, fix bugs, or make changes
16- **OUTPUT IS DOCUMENTATION** — Your deliverable is analysis/plan documents only
17
18If you find yourself wanting to write code, STOP. Analysis produces documents, not software.
19
20## When to Use This Skill
21
22- Before major refactoring or architectural changes
23- When evaluating unfamiliar code for risks or technical debt
24- During security or performance audits
25- When making build-vs-buy or technology decisions
26- To produce a documented assessment for stakeholder review
27- **As the `/analyze` command** to produce implementation plans for `/implement`
28
29## Workflow
30
31### Phase 1: Reconnaissance
32
33Explore the target area to build context:
34
351. **Map the structure:**
36 - Identify relevant files, modules, and their relationships
37 - Understand the dependency graph and data flow
38
392. **Find patterns:**
40 - Look for recurring code patterns (both good and concerning)
41 - Identify conventions and deviations from them
42
433. **Gather context:**
44 - Review git history for recent changes and contributors
45 - Check for related documentation, comments, or TODOs
46
47### Phase 2: Domain Analysis
48
49Analyze the target across these dimensions:
50
51| Domain | Focus Areas |
52| ---------------- | ------------------------------------------------ |
53| **Architecture** | System design, data flow, component dependencies |
54| **Security** | Vulnerabilities, threat model, input validation |
55| **Reliability** | Scalability, failure modes, error handling |
56| **Performance** | Bottlenecks, complexity, resource usage |
57| **Code Quality** | Patterns, anti-patterns, maintainability |
58
59### Phase 3: Deep Dive
60
61Examine comprehensively:
62
63- Edge cases and potential failure modes
64- Performance implications under load
65- Security attack surface
66- Error handling completeness
67- Testability and test coverage gaps
68- Technical debt and maintenance burden
69
70### Phase 4: Synthesis
71
72Combine findings into a structured report following the template in `references/analysis-report-template.md`.
73
74The report should include:
75
76- **Executive Summary** - Key findings and top recommendation
77- **Detailed Analysis** - By domain (architecture, security, performance, code quality)
78- **Issues Found** - Prioritized as Critical (P0), High (P1), Medium (P2)
79- **Recommendations** - Immediate actions, short-term improvements, long-term considerations
80- **Trade-offs** - Analysis of different approaches with pros/cons
81
82## Analysis Focus Areas
83
84| Area | What to Examine |
85| ------------------- | --------------------------------------- |
86| **Correctness** | Logic errors, edge cases, assumptions |
87| **Security** | Input validation, auth, data protection |
88| **Performance** | Complexity, caching, resource usage |
89| **Reliability** | Error handling, failure modes, recovery |
90| **Maintainability** | Readability, coupling, documentation |
91| **Testability** | Coverage, mocking, isolation |
92
93## Output Requirements
94
95When used via `/analyze` command:
96- **Save plan to:** `working/plans/<ticket-id>-plan.md` in Obsidian vault
97- If Obsidian write fails, output full plan in chat and report error
98
99## Constraints
100
101- **Read-only** — analyze code, do not modify it
102- **Be thorough but focused** - analyze deeply but stay scoped to the target area
103- **Prioritize findings** - not all issues are equal; use P0/P1/P2 consistently
104- **Support claims with evidence** - reference specific files, lines, or patterns
105- **Provide actionable recommendations** - vague advice is not useful
106
107---
108
109Begin by performing reconnaissance on the target area before conducting domain analysis.
110
111**Remember: Your output is documentation. Do not write code.**
diegosouzapw