/analyze - Deep Analysis

Perform thorough design and implementation analysis. Trace all code paths, play devil's advocate, and evaluate from multiple angles before recommending an approach.

Usage

/analyze [description of change, design decision, or feature]

When to Use

• Before implementing a complex feature or refactor
• When evaluating competing design approaches
• When a proposed change touches many files or core abstractions
• When performance, concurrency, or cross-platform implications are unclear

Instructions

1. Scope the Analysis

• Restate the goal and constraints
• Identify all code areas that will be affected
• Map the dependency graph: what depends on what's changing?

2. Trace All Code Paths

For each affected function/method:

• Trace every caller (use grep for all import/call sites)
• Trace every callee (read the full implementation)
• Check both Node.js (src/env/node/) and Browser (src/env/browser/) paths
• Check sub-providers: src/env/node/git/sub-providers/, src/git/sub-providers/, src/plus/integrations/providers/github/sub-providers/
• Note decorator behavior (@gate(), @memoize(), @sequentialize()) that alters execution

3. Evaluate Edge Cases

For each proposed change, systematically consider:

• Concurrency: What happens with concurrent calls? Check @gate() interactions
• Caching: Will @memoize() or GitCache serve stale data after this change?
• Error paths: What happens when the operation fails? Check all catch sites
• Empty/null states: What if the input is empty, undefined, or in an unexpected state?
• Platform differences: Does this work in both Node.js and browser environments?
• Disposal: Are event listeners and subscriptions properly cleaned up?

4. Play Devil's Advocate

For each design decision, argue the opposing case:

• What's the simplest alternative that could work?
• What assumptions does this approach make? Are they guaranteed?
• What breaks if those assumptions are wrong?
• Is this solving the right problem, or a symptom?
• Could this be solved by configuration/data rather than code?
• What's the maintenance cost of this approach in 6 months?

5. Assess Risk

Rate each concern:

• High risk — Likely to cause bugs, data loss, or performance regression
• Medium risk — Could cause issues under specific conditions
• Low risk — Unlikely but worth noting

6. Present Analysis

## Analysis: [Description]

### Goal

[What we're trying to achieve and why]

### Approach Evaluated

[Description of the proposed approach]

### Code Path Trace

[Entry point] -> [Function chain with decorators noted]

- Callers: [count] call sites in [files]
- Platform: Node.js [yes/no], Browser [yes/no]

### Edge Cases & Risks

| Concern     | Risk   | Details                        |
| ----------- | ------ | ------------------------------ |
| [Concern 1] | High   | [Specific scenario and impact] |
| [Concern 2] | Medium | [Specific scenario and impact] |

### Devil's Advocate

1. **Alternative approach**: [Simpler/different way] — [why it might be better or worse]
2. **Assumption risk**: [What we're assuming] — [what happens if wrong]

### Recommendation

[Recommended approach with specific reasoning]
[What to watch out for during implementation]
[Suggested verification steps]

Anti-Patterns

• Do NOT rubber-stamp — always find at least one genuine concern or alternative
• Do NOT be contrarian for its own sake — ground concerns in specific code paths
• Do NOT skip the trace step — assumptions about "what calls what" are frequently wrong
• Do NOT ignore decorator behavior — @gate(), @memoize(), and @sequentialize() fundamentally change execution semantics