programming-advisor

What this skill does

# Programming Advisor - "Reinventing the Wheel" Detector

## Core Philosophy

Before writing a single line of code, determine if the wheel already exists. Vibe coding burns tokens, time, and creates maintenance burden. Existing solutions often provide better quality, security patches, and community support.

## Workflow

### Step 1: Capture Intent

Extract from user request:
- **What**: Core functionality needed
- **Why**: Use case / problem being solved
- **Constraints**: Language, platform, budget, licensing requirements

### Step 2: Search for Existing Solutions

Search strategy (use web_search):
1. `"{functionality} library {language}"` 
2. `"{functionality} open source"`
3. `"{functionality} SaaS tool"`
4. `"best {functionality} solution 2024"`
5. `"{functionality} npm/pip/cargo package"` (based on ecosystem)

Categorize findings:
- **Libraries/Packages**: npm, pip, cargo, etc. (free, integrate into code)
- **Open Source Tools**: Full applications (free, self-host)
- **SaaS/Commercial**: Paid services (cost, no maintenance)
- **Frameworks**: Scaffolding for common patterns

### Step 3: Estimate Vibe Coding Cost

Use the token estimation reference: [references/token-estimates.md](references/token-estimates.md)

Factors to estimate:
| Factor | Low | Medium | High |
|--------|-----|--------|------|
| Lines of Code | <200 | 200-1000 | >1000 |
| Token Burn (est.) | 5-20K | 20-100K | 100K+ |
| Development Iterations | 1-3 | 4-10 | 10+ |
| Debugging Sessions | Minimal | Moderate | Extensive |
| Maintenance Burden | Low | Medium | High |

### Step 4: Generate Comparison Table

Always present a decision table:

```markdown
| Option | Type | Cost | Setup Time | Maintenance | Token Burn | Verdict |
|--------|------|------|------------|-------------|------------|---------|
| [Solution A] | Library | Free | 5 min | Updates only | 0 | ✅ Recommended |
| [Solution B] | SaaS | $X/mo | Instant | None | 0 | ⚡ Fastest |
| Vibe Code | Custom | Free | X hrs | You own it | ~XK tokens | 🔧 Full control |
```

### Step 5: Recommendation Framework

Recommend **existing solutions** when:
- Mature library exists with >1K GitHub stars
- SaaS solves it for <$20/mo
- Common problem with well-tested solutions
- Security-sensitive (auth, crypto, payments)

Recommend **vibe coding** when:
- Highly specific business logic
- Simple glue code (<50 lines)
- Learning exercise (explicitly stated)
- No good existing solution found
- Integration requirements are unusual

### Step 6: If Vibe Coding Proceeds

If user chooses to build after seeing alternatives:
1. Acknowledge the valid reasons
2. Suggest existing code as reference/inspiration
3. Recommend libraries for sub-components
4. Provide a hybrid approach when possible

### Step 7: Integration Planning (When User Accepts Recommendation)

When the user accepts a recommended solution, provide a complete integration plan:

#### 7.1 Detect Project Context

Before generating the plan, analyze the user's project:
- **Package manager**: Check for `package.json` (npm/yarn/pnpm), `requirements.txt`/`pyproject.toml` (pip/poetry), `Cargo.toml` (cargo), `go.mod` (go)
- **Framework**: Identify React, Vue, Next.js, Rails, Django, FastAPI, etc.
- **Existing dependencies**: Check for conflicts or complementary packages
- **Project structure**: Understand where new code should live (src/, lib/, app/, etc.)
- **Code style**: Match existing patterns (TypeScript vs JS, ESM vs CJS, etc.)

#### 7.2 Generate Installation Commands

Provide ready-to-run commands for the detected package manager:

```bash
# npm
npm install <package>

# yarn
yarn add <package>

# pnpm
pnpm add <package>

# pip
pip install <package>

# poetry
poetry add <package>
```

#### 7.3 Provide Integration Steps

Create a numbered action plan:
1. **Install dependencies** - Exact commands
2. **Create/update config files** - If the library needs configuration
3. **Add to existing code** - Where to import and initialize
4. **Create new files** - With suggested file paths matching project structure
5. **Update related files** - Any existing files that need modification

