mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-19 08:33:31 +08:00
Ports functionality from 10+ separate plugins into ECC so users only need one plugin installed. Consolidates: pr-review-toolkit, feature-dev, commit-commands, hookify, code-simplifier, security-guidance, frontend-design, explanatory-output-style, and personal skills. New agents (8): code-architect, code-explorer, code-simplifier, comment-analyzer, conversation-analyzer, pr-test-analyzer, silent-failure-hunter, type-design-analyzer New commands (9): commit, commit-push-pr, clean-gone, review-pr, feature-dev, hookify, hookify-list, hookify-configure, hookify-help New skills (8): frontend-design, hookify-rules, github-ops, knowledge-ops, lead-intelligence, oura-health, pmx-guidelines, remotion Enhanced skills (8): article-writing, content-engine, market-research, investor-materials, investor-outreach, x-api, security-scan, autonomous-loops — merged with personal skill content New hook: security-reminder.py (pattern-based OWASP vulnerability warnings on file edits) Totals: 36 agents, 69 commands, 128 skills, 29 hook scripts
145 lines
5.1 KiB
Markdown
145 lines
5.1 KiB
Markdown
---
|
|
name: investor-materials
|
|
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
|
origin: ECC
|
|
---
|
|
|
|
# Investor Materials
|
|
|
|
Build investor-facing materials that are consistent, credible, and easy to defend.
|
|
|
|
## When to Activate
|
|
|
|
- creating or revising a pitch deck
|
|
- writing an investor memo or one-pager
|
|
- building a financial model, milestone plan, or use-of-funds table
|
|
- answering accelerator or incubator application questions
|
|
- aligning multiple fundraising docs around one source of truth
|
|
|
|
## Golden Rule
|
|
|
|
All investor materials must agree with each other.
|
|
|
|
Create or confirm a single source of truth before writing:
|
|
- traction metrics
|
|
- pricing and revenue assumptions
|
|
- raise size and instrument
|
|
- use of funds
|
|
- team bios and titles
|
|
- milestones and timelines
|
|
|
|
If conflicting numbers appear, stop and resolve them before drafting.
|
|
|
|
## Core Workflow
|
|
|
|
1. inventory the canonical facts
|
|
2. identify missing assumptions
|
|
3. choose the asset type
|
|
4. draft the asset with explicit logic
|
|
5. cross-check every number against the source of truth
|
|
|
|
## Asset Guidance
|
|
|
|
### Pitch Deck
|
|
Recommended flow:
|
|
1. company + wedge
|
|
2. problem
|
|
3. solution
|
|
4. product / demo
|
|
5. market
|
|
6. business model
|
|
7. traction
|
|
8. team
|
|
9. competition / differentiation
|
|
10. ask
|
|
11. use of funds / milestones
|
|
12. appendix
|
|
|
|
If the user wants a web-native deck, pair this skill with `frontend-slides`.
|
|
|
|
### One-Pager / Memo
|
|
- state what the company does in one clean sentence
|
|
- show why now
|
|
- include traction and proof points early
|
|
- make the ask precise
|
|
- keep claims easy to verify
|
|
|
|
### Financial Model
|
|
Include:
|
|
- explicit assumptions
|
|
- bear / base / bull cases when useful
|
|
- clean layer-by-layer revenue logic
|
|
- milestone-linked spending
|
|
- sensitivity analysis where the decision hinges on assumptions
|
|
|
|
### Accelerator Applications
|
|
- answer the exact question asked
|
|
- prioritize traction, insight, and team advantage
|
|
- avoid puffery
|
|
- keep internal metrics consistent with the deck and model
|
|
|
|
## Red Flags to Avoid
|
|
|
|
- unverifiable claims
|
|
- fuzzy market sizing without assumptions
|
|
- inconsistent team roles or titles
|
|
- revenue math that does not sum cleanly
|
|
- inflated certainty where assumptions are fragile
|
|
|
|
## Pitch Deck Structure (10-12 slides)
|
|
|
|
Recommended flow with guidance per slide:
|
|
1. **Title:** Company name + one-line positioning
|
|
2. **Problem:** Quantify the pain. Use specific market numbers.
|
|
3. **Solution:** Show the product, not a description of it. Screenshots, demo frames, or architecture diagrams.
|
|
4. **Product demo:** Phase 1 (live) vs Phase 2 (funded). Always present as phased if not fully built.
|
|
5. **Market:** TAM with source. Growth rate with source. Key catalyst for "why now."
|
|
6. **Business model:** Revenue layers with year-by-year projections. Show the math.
|
|
7. **Traction:** Working product, users, revenue, waitlist, partnerships. Concrete numbers only.
|
|
8. **Team:** Each founder gets a credibility anchor (prior company, metric, recognition).
|
|
9. **Competitive landscape:** Positioning map or table. Show the gap you fill.
|
|
10. **Ask:** Raise amount, instrument (SAFE/priced), valuation range.
|
|
11. **Milestones / Use of funds:** Timeline from now to Series A. Use of funds must sum exactly.
|
|
12. **Appendix:** Revenue model detail, regulatory strategy, technical architecture.
|
|
|
|
## Financial Model Requirements
|
|
|
|
When building or updating financial models:
|
|
- All assumptions must be stated explicitly and separately from projections
|
|
- Include bear/base/bull scenarios (sensitivity analysis)
|
|
- Revenue layers must sum correctly across all timeframes
|
|
- Use of funds must sum to the exact raise amount
|
|
- Include unit economics where possible (cost per user, revenue per customer)
|
|
- Discount rates and growth rates must be sourced or justified
|
|
- Milestone-linked spending: tie spend to specific milestones
|
|
|
|
## Accelerator Applications
|
|
|
|
When writing accelerator applications:
|
|
- Follow the specific word/character limits of each program
|
|
- Lead with traction (metrics, users, revenue, recognition)
|
|
- Be specific about what the accelerator adds (network, funding, customers)
|
|
- Never sound desperate. Frame as mutual fit.
|
|
- Keep internal metrics consistent with the deck and model
|
|
|
|
## Honesty Requirements
|
|
|
|
These are non-negotiable:
|
|
- Clearly distinguish between what is live/working and what requires funding
|
|
- Never attach revenue figures to things that are not revenue-generating
|
|
- Never claim awards or recognition not actually received
|
|
- "Algorithmic" when the tech is algorithmic, "AI" only when there is actual ML/AI
|
|
- All traction claims must be verifiable
|
|
|
|
## Quality Gate
|
|
|
|
Before delivering:
|
|
- every number matches the current source of truth
|
|
- use of funds and revenue layers sum correctly
|
|
- assumptions are visible, not buried
|
|
- the story is clear without hype language
|
|
- the final asset is defensible in a partner meeting
|
|
- phase distinctions (live vs funded) are clear
|
|
- no unverifiable claims
|
|
- team roles and titles are correct
|