@c0x12c/ai-toolkit 1.15.0

package/skills/design-workflow/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: design-workflow
+description: "Anti-AI-generic design guidelines. Use when creating UI prototypes, reviewing designs for generic AI patterns, or setting up a project design system."
+allowed_tools:
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+---
+
+# Design Workflow Skill
+
+Guidelines for making UI designs that don't look AI-generated. These rules apply to any design work — prototypes, design docs, or UI code.
+
+## What This Skill Does
+
+1. Teaches how to avoid "generic AI" design patterns
+2. Provides a checklist for design quality
+3. Guides component-by-component design approach
+4. Sets prototype quality standards
+
+## Rule 1: Use the Existing Design System
+
+**NEVER invent new colors, fonts, or spacing.** Always use what the project defines.
+
+### What to Read FIRST
+1. `.planning/design-config.md` — project colors, fonts, spacing, brand identity
+2. The theme files listed in design-config — actual CSS tokens
+3. Existing components in the codebase — match their patterns
+
+### Key Points
+- Use EXACT hex values from the project palette (not Tailwind defaults like `bg-blue-500`)
+- Use the project's font — don't swap in Inter, Poppins, or Space Grotesk
+- Use the project's border radius and shadow values
+- Reference CSS variables or tokens — don't hardcode
+
+---
+
+## Rule 2: Avoid Generic AI Patterns
+
+These patterns scream "AI made this" — avoid them ALL:
+
+### Colors
+- Don't use colors outside the project palette
+- No random purple/violet gradients (the #1 AI cliche)
+- No neon colors or rainbow gradients
+- No gray-on-gray with no accent color
+- Use the project's accent color — that's what makes it unique
+
+### Layout
+- No centered-everything-with-max-width-on-every-section
+- No hero with a giant gradient blob behind text
+- No three-column feature cards with icons that all look the same
+- No 50/50 split with image on right, text on left (for every section)
+- Break the grid sometimes — asymmetry is more interesting
+
+### Typography
+- No single font size for everything
+- Create clear hierarchy: big headings, medium subheads, small body
+- Use font weight contrast
+- Don't center-align long text blocks
+
+### Components
+- No rounded rectangles that all look identical
+- Give cards visual variety — different sizes, featured vs normal
+- Buttons should have clear primary/secondary/ghost hierarchy
+- Don't use icons for everything — sometimes text is better
+
+### Copy
+- No generic marketing fluff ("Unlock your potential", "Take it to the next level")
+- Be specific — use real feature names and real numbers
+- Match the tone from design-config's Design Personality
+
+---
+
+## Rule 3: Design Component by Component
+
+Don't design a whole page at once. Build pieces, then compose.
+
+### Order of Work
+1. **Design tokens** — Confirm colors, fonts, spacing from existing theme files
+2. **Base components** — Button, Card, Badge, Input (small, isolated)
+3. **Composite components** — Nav bar, Sidebar, Hero section, Feature card
+4. **Full screens** — Compose components into pages
+5. **States** — Add loading, empty, error states to each component
+6. **Responsive** — Adjust each screen for mobile/tablet/desktop
+
+---
+
+## Rule 4: Use Visual References
+
+When references are given:
+1. Study what makes it look good (layout, color, typography, whitespace)
+2. Take inspiration, don't copy — match the quality level, not the exact layout
+3. Apply to the project's design system
+
+When NO references are given:
+- Check Reference Apps in design-config
+- Focus on whitespace — more space = more premium
+- Use accent color sparingly — max 10-15% of the screen
+- Make one thing big and bold per section (hierarchy)
+
+---
+
+## Rule 5: Prototype Quality Standards
+
+### Must Have
+- Exact colors from the project theme files
+- Real fonts loaded
+- Proper spacing (not random padding everywhere)
+- Real content (not "Lorem ipsum")
+- All states visible (loading, empty, error, success)
+- Responsive: works at 375px, 768px, 1440px
+
+### Must NOT Have
+- Placeholder images or stock photo URLs
+- Default Tailwind colors
+- Missing hover/focus states
+- Broken layout at any viewport
+- Text that's hard to read (check contrast)
+
+---
+
+## Review & Checklists
+
+> See checklists.md for the self-check, critic review checklists, and design-implementation mismatch troubleshooting.

package/skills/design-workflow/checklists.md

@@ -0,0 +1,45 @@
+# Design Workflow — Checklists & Review
+
+> This file is referenced by SKILL.md. Read it when reviewing a design or debugging visual issues.
+
+## Self-Check Before Review
+
+Before sending to any reviewer, verify:
+
+1. **Does it look like a real app, or a generic template?**
+2. **Squint test** — squint at the screenshot, can you still see the structure?
+3. **Comparison test** — does this look as good as the Reference Apps?
+4. **Copy check** — is the text specific and helpful?
+5. **Personality check** — does it match the Design Personality?
+
+## Critic Review Checklist
+
+### AI Generic Detection
+- [ ] No colors outside the project palette
+- [ ] No generic gradient blobs
+- [ ] Layout has visual variety (not everything centered, same size)
+- [ ] Typography has clear hierarchy (3+ distinct sizes/weights)
+- [ ] Copy is specific to the project domain
+
+### Design Quality
+- [ ] Whitespace is balanced
+- [ ] Accent color used sparingly and with purpose
+- [ ] Cards/components have variety
+- [ ] Hover states exist and look good
+- [ ] The design has personality matching design-config
+
+### Consistency
+- [ ] Same button styles across all screens
+- [ ] Same spacing patterns throughout
+- [ ] Same card styles with minor variations
+- [ ] Font usage matches design-config
+
+## Troubleshooting: Design vs Implementation Mismatch
+
+| Problem | Cause | Fix |
+|---------|-------|-----|
+| Colors are wrong | Used Tailwind defaults | Use exact values from theme files |
+| Spacing is off | Used random padding | Follow the spacing scale in theme files |
+| Fonts look different | Fonts not loaded | Load fonts from design-config |
+| Components look generic | No reference to project style | Read theme files and design-config first |
+| Mobile is broken | Desktop-first without testing | Always check at all 3 breakpoints |

package/skills/idea-validation/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: idea-validation
+description: Validate a startup idea with competitor analysis, market signals, and risk assessment. Be brutally honest. Use when the user wants to test if an idea is worth building.
+allowed_tools:
+  - WebSearch
+  - WebFetch
+  - Read
+---
+
+# Idea Validation
+
+Kill bad ideas fast. Save time for good ones.
+
+## When to Use
+
+- User has a specific idea to test
+- Before building anything
+- Before spending money on research
+- When choosing between ideas
+
+> See `example-report.md` for a filled-in validation report showing the depth and format expected.
+
+## Process
+
+### 1. Understand the Idea
+Get clear on:
+- What does it do? (one sentence)
+- Who is it for? (specific person)
+- What problem does it fix?
+- How do they fix it today?
+
+### 2. Problem Check
+- Is this a real pain? Or just "nice to have"?
+- How often does this problem happen?
+- Do people spend money/time on it now?
+- Search for Reddit threads, forum posts, review complaints
+- Look for "hair on fire" signals
+
+### 3. Market Check
+- TAM/SAM/SOM (rough numbers, show math)
+- Growing or shrinking?
+- Any tailwinds? (new regulation, tech shift, behavior change)
+- Any headwinds?
+
+### 4. Competitor Check
+Find 5-10 competitors or close alternatives:
+- Direct competitors (same problem, same solution)
+- Indirect competitors (same problem, different solution)
+- What they do well
+- What they do badly (check 1-star reviews)
+- Pricing
+- Funding
+
+### 5. Distribution Check
+- How would you get your first 100 users?
+- Is there a natural channel? (SEO, community, viral, sales)
+- What's the CAC estimate?
+- Is there a network effect or flywheel?
+
+### 6. Build Check
+- Can you make an MVP in 2 weeks?
+- What's the hardest technical part?
+- Any regulatory or legal issues?
+
+### 7. Verdict
+
+Give a clear verdict:
+- **GO** - Strong signals, build it
+- **TEST MORE** - Some signals, needs cheap validation first
+- **PASS** - Weak signals, don't build
+
+Include:
+- Top 3 reasons for your verdict
+- The #1 risk
+- The cheapest next step to test
+
+## Interaction Style
+
+**No BS. Honest feedback only.**
+
+This is a two-way talk:
+- I ask you questions → you answer
+- You ask me questions → I think hard, give you options, then answer
+
+**When I ask you a question, I always:**
+1. Think about it first
+2. Give you 2-3 options with my honest take on each
+3. Tell you which one I'd pick and why
+4. Then ask what you think
+
+**When you ask me something:**
+- I give you a straight answer with data
+- If your idea is weak, I tell you why
+- I don't let your excitement change my analysis
+
+**Never:**
+- Ask a question without giving options
+- Sugarcoat a bad verdict
+- Say "it depends" without picking a side
+- Dodge the hard truth to be polite
+- Let a cool idea pass without real demand signals
+
+## Rules
+
+- Be harsh. Most ideas should get PASS or TEST MORE.
+- Don't sugarcoat. "This probably won't work because..." is fine.
+- Back opinions with data when you can.
+- If you can't find data, say so.
+- Don't let the user's excitement bias your analysis.
+
+## Gotchas
+
+- **Confirmation bias is the #1 killer.** The user wants to hear "GO." Your job is to find reasons to say "PASS." Start with reasons it won't work.
+- **TAM without math is fiction.** "The market is $50B" means nothing. Show the calculation: X users x Y price x Z frequency.
+- **"No competitors" is a red flag, not a green one.** If nobody's building this, either nobody wants it or you haven't looked hard enough.
+- **Don't validate ideas -- validate problems.** An idea can be wrong while the problem is real. Always separate problem validation from solution validation.
+- **Quick test > more research.** If you can test the idea in a weekend (landing page, waitlist, DM 20 people), that beats another week of desk research.
+
+## Output
+
+Save to the project's `03-validation/` folder.
+
+## Frameworks to Use
+
+Pull from `/frameworks/` when relevant:
+- Lean Canvas (01-lean-canvas.md)
+- Jobs to Be Done (06-jobs-to-be-done.md)
+- Mom Test (07-mom-test.md)
+- Value Proposition Canvas (08-value-proposition-canvas.md)

package/skills/idea-validation/example-report.md

@@ -0,0 +1,50 @@
+# Idea Validation — Example Report
+
+> This file is referenced by SKILL.md. Use this format when producing a validation report.
+
+## Validation: AI-Powered Code Review Bot
+
+### The Idea
+A GitHub bot that reviews PRs automatically, catches bugs, suggests improvements, and enforces team conventions.
+
+### Problem Check
+- **Is it real pain?** Yes. Code reviews are a bottleneck — PRs wait 4-24 hours for review at most companies.
+- **How often?** Daily. Every PR needs review.
+- **Spending today?** Teams spend ~20% of senior engineer time on reviews. Some pay for CodeClimate ($15/user/mo) or SonarQube.
+- **Demand signals:** "automated code review" — 8.1K monthly searches. r/programming threads about slow PR reviews every month. Multiple HN posts about review fatigue.
+
+### Market Check
+- **TAM:** 28M developers worldwide x ~$10/mo = ~$3.4B
+- **SAM:** 4M developers at companies with >10 devs (need formal review) x $10/mo = ~$480M
+- **SOM:** 50K developers in first 2 years (realistic with PLG) x $10/mo = $6M ARR
+- **Trend:** Growing. AI coding tools market expanding 40%+ YoY.
+
+### Competitor Check
+| Competitor | What they do | Funding | Weakness |
+|-----------|-------------|---------|----------|
+| CodeRabbit | AI PR review | $2.5M seed | Generic comments, high noise |
+| Sourcery | Python-focused AI review | $5M | Python only, limited languages |
+| SonarQube | Static analysis | Public | Rule-based, not AI, slow setup |
+| GitHub Copilot | Code completion | Microsoft | Writes code, doesn't review PRs |
+
+### Distribution Check
+- **First 100 users:** GitHub Marketplace listing + Show HN + dev Twitter
+- **Natural channel:** GitHub Marketplace is a built-in distribution channel
+- **CAC estimate:** ~$0 for early users (PLG via marketplace)
+- **Network effect:** Weak. Each install is independent.
+
+### Build Check
+- **MVP in 2 weeks?** Yes — GitHub webhook + LLM API + comment on PR
+- **Hard part:** Reducing false positives. Bad suggestions = uninstall.
+- **Legal:** No issues. Code stays in GitHub, model doesn't train on it.
+
+### Verdict: TEST MORE
+
+**Top 3 reasons:**
+1. Real pain (review bottleneck is universal), strong search demand
+2. Clear distribution channel (GitHub Marketplace)
+3. BUT: crowded space, CodeRabbit has traction, differentiation unclear
+
+**#1 risk:** False positive rate. If >30% of comments are noise, teams disable it after a week.
+
+**Cheapest next step:** Build a minimal bot that reviews PRs for ONE thing well (e.g., just security issues). Ship to 10 teams. Measure: do they keep it on after 2 weeks?

package/skills/investor-materials/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: investor-materials
+description: Create pitch decks, one-pagers, memos, financial models, and fundraising materials. Use when the user needs investor-facing docs.
+allowed_tools:
+  - Read
+  - Write
+  - WebSearch
+---
+
+# Investor Materials
+
+Build investor materials that are consistent, real, and hard to poke holes in.
+
+## When to Use
+
+- Making or fixing a pitch deck
+- Writing an investor memo or one-pager
+- Building financial projections
+- Answering accelerator applications
+- Making sure all fundraising docs tell the same story
+
+> See `example-outline.md` for an example seed deck outline showing slide structure and content depth.
+
+## Golden Rule
+
+All investor materials must agree with each other.
+
+Before writing, confirm one source of truth:
+- Traction numbers
+- Pricing and revenue math
+- Raise size and terms
+- Use of funds
+- Team bios
+- Milestones and timeline
+
+If numbers don't match across docs, stop and fix that first.
+
+## Workflow
+
+1. Collect the real facts
+2. Find what's missing
+3. Pick the doc type
+4. Write it with clear logic
+5. Check every number against the source of truth
+
+## Pitch Deck Flow
+
+1. Company + wedge (why you)
+2. Problem
+3. Solution
+4. Product / demo
+5. Market
+6. Business model
+7. Traction
+8. Team
+9. Competition
+10. Ask
+11. Use of funds / milestones
+12. Appendix
+
+## One-Pager / Memo
+
+- Say what the company does in one sentence
+- Show why now
+- Put traction early
+- Make the ask clear
+- Keep claims easy to check
+
+## Financial Model
+
+- Show your assumptions
+- Bear / base / bull cases
+- Revenue logic layer by layer
+- Spending tied to milestones
+- Sensitivity analysis where the answer depends on guesses
+
+## Gotchas
+
+- **Numbers that don't match across docs are a deal-killer.** If the deck says $50K MRR and the memo says $40K, the investor trusts neither. Check every number against one source of truth.
+- **Market sizing without math is the #1 slide that gets called out.** "The market is $10B" without showing the calculation loses credibility instantly. Always show: X users × Y price × Z frequency.
+- **Fake certainty about assumptions kills trust.** "We will reach 100K users in 12 months" — no, you won't know that. Say "we assume" and show bear/base/bull cases.
+- **Team titles that don't match LinkedIn get checked.** Investors will look. If your CTO is listed as "Senior Developer" on LinkedIn, they'll notice.
+- **Revenue math that doesn't work backwards is obvious.** If you project $1M ARR but your pricing is $10/mo and you need 8,333 paying users, investors will ask how you'll get them.
+- **Hype language ("revolutionary", "disruptive") signals first-time founder.** Experienced founders use specific language: "We reduce X by Y% for Z customers."
+
+## Interaction Style
+
+**No BS. Honest feedback only.**
+
+This is a two-way talk:
+- I ask you questions → you answer
+- You ask me questions → I think hard, give you options, then answer
+
+**When I ask you a question, I always:**
+1. Think about it first
+2. Give you 2-3 options with my honest take on each
+3. Tell you which one I'd pick and why
+4. Then ask what you think
+
+**When you ask me something:**
+- I give you a straight answer
+- I tell you if a claim is weak or a number doesn't hold up
+- I push you to cut the hype and show real proof
+
+**Never:**
+- Ask a question without giving options
+- Let a weak claim slide into the deck
+- Say "it depends" without picking a side
+- Write hype that you can't back up in a meeting
+- Skip the "investor will ask about this" warnings
+
+## Before You Deliver
+
+- Every number matches the source of truth
+- Use of funds adds up
+- Assumptions are visible
+- No hype language
+- You could defend this in a meeting
+
+## Output
+
+Save to the project's `04-build/` folder.

package/skills/investor-materials/example-outline.md

@@ -0,0 +1,70 @@
+# Investor Materials — Example Deck Outline
+
+> This file is referenced by SKILL.md. Use this as a reference for pitch deck structure and slide content.
+
+## Example: Seed Deck for a Developer Tool
+
+### Slide 1: Title
+**[Company Name]** — AI-powered code review for engineering teams
+Raising $2M seed | [Founder Name], CEO
+
+### Slide 2: Problem
+- Code reviews take 4-24 hours per PR
+- Senior engineers spend 20% of time reviewing
+- Quality is inconsistent — reviewers miss bugs when tired
+- *"At our last company, 3 production bugs in Q4 were in code that passed review."*
+
+### Slide 3: Solution
+- GitHub bot that reviews every PR in <2 minutes
+- Catches security issues, bugs, and convention violations
+- Learns team patterns — gets better with feedback
+- [Screenshot of bot commenting on a real PR]
+
+### Slide 4: Demo / Product
+[2-3 screenshots showing: PR opened → bot reviews → developer accepts suggestion]
+
+### Slide 5: Traction
+- 340 teams installed (GitHub Marketplace)
+- $18K MRR, growing 25% month-over-month
+- 72% weekly active rate (teams use it every week)
+- NPS: 62
+
+### Slide 6: Market
+- $3.4B TAM (28M devs x $10/mo)
+- $480M SAM (4M devs at review-heavy companies)
+- Growing 40% YoY (AI dev tools market)
+
+### Slide 7: Business Model
+- Free: 5 PRs/week
+- Team: $8/user/mo (unlimited PRs)
+- Enterprise: $15/user/mo (SSO, custom rules, SLA)
+- Current split: 60% free, 35% team, 5% enterprise
+
+### Slide 8: Competition
+| | Us | CodeRabbit | SonarQube |
+|---|---|---|---|
+| AI-native | Yes | Yes | No (rules) |
+| Setup time | 30 seconds | 5 minutes | 2+ hours |
+| Learns team style | Yes | No | No |
+| False positive rate | 12% | 35% | 20% |
+
+### Slide 9: Team
+- **[CEO]** — ex-GitHub, built [relevant thing]
+- **[CTO]** — ex-Google, ML/NLP background
+- **[Head of Growth]** — scaled [previous company] to 50K users
+
+### Slide 10: Ask
+- Raising **$2M seed**
+- 18-month runway
+- Use of funds: 60% engineering (hire 3), 25% growth, 15% ops
+- Milestones: 2,000 teams, $100K MRR, Series A ready
+
+---
+
+## What Makes This Work
+
+- **Slide 2** opens with a quote — personal, not abstract
+- **Slide 5** leads with a number, not a description
+- **Slide 6** shows the math, not just a big number
+- **Slide 8** uses a metric the investor cares about (false positive rate), not a feature list
+- **Slide 10** ties money to milestones, not vague plans

package/skills/investor-outreach/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: investor-outreach
+description: Draft cold emails, warm intro blurbs, follow-ups, and investor communications. Use when the user needs to write to angels, VCs, or accelerators.
+allowed_tools:
+  - Read
+  - Write
+  - WebSearch
+---
+
+# Investor Outreach
+
+Write investor emails that are short, personal, and easy to act on.
+
+## When to Use
+
+- Writing a cold email to an investor
+- Making a warm intro request
+- Following up after a meeting or no reply
+- Writing investor updates
+
+> See `examples.md` for good vs bad email examples (cold outreach, warm intro, and follow-up).
+
+## Rules
+
+1. Make it personal. Every email.
+2. Keep the ask easy to say yes to.
+3. Use proof, not adjectives.
+4. Keep it short.
+5. Never send something that could go to any investor.
+
+## Cold Email Structure
+
+1. **Subject line** - Short and specific
+2. **Opener** - Why this investor, specifically
+3. **Pitch** - What you do, why now, one proof point
+4. **Ask** - One clear next step
+5. **Sign off** - Name, role, one credibility thing if needed
+
+## How to Personalize
+
+Use one or more:
+- Their portfolio companies
+- A talk, post, or article they wrote
+- A shared connection
+- A clear fit with their thesis
+
+If you don't have this info, ask for it. Or say the draft needs personalizing.
+
+## Follow-Up Timing
+
+- Day 0: First email
+- Day 4-5: Short follow-up with one new thing
+- Day 10-12: Final follow-up, clean close
+
+Stop after 3 unless told otherwise.
+
+## Warm Intro Requests
+
+Make it easy for the connector:
+- Why this intro makes sense
+- Include a forwardable blurb
+- Keep the blurb under 100 words
+
+## After a Meeting
+
+Include:
+- What you talked about
+- The answer or update you promised
+- One new proof point if you have one
+- What happens next
+
+## Interaction Style
+
+**No BS. Honest feedback only.**
+
+This is a two-way talk:
+- I ask you questions → you answer
+- You ask me questions → I think hard, give you options, then answer
+
+**When I ask you a question, I always:**
+1. Think about it first
+2. Give you 2-3 options with my honest take on each
+3. Tell you which one I'd pick and why
+4. Then ask what you think
+
+**When you ask me something:**
+- I give you a straight answer
+- I tell you if an email sounds desperate or generic
+- I push back if the proof point is weak
+
+**Never:**
+- Ask a question without giving options
+- Write a generic email and call it done
+- Say "it depends" without picking a side
+- Let a weak ask slide into the email
+- Skip the "this won't land because..." feedback
+
+## Gotchas
+
+- **Generic emails get deleted instantly.** "I'm reaching out because I admire your work" — every founder writes this. Reference a specific deal, post, or thesis point.
+- **The email is too long.** If it's more than 5 sentences, cut it. Investors scan, they don't read. The first email's job is to get a reply, not explain your whole company.
+- **The ask is too big for a cold email.** Don't ask for a 30-minute call in the first email. Ask for a quick reply, a 15-minute chat, or just to see the deck.
+- **No proof point = no interest.** "We're building X for Y" isn't enough. Include one concrete number: users, revenue, growth rate, waitlist size, or a notable customer.
+- **Follow-ups with no new information are annoying.** Don't just say "following up." Each follow-up needs something new: a milestone, a press mention, a new metric.
+
+## Before You Deliver
+
+- It's personalized
+- The ask is clear
+- No begging or fluff
+- Proof point is real
+- It's short