> investor-outreach
Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
curl "https://skillshub.wtf/affaan-m/everything-claude-code/investor-outreach?format=md"Investor Outreach
Write investor communication that is short, personalized, and easy to act on.
When to Activate
- writing a cold email to an investor
- drafting a warm intro request
- sending follow-ups after a meeting or no response
- writing investor updates during a process
- tailoring outreach based on fund thesis or partner fit
Core Rules
- Personalize every outbound message.
- Keep the ask low-friction.
- Use proof, not adjectives.
- Stay concise.
- Never send generic copy that could go to any investor.
Cold Email Structure
- subject line: short and specific
- opener: why this investor specifically
- pitch: what the company does, why now, what proof matters
- ask: one concrete next step
- sign-off: name, role, one credibility anchor if needed
Personalization Sources
Reference one or more of:
- relevant portfolio companies
- a public thesis, talk, post, or article
- a mutual connection
- a clear market or product fit with the investor's focus
If that context is missing, ask for it or state that the draft is a template awaiting personalization.
Follow-Up Cadence
Default:
- day 0: initial outbound
- day 4-5: short follow-up with one new data point
- day 10-12: final follow-up with a clean close
Do not keep nudging after that unless the user wants a longer sequence.
Warm Intro Requests
Make life easy for the connector:
- explain why the intro is a fit
- include a forwardable blurb
- keep the forwardable blurb under 100 words
Post-Meeting Updates
Include:
- the specific thing discussed
- the answer or update promised
- one new proof point if available
- the next step
Quality Gate
Before delivering:
- message is personalized
- the ask is explicit
- there is no fluff or begging language
- the proof point is concrete
- word count stays tight
> related_skills --same-repo
> skill-comply
Visualize whether skills, rules, and agent definitions are actually followed — auto-generates scenarios at 3 prompt strictness levels, runs agents, classifies behavioral sequences, and reports compliance rates with full tool call timelines
> santa-method
Multi-agent adversarial verification with convergence loop. Two independent review agents must both pass before output ships.
> safety-guard
# Safety Guard — Prevent Destructive Operations ## When to Use - When working on production systems - When agents are running autonomously (full-auto mode) - When you want to restrict edits to a specific directory - During sensitive operations (migrations, deploys, data changes) ## How It Works Three modes of protection: ### Mode 1: Careful Mode Intercepts destructive commands before execution and warns: ``` Watched patterns: - rm -rf (especially /, ~, or project root) - git push --force
> product-lens
# Product Lens — Think Before You Build ## When to Use - Before starting any feature — validate the "why" - Weekly product review — are we building the right thing? - When stuck choosing between features - Before a launch — sanity check the user journey - When converting a vague idea into a spec ## How It Works ### Mode 1: Product Diagnostic Like YC office hours but automated. Asks the hard questions: ``` 1. Who is this for? (specific person, not "developers") 2. What's the pain? (quantify