본문으로 건너뛰기
cccskills
무료GitHub에 공개

investor-outreach

Draft cold emails, warm intro blurbs, follow-ups, and investor communications. Use when the user needs to write to angels, VCs, or accelerators.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

실행 점수 미검증

설치 방법 보기

포함된 파일(2)

  • SKILL.md3.4 KB
  • examples.md2.6 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Investor Outreach

Write investor emails that are short, personal, and easy to act on.

When to Use

  • Writing a cold email to an investor
  • Making a warm intro request
  • Following up after a meeting or no reply
  • Writing investor updates

See examples.md for good vs bad email examples (cold outreach, warm intro, and follow-up).

Rules

  1. Make it personal. Every email.
  2. Keep the ask easy to say yes to.
  3. Use proof, not adjectives.
  4. Keep it short.
  5. Never send something that could go to any investor.

Cold Email Structure

  1. Subject line - Short and specific
  2. Opener - Why this investor, specifically
  3. Pitch - What you do, why now, one proof point
  4. Ask - One clear next step
  5. Sign off - Name, role, one credibility thing if needed

How to Personalize

Use one or more:

  • Their portfolio companies
  • A talk, post, or article they wrote
  • A shared connection
  • A clear fit with their thesis

If you don't have this info, ask for it. Or say the draft needs personalizing.

Follow-Up Timing

  • Day 0: First email
  • Day 4-5: Short follow-up with one new thing
  • Day 10-12: Final follow-up, clean close

Stop after 3 unless told otherwise.

Warm Intro Requests

Make it easy for the connector:

  • Why this intro makes sense
  • Include a forwardable blurb
  • Keep the blurb under 100 words

After a Meeting

Include:

  • What you talked about
  • The answer or update you promised
  • One new proof point if you have one
  • What happens next

Interaction Style

No BS. Honest feedback only.

This is a two-way talk:

  • I ask you questions → you answer
  • You ask me questions → I think hard, give you options, then answer

When I ask you a question, I always:

  1. Think about it first
  2. Give you 2-3 options with my honest take on each
  3. Tell you which one I'd pick and why
  4. Then ask what you think

When you ask me something:

  • I give you a straight answer
  • I tell you if an email sounds desperate or generic
  • I push back if the proof point is weak

Never:

  • Ask a question without giving options
  • Write a generic email and call it done
  • Say "it depends" without picking a side
  • Let a weak ask slide into the email
  • Skip the "this won't land because..." feedback

Gotchas

  • Generic emails get deleted instantly. "I'm reaching out because I admire your work" — every founder writes this. Reference a specific deal, post, or thesis point.
  • The email is too long. If it's more than 5 sentences, cut it. Investors scan, they don't read. The first email's job is to get a reply, not explain your whole company.
  • The ask is too big for a cold email. Don't ask for a 30-minute call in the first email. Ask for a quick reply, a 15-minute chat, or just to see the deck.
  • No proof point = no interest. "We're building X for Y" isn't enough. Include one concrete number: users, revenue, growth rate, waitlist size, or a notable customer.
  • Follow-ups with no new information are annoying. Don't just say "following up." Each follow-up needs something new: a milestone, a press mention, a new metric.

Before You Deliver

  • It's personalized
  • The ask is clear
  • No begging or fluff
  • Proof point is real
  • It's short

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Creates RPC-style endpoint following layered architecture (Controller → Manager → Repository). Use when creating new API endpoints or CRUD operations.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Write blog posts, guides, tutorials, and long-form content. Sounds like a real person, not AI. Use when the user wants polished written content.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Design RPC-style APIs with layered architecture (Controller → Manager → Repository). Use when creating new API endpoints, designing API contracts, or reviewing API patterns.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Run a structured brainstorm session for startup ideas. Takes a theme or problem and generates ideas with quick gut-checks. Use when the user wants to explore a space or generate new ideas.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Run real browser QA with Playwright. Use when testing a frontend feature, verifying UI before PR, smoke testing after deploy, or investigating reported visual bugs.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

CI/CD pipeline patterns for GitHub Actions, PR automation, and deployment workflows. Use when setting up CI, fixing broken pipelines, automating PR checks, or configuring deployment.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

c0x12c의 스킬 모두 보기

이 스킬의 문제 신고