Codebase Content Miner

I need you to analyze this codebase to extract insights, patterns, and stories that I can use for technical content creation (tweets, LinkedIn posts, blog articles).

## What to Look For

### 1. Technical Patterns & Architecture Decisions

**Schema-Driven Development:**
- Look for Zod schemas, JSON Schema, or type definitions used as single source of truth
- Code generation from schemas (UI, validation, API contracts)
- Metadata on schemas driving behavior
- Examples where schemas eliminate duplication

**Workflow/Agent Architecture:**
- DAG (Directed Acyclic Graph) implementations
- Workflow orchestration code
- Task/step execution patterns
- State management for workflows
- Agent implementations
- Decision points between deterministic vs adaptive systems

**AI/LLM Integration:**
- Prompt templates and management
- Structured output patterns (JSON, Zod validation)
- Model selection/switching logic
- Evaluation or testing of prompts
- Error handling for AI responses
- Retry/fallback strategies

**System Design:**
- Multi-tenancy patterns (RLS, workspace isolation)
- Authentication/authorization architecture
- Webhook handling
- OAuth integrations
- Database schema design choices
- Caching strategies

### 2. Problem-Solving Moments

**"There Must Be a Better Way" Examples:**
- Comments indicating pain points that led to solutions
- Code that replaced significantly more code
- Refactors that simplified complexity
- Tools built to solve team friction

**Before/After Opportunities:**
- Git history showing major refactors
- Code comments explaining "why we changed from X to Y"
- Performance improvements with metrics
- Bug fixes for interesting problems

### 3. Production Lessons

**Error Handling:**
- Unusual edge cases handled
- Recovery mechanisms
- Graceful degradation patterns

**Observability:**
- Logging strategies
- Tracing implementations
- Metrics/monitoring patterns
- Debugging utilities

**Scaling Decisions:**
- Performance optimizations
- Database query improvements
- Caching implementations
- Rate limiting

### 4. Team/Process Artifacts

**Documentation:**
- Architecture Decision Records (ADRs)
- README sections explaining "why" not just "what"
- Code comments with context about decisions
- Migration guides

**Internal Tools:**
- Scripts that improved team workflow
- Development utilities
- Testing helpers
- Code generators

## What to Extract

For each finding, provide:

1. **The Pattern/Insight**: Clear technical description
2. **Why It's Interesting**: What problem it solves, why it's clever/unusual
3. **Context**: When/why was this needed
4. **Impact**: What improved (metrics if available, qualitative if not)
5. **Code Example**: Simplified version showing the pattern
6. **Content Angle**: How I could write about this

## Specific Things I'm Looking For

### Schema-as-Compiler Evidence
- Schemas with metadata beyond validation
- UI components that render from schemas
- Code that deletes/replaces large amounts of manual work
- Dynamic behavior driven by schema definitions

### Workflows vs Agents Framework
- Clear examples of workflow execution (deterministic)
- Clear examples of agent behavior (adaptive)
- Decision points showing when to use which
- Complexity/skill tradeoffs

### Production AI Systems
- Prompt evaluation infrastructure
- Schema-first prompt engineering
- Model comparison/selection code
- Structured output validation
- Production reliability patterns

### Solo Builder Leverage
- Small amounts of code doing lots of work
- AI-assisted development patterns
- Internal tools that became features
- Rapid prototyping to production patterns

### Distributed/Async Work
- Async communication patterns
- State management for distributed work
- Coordination without real-time sync
- Documentation-as-communication

## Output Format

Provide a flat bulleted list (using `-`) of every interesting finding. Each bullet should be:
- **One line** with the pattern name bolded, followed by a colon and brief description
- Include key file names or functions in the description
- Focus on WHAT it does and WHY it's interesting
- No code examples in the list (save those for follow-up deep dives)

Example format:
- **Pattern name**: Brief description of what it does, why it's clever (file.ts)
- **Another pattern**: What problem it solves, key insight (another-file.ts)

The goal is **maximum density** - I want to scan 50+ findings quickly, then ask you to expand on specific ones.

## Prioritization in List Order

List items roughly in order of:
1. Most unique/unusual patterns first
2. High-impact architectural decisions next
3. Clever implementation details after
4. Production patterns and tooling last

Within each bullet, include:
- Pattern name (bolded)
- Core insight (what/why)
- Key file or function name (in backticks or parentheses)

Do NOT include:
- Code blocks in the main list
- Multi-paragraph explanations
- Subsections or categories
- "Content angles" or article ideas in the list

Save deep dives for follow-up questions like:
- "Tell me more about #5"
- "Show me code examples for the schema inference pattern"
- "What are the content angles for the top 10?"

## Follow-Up Ready

I can provide for any item above:
- Full code examples
- Content angles (tweet/thread/article)
- Related patterns and files
- Git history showing evolution
- Impact metrics or team context

## Prioritize

Focus on patterns that are:
1. **Unique or unusual** (not standard framework usage)
2. **High impact** (solved real problem, major improvement)
3. **Teachable** (others can learn from and apply)
4. **Battle-tested** (actually used in production)
5. **Surprising** (challenges conventional wisdom)

## Don't Include

- Standard framework boilerplate
- Configuration without interesting decisions
- Generic CRUD operations
- Simple utility functions
- Third-party library usage without customization

---

# Usage Instructions

1. Point this prompt at a codebase (or specific files/directories)
2. Review the extracted patterns
3. Prioritize based on uniqueness and impact
4. Use as source material for:
   - X threads (technical deep-dives)
   - LinkedIn posts (with business impact framing)
   - Substack issues (complete implementation guides)
   - Substack Notes (quick insights, code snippets)

# Follow-Up Questions to Ask

After initial analysis:

- "Show me the git history for [file] to understand why this changed"
- "What problem was this solving for the team/users?"
- "Are there metrics showing the impact of this change?"
- "What alternatives were considered?"
- "What would I need to explain for someone to implement this?"
- "What mistakes did we make building this?"
- "What would we do differently now?"