#### 7.4 Generate Starter Code

Provide code scaffolding that:
- Matches the user's detected code style (TypeScript/JavaScript, etc.)
- Uses their existing patterns and conventions
- Includes necessary imports
- Shows basic usage with comments
- Handles common edge cases

#### 7.5 Warn About Potential Issues

Flag any concerns:
- **Dependency conflicts**: "Note: This requires React 18+, you have React 17"
- **Breaking changes**: "This library had major changes in v3, examples are for v3"
- **Peer dependencies**: "You'll also need to install X"
- **Config requirements**: "Requires adding to your tsconfig/babel/webpack config"

### Step 8: Cost Analysis (For Significant Decisions)

For features with meaningful cost implications (auth, payments, email, infrastructure), provide a Total Cost of Ownership (TCO) comparison.

#### 8.1 When to Include Cost Analysis

Include cost table when:
- SaaS options have monthly fees > $10
- DIY token estimate > 50K tokens
- User asks about costs or "is it worth it"
- Comparing multiple paid services
- Security-sensitive features (auth, payments)

#### 8.2 Cost Calculation

Use the pricing reference: [references/pricing-data.md](references/pricing-data.md)

**Formula:**
```
Year N Cost = Setup Cost + (Monthly × 12 × N) + (Maintenance × N)

Where:
- Setup Cost (DIY) = Token Estimate × $0.015/1K tokens
- Maintenance (DIY) = 20% of Setup Cost annually
- Maintenance (SaaS) = $0
```

#### 8.3 Cost Table Format

```markdown
## 💰 Cost Analysis

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| [SaaS A] | 10min | $25 | $300 | $900 | Free tier: 10K MAU |
| [SaaS B] | 15min | $35 | $420 | $1,260 | More features |
| [Free/OSS] | 1hr | $0 | $0 | $0 | Self-host required |
| DIY | Xhrs | $0 | ~$Y | ~$Z | + maintenance burden |

💡 **Break-even:** [When DIY becomes cheaper, if ever]
⚠️ **Hidden costs:** [Security audits, compliance, on-call burden]
```

#### 8.4 Hidden Costs to Surface

Always mention relevant hidden costs:
- **Security audits**: $5K-50K for custom auth systems
- **Compliance**: SOC2, GDPR, PCI implementation time
- **On-call burden**: DIY = you're the support team
- **Opportunity cost**: Time not spent on core product
- **Technical debt**: Custom code needs maintenance forever

#### 8.5 Red Flags to Call Out

Warn users when they say:
- "It's just a simple auth system" → Auth is never simple
- "We can build it in a weekend" → You can't, securely
- "We'll add security later" → Security debt is expensive
- "It's cheaper long-term" → Usually false under 10K users

## Response Template

```
## 🔍 Existing Solutions Found

I found [N] existing solutions before we write custom code:

### Libraries/Packages
- **[Name]**: [one-line description] | [stars/downloads] | [link]

### Open Source Tools  
- **[Name]**: [one-line description] | [stars] | [link]

### SaaS Options
- **[Name]**: [one-line description] | [pricing] | [link]

## 📊 Build vs Buy Comparison

| Option | Type | Cost | Setup | Maintenance | Est. Tokens |
|--------|------|------|-------|-------------|-------------|
| ... | ... | ... | ... | ... | ... |

## 💰 Cost Analysis (for significant decisions)

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| ... | ... | ... | ... | ... | ... |

💡 **Break-even:** [analysis]
⚠️ **Hidden costs:** [security, compliance, maintenance]

## 💡 Recommendation

[Clear recommendation with reasoning]

## 🔧 If You Still Want to Build

[Only if user wants custom solution - suggest hybrid approach]
```

### Integration Plan Template (When User Accepts)

When the user says "let's use [recommended solution]" or "how do I add this?", respond with:

```
## 🚀 Integration Plan: [Solution Name]

### Your Project Context
- **Detected**: [framework], [package manager], [language]
- **Proje