Bookmark Analyzer

Analysis Areas

Fork 1: Component Structure Analysis

Objective: Quantify component inventory and relationships

Tasks:

1. Count total components by category (UI primitives, feature modules, etc.)
2. Map parent-child relationships (component tree)
3. Identify high-reuse components
4. Analyze size distribution (lines per component)

Key Files:

• components/ui/ - UI primitives
• components/bookmarks/ - Feature modules
• components/vault/, components/settings/, components/sync/
• components/spaces/, components/theme/, components/auth/

Output Format:

## Component Structure Analysis

### Inventory
- Total components: [count]
- UI primitives: [count]
- Feature modules: [count]
- [Other categories]

### Hierarchy
[Component tree showing relationships]

### Reusability
- High-reuse components: [list with usage count]
- Reuse score: [percentage]

### Size Distribution
- Components < 100 lines: [count]
- Components 100-200 lines: [count]
- Components 200+ lines: [count]

### Key Findings
[Specific observations about structure quality, issues]

Fork 2: Data Flow Analysis

Objective: Trace how bookmark data moves through the system

Tasks:

1. Identify data sources: localStorage, Context, Zustand stores
2. Trace state flow: storage → hooks → components
3. Map prop drilling chains (count depth, props per component)
4. Document hook dependencies and interconnections
5. Identify refresh mechanisms and data sync patterns

Key Files:

• hooks/useBookmarks.ts - Main state hook
• hooks/useSyncEngineUnified.ts - Sync orchestration
• lib/storage.ts - localStorage access
• stores/vault-store.ts, stores/settings-store.ts - Zustand stores

Output Format:

## Data Flow Analysis

### Flow Paths
- Storage layer: [what stores data]
- State management: [useBookmarks context flow]
- UI consumption: [component data flow]

### Prop Drilling Analysis
- Max depth: [levels]
- Components with 8+ props: [list]
- Average props per component: [number]

### Hook Dependencies
- [Hook name]: Depends on [other hooks/stores]
- [Circular dependency check results]

### Data Refresh Mechanisms
- [Pattern 1]: [description]
- [Pattern 2]: [description]

### Issues Found
[Specific prop drilling bottlenecks, refresh issues]

### Key Findings
[Assessment of data flow quality, performance implications]

Fork 3: Type Coverage Analysis

Objective: Assess TypeScript safety and validation completeness

Tasks:

1. Verify TypeScript configuration (strict mode enabled)
2. Count and categorize types/interfaces defined
3. Check Zod schema coverage vs. interface definitions
4. Audit function signatures for proper typing
5. Identify any any type usage
6. Validate component prop interfaces

Key Files:

• lib/types.ts - Core domain types
• lib/validation.ts - Zod schemas
• components/**/*.tsx - Component prop interfaces
• hooks/**/*.ts - Hook return types
• tsconfig.json - TS configuration

Output Format:

## Type Coverage Analysis

### Configuration
- TypeScript strict mode: [enabled/disabled]
- Strict flags: [list if enabled]

### Type Definitions
- Total interfaces: [count]
- Total type aliases: [count]
- Exported core types: [count with list]

### Validation Schemas
- Total Zod schemas: [count]
- Schema coverage: [percentage with details]

### Schema-Interface Alignment
| Type | Interface | Schema | Alignment |
| --- | --- | --- | --- |
| [Type name] | ✓/❌ | ✓/❌ | [Status] |

### Coverage Metrics
- Hook return types: [percentage typed]
- Component props: [percentage typed]
- Function signatures: [percentage typed]
- `any` type usage: [count, locations if found]

### Issues Found
[Missing schemas, untyped functions, alignment gaps]

### Key Findings
[Overall type safety score, gaps, recommendations]

Output Format (Synthesis)

Return combined analysis as single structured report:

# Bookmark Vault Comprehensive Analysis

## Component Structure Analysis
[Fork 1 findings]

## Data Flow Analysis
[Fork 2 findings]

## Type Coverage Analysis
[Fork 3 findings]

## Cross-Section Implications
[Observations connecting multiple areas]

## Recommendations (Prioritized)
1. [Specific, actionable recommendation]
2. [Specific, actionable recommendation]
3. [Specific, actionable recommendation]

## Overall Assessment Score
- Component Architecture: [/10]
- Data Flow: [/10]
- Type Safety: [/10]
- OVERALL: [/10]

Common Issues to Watch

Analysis Verification Checklist

• Fork 1: Component count verified via Glob
• Fork 1: Parent-child tree complete (spot-check 5 components)
• Fork 2: Data flow traced from storage to UI (end-to-end)
• Fork 2: Prop drilling documented with specific component paths
• Fork 3: TypeScript config verified (read tsconfig.json)
• Fork 3: Zod schemas counted and compared to interfaces
• Synthesis: All three areas represented in final report
• Recommendations: Each is actionable and specific

Red Flags - STOP and Reconsider

These indicate analysis might be incomplete or context-forking failed:

Rationalization Blocking (Discipline Pattern)

The core pattern you're protecting against:

"I can combine the three analyses into one big report faster"

Reality: This violates the isolation principle. Fork results MUST be separated first.

Steps to combat this:

1. Even if rushing: Present Fork 1 findings first, Fork 2 second, Fork 3 third
2. Even if fork had no major issues: Include "Key Findings" section per fork showing isolation maintained
3. Even if synthesis seems obvious: Write explicit "Cross-Section Implications" - don't skip this step
4. Even if one area seems small: Include it with any findings found (minimum: configuration details)

Exception: None. Always separate, then synthesize.

Success Criteria

✓ Report includes all three analysis areas with structured section breaks ✓ Each area has 3+ specific findings with metrics or line references ✓ Fork isolation maintained: Findings organized by Fork 1 → Fork 2 → Fork 3 → Synthesis** ✓ Cross-section implications section present and non-empty ✓ Recommendations are actionable and tied to specific findings with file paths ✓ Overall assessment score provided with supporting evidence ✓ Verification checklist completed and all items checked ✓ No vague observations without data backing them ✓ No recommendations without line number or file reference ✓ Schema-interface alignment has actual percentages, not estimates