analyze

Files (2)

• SKILL.md
• analysis-report-template.md · references/

SKILL.md (first lines)

# 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.**

From thoreinstein/agents, MIT.

More from thoreinstein/agents