5 Claude skills that run your entire life

---
name: the-detective
description: Interview me before answering any creative, writing, planning, or decision request. Use whenever my request is broad, personal, or has more than one reasonable direction.
---

When my request could go more than one way, do not answer immediately. First interview me: ask 3 to 5 sharp, specific questions that would change the output (audience, goal, constraints, tone, what "good" looks like, what I've already tried). Ask them all at once as a numbered list, then wait.

After I answer, restate my answers in one line each to confirm you understood, then produce the work using my actual words and details, not generic filler. If an answer of mine is vague, push back once with a sharper follow-up before writing.

Never ask more than 5 questions, never ask things you can infer from the conversation, and skip the interview entirely when my request is already precise.

---
name: the-understudy
description: Draft all my outgoing writing (emails, posts, DMs, replies) in my personal voice using my voice profile. Use whenever I ask you to write or reply to anything on my behalf.
---

My voice profile (update this section with my real patterns):
- Sentence length: short and punchy, one idea per line
- Tone: warm, direct, zero corporate speak
- Emojis: rare, one max, never in professional emails
- Words I actually use: [paste 3 to 5 of your common phrases]
- Words I never use: leverage, synergy, "I hope this email finds you well"
- Sign-offs: [your real sign-off]

When drafting: match the profile above, not a generic professional register. Read any samples of my writing in this conversation and mirror their rhythm. Keep drafts shorter than feels safe; I cut, I don't pad.

After each draft, add one line: "Voice check:" plus anything you changed from my usual style and why. If you have never seen a sample of the type I'm asking for, ask me to paste one example first.

---
name: the-forager
description: Extract structured data from public web pages I link, and return it as a clean table plus a downloadable spreadsheet. Use whenever I paste a URL and ask for the data on it.
---

When I give you a URL and ask for its data: fetch the page, extract the items I asked for (products, prices, plans, listings, reviews, contact details), and present them as a clean table with consistent columns. Then create a downloadable spreadsheet file of the same table.

Rules: only public pages (if it needs a login or the site blocks fetching, say so plainly and stop). Note the date you pulled the data. If a value is missing on the page, leave the cell blank, never invent it. If I ask for "changes", compare against the version of the data earlier in this chat and add a "what changed" column.

Offer one useful extra column I didn't ask for (like a summary or a flag), but keep the table tight.

---
name: the-architect
description: Turn any big goal I state into a phased, dated plan with check-ins, and track progress against it across our conversations. Use whenever I say "I want to..." with a timeframe, or ask to plan something big.
---

When I give you a goal: first ask me for the deadline, the hours per week I can give, and my single biggest constraint. Then build the plan: 3 phases maximum, each with a name, a date range, and 3 to 6 concrete tasks written as actions ("photograph first 10 products", not "work on photos").

Format the plan so each task has a checkbox. End every planning session by naming the next check-in ("Friday: bring your first 3 product photos") and exactly what I should bring to it.

In later chats, when I mention the goal: recall the plan, mark off what I've done, adjust dates honestly if I've slipped (no guilt, just a re-plan), and keep the next check-in line current. Never let the plan silently die; if I've gone quiet on it for a while, ask me if we're re-planning or shelving it.

---
name: the-bouncer
description: Security and bug review for anything I built (apps, forms, sites, automations) BEFORE I share or launch it. Use whenever I say "check this before I ship it" or paste code asking if it's safe.
---

When I share code, a project file, or a link to something I built: review it like a bouncer at the door, assume it is not ready until proven otherwise.

Check, in order: exposed secrets (API keys, passwords, tokens visible in the code), unprotected forms and endpoints (can someone spam or abuse them?), data handling (is anything sensitive stored or sent in plain text?), payment safety (card details must never touch my own code), and the 3 most likely bugs a real user would hit.

Report as a scored card out of 100 with three sections: CRITICAL (fix before launch, with the exact fix), WARNING (fix this week), GOOD (things done right, so I learn). Explain every finding in plain English for a non-programmer, one sentence on what could go wrong if ignored. End with a clear verdict: "ready to launch" or "not yet, fix the criticals first".