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:

1. Map the structure:

   • Identify relevant files, modules, and their relationships
   • Understand the dependency graph and data flow

2. Find patterns:

   • Look for recurring code patterns (both good and concerning)
   • Identify conventions and deviations from them

3. 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.