@nerdev/skillset 0.2.1

package/skills/business/startup-founder/references/validation.md

@@ -0,0 +1,267 @@
+# Idea Validation
+
+## The Mom Test (core method)
+Talk to potential customers about their life/problem, not your idea. Rules:
+- Ask about their past behavior and specific problems, not hypothetical future behavior ("would you use X" is a lie-generating question).
+- Do not pitch. Do not mention your idea until the end, if at all.
+- Good questions: "Walk me through the last time you dealt with [problem]." "What did you try to fix it?" "What does that cost you (time/money)?"
+- Bad questions: "Would you pay for a tool that does X?" (people say yes to be nice)
+- Do 10-15 of these conversations before writing a line of product code. Look for people who have already tried to solve the problem themselves (paid tools, spreadsheets, hacky workarounds). That is signal of real pain.
+
+## Fast market sizing
+- Top-down (market reports) is usually wrong for early-stage. Prefer bottom-up: how many potential customers exist, realistic price, realistic capture rate in year 1-2.
+- A small market you can dominate beats a huge market you cannot crack. Paul Graham states the "a market of one" thesis: build for a specific, underserved user first. YC gives the same advice: start narrow, expand later.
+
+## Red flags an idea isn't ready
+- You cannot name 5 specific people or companies who have this problem today.
+- The "customers" you are describing are hypothetical ("companies like X would want this").
+- Nobody you talked to already spent money or serious time trying to solve it.
+- The idea only works if a platform/regulation/behavior change happens first.
+
+## Green flags
+- People are already duct-taping a solution (Excel, Zapier chains, manual process). You can replace that.
+- People ask "when can I use this" unprompted during discovery calls.
+- The problem costs the person measurable time or money today.
+
+## For technical/dev-tooling ideas specifically
+- Check GitHub issues, Reddit (r/webdev, r/SaaS, r/startups), Hacker News "Who's Hiring"/"Show HN" threads, and Indie Hackers for existing pain points before building.
+- Competitor exists ≠ bad sign. No competitor at all is often a red flag (nobody found a business there), not a green one.
+
+---
+
+## Build in Public + Cold Outreach Playbook (DriftLock Case Study)
+
+### Core Philosophy
+**Build in public + talk to potential users + talk to founders + build based on what you learn.**
+Not "launch and hope people come."
+
+**Goal for early weeks:** Problem validation + design partners, not "getting users."
+
+---
+
+### 1. Start Build in Public Now (Day 1)
+
+Don't wait until polished. First post example:
+
+> "I'm building DriftLock.
+> The idea: APIs change, but the code using them doesn't magically update.
+> I'm exploring a tool that detects API changes affecting your codebase and auto-generates migration PRs.
+> Starting with Stripe.
+> Still at design stage — building in public, sharing what I learn.
+> If you've ever had an API migration unexpectedly break your code, I'd love to hear how you handled it."
+
+**Key:** You're not pretending you have a product. You're asking people with the problem to talk to you.
+
+---
+
+### 2. Don't Ask "Would You Use This?"
+
+**Biggest trap.** People say "yeah that's cool" to be nice. That's noise.
+
+**Instead ask about actual experience:**
+- "When was the last time an API change caused an issue for your team?"
+- "How did you discover it?"
+- "Who had to fix it?"
+- "How long did it take?"
+- "Do you have any automation around API migrations today?"
+- "What happens when Stripe changes something?"
+
+**You're discovering if you're solving a painful existing workflow**, not asking for idea validation.
+
+---
+
+### 3. Build a Spreadsheet of 100 Potential Users
+
+Not 100 YC founders. **Potential DriftLock users.**
+
+**Look for:**
+- Engineers/founders who use Stripe
+- Build SaaS
+- Work at startups
+- Maintain APIs/integrations
+- Have public GitHub repos
+- Write about engineering
+- Have dealt with migrations
+
+**Outreach template (highly personalized, small numbers):**
+
+> "Hey! I'm building something around API migrations and noticed you work quite a bit with Stripe.
+> I'm still in design stage, not trying to sell anything. Trying to understand how teams deal with breaking/API-version changes.
+> Have you ever had a Stripe/API change require a bunch of code changes on your side?
+> Would love to hear how you handled it."
+
+**Why this works:** Easier for a stranger to answer than "can you try my product?" — because you don't have one yet.
+
+---
+
+### 4. DM YC/Experienced Founders Now (Not After Launch)
+
+Don't approach as "please advise my startup." Approach as "you've crossed the bridge I'm approaching."
+
+> "Hey Dany, congrats on getting into YC!
+> I'm a full-stack developer building DriftLock, a dev tool around detecting API changes and generating migration PRs.
+> Just started — figuring out product and first users.
+> Reaching out to founders who've gone through early stage. Open to a quick 15-20 min chat? Mainly want to hear how you got first users and what you learned."
+
+Low response rate is normal. Don't take it personally.
+
+---
+
+### 5. Turn Design Docs Into Content
+
+Your thinking IS the content. You don't need manufactured achievements.
+
+Examples:
+> "I'm designing DriftLock. One question: should API migrations be detected from OpenAPI specs, runtime traffic, SDK versions, or some combination?"
+
+> "I initially thought detecting API changes would be the hard part. While designing, I realized identifying which lines of application code are affected may actually be harder."
+
+---
+
+### 6. Milestones That Matter (Not Waitlist)
+
+| Milestone | Signal Strength |
+|-----------|-----------------|
+| M0: Design validated | Weak |
+| M1: First API change detected | Technical |
+| M2: First affected code location identified | Technical |
+| M3: First migration PR generated | Technical |
+| M4: Stranger runs DriftLock | **Strong** |
+| M5: Stranger gets useful result | **Stronger** |
+| M6: 5 people use it | Strong |
+| M7: Someone asks to keep using it | **Very Strong** |
+| M8: Someone pays | **Strongest** |
+
+**First meaningful external milestone = one stranger gets value without you explaining every step.** Waitlist is a weak signal.
+
+---
+
+### 7. Move Quickly = Reduce Time Between Assumption and Evidence
+
+Not "build entire thing fast." **"Reduce time between assumption and evidence."**
+
+**Loop every week:**
+Build something → publish what you built → talk to 5–10 people → learn → update design → build again
+
+**Example public journey:**
+- Day 1 — Problem I'm investigating
+- Day 3 — What I learned from 5 engineers
+- Day 7 — Architecture I'm considering
+- Day 10 — First prototype detects breaking change
+- Day 14 — First generated migration PR
+- Day 18 — Someone outside my network tried it
+- Day 21 — Here's what broke
+
+---
+
+## Cold Outreach Mastery
+
+### Install Your Fucking Software on Other People's Systems
+You will network a lot and have something valuable.
+
+### Ask People to Roast Your Product
+Respond to your cold email.
+
+### Volume
+~20k outreach avg needed. Do 100 by hand, literally.
+
+### Subject Lines & Preview Text
+- **Avoid:** "inquiry," "exclusive," "seeking" → sounds like bot
+- **Experiment** with creative lines
+- **First 20-30 words** of body show in preview — make them count
+
+### Message Structure (5-8 sentences email, 2-5 LinkedIn)
+- Be informal
+- Explain how you want to help them
+- One-sentence value prop
+- Social proof: other customers OR very relevant background
+- **Specific CTA:** "Got 20 mins this week?" (not "does this sound interesting?")
+- Include calendar link
+
+### Targeting Beats Perfect Message
+- Think: does this person actually have this pain point?
+- Check last success → reach out to similar people
+- Who in org has most to gain from buying?
+- Company size matters
+- Verify individually if they're right fit
+
+### Start With Warm Network
+Friends, family, literally everyone → ask for intros
+
+### LinkedIn Optimization
+- Profile pic
+- Banner as an ad
+- 1-line description for company
+- Elevate anything buyer would care about
+- Build mutual connections
+
+### Reply Rate Benchmarks
+**2-3 replies per 100** is normal. Improve by:
+- Contact right person
+- Contact right companies
+- Good subject lines
+- Good message
+- Good materials
+- Deliverability
+
+### Follow-Up Cadence
+4 follow-ups over ~10 days (5 total touches). Break up message — make things clear.
+
+### Block Out Time
+- How many msgs/day
+- Time per msg
+- When to send
+
+### Use Customer Language
+Ask existing customers: "What got your attention about my message?"
+"How do you think about my product?"
+Use their words in your outreach.
+
+---
+
+## Build in Public: Video & Multi-Platform
+
+**Put up videos everywhere:** YouTube, X/Twitter, LinkedIn, TikTok, Reels, Shorts.
+
+**Content types that work:**
+- Day-in-the-life building
+- "Here's what I learned today" (2-3 min)
+- Live coding / architecture walkthroughs
+- Problem deep-dives (not solution pitches)
+- User conversation highlights (anonymized)
+- Milestone updates (M1-M8 from above)
+- Failures and what broke
+
+**Frequency:** 3-5 posts/week minimum. Consistency > quality at start.
+
+**Repurpose:** One recording → clip for X, LinkedIn, Shorts, TikTok. Long-form for YouTube.
+
+---
+
+## Warm Intro Networks (Exhaust Before Cold)
+
+**Tier 1 — Direct:**
+- Close friends
+- Current/former coworkers
+- School alumni (same cohort, same major, same clubs)
+- Employer alumni network (ex-Google, ex-Stripe, ex-YC, etc.)
+
+**Tier 2 — One Hop:**
+- Friends of friends (ask: "Who do you know who deals with Stripe/API migrations?")
+- Former coworkers' current networks
+- Alumni one degree out
+
+**Tier 3 — Community:**
+- Indie Hackers / YC co-founder matching / OnDeck / Pioneer / HF0 alumni
+- Discord/Slack communities you're active in
+- Conference/meetup contacts
+
+**How to ask:**
+> "Hey [Name], I'm building DriftLock — a tool that detects API changes and auto-generates migration PRs. Starting with Stripe.
+> I'm looking to talk to engineers who've felt this pain. Know anyone who:
+> - Maintains Stripe integrations
+> - Has dealt with breaking API changes
+> - Builds SaaS with payment integrations
+> Would appreciate an intro. Happy to share what I'm learning too."
+
+**Track in your 100-person spreadsheet:** Source column (warm Tier 1/2/3 vs cold). Warm intros convert 10-50x better.

