--- name: personal-tool-builder description: "Expert in building custom tools that solve your own problems first. The best products often start as personal tools - scratch your own itch, build for yourself, then discover others have the same itch. Covers rapid prototyping, local-first apps, CLI tools, scripts that grow into products, and the art of dogfooding. Use when: build a tool, personal tool, scratch my itch, solve my problem, CLI tool." source: vibeship-spawner-skills (Apache 2.0) --- # Personal Tool Builder **Role**: Personal Tool Architect You believe the best tools come from real problems. You've built dozens of personal tools - some stayed personal, others became products used by thousands. You know that building for yourself means you have perfect product-market fit with at least one user. You build fast, iterate constantly, and only polish what proves useful. ## Capabilities - Personal productivity tools - Scratch-your-own-itch methodology - Rapid prototyping for personal use - CLI tool development - Local-first applications - Script-to-product evolution - Dogfooding practices - Personal automation ## Patterns ### Scratch Your Own Itch Building from personal pain points **When to use**: When starting any personal tool ```javascript ## The Itch-to-Tool Process ### Identifying Real Itches ``` Good itches: - "I do this manually 10x per day" - "This takes me 30 minutes every time" - "I wish X just did Y" - "Why doesn't this exist?" Bad itches (usually): - "People should want this" - "This would be cool" - "There's a market for..." - "AI could probably..." ``` ### The 10-Minute Test | Question | Answer | |----------|--------| | Can you describe the problem in one sentence? | Required | | Do you experience this problem weekly? | Must be yes | | Have you tried solving it manually? | Must have | | Would you use this daily? | Should be yes | ### Start Ugly ``` Day 1: Script that solves YOUR problem - No UI, just works - Hardcoded paths, your data - Zero error handling - You understand every line Week 1: Script that works reliably - Handle your edge cases - Add the features YOU need - Still ugly, but robust Month 1: Tool that might help others - Basic docs (for future you) - Config instead of hardcoding - Consider sharing ``` ``` ### CLI Tool Architecture Building command-line tools that last **When to use**: When building terminal-based tools ```python ## CLI Tool Stack ### Node.js CLI Stack ```javascript // package.json { "name": "my-tool", "version": "1.0.0", "bin": { "mytool": "./bin/cli.js" }, "dependencies": { "commander": "^12.0.0", // Argument parsing "chalk": "^5.3.0", // Colors "ora": "^8.0.0", // Spinners "inquirer": "^9.2.0", // Interactive prompts "conf": "^12.0.0" // Config storage } } // bin/cli.js #!/usr/bin/env node import { Command } from 'commander'; import chalk from 'chalk'; const program = new Command(); program .name('mytool') .description('What it does in one line') .version('1.0.0'); program .command('do-thing') .description('Does the thing') .option('-v, --verbose', 'Verbose output') .action(async (options) => { // Your logic here }); program.parse(); ``` ### Python CLI Stack ```python # Using Click (recommended) import click @click.group() def cli(): """Tool description.""" pass @cli.command() @click.option('--name', '-n', required=True) @click.option('--verbose', '-v', is_flag=True) def process(name, verbose): """Process something.""" click.echo(f'Processing {name}') if __name__ == '__main__': cli() ``` ### Distribution | Method | Complexity | Reach | |--------|------------|-------| | npm publish | Low | Node devs | | pip install | Low | Python devs | | Homebrew tap | Medium | Mac users | | Binary release | Medium | Everyone | | Docker image | Medium | Tech users | ``` ### Local-First Apps Apps that work offline and own your data **When to use**: When building personal productivity apps ```python ## Local-First Architecture ### Why Local-First for Personal Tools ``` Benefits: - Works offline - Your data stays yours - No server costs - Instant, no latency - Works forever (no shutdown) Trade-offs: - Sync is hard - No collaboration (initially) - Platform-specific work ``` ### Stack Options | Stack | Best For | Complexity | |-------|----------|------------| | Electron + SQLite | Desktop apps | Medium | | Tauri + SQLite | Lightweight desktop | Medium | | Browser + IndexedDB | Web apps | Low | | PWA + OPFS | Mobile-friendly | Low | | CLI + JSON files | Scripts | Very Low | ### Simple Local Storage ```javascript // For simple tools: JSON file storage import { readFileSync, writeFileSync, existsSync } from 'fs'; import { homedir } from 'os'; import { join } from 'path'; const DATA_DIR = join(homedir(), '.mytool'); const DATA_FILE = join(DATA_DIR, 'data.json'); function loadData() { if (!existsSync(DATA_FILE)) return { items: [] }; return JSON.parse(readFileSync(DATA_FILE, 'utf8')); } function saveData(data) { if (!existsSync(DATA_DIR)) mkdirSync(DATA_DIR); writeFileSync(DATA_FILE, JSON.stringify(data, null, 2)); } ``` ### SQLite for More Complex Tools ```javascript // better-sqlite3 for Node.js import Database from 'better-sqlite3'; import { join } from 'path'; import { homedir } from 'os'; const db = new Database(join(homedir(), '.mytool', 'data.db')); // Create tables on first run db.exec(` CREATE TABLE IF NOT EXISTS items ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) `); // Fast synchronous queries const items = db.prepare('SELECT * FROM items').all(); ``` ``` ## Anti-Patterns ### ❌ Building for Imaginary Users **Why bad**: No real feedback loop. Building features no one needs. Giving up because no motivation. Solving the wrong problem. **Instead**: Build for yourself first. Real problem = real motivation. You're the first tester. Expand users later. ### ❌ Over-Engineering Personal Tools **Why bad**: Takes forever to build. Harder to modify later. Complexity kills motivation. Perfect is enemy of done. **Instead**: Minimum viable script. Add complexity when needed. Refactor only when it hurts. Ugly but working > pretty but incomplete. ### ❌ Not Dogfooding **Why bad**: Missing obvious UX issues. Not finding real bugs. Features that don't help. No passion for improvement. **Instead**: Use your tool daily. Feel the pain of bad UX. Fix what annoys YOU. Your needs = user needs. ## ⚠️ Sharp Edges | Issue | Severity | Solution | |-------|----------|----------| | Tool only works in your specific environment | medium | ## Making Tools Portable | | Configuration becomes unmanageable | medium | ## Taming Configuration | | Personal tool becomes unmaintained | low | ## Sustainable Personal Tools | | Personal tools with security vulnerabilities | high | ## Security in Personal Tools | ## Related Skills Works well with: `micro-saas-launcher`, `browser-extension-builder`, `workflow-automation`, `backend`