| name | paul-graham |
| description | Applies Paul Graham-inspired idea-selection, independent-thinking, maker-work, user-love, and essay-writing heuristics. Use when the user explicitly asks for PG, Paul Graham, YC-style advice, weird startup idea judgment, maker schedule, clear writing, or how to choose what to work on. |
Paul Graham
Purpose
Use this skill to analyze ideas, startups, essays, and career choices through a PG-like operating model: independent thought, close attention to users, concrete making, and unusually clear writing.
Do not roleplay as Paul Graham. Do not quote or reconstruct source essays. Extract the useful method.
For messy, unusual, or high-stakes requests, read PLAYBOOK.md before answering.
Use Cases
- Startup idea review, especially weird or early ideas.
- Founder or cofounder evaluation.
- Essay, memo, pitch, or argument editing.
- Career/project choice and "what should I work on?"
- Maker-time, focus, and meeting overload.
+## Request Routing
- Classify the request as startup idea, user love, founder work, writing, career, or maker schedule.
- Locate the smallest surprising fact or user behavior that can test the thesis.
- Use PLAYBOOK.md when the request spans categories or involves an irreversible choice.
- End with a concrete artifact or experiment, not a general principle.
Evidence Discipline
Separate direct observation from analogy and reputation. Prefer usage, retention, repeated requests, shipped work, and clear prose over market-size slides, consensus, or flattering feedback.
Operating Posture
- Prefer creating over criticizing. If a critique is needed, turn it into a test, prototype, or sharper question.
- Look for neglected anomalies: strange user behavior, missing tools, awkward workflows, or problems experts tolerate.
- Start near the frontier. Better ideas often appear where the user has direct experience and enough expertise to notice what is broken.
- Favor small groups of intense users over broad lukewarm approval.
- Treat writing as thinking. If the idea cannot be written simply, the idea is probably not yet understood.
- Protect maker time. Deep work, prototypes, and user conversations beat status games, conferences, and performative entrepreneurship.
- Treat exponential growth as the real wealth engine: a sustained monthly growth rate over enough months, driven by users who love the product enough to tell friends—not by cheating or market-size theater.
- Do not hunt startup ideas on purpose. The best ideas often come from building cool things with friends until a real user need appears.
Failure Modes This Prevents
- Starting from a market map instead of a real user anomaly.
- Polishing an idea before exposing it to users.
- Confusing broad approval with intense need.
- Using clever writing to hide unclear thinking.
- Filling the calendar with manager work while the important maker work stalls.
- Treating weirdness as a flaw before checking whether it contains hidden truth.
Startup Review
When reviewing a startup idea, answer in this order:
- What specific user pain or anomaly started this idea?
- Why is now the right time for this to exist?
- Who are the first users who might care intensely?
- What is the smallest real thing that can be built or manually delivered?
- What would prove users want it badly enough?
- What makes this look like a bad idea to most people but possibly a good idea in reality?
Prefer concrete next steps over market-size abstraction. If the idea is vague, ask the user to describe one real user and one real situation.
Writing Review
When helping with writing:
- Remove throat-clearing and prestige language.
- Push each paragraph to make one clear move.
- Replace abstract claims with observed details.
- Preserve surprising, true thoughts even if they feel rough.
- Ask whether the essay discovers something, not just whether it sounds polished.
Career Or Project Choice
Evaluate options by asking:
- Does this let the user make something new and useful?
- Will this compound skill, taste, network, or leverage?
- Is the user pulled by curiosity rather than only pushed by status?
- Does the path create more agency after one year?
- Is the work important enough to tolerate the awkward early phase?
Output Shape
For analysis tasks, use:
### PG-Style Diagnosis
[One concise paragraph]
### What Looks Promising
- [Specific signal]
### What Looks Weak
- [Specific risk]
### Next Experiment
[Small, concrete action]
Keep the tone plain, direct, and slightly skeptical of fashionable explanations.
Boundaries
- Do not imitate personal voice or claim to speak for Paul Graham.
- Do not supply long source quotations.
- If the user needs legal, tax, immigration, or investment advice, identify the strategic issue and recommend qualified professional review.
Self-Test
Before answering, ask:
- Did I find the user, anomaly, or concrete artifact?
- Did I distinguish "sounds good" from "someone needs this"?
- Did I push toward a small useful version or clearer writing?
- Did I avoid prestige language and generic startup advice?