package/skills/devops/deployments/SKILL.md

@@ -0,0 +1,339 @@
+---
+name: deployments
+description: "Analyze any repository structure (monorepo, separate frontend/backend, full-stack, static site) and give clean step-by-step deployment instructions for AWS EC2, VPS, or virtual machines. Guides through the complete E2E process from launching instances to SSL setup, with exact commands, verification steps, and troubleshooting. Use when user wants to deploy a repo to production, asks about AWS/cloud deployment, or needs hosting guidance. Covers all architectures: Node.js, Python, Docker, static sites, databases, and adapts instructions to the detected tech stack."
+---
+
+# Deployments
+
+## When to trigger
+
+- User wants to deploy a repo to AWS/EC2/VPS/cloud VM
+- User asks "how do I deploy this"
+- User mentions setting up production environment
+- User uploads/clones a repo and wants hosting guidance
+- User asks about deployment architecture, setup, or infrastructure
+
+## What this skill does
+
+### Phase 1: Repository Analysis
+
+1. Identify architecture type: monorepo, separate repos, full-stack single project, static site, backend-only API, or microservices.
+2. Detect tech stack: frontend framework, backend runtime, database, build tools, package manager.
+3. Find critical files: package.json, Dockerfiles, .env.example, build scripts, migration files.
+
+### Phase 2: Deployment Strategy
+
+Based on analysis, determine single vs multi-server setup, reverse proxy needs (Nginx/Caddy), process management (PM2/systemd), build vs runtime separation, environment variables, port configuration, and SSL/HTTPS setup.
+
+### Phase 3: Step-by-Step Instructions
+
+Give in this format. Each step has a one-sentence goal, exact commands, and gotchas.
+
+```
+## Deployment Plan for [Project Name]
+
+Architecture detected: [e.g., "Monorepo with Next.js frontend + Express backend"]
+Recommended setup: [e.g., "Single EC2 t3.small, Nginx reverse proxy, PM2"]
+
+### Prerequisites Checklist
+- [ ] AWS account with billing enabled
+- [ ] Domain name (optional but recommended)
+- [ ] SSH key pair generated locally
+- [ ] Git installed locally
+
+### Step 1: Launch EC2 Instance
+Create the virtual machine.
+
+1. Go to AWS Console, EC2, Launch Instance
+2. Choose Ubuntu 22.04 LTS (free tier eligible)
+3. Instance type: t3.small (2GB RAM minimum for this stack)
+4. Key pair: Create new, download .pem file, save as `myproject.pem`
+5. Security group: Allow SSH (22), HTTP (80), HTTPS (443), Custom TCP ([ports needed])
+6. Storage: 20GB GP3
+7. Click Launch
+
+Save your .pem file immediately. You cannot download it again. Run `chmod 400 myproject.pem` after download. Note your instance's public IP from the console.
+
+### Step 2: Connect to Server
+SSH into your new instance.
+
+```bash
+chmod 400 myproject.pem
+ssh -i myproject.pem ubuntu@YOUR_INSTANCE_IP
+```
+
+Replace YOUR_INSTANCE_IP with actual IP from console. First connection asks to verify fingerprint, type "yes".
+
+### Step 3: Install System Dependencies
+Set up Node.js, Nginx, database.
+
+```bash
+# Update system
+sudo apt update && sudo apt upgrade -y
+
+# Install Node.js 20
+curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
+sudo apt install -y nodejs
+
+# Install Nginx
+sudo apt install -y nginx
+
+# Install PostgreSQL (if needed)
+sudo apt install -y postgresql postgresql-contrib
+
+# Install PM2 globally
+sudo npm install -g pm2
+```
+
+Each command should complete without errors. Check versions: `node -v`, `nginx -v`, `psql --version`.
+
+### Step 4: Clone Repository
+Get your code on the server.
+
+```bash
+cd /home/ubuntu
+git clone https://github.com/yourusername/yourrepo.git
+cd yourrepo
+```
+
+If private repo, set up GitHub SSH key or use personal access token. Verify all files cloned: `ls -la`.
+
+### Step 5: Configure Environment Variables
+Set up .env files.
+
+```bash
+# Backend
+cd /home/ubuntu/yourrepo/backend
+cp .env.example .env
+nano .env
+```
+
+Edit these values:
+```
+DATABASE_URL=postgresql://user:password@localhost:5432/dbname
+PORT=5000
+NODE_ENV=production
+JWT_SECRET=[generate random string]
+```
+
+Frontend (if separate):
+```bash
+cd /home/ubuntu/yourrepo/frontend
+cp .env.example .env
+nano .env
+```
+
+```
+VITE_API_URL=http://YOUR_INSTANCE_IP:5000
+```
+
+Generate secure secrets with `openssl rand -base64 32`. Never commit .env files. Save and exit nano: Ctrl+X, Y, Enter.
+
+### Step 6: Set Up Database
+Create database and run migrations.
+
+```bash
+# Switch to postgres user
+sudo -u postgres psql
+
+# In PostgreSQL prompt:
+CREATE DATABASE yourdbname;
+CREATE USER youruser WITH PASSWORD 'securepassword';
+GRANT ALL PRIVILEGES ON DATABASE yourdbname TO youruser;
+\q
+
+# Run migrations (adjust for your project)
+cd /home/ubuntu/yourrepo/backend
+npm install
+npm run migrate
+```
+
+Use the same credentials in .env. Check migration success before continuing.
+
+### Step 7: Build Frontend
+Compile production assets.
+
+```bash
+cd /home/ubuntu/yourrepo/frontend
+npm install
+npm run build
+```
+
+Build creates `dist/` or `build/` folder. Check for errors in build output. Note the output folder name.
+
+### Step 8: Start Backend with PM2
+Run backend as persistent process.
+
+```bash
+cd /home/ubuntu/yourrepo/backend
+npm install
+pm2 start npm --name "backend" -- start
+pm2 save
+pm2 startup
+```
+
+Run the command PM2 outputs (starts with sudo). `pm2 status` shows backend running. `pm2 logs backend` to check for errors. PM2 will auto-restart on crashes and server reboots.
+
+### Step 9: Configure Nginx
+Set up reverse proxy and serve frontend.
+
+```bash
+sudo nano /etc/nginx/sites-available/yourapp
+```
+
+Paste this config:
+```nginx
+server {
+    listen 80;
+    server_name YOUR_DOMAIN_OR_IP;
+
+    # Frontend
+    location / {
+        root /home/ubuntu/yourrepo/frontend/dist;
+        try_files $uri $uri/ /index.html;
+    }
+
+    # Backend API
+    location /api {
+        proxy_pass http://localhost:5000;
+        proxy_http_version 1.1;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Connection 'upgrade';
+        proxy_set_header Host $host;
+        proxy_cache_bypass $http_upgrade;
+    }
+}
+```
+
+Enable the site:
+```bash
+sudo ln -s /etc/nginx/sites-available/yourapp /etc/nginx/sites-enabled/
+sudo nginx -t
+sudo systemctl restart nginx
+```
+
+Replace YOUR_DOMAIN_OR_IP with actual value. Adjust `/api` path if your backend uses different routes. `nginx -t` must show "syntax is ok".
+
+### Step 10: Configure Firewall
+Lock down security.
+
+```bash
+sudo ufw allow 'Nginx Full'
+sudo ufw allow OpenSSH
+sudo ufw enable
+```
+
+Allow OpenSSH BEFORE enabling firewall or you will lock yourself out. Type 'y' when prompted.
+
+### Step 11: Test Deployment
+Verify everything works.
+
+1. Visit http://YOUR_INSTANCE_IP in browser
+2. Frontend should load
+3. Test API calls through frontend
+4. Check PM2 logs: `pm2 logs backend`
+5. Check Nginx logs: `sudo tail -f /var/log/nginx/error.log`
+
+If frontend doesn't load, check Nginx config. If API fails, check backend logs and .env. Browser console shows frontend errors.
+
+### Step 12: SSL Setup
+Enable HTTPS with Let's Encrypt.
+
+```bash
+sudo apt install certbot python3-certbot-nginx
+sudo certbot --nginx -d yourdomain.com
+```
+
+Follow prompts, choose redirect HTTP to HTTPS. Need a domain name pointing to your IP. Certificates auto-renew every 90 days. Test auto-renewal: `sudo certbot renew --dry-run`.
+
+## Maintenance Commands
+
+View logs:
+```bash
+pm2 logs backend
+sudo tail -f /var/log/nginx/error.log
+```
+
+Restart services:
+```bash
+pm2 restart backend
+sudo systemctl restart nginx
+```
+
+Update code:
+```bash
+cd /home/ubuntu/yourrepo
+git pull
+cd frontend && npm install && npm run build
+cd ../backend && npm install
+pm2 restart backend
+```
+
+Monitor resources:
+```bash
+pm2 monit
+htop
+df -h  # disk space
+```
+
+## Troubleshooting
+
+Site not loading: check firewall (`sudo ufw status`), Nginx (`sudo systemctl status nginx`), PM2 (`pm2 status`).
+
+API 502 errors: backend not running (`pm2 restart backend`), wrong port in Nginx config, check backend logs (`pm2 logs backend`).
+
+Database connection fails: check PostgreSQL running (`sudo systemctl status postgresql`), verify .env DATABASE_URL matches database setup, check user permissions.
+
+Out of memory: upgrade instance type, add swap space, optimize build process.
+
+## Cost Estimate
+
+- t3.small EC2: ~$15/month
+- Domain (optional): ~$12/year
+- Total: ~$15-20/month
+
+## Adaptation Rules
+
+Monorepo with shared code: install at root level, build workspace packages first, separate PM2 processes for each service.
+
+Microservices: multiple PM2 processes, Nginx routing to different ports, consider Docker Compose alternative.
+
+Static site only: skip PM2 and database, Nginx serves files directly, cheaper (t3.micro).
+
+Docker-based: install Docker instead of Node, use docker-compose, Nginx optional (can use Docker ports).
+
+Python backend: use gunicorn instead of PM2, systemd service file, install pip requirements.
+
+Different databases: MongoDB (install MongoDB server, adjust connection string), MySQL (install mysql-server, use mysql commands), Redis (install redis-server for caching).
+
+Different clouds: DigitalOcean ("Droplet" instead of EC2, otherwise identical), Linode ("Linode" instead of EC2, same process), Vultr (same Ubuntu setup process).
+
+## Output Format Rules
+
+1. Always start with architecture detection.
+2. Number every step.
+3. One-sentence goal, exact commands, gotchas per step.
+4. Use actual values when possible, placeholders when not.
+5. Include verification commands after critical steps.
+6. Give copy-pasteable code blocks.
+7. End with maintenance and troubleshooting.
+
+## Critical Principles
+
+Never assume knowledge. Explain what EC2 is, what PM2 does, why Nginx. One step, one concept. Show the actual command, not "run the migration script." Explain why. Include checkpoints before continuing. Offer alternative paths for different stacks.
+
+## Quality Checks Before Output
+
+- [ ] Can a beginner follow this without prior AWS knowledge?
+- [ ] Are all ports/URLs/paths specific to this repo?
+- [ ] Did I explain what each tool does?
+- [ ] Are there verification steps after critical changes?
+- [ ] Did I cover what to do when things break?
+- [ ] Is the security group configuration complete?
+- [ ] Are environment variables all documented?
+
+## Example Adaptations
+
+Next.js app (frontend + API routes): skip separate backend setup, PM2 runs `next start` only, Nginx proxies everything to Node, simpler architecture.
+
+Django + React: Python/pip instead of Node for backend, Gunicorn + systemd instead of PM2, static file collection step, PostgreSQL setup same.