Accelerator Application

When to Use

• Founder wants to apply to Y Combinator, Techstars, or other accelerator programs
• Founder wants to identify which accelerators are the best fit for their stage and sector
• Founder wants help drafting application essays and preparing for interviews
• Founder wants to batch-apply to multiple programs efficiently

Context Required

• Company stage, product, and traction metrics
• Founder backgrounds and why this team is uniquely positioned
• What the founder wants from an accelerator (funding, network, credibility, customers, mentorship)
• Industry/vertical (some accelerators are sector-specific)
• Geography and willingness to relocate
• Previous applications or rejections (to improve this round)

Workflow

1. Match accelerators to the startup — filter the directory below by stage fit, sector focus, geography, and program terms. Recommend a shortlist of 5-10 programs ranked by fit.
2. Research each program's preferences — review recent cohort companies, partner bios, and published advice from each accelerator on what they look for. Note any patterns (YC values technical founders and fast growth; Techstars values coachability and market size).
3. Draft the core narrative — write the foundational answers that most applications share:
   • What does your company do? (one sentence, no jargon)
   • What problem are you solving and for whom?
   • Why now? What's changed that makes this possible?
   • Why is this team the right team?
   • What traction do you have?
   • What's your unfair advantage or unique insight?
4. Customize per application — adapt the core narrative to each program's specific questions, word limits, and culture. YC applications are famously terse. Techstars wants to see coachability. Others want market size.
5. Prepare the video (if required) — draft a script for the 1-2 minute application video. Structure: problem → solution → traction → team → ask. Keep it authentic, not polished.
6. Prepare for interviews — draft answers to common accelerator interview questions (see below). Practice the 30-second pitch.

Top US Accelerators Directory (40+)

Tier 1 — Generalist, Top-Tier

Tier 2 — Sector-Specific

Tier 3 — Non-Profit, University & Government

Note: Terms, investment amounts, and equity percentages change frequently. Verify current terms on each program's website before applying.

Output Format

## Accelerator Application Plan

### Recommended Programs (ranked by fit)
1. **[Program]** — [why it's a fit] | Deadline: [date] | Apply: [link]
2. ...

### Core Narrative
- **One-liner:** [what you do in one sentence]
- **Problem:** [2-3 sentences]
- **Solution:** [2-3 sentences]
- **Why now:** [1-2 sentences]
- **Traction:** [key metrics]
- **Team:** [why you're the right people]
- **Unique insight:** [what you know that others don't]

### [Program Name] Application Draft
**Q: [Question from application]**
A: [Draft answer within word limit]
...

### Interview Prep
**30-second pitch:** [draft]
**Common questions and answers:**
- "What do you understand that others don't?" — [answer]
- "How do you acquire users/customers?" — [answer]
- "What's the biggest risk?" — [answer]
- "Why hasn't this been done before?" — [answer]
- "What will you do if this doesn't work?" — [answer]

Frameworks & Best Practices

What top accelerators look for:

• YC: Founders who build fast. Technical co-founders. Clear thinking, not polish. "Make something people want." They read applications in under 2 minutes — be concise.
• Techstars: Coachability and self-awareness. Market size. The "why you" answer. They call references on founders.
• 500 Global: Diverse founders, international-friendly. Traction and hustle over pedigree.

Application writing principles:

• Lead with what you've built and what's working, not the market opportunity
• Use specific numbers ("1,200 users, 40% WoW growth") not vague claims ("rapidly growing")
• Show velocity — what you've accomplished in the last 4 weeks matters more than a 5-year vision
• Be honest about what's not working — self-awareness is a signal of founder quality
• Write at a 6th-grade reading level. No jargon, no buzzwords, no "leveraging AI to disrupt"

Common mistakes:

• Applying to every accelerator instead of targeting the best 5-7 fits
• Writing what you think they want to hear instead of what's true
• Burying the traction (put numbers in the first sentence)
• Over-explaining the market instead of showing what you've done
• Sending a polished video instead of an authentic one (YC explicitly says don't do this)
• Not researching which partners/mentors at the program are relevant to your space

Related Skills

• pitch-deck — accelerator interviews often involve a short pitch
• fundraising-email — for follow-up communication with program partners
• investor-research — accelerator partners are also investors

Examples

Prompt: "Help me apply to YC for the next batch. We're a developer tools startup with 500 users."

Good output includes: Tailored YC application draft with concise answers to each question, emphasis on technical depth and growth rate, a 60-second video script, and interview prep focused on YC's known question patterns.

Prompt: "What accelerators should I apply to for my healthtech startup? We're pre-revenue but have LOIs from 3 hospitals."

Good output includes: Filtered list prioritizing Dreamit (HealthTech focus), YC (strong health portfolio), and relevant sector programs. Application strategy emphasizing LOIs as traction signal.

Architecture Design

When to Use

• Starting a new product or major feature that needs system design
• Choosing between monolith, modular monolith, microservices, or event-driven patterns
• Selecting a database (SQL vs NoSQL vs specialized) for a new project
• Analyzing dependencies for circular references, coupling issues, or outdated packages
• Creating architecture diagrams (Mermaid, PlantUML, ASCII) for documentation or review
• Writing Architecture Decision Records (ADRs) for technical choices
• Evaluating scalability bottlenecks or planning capacity

Context Required

From startup-context: product description, tech stack, current state (prototype/beta/scaling), team size, expected scale (users, requests/sec, data volume). If missing, ask:

• What does this system need to do? (core use cases)
• What scale are you targeting? (users, requests/sec, data size)
• What is your team size and backend experience level?
• Are there hard constraints? (compliance, latency, budget, existing infra)

Workflow

1. Gather requirements — Identify functional requirements (use cases), non-functional requirements (latency, throughput, availability, consistency), and constraints (budget, team size, compliance).
2. Run architecture assessment — Analyze the existing project structure to detect current patterns (MVC, layered, hexagonal, microservices indicators), code organization issues (god classes, mixed concerns), and layer violations.
3. Analyze dependencies — Examine the dependency tree for circular dependencies, coupling scores, and outdated packages across npm, Python, Go, or Rust projects.
4. Select architecture pattern — Use the decision workflows below to match team size, deployment needs, and data boundaries to the right pattern. For most early-stage startups, recommend modular monolith.
5. Select database — Match data characteristics, scale requirements, and consistency needs to the appropriate database technology using the selection workflow below.
6. Design data model — Produce an ER diagram in Mermaid. Define entity ownership: which module/service writes, others read via API.
7. Define API contracts — Specify key endpoints with method, path, request/response shapes, and error codes. Version from day one.
8. Generate architecture diagram — Produce a Mermaid C4 or flowchart diagram showing components, data stores, external services, and communication patterns.
9. Write ADRs — Document key decisions using the ADR format below.
10. Identify risks — Call out single points of failure, data consistency risks, and scaling bottlenecks with mitigations.

Output Format

Deliver a structured architecture document with these sections:

• Requirements Summary — Functional, non-functional, and constraints
• Architecture Assessment — Detected pattern with confidence, issues, recommendations
• System Diagram — Mermaid C4 or flowchart (component, layer, or deployment view)
• Domain Model — Mermaid ER diagram with entity ownership
• Module Boundaries — Table: Module, Responsibility, Owns Data, Exposes API
• API Contracts — Key endpoints with method, path, request/response shapes
• ADRs — Architecture Decision Records for key choices
• Dependency Analysis — Total deps, coupling score, circular deps, outdated packages
• Risks & Mitigations — Table: Risk, Impact, Likelihood, Mitigation

Frameworks & Best Practices

Architecture Pattern Selection

Default for early startups: Modular monolith with clear module boundaries that can be extracted later. Microservices add operational overhead that kills small teams.

Monolith vs Microservices Checklist

Choose Monolith when: team is small (<10), domain boundaries are unclear, rapid iteration is the priority, shared database is acceptable.

Choose Microservices when: teams can own services end-to-end, independent deployment is critical, different scaling requirements per component, domain boundaries are well understood.

Hybrid approach: Start monolith. Extract a service only when a module has significantly different scaling needs, a team needs independent deployment, or technology constraints require separation.

Database Selection

Structured data with relationships or ACID needs points to SQL. Flexible/evolving schema or document-oriented data points to NoSQL. Quick reference: PostgreSQL (default for most apps), MongoDB (document store), Redis (caching/sessions), DynamoDB (serverless auto-scaling), TimescaleDB (time-series), CockroachDB/Spanner (global distribution).

ADR Format

Use five fields: Status (Proposed/Accepted/Deprecated/Superseded), Context (what prompted the decision), Decision (what was chosen and why), Consequences (trade-offs and remaining risks), Alternatives considered (what else was evaluated and why it lost).

Key Design Principles

• Every entity has a clear owner (one module writes, others read via API)
• Use UUIDs for primary keys if multi-service or future extraction is likely
• Version APIs from day one (/v1/resource); paginate all list endpoints (cursor-based preferred)
• Consistent error shapes: { "error": { "code": "...", "message": "..." } }
• Design write operations for idempotency (idempotency keys)
• Synchronous calls (HTTP/gRPC) for queries needing immediate confirmation; async events for notifications, analytics, and cross-service data sync
• Avoid distributed transactions — use sagas or eventual consistency

Related Skills

• tech-stack-eval — Chain when choosing specific technologies for the architecture
• security-review — Chain to review the architecture for threat vectors before implementation
• code-review — Chain after implementation to verify code matches architectural intent

Examples

Prompt: "I'm building a SaaS project management tool. 3 engineers. How should I architect it?"

Good output snippet:

Given your team of 3 and early stage, I recommend a modular monolith.
Domain modules:

1. Auth Module — user accounts, roles, sessions
2. Projects Module — workspaces, projects, permissions
3. Tasks Module — tasks, assignments, comments, activity log
4. Notifications Module — email digests, in-app notifications

Each module gets its own DB schema (auth.*, projects.*) and communicates
through internal function calls with typed interfaces — not HTTP. This
gives you service-like boundaries without deployment complexity.

Architecture Assessment:
  Detected pattern: Layered Architecture (confidence: 85%)
  ✓ controllers/  - Presentation layer
  ✓ services/     - Business logic layer
  ✓ repositories/ - Data access layer

Prompt: "Should we use WebSockets or SSE for real-time collaboration?"

Good output snippet:

## ADR-001: Use WebSockets for Real-Time Collaboration
- Status: Proposed
- Context: Document editor needs sub-200ms latency for cursor positions
  and concurrent edits across 2-50 users per document.
- Decision: WebSockets via Socket.io with Redis pub/sub for horizontal
  scaling. SSE only supports server-to-client; we need bidirectional
  communication for operational transforms.
- Consequences: Adds WebSocket infrastructure (sticky sessions or Redis
  adapter), ~2KB memory per connection. Team needs OT/CRDT knowledge.
- Alternatives: SSE + POST (simpler but higher edit latency),
  Firebase Realtime DB (vendor lock-in, cost at scale).

Board Update

When to Use

Activate when a founder needs to draft an investor update email, prepare a board meeting deck, or write a quarterly business review. This includes prompts like "write my monthly investor update," "prepare for our board meeting," "draft a quarterly recap," or "how do I communicate bad news to the board." Also activate for fundraising decks where market and vision framing is needed.

Context Required

• From startup-context: company stage, fundraising history, board composition, key metrics (MRR, burn, runway, headcount), current strategic priorities, and previous update cadence.
• From the user: reporting period, key wins and losses, metric changes, specific topics requiring board input or approval, any sensitive issues to address, and whether this is an email update or a slide deck.

Workflow

1. Determine format and cadence — Monthly email update (standard for seed/Series A, under 800 words), quarterly board deck (Series A onward, 20-30 slides, sent as pre-read 48 hours ahead), monthly condensed deck (8-12 slides), or ad-hoc update (one page, one topic, sent immediately for material events). Default to monthly email for early-stage.
2. Collect the 11 sections — Walk through each section of the framework below. Each section has a designated C-suite owner. For each, apply the "Headline - Data - Narrative - Ask/Next" structure.
3. Lead with the headline — Write a 1-3 sentence executive summary that captures the single most important takeaway. Boards see 10+ decks per quarter. Surface key messages by slide three. Some investors read only the summary.
4. Apply the bad-news protocol — If any section contains negative developments, use the transparent delivery framework. Never bury bad news. Boards find out eventually. Finding out late makes it worse.
5. Add specific asks — Every update ends with concrete, actionable requests. Name the person if possible. Investors who cannot help you cannot add value.
6. Format for scanability — Investors spend 3-5 minutes on updates. Bold key numbers, use tables for metrics, keep paragraphs to 2-3 sentences. Cap metrics dashboards at 6-8 KPIs with targets and status.

Output Format

For email updates, output as markdown ready to paste into email. For board decks, output as structured markdown with one H3 per slide.

The 11-Section Framework

Every section follows: Headline - Data - Narrative - Ask/Next.

Frameworks & Best Practices

The Four-Act Narrative Structure

Apply this to every section, especially when explaining variances:

1. Prior targets — what we said we would do
2. Current reality — what actually happened
3. Gap explanation — why (owned cause, not excuses)
4. Remediation — specific fixes with timeline

This structure works for both positive and negative scenarios.

Transparent Bad-News Delivery

1. State the fact plainly. "We missed our Q3 revenue target by 22%." No euphemisms.
2. Own the cause. "Two enterprise deals worth $180K ARR slipped to Q4 due to procurement delays we did not anticipate." Do not lead with context or excuses.
3. Demonstrate understanding. Show the analysis that explains the root cause.
4. Present specific fixes. "We implemented procurement-tracking in our sales process and added 30 days of buffer to enterprise deal timelines."
5. Update the forecast. "Revised Q4 target is $X." Include confidence levels, not single-point estimates: "High confidence $2.6M, upside to $2.9M if two late-stage deals close."
6. Ask for help if needed. "A warm intro to their CFO would accelerate procurement."

Investors forgive bad quarters. They do not forgive founders who hide problems until they become crises.

Metrics Presentation Rules

• Always show trends. Current vs. prior period vs. plan. A single number is meaningless.
• Use consistent timeframes. Do not mix monthly and annualized numbers in the same table.
• Highlight variance. Bold any metric that deviates more than 10% from plan in either direction.
• Include unit economics. CAC, LTV, and payback period tell the story top-line revenue cannot.
• Show runway in months, not dollars. "14 months at current burn" is more actionable than "$2.1M in the bank."
• Revenue forecasts need confidence levels. Never present a single-point estimate.
• Provide one-sentence explanations for every variance from targets.

Cadence Guidelines

Common Mistakes

1. Excessive length — keep quarterly decks under 25-30 slides
2. Metrics without targets — every number needs a comparison point
3. No narrative — data without story is noise
4. Buried bad news — surface it in the first three slides
5. Vague asks — "any intros would be great" vs. "intro to VP Ops at Stripe"
6. Unexplained variances — every miss needs a one-sentence explanation
7. Stale appendix — update supporting data every cycle
8. Deck designed for reading, not presenting — slides should support conversation, not replace it
9. Sending updates only when things go well — creates suspicion during quiet periods
10. All narrative, no data — makes it impossible to track progress over time

Related Skills

• process-docs — chain to create an SOP for the internal board-update preparation process, ensuring consistent quality each cycle.
• pitch-deck — chain when the board update reveals a need to begin fundraising or when the update doubles as a re-up deck for existing investors.

Examples

Example 1: Monthly investor email

User: "Write my February investor update. MRR hit $85K (up from $72K), we hired a VP Engineering, but we lost our largest customer."

Good output excerpt:

TL;DR: February MRR grew 18% to $85K driven by strong mid-market expansion, but we lost Acme Corp ($12K/mo) due to budget restructuring outside our control. We hired Sarah Chen as VP Engineering (ex-Stripe). Net: ahead on product velocity, slightly behind on net revenue retention. 14 months runway remaining.

Key Metrics

Metric	Feb	Jan	vs. Plan
MRR	$85K	$72K	+3%
Net New ARR	$156K	$120K	+8%
Gross Churn	$12K	$2K	-$10K
Burn	$110K	$105K	On plan
Runway	14 mo	15 mo	On plan

On the churn: Acme Corp's new CFO cut all software contracts under $50K ARR during a company-wide cost reduction. We had 30 days notice and attempted a reduced plan; they declined. This was not a product failure, but it exposes revenue concentration risk — Acme was 14% of MRR. We are diversifying our top-10 account exposure.

Asks

1. Intros to mid-market fintech companies — specifically VP Operations or Head of Compliance contacts.
2. Referrals for a Senior Backend Engineer. JD attached.

Example 2: Communicating a major miss

User: "We're going to miss our quarterly target by a lot. Help me write this update."

Good output approach: Open with the miss stated plainly in the executive summary. Quantify the gap. Explain root cause in 2-3 sentences using owned language, not excuses. Follow immediately with the remediation plan including timeline and revised forecast with confidence levels. Close with specific asks for help. Never let bad news be the last thing the reader sees — always end with forward momentum and concrete next steps.

Churn Analysis

When to Use

Activate when a founder needs to identify at-risk accounts before they churn, diagnose churn drivers, build a customer health scoring system, design cancellation or save flows, recover failed payments, or re-engage lost customers. This includes prompts like "our churn is too high," "which customers are about to leave," "why are customers canceling," "build a customer health score," "set up dunning emails," or "create a win-back campaign." Especially relevant for seed/Series A teams managing customers manually without dedicated CS platforms like Gainsight or ChurnZero.

Context Required

• From startup-context: business model (B2B/B2C, subscription/usage-based), current churn rate (logo and revenue), customer segments, pricing tiers, contract terms, product usage data availability, and current retention tooling.
• From the user: available data sources (support tickets, Slack channels, NPS scores, usage logs, email logs, billing data), what "healthy" customer behavior looks like, any historical churn patterns, whether churn is primarily voluntary or involuntary, and the specific churn problem to solve.

Work with whatever data is available. Early-stage companies often lack formal CS systems — the skill works with support inboxes, Slack history, and spreadsheets.

Workflow

1. Intake and baseline — Gather all available customer data: customer lists, support tickets, Slack/communication history, NPS scores, usage data, email logs, and billing records. Establish what "healthy" looks like and identify any known churn patterns.
2. Extract signals — Analyze four signal categories across every account: support signals, communication signals, usage signals, and commercial signals (see framework below).
3. Score risk — Build a composite risk score (0-100) for each account using weighted signal categories. Higher score means higher risk.
4. Generate save plays — For high-risk accounts, produce specific interventions: root cause hypothesis, recommended actions, talk tracks for the CS conversation, and escalation triggers.
5. Build the weekly scorecard — Compile into a weekly risk report with account-by-account analysis, MRR at risk, trend data, signal distribution, and recommended focus areas.
6. Design interventions — For each churn driver identified, design the appropriate intervention: product fix, CS outreach, cancel flow save offer, dunning sequence, or win-back campaign.

Output Format

A churn risk report tailored to the specific request. This may include:

1. Weekly risk scorecard — Every account scored and tiered with signal breakdown
2. MRR at risk summary — Total revenue exposure by risk tier
3. Save play briefs — For each red/orange account: root cause, recommended action, talk track, escalation trigger
4. Intervention designs — Cancel flows, dunning sequences, or win-back campaigns as needed
5. Trend analysis — Signal distribution changes over time

Frameworks & Best Practices

Signal Extraction Categories

Analyze every account across these four signal types:

Support signals: Ticket volume spikes, unresolved tickets, escalation language ("frustrated," "unacceptable," "cancel"), response time degradation, repeat issues on the same topic.

Communication signals: Silent accounts (no contact in 30+ days), frequency decline, sentiment shifts in Slack/email, champion disengagement (the main contact goes quiet), new stakeholder asking basic questions (signals champion departure).

Usage signals: Login frequency drops, feature abandonment (stopped using features they previously used regularly), shallow usage (logging in but not completing core workflows), no growth in usage over time, export/data download spikes (preparing to migrate).

Commercial signals: Discount requests, downgrade inquiries, payment failures, renewal proximity with no expansion discussion, competitor mentions in any channel.

Risk Scoring Model

Build a composite score (0-100) by weighting individual signals:

Multiple signals compound. An account with two high signals (30 points) and three medium signals (24 points) scores 54 — solidly in the Orange tier.

Risk Tiers and Response Timelines

The Churn Driver Taxonomy

Categorize every churn event into one of these buckets:

1. Value gap — Product does not solve the problem well enough
2. Onboarding failure — Customer never reached the aha moment (churn in first 30-60 days)
3. Support failure — Bad experience getting help
4. Price sensitivity — Too expensive relative to perceived value
5. Champion departure — Internal champion left the customer's company
6. Business change — Customer's needs changed (acquisition, pivot, shutdown)
7. Involuntary churn — Payment failure, not a conscious decision to leave

Cancel Flow Design

1. Ask why (required). Present 5-7 reason options matching the taxonomy. Include free-text. This data is essential.
2. Offer a targeted save based on stated reason: "too expensive" gets a discount/downgrade, "missing feature" gets the roadmap, "not using it" gets a billing pause.
3. Confirm with friction. One extra click showing what they lose. Show value, not guilt.
4. Offer a pause. 30-60 day billing pause saves 15-25% of would-be churners in B2C and 10-15% in B2B.
5. Offboard gracefully. Confirmation email with data export and a "we'd love to have you back" message.

A well-designed cancel flow saves 10-20% of users who initiate cancellation.

Dunning and Payment Recovery

Involuntary churn accounts for 20-40% of total churn and is the easiest to reduce. Retry failed charges 4-6 times over 10-14 days. Send card update links (pre-authenticated). Warn before cards expire (30 and 7 days prior). A good dunning system recovers 30-50% of failed payments.

Win-Back Campaigns

Target customers who churned 30-90 days ago. Beyond 90 days, response rates drop sharply. Segment by churn reason — users who left for fixable reasons (price, missing feature now shipped) reactivate at 2-3x the average. Expect 5-15% overall reactivation from a well-executed sequence.

Related Skills

• feedback-synthesis — Analyze qualitative feedback from churned customers alongside quantitative churn data
• onboarding-flow — When churn analysis reveals early-tenure churn as the primary driver, indicating an activation problem
• email-marketing — Build full lifecycle email sequences (dunning, win-back, health-triggered re-engagement)

Examples

Example 1: Weekly risk scorecard

User: "I manage 45 accounts manually. Help me figure out which ones are about to churn."

Good output excerpt:

Weekly Risk Scorecard — March 15, 2026

MRR at Risk: $18,400 (12% of total MRR)

Account	MRR	Risk Score	Tier	Key Signals
Acme Corp	$2,400	82	Red	Champion left 3 weeks ago, usage down 60%, no response to last 2 emails
Beta Inc	$1,200	55	Orange	4 support tickets in 2 weeks (up from 1/month), asked about downgrade
Gamma LLC	$800	28	Yellow	Login frequency declining, approaching renewal with no expansion signals

Save Play — Acme Corp: Root cause: Champion departure. New contact has not been onboarded. Action: Executive-level outreach to identify new stakeholder. Offer a dedicated re-onboarding session. Prepare a 20% renewal discount if needed. Escalation trigger: No response within 5 business days — CEO-to-CEO email.

Example 2: Churn diagnostic

User: "Our monthly churn jumped from 4% to 7% over the last quarter. Help me figure out why."

Good output approach: Segment the increase by cohort, plan tier, and acquisition channel. Cross-reference with exit survey data to identify which churn drivers are increasing. Produce a root cause hypothesis linking the spike to specific changes (pricing, acquisition quality, product issues) and recommend targeted interventions for each driver.

CI/CD Setup

When to Use

• Setting up CI for a new project from scratch
• Replacing unreliable copied pipeline configurations that do not match the actual stack
• Transitioning between GitHub Actions and GitLab CI platforms
• Reviewing whether pipeline stages align with actual project tooling
• Optimizing slow builds (caching, parallelism, conditional steps)
• Establishing a stable CI foundation before adding specialized hardening

Context Required

From startup-context: tech stack, deployment target, team size. Also detect or ask:

• Language and framework (auto-detect from repo files before asking)
• Deployment target (Vercel, AWS, GCP, Fly.io, etc.)
• CI/CD platform (default: GitHub Actions; also supports GitLab CI)
• Environments (dev, staging, production) and existing test coverage
• Secrets and credentials needed for build or deploy

Workflow

1. Detect stack from repo signals — Scan for lockfiles (package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock), language manifests (package.json, pyproject.toml, go.mod), and script definitions (test, lint, build commands). Lockfiles indicate package manager choice. Absent scripts trigger conservative defaults. Never assume Node for a Python project.
2. Choose pipeline stages — Start with a dependable baseline: checkout, runtime setup, dependency install with caching, then sequential lint, test, build. Only add complexity after the baseline works.
3. Generate pipeline config — Write CI config for the detected platform. Output machine-readable YAML with correct caching strategy for the detected package manager. Verify all referenced commands actually exist in the project.
4. Configure secrets — List required secrets and how to add them. Use platform-managed secret stores. Recommend OIDC for cloud auth over long-lived keys. Never hardcode credentials in YAML.
5. Add deployment stages safely — Begin CI-only (lint/test/build). Add staging deployment with explicit environment info. Add production deployment with manual approval. Maintain transparency in rollout and rollback procedures.
6. Validate before merge — Confirm generated YAML is syntactically valid, all commands exist in the project, caching aligns with the package manager, and branch protections match organizational requirements.
7. Deliver config and instructions — Full config file plus setup steps.

Output Format

# CI/CD Pipeline: [Project Name]
## Stack Detection Results — detected language, runtime, tools, and build commands
## Pipeline Overview — Mermaid flowchart showing stages
## Pipeline Configuration — Full YAML config file
## Secrets Required — table: name, where to get, how to add
## Setup Instructions — step-by-step to activate
## Validation Checklist — commands verified, caching confirmed, branch rules set
## Optimization Notes — caching strategy, estimated build time

Frameworks & Best Practices

Detection-First Pipeline Generation

Always detect before generating. The detector relies on concrete file signals:

• Lockfiles indicate package manager choice (npm, yarn, pip, cargo, go modules)
• Language manifests identify runtime families
• Script definitions in package.json/pyproject.toml inform lint/test/build commands
• Absent scripts trigger conservative default commands rather than assumptions

Caching Strategies by Ecosystem

Pipeline Architecture Principles

• Lint first — fail early before expensive test runs
• Sequential baseline — checkout, install, lint, test, build, then artifact publish
• Cache aggressively — cuts 30-60% off build times
• Pin action versions — use SHA hashes, not tags, for supply chain security
• Set timeouts (timeout-minutes: 15) and concurrency to cancel redundant runs
• One enhancement at a time — do not add matrix builds, security scanning, and deployment in one PR

Environment Strategy

Common Pitfalls

1. Applying Node-specific pipelines to Python or Go repos (detect first)
2. Enabling deployment before establishing reliable test coverage
3. Overlooking dependency caching configuration
4. Running full matrix builds on minor branch updates (use path filters)
5. Omitting branch protections on production deployments
6. Embedding credentials directly in pipeline YAML

Scaling & Platform Notes

• Split long-running jobs when execution exceeds 10 minutes
• Implement test matrices only when genuine compatibility concerns exist
• GitHub Actions for GitHub ecosystem; GitLab CI for self-hosted SCM+CI
• Maintain a single canonical pipeline source per repository

Related Skills

• code-review — chain to review the CI config itself before committing
• security-review — chain to add or audit security scanning stages (trivy, semgrep, npm audit)

Examples

Example prompt: "Set up CI/CD for my Next.js app deployed on Vercel."

Good output snippet:

name: CI
on:
  push: { branches: [main] }
  pull_request: { branches: [main] }
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  lint:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run lint && npx tsc --noEmit
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci && npm test -- --coverage

Example prompt: "My Python CI takes 8 minutes, how do I speed it up?"

Good output snippet:

Stack detection shows: Python 3.11, pytest, pip. Three fixes to cut to ~3 minutes:
(1) Add pip caching keyed on hashFiles('requirements*.txt'),
(2) split unit/integration tests into parallel jobs,
(3) add path filters to skip CI on docs-only changes.

Code Review

When to Use

• The user shares code (file, snippet, or diff) and asks for feedback
• They paste a pull request or want to know if code is production-ready
• Pre-merge quality gate or bug hunting
• Reviewing architectural decisions in a PR

Context Required

From startup-context: tech stack, product stage, team size. Also need from the user:

• The code or diff to review
• What the code is supposed to do (PR purpose or feature context)
• Any specific concerns (performance, security, correctness)
• Language and framework if not obvious from the code

Workflow

Follow a structured five-step methodology. Each step must be completed before moving to the next.

1. Context — Understand and summarize the PR's purpose before any analysis. Recap the intent back to the user in 1-2 sentences. If unclear, ask before proceeding. Never start reviewing without understanding what the code is trying to accomplish.
2. Structure — Evaluate architectural decisions and design patterns:
   • Does the code belong in the right module/layer?
   • Are abstractions appropriate (not too many, not too few)?
   • Does this change align with the existing codebase patterns?
   • For non-obvious design choices, acknowledge the author's reasoning before proposing alternatives.
3. Details — Assess code quality across multiple dimensions:
   • Correctness: Logic errors, off-by-one bugs, null/undefined handling, race conditions, edge cases
   • Security: OWASP Top 10 baseline — injection, broken auth, data exposure, XSS, access control, misconfig, insecure deserialization, vulnerable components
   • Performance: N+1 queries, unnecessary re-renders, O(n^2) on large datasets, missing caching, memory leaks
   • Naming and clarity: Do names communicate intent? Are functions focused on a single responsibility?
4. Tests — Validate test coverage with equal rigor as code review:
   • Are behavioral assertions present (not just implementation testing)?
   • Are edge cases and error paths covered?
   • Are tests brittle or resilient to refactoring?
   • What test cases are missing?
5. Feedback — Generate a prioritized, categorized report with specific code examples and concrete improvements. Recognize strong patterns and good decisions explicitly.

Output Format

# Code Review: [Feature/File Name]

## Summary
One-paragraph assessment: what the PR does, whether it is ready to merge, needs minor fixes, or needs rework.

## Findings

### Critical (must fix before merge)
- **[CRT-1] Title** — file:line — description, why it matters, suggested fix with code example

### Major (should fix before merge)
- **[MAJ-1] Title** — file:line — description, why it matters, suggested fix

### Minor (fix when convenient)
- **[MIN-1] Title** — file:line — description, suggestion

### Positive (things done well)
- **[POS-1] Title** — file:line — what was done well and why it matters

## Questions
Clarifying questions about non-obvious design choices before blocking on them.

## Suggested Tests
- Test case 1
- Test case 2

Frameworks & Best Practices

Severity Definitions

Review Principles

• Always ground feedback in specifics. Every finding must reference a file, line, and include a concrete improvement — not just "this could be better."
• Recognize good work explicitly. Call out strong patterns, clean abstractions, and thoughtful error handling. Reviews that only flag problems are demoralizing and incomplete.
• Acknowledge author reasoning. For non-obvious choices, assume the author had a reason. Ask before overriding. Phrase as "I see you chose X — was that because of Y? If so, consider Z as an alternative."
• Do not block on style when automated tooling handles it. Linting and formatting are the job of CI, not reviewers. Focus on logic, architecture, and correctness.
• Treat test review with equal weight. Tests are not an afterthought. Missing tests for critical paths is a major finding, not a minor one.

OWASP Top 10 Quick Checks

1. Injection — Are user inputs parameterized? Check SQL, NoSQL, OS command, LDAP
2. Broken Auth — Sessions secure? Tokens rotated? Passwords hashed (bcrypt/argon2)?
3. Sensitive Data Exposure — Secrets in env vars (not code)? PII encrypted at rest?
4. XXE — XML parsing disabled or configured to reject external entities?
5. Broken Access Control — Every endpoint checks authorization, not just authentication?
6. Misconfiguration — Debug modes off? CORS restrictive? Security headers set?
7. XSS — Outputs encoded? No dangerouslySetInnerHTML / v-html with user data?
8. Insecure Deserialization — Serialized objects from untrusted sources validated?
9. Vulnerable Components — Dependencies up to date? Any known CVEs?
10. Insufficient Logging — Auth failures, access violations, and errors logged?

N+1 Query Detection

• Looping over a collection and making a DB call per item
• ORM lazy loading inside a loop (e.g., user.posts in a for user in users loop)
• GraphQL resolvers fetching related data per parent without DataLoader
• Fix: Eager loading, batch queries, or DataLoader pattern

Language-Agnostic Red Flags

• Functions longer than 40 lines or more than 3 levels of nesting
• Boolean params that change behavior (use separate functions)
• Catch blocks that swallow exceptions silently
• Hardcoded values that should be configuration
• Missing input validation on public API boundaries

Related Skills

• security-review — chain for a deep-dive security audit when critical security findings surface
• architecture-design — chain when code review reveals structural problems that need architectural rethinking

Examples

Example prompt: "Review this Express route handler for creating users."

Good output snippet:

# Code Review: POST /api/users Handler

## Summary
The handler creates users but has a critical SQL injection vulnerability and missing
input validation. Needs fixes before merge. Clean async/await usage is a positive.

## Findings
### Critical
- **[CRT-1] SQL Injection** — routes/users.js:14 — Email interpolated
  directly into SQL string. Use parameterized queries:
  `db.query('INSERT INTO users (email) VALUES ($1)', [email])`

### Major
- **[MAJ-1] No input validation** — routes/users.js:12 — Email from
  `req.body` used with no validation. Add zod/joi schema validation.
- **[MAJ-2] Missing error handling** — routes/users.js:18 — DB errors
  propagate as 500 with stack trace. Wrap in try/catch, return generic error.

### Positive
- **[POS-1] Clean async/await** — routes/users.js:11 — Easy to follow,
  no callback nesting.

## Questions
- Is there a validation middleware already in the project that should be reused here?

Cold Outreach

When to Use

Activate when a founder needs to write cold emails or LinkedIn messages to prospects, potential customers, investors, or strategic contacts. Also use when the user says "nobody replies to my emails," "how do I reach out to X," "write me a cold email," or "help with outbound."

Context Required

From startup-context or the user:

• Target prospect — Name, role, company, and why them specifically
• Research signals — Recent news (funding, launches, hires), LinkedIn activity, company growth data, or role/industry context
• Sender positioning — Who you are, what you offer, your unique credibility
• Platform — Email, LinkedIn, or both
• Batch size — Single prospect or multi-prospect campaign

Work with whatever the user provides. A strong research signal and clear value prop is enough to draft. Note what would strengthen the message but do not block on missing inputs.

Workflow

1. Gather context — Read startup-context if available. Ask for missing info on prospect, value prop, and proof points.
2. Research the prospect — Conduct web searches for recent signals. The core principle: 10 minutes of research transforms a cold message into a warm one. Rank signals by strength:
   • Tier 1 (strongest): Recent news — funding rounds, product launches, key hires
   • Tier 2: LinkedIn activity — posts, comments, job changes
   • Tier 3: Company growth signals — hiring trends, tech stack changes
   • Tier 4 (weakest): Role/industry awareness only
3. Assign personalization tier — Based on research signals found:
   • Tier 1 (custom): Named signals across multiple research sources — fully personalized message
   • Tier 2 (templated + personalized): Company info and role context — template with personalized elements
   • Tier 3 (volume template): No signals found — use volume approach with strong value prop
4. Select mode based on scope:
   • Quick: Single connection request + follow-up for one prospect
   • Standard: Four-touch sequence for a prospect (default)
   • Deep: Multi-prospect system with A/B variant messages
5. Draft the sequence — Write messages following the structure and rules below.
6. Self-critique pass — Before delivering, validate that personalization connects to the problem. If you remove the personalized opening and the message still makes sense, the personalization is not working. Rewrite.

Output Format

Deliver all of the following:

• Connection request (LinkedIn, max 300 characters) or Subject line (email, 2-4 words, lowercase)
• Primary message — the full outreach text (emails under 125 words, InMails under 500 characters)
• Follow-up sequence — with timing and a new angle per touch
• Personalization notes — what to customize per recipient if sending to multiple prospects
• Tier label — which personalization tier this message uses and why

Frameworks & Best Practices

The Core Principle

The word "cold" is the problem. Every message should feel like it comes from someone who understands the prospect's world. Research is what makes that possible.

Message Structure

• Connection request (LinkedIn): Max 300 characters. Reference something specific. Never pitch in the request.
• First message (24-48 hours after connection): "Thanks for connecting" + bridge to a research signal + value statement + question. Keep it conversational.
• Follow-up 1 (Day 7): Introduce a new angle — different problem, proof point, or insight.
• Follow-up 2 (Day 14): Share something valuable (article, data, framework) with a soft reconnect.
• Break-up (Day 21): Professional close — "Closing the loop. If timing is ever right, I'm here."

Writing Principles

• Write like a peer, not a vendor. Use contractions. If it sounds like marketing copy, rewrite it.
• Every sentence must earn its place. If it does not move toward a reply, cut it.
• Lead with their world, not yours. "You/your" should dominate over "I/we."
• One ask, low friction. Interest-based CTAs ("Worth exploring?") beat meeting requests.
• Every message must reference a specific research signal or explicitly default to Tier 3. This is a hard rule.

Email Frameworks

• Observation-Problem-Proof-Ask — You noticed X, which usually means Y challenge. We helped Z with that. Interested?
• Trigger-Insight-Ask — Congrats on X. That usually creates Y challenge. We have helped similar companies. Curious?
• Story-Bridge-Ask — [Similar company] had [problem]. They [solved it this way]. Relevant to you?

Subject Lines

• 2-4 words, lowercase, no punctuation tricks
• Should look like an internal email ("quick question," "re: [their company]")
• No product pitches, no urgency, no emojis

What to Avoid

• Opening with "I hope this finds you well" or "My name is X and I work at Y"
• Jargon: "synergy," "leverage," "best-in-class," "leading provider"
• Feature dumps — one proof point beats ten features
• HTML formatting, images, or multiple links in cold emails
• Fake "Re:" or "Fwd:" subject lines
• Asking for 30-minute calls in first touch
• Sending identical templates with only the name swapped
• Pitching in a LinkedIn connection request

Founder-Specific Advantages

• Founder-to-founder or founder-to-exec emails get 2-3x higher reply rates
• Lead with "I built this because..." — more compelling than "our company offers..."
• Offer what reps cannot: personal onboarding, product roadmap input, advisory relationships

Related Skills

• lead-scoring — use to prioritize which prospects to reach out to first
• sales-script — use when the outreach lands a meeting and you need a discovery call or demo script

Examples

Example prompt: "I need to reach out to VP Engineering at mid-market SaaS companies about our API monitoring tool. We reduced downtime by 73% for Acme Corp."

Good email output (Standard mode, Tier 2):

Subject: api alerts

Hi [Name],

Saw your team just shipped the new payments integration — nice work. Launches like that usually surface a wave of edge-case API failures that are tough to catch with standard monitoring.

We built a tool that catches those failures before customers notice. Acme Corp cut their API downtime by 73% in the first month.

Worth a quick look?

Good LinkedIn connection request:

Hi [Name] — saw the payments launch. We help engineering teams catch API failures before customers do. Would love to connect.

Follow-up (Day 7, new angle):

Hi [Name], quick thought — after launches like yours, the #1 issue teams tell us about isn't downtime, it's the silent failures that slip through alerts. Happy to share what patterns we see across 50+ engineering teams if useful.

Community Discovery

When to Use

• Founder wants to find online communities where their target customers are active
• Founder wants to identify channels for organic promotion and community-led growth
• Founder wants to build relationships in relevant communities before launching
• Founder wants to find beta testers, early adopters, or design partners
• Founder wants distribution beyond paid ads and cold outreach

Context Required

• Target customer profile (role, industry, interests, seniority)
• Product category and the problem it solves
• What the founder wants from communities (feedback, users, partnerships, awareness)
• Founder's bandwidth for community engagement (lurk and post vs. become a regular)

Workflow

1. Map the community landscape — identify where your target audience spends time online:
   • Reddit: find subreddits by searching for the problem you solve, competitor names, and industry terms. Check subscriber count, post frequency, and moderation rules.
   • Slack: search Slofile, Slack directories, and Google "[industry] slack community" to find relevant workspaces.
   • Discord: search Disboard, Discord.me, and Google "[topic] discord server" for relevant servers.
   • Forums & others: Indie Hackers, Hacker News, Stack Overflow, niche forums, Facebook Groups, LinkedIn Groups.
2. Qualify each community — not all communities are equal. Score each on:
   • Relevance: does your target customer actually hang out here?
   • Activity: are there regular posts and discussions (not a ghost town)?
   • Size: big enough to matter, small enough to stand out (sweet spot: 1K-50K members)
   • Promotion tolerance: does the community allow product mentions, or is it strictly no self-promotion?
   • Quality of discussion: are conversations substantive or just spam and memes?
3. Categorize by engagement type — sort communities into:
   • Promote: explicitly allows product sharing, launch announcements, or "Show X" posts
   • Contribute-first: allows organic mentions if you're a genuine, helpful member first
   • Listen-only: valuable for research and voice-of-customer, but no promotion allowed
4. Build the engagement plan — for each community:
   • Join and observe for 1-2 weeks before posting
   • Identify the norms (how do regulars communicate? what gets upvoted/praised?)
   • Plan your first 5 contributions (helpful answers, not product pitches)
   • Plan when and how to introduce your product (if appropriate)
5. Create the community map — output a prioritized list with engagement strategy for each.

Output Format

## Community Map for [Product/Category]

### Tier 1 — High Priority (engage weekly)

**[Community Name]** — [Platform]
- Link: [URL]
- Members: [count] | Activity: [posts/day or week]
- Relevance: [why your target customer is here]
- Rules: [promotion policy summary]
- Engagement type: [Promote / Contribute-first / Listen-only]
- Strategy: [specific plan — what to post, how to contribute, when to mention product]
- Key threads/channels: [specific channels or recurring threads to participate in]

### Tier 2 — Medium Priority (engage biweekly)
...

### Tier 3 — Monitor (check monthly)
...

### Engagement Calendar
| Week | Community | Action | Goal |
|------|-----------|--------|------|
| 1 | [name] | Join, read top 20 posts, identify norms | Understand culture |
| 2 | [name] | Answer 3 questions, no product mention | Build reputation |
| 3 | [name] | Share insight related to your space | Establish expertise |
| 4 | [name] | Soft product mention in relevant thread | Drive first traffic |

Frameworks & Best Practices

The 10:1 rule: Give 10 valuable contributions for every 1 product mention. Communities have long memories — one spammy post can get you banned and your brand damaged permanently.

Platform-specific tactics:

Red flags — avoid these communities:

• More self-promo than real discussion
• Moderators are inactive or absent
• "Pay to post" or "pay for featured" requirements
• Last meaningful discussion was months ago
• Members are mostly other founders/marketers (not your actual customers)

Common mistakes:

• Joining 20 communities and being active in none (pick 3-5 and go deep)
• Leading with your product instead of being helpful first
• Copy-pasting the same message across communities
• Ignoring community rules and getting banned
• Giving up after 2 weeks because no one clicked your link

Related Skills

• cold-outreach — for direct outreach to individuals found through communities
• content-strategy — for creating content to share in communities
• launch-strategy — for using communities as launch distribution channels
• landing-page — to convert community traffic into signups

Examples

Prompt: "I'm building a tool for data engineers. Where should I be hanging out online?"

Good output includes: A prioritized map of communities — specific subreddits (r/dataengineering, r/apachekafka), Slack groups (dbt Slack, Data Engineering Weekly), Discord servers, relevant HN threads, and a 4-week engagement plan for the top 3.

Prompt: "We're launching our design tool next month. Which communities should I warm up in advance?"

Good output includes: Communities sorted by launch relevance (Designer Hangout Slack, r/UI_Design, Dribbble, specific Discord servers), a pre-launch engagement timeline, and specific "Show X" or "Share your project" threads to target on launch day.

Competitive Analysis

When to Use

Activate when a founder needs to analyze the competitive landscape, evaluate specific competitors, find differentiation opportunities, or prepare a competitive brief. Trigger phrases include "who are our competitors," "analyze this competitor," "competitive landscape," "how do we compare to X," "feature comparison," "what's our moat," or "differentiation opportunities." Also activate before fundraising (investors will ask) or when entering a new market segment.

Context Required

• From startup-context: product description, target market, current positioning, key differentiators, pricing model, geographic scope.
• From the user: specific competitors to analyze (or request to identify them), market/industry segment to scope, the strategic question driving the analysis (positioning, pricing, feature gaps, market entry).

Workflow

1. Scope the market -- Define the market boundaries, industry segment, and customer type. Precision here determines whether the competitive set is meaningful.
2. Identify 5 primary competitors -- Find direct competitors (same problem, same customer), adjacent competitors (different approach to same problem), and emerging entrants. Distinguish between direct competitors and alternatives (including "do nothing" or manual workarounds).
3. Gather competitive intelligence -- Research each competitor across: product capabilities, pricing/business model, positioning and messaging, distribution channels, team/funding, and traction signals. Use competitor websites, pricing pages, customer reviews (G2, Capterra), job postings, and product trials as primary sources.
4. Assess strengths and weaknesses -- For each competitor, identify core product strengths, product gaps, business model advantages, and competitive threats. Validate insights across multiple sources.
5. Map differentiation opportunities -- Identify unmet customer pain points no competitor addresses well, underserved segments, and areas where you can credibly win. Focus on where the market is heading, not just where it is.
6. Synthesize strategic positioning -- Formulate a competitive positioning recommendation with suggested positioning, key differentiators, target segments to prioritize, competitors to monitor, and 12-18 month competitive risks.

Output Format

Market Overview

One paragraph defining the market structure: how many players, how fragmented, major categories of solutions, and overall market dynamics.

Competitor Profiles (x5)

For each competitor:

Differentiation Opportunities

• Unmet customer pain points no competitor addresses well
• Underserved market segments or personas
• Emerging needs created by market shifts or technology changes
• Positioning angles that create clear separation from the field

Competitive Positioning Recommendation

• Suggested market positioning and category framing
• Key differentiators to emphasize (backed by evidence)
• Target segments where competitive dynamics favor your approach
• Monitoring priorities (which competitors to watch and why)
• 12-18 month competitive risks and mitigation strategies

Frameworks & Best Practices

• Primary sources over secondhand. Use the competitor's own product (sign up for free trials), pricing page, job postings (reveal strategy), and customer reviews over analyst reports. Job postings are strategy signals -- hiring ML engineers means AI investment, enterprise sales reps means upmarket movement.
• Status quo is your biggest competitor. For most startups, the real competitor is "do nothing" or "use a spreadsheet." Analyze this alternative with the same rigor as named competitors.
• Compete on a different axis. If incumbents compete on features, compete on simplicity. If they compete on price, compete on experience. Winning means changing the evaluation criteria, not beating incumbents at their own game.
• Track momentum, not just position. A well-funded competitor with flat growth is weaker than an unfunded one growing 20% month-over-month. Monitor hiring velocity, product release cadence, and review sentiment trends.
• Distinguish direct from adjacent. Direct competitors solve the same problem for the same customer. Adjacent competitors solve the same problem differently or solve a related problem. Both matter but require different strategic responses.
• Feature comparison honesty. Mark your own product's gaps accurately. An internal competitive analysis that overstates your strengths is useless. The purpose is truth, not comfort.
• Refresh cadence. Update quarterly in fast-moving markets, semi-annually in slower ones. Track funding rounds, executive moves, and product launches as trigger events for ad-hoc updates.
• Identify subtle differentiation. The most durable competitive advantages are often not feature-based -- they are distribution advantages, data moats, ecosystem effects, or brand trust built over time.

Related Skills

• market-research -- Pair competitive analysis with market sizing to understand both the landscape and the size of the prize.
• prd-writing -- Use competitive gaps to inform the solution section of a PRD. Build what competitors miss.
• user-research-synthesis -- Ground feature comparisons in what customers actually value, not what competitors assume they value.

Examples

Example 1: Competitive landscape for fundraising

User: "I need a competitive landscape slide for our Series A deck."

Good output: A market overview paragraph, profiles of 4-5 key competitors highlighting their weaknesses relative to the startup's strengths, a differentiation map showing clear whitespace where the startup sits, and a positioning recommendation that tells a narrative about why competitive dynamics favor the startup's approach.

Example 2: Direct competitor deep-dive

User: "We keep losing deals to Competitor X. Help us understand why and how to win."

Good output: Deep analysis of Competitor X's strengths in the dimensions that matter to buyers (e.g., enterprise readiness, integrations, brand trust), identification of the specific evaluation criteria where they win, and actionable recommendations to either match their advantages on must-have dimensions or shift the evaluation criteria to dimensions where you are stronger.

Competitor Monitoring

When to Use

• Founder wants to know when competitors change pricing, ship features, or raise funding
• Founder wants a recurring "what changed this week" scan of competitor activity
• Founder wants to detect strategic shifts from competitor job postings, blog posts, or product updates
• Founder wants to stay informed without manually checking 10 websites daily

This is the recurring sibling of competitive-analysis (one-time deep dive). Use this skill for ongoing monitoring, not initial research.

Context Required

• List of 3-7 competitors to track (names, websites, product URLs)
• What the founder cares about most (pricing, features, positioning, hiring, funding, content)
• Monitoring frequency (weekly recommended for early-stage, biweekly for established markets)
• The founder's own positioning (to flag threats and opportunities)

Workflow

1. Define the monitoring surface — for each competitor, identify what to watch:
   • Pricing page — plan changes, new tiers, free plan adjustments
   • Changelog / release notes — new features, deprecations, platform shifts
   • Job postings — engineering roles signal product direction, sales roles signal GTM shifts, exec hires signal strategy changes
   • Blog / content — new positioning, case studies (reveal target customers), thought leadership pivots
   • Social media — founder posts, company announcements, community reactions
   • Review sites — new reviews on G2, Capterra, Trustpilot (sentiment shifts)
   • Funding / press — Crunchbase alerts, press releases, media coverage
2. Set up the monitoring stack — recommend tools and manual checks:
   • Automated: Google Alerts (brand mentions), Visualping or ChangeTower (page change detection), Crunchbase alerts (funding), LinkedIn job alerts
   • Manual weekly scan: pricing pages, changelogs, recent blog posts, latest job postings
   • Quarterly deep dive: full competitive-analysis refresh
3. Run the scan — check all sources for the monitoring period and flag changes.
4. Analyze signals — for each change detected:
   • What changed (factual description)
   • What it signals (interpretation — are they moving upmarket? entering your segment? struggling with churn?)
   • Threat level (none / watch / respond / urgent)
   • Recommended action (if any)
5. Generate the report — produce a concise weekly/biweekly competitor intel brief.

Output Format

## Competitor Intel Brief — Week of [Date]

### Summary
[1-2 sentence overview: "Quiet week. Competitor A shipped a free tier. No pricing changes elsewhere."]

### Changes Detected

**[Competitor A]**
- **What changed:** [factual description]
- **Signal:** [what this likely means strategically]
- **Threat level:** [None / Watch / Respond / Urgent]
- **Recommended action:** [what to do, if anything]

**[Competitor B]**
- No changes detected this period.

### Job Posting Signals
| Competitor | New Roles | Signal |
|-----------|-----------|--------|
| [A] | 3 enterprise AEs, VP Sales | Moving upmarket |
| [B] | ML engineer, data scientist | Building AI features |

### Emerging Patterns
- [Pattern observed across multiple competitors or over time]

### Action Items
- [ ] [Specific action for the founder]

Frameworks & Best Practices

Reading job postings as strategy signals:

Threat level framework:

• None: Routine activity, no impact on you
• Watch: Interesting move, could affect you in 3-6 months — add to next strategy discussion
• Respond: Directly affects your positioning, pricing, or target market — needs a plan within 2 weeks
• Urgent: Launches directly competing feature, undercuts your pricing, or targets your exact ICP — needs immediate response

Common mistakes:

• Monitoring too many competitors (pick 3-5, not 15)
• Reacting to every move instead of identifying patterns
• Confusing competitor activity with competitor success (they shipped a feature — doesn't mean it works)
• Ignoring indirect competitors and new entrants
• Not archiving snapshots (you'll want to see how their pricing page looked 6 months ago)

Related Skills

• competitive-analysis — for the initial deep dive and periodic refresh
• daily-product-digest — for broader market monitoring beyond specific competitors
• review-mining — for tracking competitor sentiment on review platforms
• market-research — for understanding market shifts driving competitor behavior

Examples

Prompt: "Set up competitor monitoring for our 4 main competitors in the email marketing space."

Good output includes: Monitoring surface for each competitor (pricing pages, changelogs, job boards, blogs), recommended tool stack for automated alerts, and a template for the weekly intel brief.

Prompt: "What have our competitors been up to this week?"

Good output includes: Scan of changelogs, pricing pages, blog posts, job postings, and social accounts for each tracked competitor. Flagged changes with signal interpretation and threat levels. Actionable summary.

Content Strategy

When to Use

• Building a content program from scratch for a startup.
• Deciding what content types to invest in first.
• Identifying content pillars and topic clusters.
• Planning an editorial calendar for the next 30/60/90 days.
• Evaluating whether existing content is working and what gaps exist.
• Choosing between searchable (SEO) and shareable (social) content investments.

Context Required

• From startup-context: product description, ICP, value proposition, competitive positioning, stage, existing traction, team capacity.
• From the user: current content assets (if any), distribution channels in use, business goals for content (traffic, leads, brand awareness, thought leadership), team capacity (who writes, how often), target topics or keywords of interest, customer research available (sales calls, surveys, support tickets).

Workflow

1. Gather context before planning -- Assess four dimensions: (a) business context -- what the company does, who it serves, what problems it solves; (b) customer research -- pre-purchase questions, sales objections, support patterns, customer vocabulary; (c) current state -- existing content performance, available resources, production capabilities; (d) competitive landscape -- what competitors publish, market content gaps.
2. Classify the content need -- Is the goal searchable content (SEO-driven, captures existing demand) or shareable content (social-native, creates demand)? Most startups need both but should weight based on stage:
   • Pre-PMF: lean toward shareable (faster feedback, builds audience)
   • Post-PMF: lean toward searchable (compounds over time, captures demand)
3. Identify 3-5 content pillars -- Each pillar is a core topic your brand owns, spawning related content clusters. Use four identification methods:
   • Product-led: Problems your product solves
   • Audience-led: What your ICP needs to learn
   • Search-led: Topic volume in your space
   • Competitor-led: What competitors rank for (and gaps they miss)
   • Pillar criteria: aligns with product, matches audience interests, has search volume or social interest, broad enough for multiple subtopics.
4. Map content types to pillars -- Select from proven content formats:
   • Use-case content: "[Persona] + [use-case]" targeting long-tail keywords -- bottom of funnel, high intent
   • Hub-and-spoke: Comprehensive pillar page with linked subtopic articles -- SEO authority play
   • Templates and tools: Downloadable resources that solve a micro-problem -- lead generation
   • Thought leadership: Contrarian takes, original data, founder stories -- brand and trust
   • Case studies: Customer transformation stories (Challenge, Solution, Results, Learnings) -- proof
   • Comparison pages: "[Product] vs [Competitor]" -- captures switching intent
   • Data-driven content: Product data analysis (anonymized), public data analysis, original research
   • Expert roundups: 15-30 experts answering one specific question -- built-in distribution
5. Score and prioritize -- Rate each content idea on four weighted dimensions:
   • Customer impact (40%): Frequency in research, percentage of customers affected, emotional charge
   • Content-market fit (30%): Problem-solution alignment, unique insights available, natural path to product
   • Search potential (20%): Monthly volume, competition level, long-tail opportunities, growth trajectory
   • Resource requirements (10%): Internal expertise, research needs, required assets
6. Map to buyer journey -- Ensure coverage across awareness stages using keyword modifiers:
   • Awareness: "what is," "how to," "guide to" -- thought leadership, educational content
   • Consideration: "best," "top," "vs," "alternatives" -- comparison pages, how-to guides
   • Decision: "pricing," "reviews," "demo," "trial" -- case studies, use-case content
   • Implementation: "templates," "examples," "tutorial," "setup" -- onboarding content, feature deep-dives
7. Build the editorial calendar -- Assign content to a realistic publishing cadence. For early-stage: 1-2 high-quality pieces per week beats daily low-effort posts.
8. Define distribution plan -- Every piece needs a distribution path. Budget 50% of effort for distribution. A great article with no distribution plan underperforms a good article with a strong distribution plan.

Output Format

• Content pillars (3-5) with rationale and subtopic clusters per pillar
• Prioritized content backlog with scores and buyer stage mapping
• Topic cluster map showing content interconnections
• If building a calendar: 30/60/90 day editorial calendar with titles, content types, target keywords, funnel stage, and distribution channels

Frameworks & Best Practices

• Searchable vs. Shareable. Searchable content (SEO articles) compounds over time but is slow to start. Shareable content (social posts, hot takes) gets immediate distribution but decays fast. Blend both. The 80/20 split: 80% serves existing demand, 20% creates demand.
• Content-market fit before scale. Test topics in lightweight formats (social posts, community discussions) before investing in long-form. Just like product-market fit, content needs to resonate with a specific audience.
• Topic authority over breadth. Better to own 3 topics completely than write one article about 30 topics. Search engines and audiences reward depth.
• Searchable content guidelines. Target specific keywords matching search intent. Use titles that mirror search queries. Place keywords in title, headings, first paragraph, URL. Optimize for AI/LLM discovery with clear positioning and structured content.
• Shareable content guidelines. Lead with novel insights, original data, or counterintuitive angles. Challenge conventional wisdom with evidence. Create content people share to look smart or help others. Connect to trends or emerging problems.
• Repurposing is a strategy. Every long-form piece should be planned with repurposing in mind -- blog post becomes Twitter thread becomes newsletter section becomes LinkedIn carousel.
• Mine your existing data for content ideas. Sources: keyword data exports, sales call transcripts, survey responses, forum research (Reddit, Quora, Hacker News), competitor content analysis (site:competitor.com/blog), and input from sales/support teams.
• Measure what matters. Searchable: organic traffic and keyword rankings. Shareable: engagement and referral traffic. Conversion content: leads and pipeline influence.

Related Skills

• seo-technical -- when content pillars need keyword research and on-page optimization to rank
• social-content -- when content needs to be adapted and distributed across social platforms
• email-marketing -- when content is distributed through newsletters or used in nurture sequences

Examples

Example 1: New content program

"We're a seed-stage B2B SaaS for engineering teams. No content yet. Where do we start?"

Good output: Identifies 3-4 content pillars using the four identification methods. Recommends starting with 2 comparison pages (capture existing demand), 3 use-case articles (bottom-funnel), and 1 thought leadership piece per month. Includes a scored backlog of 15 content ideas with priorities and a 90-day calendar. Distribution plan emphasizes LinkedIn, Hacker News, and relevant communities.

Example 2: Content audit

"We have 40 blog posts but they barely get traffic. What should we do?"

Good output: Asks for top-performing vs. underperforming posts, identifies content gaps using the buyer journey map, recommends which posts to update/consolidate/kill, proposes hub-and-spoke restructuring around 3 pillar topics, and provides a 60-day optimization calendar alternating between updating old content and publishing new gap-filling pieces.

Contract Review

When to Use

Activate when a founder has received a contract to sign and wants to understand the risks before proceeding. This includes vendor agreements, customer enterprise agreements, partnership deals, investment documents, employment agreements, NDAs, IP assignment agreements, and any other binding legal document. Also activate when the user says things like "review this contract," "is this agreement fair," "what should I push back on," or "flag anything concerning."

Context Required

• From startup-context: company stage, team size, business model, fundraising status, current revenue, and any existing legal counsel.
• From the user: the contract text (or key sections), who the counterparty is, the business relationship context (are they a customer, vendor, investor, partner), the user's negotiating leverage, and any specific concerns they have. Also helpful: whether this is a template/standard agreement or has been negotiated.

Workflow

1. Contract intake — Receive the contract text. Identify the contract type, parties, effective date, and term. Create a one-paragraph summary of what the contract does.
2. Section-by-section analysis — Walk through each major section, summarizing what it means in plain language and flagging anything noteworthy.
3. Risk flagging — Apply the red/yellow/green flagging system (see below) to each clause. Assign a severity and explain why.
4. Missing protections — Identify standard protections that are absent from the contract but should be present given the contract type and relationship.
5. Negotiation recommendations — For each red and yellow flag, suggest specific alternative language or a negotiation strategy.
6. Summary report — Produce a structured risk assessment with prioritized action items.

Output Format

Contract Summary (top of report)

• Contract type: (e.g., SaaS vendor agreement, MSA, NDA)
• Parties: Company name vs. counterparty name
• Term: Duration, renewal mechanism
• Total value: Financial commitment if applicable
• Overall risk level: Red / Yellow / Green with one-sentence rationale

Clause-by-Clause Analysis Table

Missing Protections Checklist

Bulleted list of protections that should be present but are not.

Prioritized Action Items

Numbered list of what to do, in order of importance.

Frameworks & Best Practices

The Red/Yellow/Green Flagging System

Red Flags — Immediate concern, do not sign without modification:

• Unlimited liability or liability cap below a reasonable threshold
• Broad IP assignment that could capture pre-existing IP or IP unrelated to the engagement
• Non-compete clauses that are overly broad in scope, geography, or duration
• Unilateral termination rights without cure period for one party only
• Automatic renewal with no opt-out window or unreasonable notice requirements
• Indemnification obligations that are uncapped or wildly asymmetric
• Most-favored-nation clauses that constrain your pricing with other customers
• Exclusivity provisions that limit your ability to work with competitors
• Audit rights with unreasonable scope or no notice requirement
• Governing law in an unfavorable or distant jurisdiction with no negotiation

Yellow Flags — Worth negotiating, but not necessarily deal-breakers:

• Liability caps that are low relative to the contract value
• Warranty periods or SLA credits that are below industry standard
• Payment terms exceeding net-60
• Change-of-control provisions that allow termination on acquisition
• Broad confidentiality definitions with long or indefinite survival periods
• Assignment restrictions that prevent assignment in an acquisition scenario
• Force majeure clauses that are overly broad or favor one party
• Data handling terms that are vague about deletion, portability, or sub-processors

Green Flags — Standard and reasonable:

• Mutual confidentiality obligations
• Balanced termination rights with cure periods
• Liability capped at 12 months of fees paid
• Standard representations and warranties
• Clear payment terms (net-30)
• Reasonable non-solicitation (employees only, 12 months)

Negotiation Principles

• Symmetry first. Any obligation imposed on one party should apply to both unless there is a clear business reason for asymmetry.
• Cap everything. Liability, indemnification, and damages should all have explicit caps.
• Cure periods. Both parties should have the opportunity to fix a breach before termination.
• Specificity over breadth. Narrow definitions protect both parties. "Confidential Information means everything" protects nothing.
• Survival clarity. Specify exactly which clauses survive termination and for how long.

Related Skills

• terms-of-service — When reviewing a customer's redlines to your terms of service, use contract-review to assess their proposed modifications.
• privacy-policy — Data processing addendums and DPAs often accompany contracts. Review these for consistency with your privacy commitments.

Examples

Example 1: Reviewing a vendor SaaS agreement

User: "We're about to sign a contract with a data enrichment vendor. Here are the terms. Can you flag anything concerning?"

Good output excerpt:

Overall Risk Level: Yellow

The agreement is mostly standard but has three issues worth negotiating before signing.

Section	Flag	Issue
4.2 Data Rights	Red	Vendor claims a "perpetual, irrevocable license to use Customer Data for product improvement and benchmarking." This means they keep and use your data forever, even after termination. Negotiate to: license limited to providing the service, terminates on contract end, anonymization required for any aggregate use.
7.1 Liability	Yellow	Cap is set at "fees paid in the prior 3 months." For a $2K/month contract, that is a $6K cap. If they cause a data breach affecting your customers, your exposure could be much higher. Negotiate to: 12 months of fees, with a carve-out for uncapped liability on data breaches and IP infringement.
9.3 Termination	Yellow	90-day notice required to cancel, even on annual renewal. Combined with auto-renewal, this means you need to decide 3 months before your renewal date. Negotiate to: 30-day notice, or set a calendar reminder now.

Missing Protections:

• No data deletion timeline after termination
• No breach notification obligation
• No sub-processor list or approval rights
• No SLA or uptime commitment

Example 2: Reviewing an IP assignment in an employment agreement

User: "A new engineer's offer letter has an IP assignment clause. They're concerned about their open-source side projects. Can you review?"

Good output excerpt:

Section 8 — Invention Assignment: Red Flag

The current language reads: "Employee assigns to the Company all right, title, and interest in any invention, improvement, or work of authorship created during the term of employment."

This is overly broad. It captures the engineer's weekend open-source contributions, personal projects, and anything they create during employment regardless of whether it relates to company business.

Recommended revision: Add a carve-out: "...created during the term of employment that (a) relates to the Company's current or reasonably anticipated business, (b) was developed using Company resources, or (c) resulted from work performed for the Company."

Also add a Schedule A listing the engineer's pre-existing IP and active side projects, explicitly excluded from assignment. Note: California Labor Code Section 2870 already provides some protection, but an explicit carve-out is clearer and avoids disputes.

Disclaimer: This skill provides contract analysis for educational and planning purposes only. It does not constitute legal advice. Contract interpretation depends on jurisdiction-specific law, the full context of the business relationship, and facts that may not be apparent from the document alone. Always have a qualified attorney review contracts before signing, especially those involving significant financial commitments, IP rights, or liability exposure.

Daily Product Digest

When to Use

• Founder wants a daily or weekly summary of what's happening in the startup/product ecosystem
• Founder wants to track competitor launches and market trends
• Founder wants to identify products launching in their space or adjacent spaces
• Founder wants launch inspiration or to study what's getting traction
• Founder wants to spot emerging trends, tools, or technologies relevant to their market

Context Required

• Founder's product category and market (to filter for relevance)
• Sources to monitor (Product Hunt, Hacker News, Indie Hackers, Reddit, etc.)
• Frequency (daily, weekly, or on-demand)
• What they care about most (competitor activity, market trends, launch tactics, technology shifts)

Workflow

1. Define monitoring scope — based on startup-context, identify:
   • Keywords and categories to track (e.g., "developer tools", "AI", "fintech")
   • Direct competitors to watch for
   • Adjacent markets that could expand into your space
2. Scan sources — check each platform for the specified time period:
   • Product Hunt: top launches, upvote counts, maker comments, notable hunters
   • Hacker News: front page stories, Show HN posts, Ask HN threads, comment sentiment
   • Indie Hackers: new launches, revenue milestones, popular discussions
   • Reddit: relevant subreddit activity (r/SaaS, r/startups, r/[your-niche])
3. Filter for relevance — from everything found, flag items that are:
   • Direct competitors or alternatives to the founder's product
   • In the same category or solving adjacent problems
   • Demonstrating a trend or shift relevant to the founder's market
   • Using interesting launch tactics worth studying
4. Analyze what's working — for top-performing launches/posts, note:
   • What made it resonate (positioning, timing, problem framing)
   • Community reaction and sentiment
   • Potential implications for the founder's product or market
5. Generate the digest — produce a concise, actionable summary.

Output Format

## Product Digest — [Date or Date Range]

### Relevant to You
Items directly related to your market ([category]).

**[Product/Post Name]** — [one-line description]
- Source: [Product Hunt / HN / etc.] | [upvotes/points] | [link]
- Why it matters: [relevance to founder's product/market]
- Takeaway: [what to learn or watch]

### Competitor Activity
- [Competitor] launched [feature/product] on [platform] — [reaction summary]

### Market Trends
- **[Trend]:** [2-3 sentence summary of what's shifting and why it matters]

### Launch Tactics Worth Noting
- [Product] did [tactic] and got [result] — applicable to your launch because [reason]

### Worth Reading
- [Title] ([source]) — [why it's worth the founder's time]

Frameworks & Best Practices

Source-specific signals:

What makes a digest useful:

• Ruthless filtering — a 20-item list is noise. Pick 3-5 items that actually matter to this founder's situation.
• "So what?" for each item — don't just report what launched. Explain why the founder should care.
• Actionable takeaways — end each item with what the founder could do (watch this competitor, study this tactic, consider this positioning angle).
• Pattern recognition — after doing this regularly, highlight emerging patterns ("third AI coding tool this week targeting enterprise — market is heating up").

Common mistakes:

• Reporting everything instead of filtering for relevance
• Missing the comments/discussion (often more valuable than the launch itself)
• Treating all sources equally (HN comments are gold for developer sentiment; PH upvotes can be gamed)
• Not connecting findings to the founder's own strategy

Related Skills

• competitive-analysis — for deep competitor research beyond daily monitoring
• market-research — for structured market sizing and trend analysis
• launch-strategy — to apply launch tactics observed in the wild

Examples

Prompt: "What launched on Product Hunt and Hacker News today that's relevant to my API monitoring startup?"

Good output includes: Filtered digest of today's launches related to APIs, monitoring, observability, or developer tools. For each relevant item: what it does, how it performed, community reaction, and whether it's a competitor or adjacent product.

Prompt: "Give me a weekly roundup of what's happening in the AI coding tools space."

Good output includes: Summary of AI coding launches/updates across PH, HN, and Reddit from the past week, trend analysis (what themes keep recurring), competitor moves, and 2-3 tactical observations the founder can act on.

Data Room

When to Use

• The founder is mid-fundraise and investors are requesting due diligence materials.
• The founder wants to proactively prepare a data room before starting outreach.
• The founder received a term sheet and needs to prepare for confirmatory due diligence.

Context Required

From startup-context: stage, legal entity type, founding date, team composition, fundraising history, cap table basics, revenue/metrics, and any existing legal or financial documents.

From the user: current round stage (pre-term sheet vs. post-term sheet), which investor is requesting materials, and any specific document requests received.

Workflow

1. Read startup context — Pull company details from .agents/startup-context.md to understand stage, entity type, and what documents should already exist.
2. Assess the DD stage — Determine if this is proactive prep (pre-pitch), initial DD (post-first meeting), or confirmatory DD (post-term sheet). The scope differs significantly.
3. Generate the checklist — Produce a stage-appropriate checklist using the master framework below. Mark each item as: Exists, Needs Update, Needs Creation, or Not Applicable.
4. Audit existing materials — Review documents for completeness, staleness (financials older than 1 month), and red flags (missing signatures, inconsistent cap table).
5. Draft missing items — Provide templates or drafts for documents the founder needs to create (financial summary, KPI dashboard, org chart).
6. Organize the room — Recommend a folder structure and set access controls for what to share pre- vs. post-term sheet.

Output Format

A structured checklist in markdown, organized by category:

## Data Room Checklist — [Company Name] — [Round]

### Section 1: Corporate Documents
- [x] Certificate of Incorporation — exists, current
- [ ] Board consent for fundraise — needs creation
- [ ] 409A valuation — needs update (last done 14 months ago)

Followed by a recommended folder structure and access-level guidance.

Frameworks & Best Practices

Master Due Diligence Checklist

1. Corporate Documents: Certificate of Incorporation (and amendments), bylaws, board minutes (last 12 months), board consent for fundraise, stockholder agreements, QSBS eligibility docs, state registrations, any pending litigation.

2. Cap Table & Equity: Fully diluted cap table (Carta/Pulley export, not a manual spreadsheet), option plan and grant ledger, SAFEs/convertible notes with terms, pro forma post-round cap table, current 409A valuation (<12 months old), secondary sale history.

3. Financials: P&L, balance sheet, cash flow — actual, last 12 months (monthly). Bank balance and burn rate. 18-36 month projections with stated assumptions. Revenue breakdown by customer/cohort. Unit economics (CAC, LTV, gross margin, payback). AR/AP aging. Outstanding debt.

4. Metrics & KPIs: Monthly KPI dashboard (MRR/ARR, growth, churn, NRR, DAU/MAU). Cohort retention. Sales pipeline (B2B) or funnel conversion (B2C/PLG).

5. Product & Technology: Product roadmap (6-12 months), architecture overview, IP ownership confirmation, patent filings, open source license audit, SOC 2 or security summary.

6. Contracts & Customers: Top 10 customer contracts, customer concentration analysis (<20% per customer is ideal), key vendor/partner agreements, exclusivity or non-compete clauses, churn log.

7. Team & HR: Org chart, founder/key employee bios, employment agreements (confirm IP assignment), contractor agreements, option grant summary, HR disputes, benefits summary.

8. Legal & Compliance: Privacy policy and GDPR/CCPA status, regulatory licenses, trademarks, terms of service, insurance (D&O, E&O, cyber).

Stage-Specific Scoping

• Pre-seed / Seed: Focus on sections 1, 2, 3 (lighter — 3-6 months of financials), and 7 (team). Product and legal can be thinner. No 409A yet is fine.
• Series A: All sections expected. Monthly financials for 12+ months. Solid metrics dashboard. Airtight IP assignment. Current 409A required.
• Post-term sheet DD: Everything above, plus items the lead investor's counsel specifically requests. Corporate governance gets scrutinized here.

Folder Structure

/01-Corporate           /05-Product-and-Technology
/02-Cap-Table-Equity    /06-Contracts-Customers
/03-Financials          /07-Team-HR
/04-Metrics-KPIs        /08-Legal-Compliance
                        /09-Pitch-Materials

Access Control

• Pre-term sheet: Share pitch materials, metrics dashboard, financial summary, team bios. Hold back contracts, full cap table, legal docs.
• Post-term sheet: Open the full room. Require an NDA before sharing customer contracts or detailed financials.
• Watermark PDFs with the investor's name. Use link-level analytics (DocSend) to track what gets opened.

Red Flags That Kill Deals

• Cap table inconsistencies between the table and signed documents.
• Missing IP assignment agreements for contractors who built core product.
• Stale or missing 409A when options have been granted.
• Financial statements that don't reconcile with bank statements.
• Non-standard founder vesting without board approval documentation.

Related Skills

• pitch-deck — the deck is the top-of-funnel; the data room is the supporting evidence
• investor-research — knowing which investors are in the pipeline helps prioritize what to prepare first

Examples

Example prompt: "We just got a term sheet for our Series A. What do I need in my data room?"

Good output approach: Generate the full 8-section checklist scoped for confirmatory DD. Cross-reference against startup context to pre-fill what likely exists. Flag highest-risk items (cap table accuracy, IP assignments, 409A currency). Recommend a folder structure and 2-4 week timeline.

Example prompt: "I'm about to start fundraising for our seed round. Should I set up a data room now?"

Good output snippet:

Yes — a proactive data room signals operational maturity. For seed, focus on:

• Clean cap table export (Carta or Pulley, not a spreadsheet)
• Certificate of Incorporation and amendments
• 6-month financial summary (revenue, burn, bank balance)
• IP assignment agreements for all founders and contractors
• Monthly KPI dashboard (MRR, user count, growth rate)

Earned Media Outreach

When to Use

• Founder wants to get featured on podcasts as a guest
• Founder wants press coverage from journalists and tech publications
• Founder wants to build relationships with media for ongoing exposure
• Founder wants to identify which podcasts and publications reach their target audience
• Founder wants to write pitch emails that actually get responses

Context Required

• Founder's story and what makes it interesting (not just what the product does)
• Target audience — who are you trying to reach through media? (customers, investors, talent)
• Topics the founder can speak on with genuine authority
• Previous media experience (if any)
• Upcoming newsworthy events (launch, funding round, milestone, contrarian take)

Workflow

1. Define the media angle — journalists and podcast hosts don't cover products, they cover stories. Identify your angles:
   • Founder story: unusual background, pivot story, "I quit X to build Y"
   • Trend story: "Why [trend] is changing [industry]" — you as the expert source
   • Data story: original data or insights from your product/market
   • Contrarian take: challenge conventional wisdom in your space
   • Milestone: funding round, user milestone, revenue milestone, major partnership
2. Build the target list — research podcasts and publications that reach your audience:
   • Podcasts: search Apple Podcasts, Spotify, ListenNotes, and Podchaser by topic. Look for shows that have had similar-stage founders as guests. Check episode frequency (active shows only) and audience size (download numbers if available).
   • Publications: identify journalists who cover your space. Read their last 10 articles. Follow them on X/Twitter. Check if they have a tips inbox or preferred pitch method.
   • Newsletters: Substack writers, industry newsletter authors who feature startups
   • YouTube channels: tech reviewers, industry commentators
3. Tier the list — prioritize by reach x relevance:
   • Tier 1 (5-10): perfect audience fit, worth significant prep time
   • Tier 2 (10-20): good fit, standard outreach
   • Tier 3 (20+): adjacent audience, batch outreach
4. Write the pitches — different formats for different targets:
   • Podcast pitch: short, personal, focused on what you'll teach their audience (not what you'll promote)
   • Journalist pitch: newsworthy angle, relevant data, why their readers care, not a press release
   • Newsletter pitch: how featuring you provides value to their subscribers
5. Send and follow up — outreach cadence:
   • Initial pitch
   • Follow-up 1 (5-7 days later, add new context)
   • Follow-up 2 (7-10 days later, final touch — offer a different angle)
   • Move on after 3 touches with no response
6. Prepare for appearances — for confirmed bookings:
   • Research the host's style and past episodes
   • Prepare 3-5 talking points with stories (not bullet points)
   • Have a clear CTA for listeners (one thing, not five)
   • Send the host a prep sheet with your bio, headshot, topics, and any questions to avoid

Output Format

## Earned Media Plan

### Media Angles
1. **[Angle name]:** [1-2 sentence pitch hook]
   - Best for: [podcast / press / newsletter]
   - Timeliness: [evergreen / time-sensitive — why now]

### Target List

#### Podcasts
| Show | Host | Audience | Fit | Pitch Angle | Contact |
|------|------|----------|-----|-------------|---------|
| [name] | [host] | [who listens] | Tier 1 | [which angle] | [email/form] |
| ... | ... | ... | ... | ... | ... |

#### Journalists & Publications
| Name | Publication | Beat | Recent Article | Pitch Angle | Contact |
|------|------------|------|---------------|-------------|---------|
| [name] | [pub] | [what they cover] | [recent relevant piece] | [which angle] | [email/X] |

#### Newsletters
| Newsletter | Author | Subscribers (est.) | Pitch Angle | Contact |
|-----------|--------|-------------------|-------------|---------|
| ... | ... | ... | ... | ... |

### Pitch Templates

**Podcast Pitch:**
Subject: [subject line]
[Draft email — 150 words max]

**Journalist Pitch:**
Subject: [subject line]
[Draft email — 200 words max]

### Appearance Prep Sheet
- **Bio:** [2-3 sentences]
- **Headshot:** [link]
- **Talking points:**
  1. [Point + story]
  2. [Point + story]
  3. [Point + story]
- **CTA for audience:** [one clear action]
- **Topics to avoid:** [if any]

Frameworks & Best Practices

Finding the right podcasts:

Pitch principles:

• Lead with their audience, not your product. "I can teach your listeners how to..." beats "I'd love to share about my startup..."
• Reference a specific episode. "Your episode with [guest] on [topic] resonated because..." proves you actually listen.
• Make it easy to say yes. Include your topic, 3 talking points, and bio in the first email. Don't make them do research.
• Short pitches win. Podcast hosts get 50+ pitches/week. 150 words max. Journalists get 200+. Be brief.
• Timing matters. Pitch journalists on Tuesday-Thursday mornings. Avoid Mondays and Fridays. For podcasts, timing is less critical but avoid holiday weeks.

What makes a founder a good podcast guest:

• Tells stories, not features ("We almost ran out of money in month 3..." not "Our platform leverages...")
• Has a genuine point of view — agrees with the host on some things, disagrees on others
• Gives actionable takeaways listeners can use immediately
• Doesn't hard-sell — mentions the product once naturally, lets the host ask about it

Common mistakes:

• Sending press releases instead of personalized pitches
• Pitching the product instead of the story
• Not researching the host/journalist before reaching out
• Saying yes to every podcast regardless of audience fit (your time is limited)
• Forgetting the CTA — you get 1,000 listeners and they have nowhere to go
• Not repurposing appearances into social content, blog posts, and email

Related Skills

• founder-thought-leadership — media appearances amplify your personal brand
• cold-outreach — similar outreach mechanics, different audience
• content-strategy — repurpose media appearances into content
• launch-strategy — coordinate press with product launches

Examples

Prompt: "I want to get on podcasts to promote our developer tools startup. Help me find shows and write pitches."

Good output includes: 15-20 podcasts that feature developer tools founders (with contact info), tiered by relevance, 2-3 media angles based on the founder's story, and customized pitch drafts for the top 5 shows.

Prompt: "We just raised our seed round. Help me get press coverage."

Good output includes: List of journalists who cover seed-stage funding in the relevant sector, a pitch angle beyond "we raised money" (what the funding enables, the market insight, the founder story), and draft pitches referencing each journalist's recent coverage.

Email Marketing

When to Use

• Building a welcome sequence for new signups or lead magnet downloads.
• Designing a lead nurture sequence to move prospects toward conversion.
• Creating a re-engagement campaign for inactive users or subscribers.
• Writing an onboarding email series that drives product activation.
• Planning a newsletter cadence and format.
• Optimizing existing sequences for open rate, click rate, or conversion.

Context Required

• From startup-context: product description, ICP, value proposition, tone of voice, current user journey stages, key activation metrics.
• From the user: sequence type needed (welcome, nurture, re-engagement, onboarding, post-purchase, educational), audience context (who they are, what triggered entry, relationship stage), current email list size and segments, existing sequences (if optimizing), email platform in use, primary conversion action, any existing performance data.

Workflow

1. Define the sequence goal -- Every sequence gets one job. Map it to a specific outcome:
   • Welcome: activate, build trust, convert
   • Nurture: educate, build desire, drive trial/demo/purchase
   • Re-engagement: reactivate or clean the list
   • Onboarding: drive users to key activation milestones (coordinate with in-app messaging -- email supports, does not duplicate)
   • Newsletter: maintain top-of-mind, drive traffic, build relationship
2. Map the sequence arc -- Plan the emotional and logical progression across emails:
   • Welcome (5-7 emails, 12-14 days): Deliver value and quick win, origin story/connection, educational content on their pain, social proof/case study, address #1 objection, feature highlight, conversion ask with reason to act now.
   • Lead nurture (6-8 emails, 2-3 weeks): Lead magnet delivery, topic expansion, problem deepening, solution framework, case study, differentiation, objection handling, direct offer.
   • Re-engagement (3-4 emails, 2 weeks, triggered at 30-60 days inactivity): Check-in, value reminder, incentive, last chance and list cleanup.
   • Onboarding (5-7 emails, 14 days): Activate, guide to aha moment, feature education, milestone celebration, upgrade prompt.
3. Write each email using One Email, One Job -- Each email has one primary message and one call to action. No competing CTAs, no kitchen-sink emails.
4. Apply the email copy structure:
   • Hook (first 1-2 lines): Open with a question, surprising fact, or relatable scenario. This determines whether they keep reading.
   • Context (2-3 lines): Bridge from hook to value. Why does this matter to them right now?
   • Value (body): Deliver the insight, story, resource, or proof.
   • CTA (final 1-2 lines): Clear, specific, single action. Button for transactional CTAs, text link for content CTAs.
   • Formatting: Short paragraphs (1-3 sentences), generous whitespace, bullet points where helpful, mobile-first. Conversational tone, active voice.
5. Optimize subject lines -- Write 3 variants per email:
   • Keep under 40-60 characters for mobile
   • Patterns: questions, how-tos, numbers, direct statements, story teases
   • Clear beats clever, specific beats vague
   • Avoid spam triggers (ALL CAPS, excessive punctuation, "free")
   • Preview text (90-140 characters) is the second subject line -- write it deliberately, do not repeat the subject
6. Set timing and triggers -- Welcome email sends immediately. Early sequence emails 1-2 days apart. Nurture phase 2-4 days apart. Long-term weekly or bi-weekly. Define behavior-triggered branching where relevant.
7. Plan measurement -- Define success metrics per email: open rate, click rate, reply rate, conversion rate. B2B SaaS benchmarks: 25-35% open, 3-5% click, 1-3% conversion.

Output Format

• Sequence overview: name, entry trigger, goal, number of emails, timing, exit conditions.
• Per-email detail: number/purpose, send timing, 3 subject line options, preview text, full body copy (50-500 words depending on type), CTA, segment/conditions.
• Email length guidance: transactional 50-125 words, educational 150-300 words, story-driven 300-500 words. Anything over 500 words should be a blog post you link to.
• Segmentation logic and branching paths if applicable.

Frameworks & Best Practices

• One Email, One Job. The most common email mistake is trying to do too much. One message, one CTA. If you have two things to say, send two emails.
• Value Before Ask. Lead with usefulness, build trust through content before making the conversion ask. The sequence arc should front-load value.
• Relevance Over Volume. Fewer, better emails win. Segmentation by behavior (what they did) matters more than personalization by demographics (who they are).
• Plain text outperforms HTML for B2B. For B2B audiences, plain text emails (or minimal HTML that looks like plain text) consistently outperform heavily designed emails. They feel personal, not promotional.
• Send timing. Tuesday through Thursday, 9-11 AM in the recipient's timezone performs best on average, but the best send time is when your audience actually reads email. Test and adjust.
• List hygiene. Remove unengaged subscribers (no opens in 90 days for weekly senders, 180 days for monthly) after a re-engagement attempt. A smaller, engaged list outperforms a large, dead one.
• Reply-to matters. Use a real person's email as the reply-to address. Replies improve deliverability and create sales conversations.
• Unsubscribe is not the enemy. Make unsubscribing easy and obvious. People who cannot leave will mark you as spam, which damages deliverability for everyone on your list.
• Mobile-first writing. Over 60% of emails are opened on mobile. Short paragraphs, generous whitespace, thumb-sized buttons.

Related Skills

• cold-outreach -- when emails are going to prospects who have not opted in (different rules, different approach)
• content-strategy -- when email content needs to be part of a broader content distribution plan
• onboarding-flow -- when the email sequence is part of product onboarding and needs to align with in-app messaging

Examples

Example 1: Welcome sequence for lead magnet

"We launched a free template as a lead magnet. Need a welcome sequence to convert downloads to free trial signups."

Good output: A 6-email sequence over 12 days. Email 1 delivers the template with a quick-start tip. Email 2 shares the founder story. Email 3 teaches a technique related to the template topic. Email 4 shares a customer case study. Email 5 addresses the "I don't have time for another tool" objection. Email 6 offers a free trial with a specific reason to start this week. Each email includes 3 subject line variants, full copy (100-400 words), and a single CTA.

Example 2: Re-engagement campaign

"We have 3,000 subscribers who haven't opened an email in 60 days. What do we do?"

Good output: A 3-email re-engagement sequence. Email 1 (day 0): "Still interested?" with a high-value resource, no hard sell. Email 2 (day 3): Direct question asking what content they want, reply-based engagement. Email 3 (day 7): "Last email unless you want to stay" with a clear re-opt-in link. Anyone who does not engage after email 3 goes to a suppression list. Includes list cleaning guidance and re-engagement benchmarks.

Employer Brand

When to Use

Activate when the user asks to write careers page copy, create a culture document, draft an engineering blog post, build "day in the life" content, document company values, or generally improve how the company presents itself to prospective hires. Also activate when the user is struggling to differentiate their startup from competitors in the talent market.

Context Required

• From startup-context: Company name, mission, stage, team size, founding story, values (stated or practiced), remote/hybrid/onsite policy, notable perks, and any existing brand voice guidelines.
• From user: The specific content type needed, target audience (engineers, designers, go-to-market, general), existing content to build on (if any), and what makes the company genuinely distinctive as a workplace.

Workflow

1. Identify the authentic story — Ask the user what is genuinely true and distinctive about working at this company. Employer brand must be rooted in reality or it backfires at onboarding. Probe for specific stories, rituals, and decisions that reveal culture.
2. Choose the content format — Select from: careers page, values document, engineering blog post, "day in the life" feature, team spotlight, hiring process transparency post, or culture deck.
3. Draft the content — Write using the Voice-Evidence-Proof framework (see below). Lead with what candidates care about (impact, growth, people, flexibility), not what the company cares about (mission statements in a vacuum).
4. Ground every claim in evidence — For each cultural claim, attach a specific example, policy, or anecdote. "We value work-life balance" becomes "We have no meetings on Wednesdays and our average team member works 42 hours/week."
5. Calibrate the tone — Match the company's actual communication style. A developer tools startup sounds different from a healthcare company. Avoid generic startup voice.
6. Review for authenticity — Flag any claims that feel aspirational rather than current. Mark those explicitly or remove them. Candidates trust specificity and distrust superlatives.

Output Format

The deliverable depends on the content type:

• Careers page: Full page copy in markdown, section by section, ready for a designer to lay out.
• Values document: 4-6 values with definitions, behavioral examples, and counter-examples.
• Blog post: A complete draft with headline, intro, body sections, and closing CTA.
• Day in the life: A narrative feature with time stamps, quotes, and concrete details.
• Culture deck: Slide-by-slide content outline with speaker notes.

Frameworks & Best Practices

The Voice-Evidence-Proof (VEP) Framework

Every employer brand claim needs three layers:

• Voice: The claim stated in the company's natural tone. ("We ship fast and learn faster.")
• Evidence: A concrete policy, practice, or structure that supports the claim. ("Our deploy pipeline runs 40+ times per day. Every engineer ships to production in their first week.")
• Proof: A real story or data point that makes it undeniable. ("Last quarter, a new hire identified a UX issue on day 3 and had the fix live by day 5 — no approval chain needed.")

Careers Page Structure

A high-converting careers page follows this arc:

1. Hero section: A bold statement about what working here means. Not the company mission — the employee promise. (e.g., "Build the future of [X] with people who actually care about the craft.")
2. Why here: 3-4 tiles or sections covering the top reasons candidates join. Use the candidate's language: impact, ownership, growth, people, flexibility.
3. How we work: Concrete details about rituals, tools, and cadences. Remote practices, meeting culture, shipping rhythm.
4. Team spotlight: Photos, quotes, and short bios of real team members. Diverse representation matters.
5. What we offer: Comp philosophy, benefits, equity, and learning budget — in specific terms, not vague promises.
6. Open roles: Live job listings with clear titles and locations.
7. Application process: What candidates can expect step-by-step with timeline estimates.

Values Documentation Framework

Strong values have four properties:

• Specific: "Default to transparency" is better than "Integrity."
• Opinionated: A real value implies a trade-off. If no reasonable company would disagree, it's not a value — it's a platitude.
• Behavioral: Each value should connect to observable actions. Define "what this looks like" and "what this does NOT look like."
• Prioritized: When two values conflict, which one wins? Documenting this makes values real.

Example:

## Ship and Iterate
We choose progress over perfection. We'd rather learn from a live
feature than debate a hypothetical one.

What this looks like:
- Shipping an MVP to 10 customers before building the "full" version
- Writing a quick RFC instead of scheduling a meeting
- Celebrating a launched experiment that failed, because we learned

What this does NOT look like:
- Shipping broken code that erodes customer trust
- Skipping testing because "we move fast"
- Ignoring feedback because "we already shipped it"

Engineering Blog Post Framework

Engineering blog posts serve dual duty as employer brand and thought leadership.

1. Start with the problem — Technical readers want to know the challenge before the solution.
2. Show the constraints — What made this problem hard at your scale, stage, or domain?
3. Walk through the decision — Show the trade-offs and alternatives you considered, not just the final choice.
4. Be honest about what didn't work — Vulnerability builds trust. "Our first approach failed because..." is more compelling than a clean narrative.
5. End with what's next — Open loops invite follow-up conversations and signal that interesting work continues.

"Day in the Life" Content Structure

• Format: First-person narrative or interviewer-led Q&A, structured around a real or representative day.
• Include: Specific tools, meetings (or lack thereof), lunch habits, collaboration moments, and a real challenge they worked through.
• Avoid: Sanitized, marketing-approved-sounding quotes. Let personality come through.
• Diversity: Feature team members across roles, levels, and backgrounds.

Anti-Patterns to Avoid

• The aspiration trap: Writing about the culture you want instead of the culture you have. Candidates who join based on aspiration churn fast.
• Superlative overload: "World-class team, cutting-edge technology, incredible culture." These words mean nothing without evidence.
• Perks over substance: Leading with the ping-pong table, free lunch, or unlimited PTO instead of meaningful work, good management, and career growth.
• Copying big tech: Your startup is not Google. Don't mimic their tone, perks list, or values format. Lean into what makes you different.
• Stock photo culture: Use real photos of real team members or none at all. Staged stock photos actively hurt trust.

Related Skills

• job-description — Every JD is an employer brand touchpoint. Ensure JD voice matches the careers page.
• content-strategy — Employer brand content (blog posts, social) should integrate into the broader content calendar and distribution plan.

Examples

Prompt: "Write careers page copy for our developer tools startup. We're 20 people, Series A, remote-first."

Good output snippet:

# Build tools that developers actually love

We're a team of 20 building [product] — and we're looking for people
who care about developer experience as much as we do.

## Why engineers join us

**You'll ship to thousands of developers weekly.** Our CLI has 50K+
monthly active users. The feature you build on Monday gets feedback
in Slack by Thursday.

**You'll own entire systems.** We don't have ticket jockeys. Each
engineer owns a domain — from design through production monitoring.
Your last PR won't need four approvals to merge.

**You'll work with people who write well.** We're remote-first and
async-heavy. That means clear writing, thoughtful RFCs, and Loom
videos instead of status meetings.

Prompt: "Help us write our company values. We keep saying we have them but haven't documented anything."

Good output snippet:

Let's start by identifying what's actually true about how you operate
today — not what sounds good on a poster. I'll ask a few questions:

1. When your team disagrees on a decision, how does it get resolved?
2. What behavior have you praised in the last month?
3. What's something your team does that an outsider might find unusual?
4. When has the team made a hard trade-off, and which side did you land on?

Your answers will reveal the real values. Then we'll name them, define
them with behavioral examples, and pressure-test them with counter-
examples to make sure they're genuinely opinionated.

Event Hosting

When to Use

• Founder wants to host a meetup, workshop, demo day, or community event
• Founder wants to use events to build pipeline, recruit, or establish thought leadership
• Founder wants to create a Luma event page with compelling copy
• Founder wants to plan a recurring event series to build community around their product or space

Context Required

• Event goal (lead generation, community building, recruiting, brand awareness, product feedback)
• Target audience (developers, founders, enterprise buyers, designers, etc.)
• Format (in-person, virtual, hybrid)
• Topic/theme and any confirmed speakers
• Capacity and venue (or virtual platform)
• Budget (many founder-hosted events are $0-500)

Workflow

1. Define the event concept — clarify:
   • Goal: what success looks like (X attendees, Y leads, Z brand impressions)
   • Format: panel, workshop, demo night, fireside chat, networking, hackathon
   • Audience: who should attend and why they'd show up
   • Value prop for attendees: what they'll learn, who they'll meet, or what they'll get
2. Write the event page — create copy for Luma (lu.ma) or similar platform:
   • Title: specific and compelling (not "Tech Meetup #4" — instead "How 5 YC Founders Got Their First 100 Customers")
   • Description: problem/hook → what you'll cover → who should attend → speaker bios → logistics
   • Image/banner: recommend dimensions and style (Luma: 1600x900px)
3. Plan the run of show — minute-by-minute agenda:
   • Doors/login open (15 min buffer)
   • Welcome and context (5 min — who you are, why this event exists)
   • Main content (30-45 min — talks, panels, demos)
   • Q&A or discussion (15 min)
   • Networking / unstructured time (30 min for in-person)
   • Close and next steps
4. Build the promotion plan — how to fill seats:
   • Post on relevant communities (use community-discovery)
   • Personal outreach to 20-30 "anchor attendees" who make the event worth attending
   • Cross-promotion with speakers' audiences
   • LinkedIn/X posts from founder personal account
   • Luma's built-in invite and reminder features
5. Prepare follow-up — plan what happens after the event:
   • Thank-you message to attendees (same day)
   • Share recording/slides (if applicable)
   • Connect with high-value attendees individually
   • Announce next event (if recurring)

Output Format

## Event Plan: [Event Title]

### Concept
- **Goal:** [what success looks like]
- **Format:** [panel / workshop / demo night / etc.]
- **Audience:** [who and why they'd come]
- **Date/Time:** [proposed]
- **Capacity:** [number]
- **Platform:** [Luma link / venue]

### Luma Event Page Copy

**Title:** [title]

**Description:**
[Full event description — 150-300 words, structured as hook → content → audience → speakers → logistics]

**Tags:** [relevant Luma tags]

### Run of Show
| Time | Segment | Owner | Notes |
|------|---------|-------|-------|
| 6:00 PM | Doors open | — | Networking, food/drinks |
| 6:15 PM | Welcome | [Founder] | Context, housekeeping |
| 6:20 PM | Talk 1 | [Speaker] | [Topic] |
| ... | ... | ... | ... |

### Promotion Plan
| Channel | Action | Timeline |
|---------|--------|----------|
| Luma | Publish event page | 3 weeks before |
| LinkedIn | Founder post + speaker reshares | 2 weeks before |
| Communities | Post in [specific communities] | 2 weeks before |
| Direct outreach | Personal invite to 20 anchor attendees | 2 weeks before |
| Reminder | Luma auto-reminder + personal note | 1 day before |

### Follow-Up Plan
- [ ] Same-day thank you email with key takeaways
- [ ] Share recording/slides within 48 hours
- [ ] Personal follow-up with [N] high-value attendees
- [ ] Announce next event date

Frameworks & Best Practices

Event formats that work for startups:

Luma-specific tips:

• Use the "Require Approval" feature to curate attendees (quality > quantity)
• Enable "Ask a Question" during registration to qualify attendees
• Set up co-hosts so speakers can also invite their networks
• Use Luma's calendar subscription feature for recurring events
• Luma's built-in reminder emails have high open rates — don't duplicate with external email

The 40% rule: Expect 40-60% of RSVPs to actually attend for free events. For paid events, expect 80-90%. Overbook accordingly.

Making events a growth channel:

• Host monthly, not "whenever" — consistency builds an audience that returns
• Each event should have a natural next step (join our community, try the product, attend the next event)
• Record everything — one event becomes 5-10 pieces of content
• The best events are conversations, not presentations — leave 30%+ of time unstructured

Common mistakes:

• Making it about your product instead of your audience's interests
• Inviting everyone instead of curating for quality
• No follow-up after the event (the event is the beginning, not the end)
• Over-programming — leave room for serendipity and networking
• Not starting the series until everything is "perfect" — first event can be 15 people in a coffee shop

Related Skills

• community-discovery — find the right communities to promote your event
• founder-thought-leadership — events are a powerful thought leadership channel
• content-strategy — repurpose event content into blog posts, social, and newsletters
• employer-brand — hosting events signals culture and attracts talent

Examples

Prompt: "Help me create a Luma event for a monthly AI founders meetup in SF."

Good output includes: Event page copy with a compelling title and description, run of show for a 2-hour evening event, promotion plan targeting AI-focused communities, and a follow-up template.

Prompt: "I want to host a virtual workshop teaching developers how to use our API."

Good output includes: Workshop structure with live coding segments, Luma event page optimized for developer audience, promotion through developer communities (from community-discovery), and a lead capture strategy.

Feedback Synthesis

When to Use

Activate when a founder or product lead needs to make sense of customer feedback from multiple sources -- support tickets, NPS surveys, user interviews, app store reviews, social media, sales call notes, feature request logs, spreadsheets, or CSVs. This includes prompts like "analyze our customer feedback," "what are users asking for most," "prioritize feature requests," "triage this backlog," or "what themes are showing up in our support tickets."

Context Required

• From startup-context: product type, customer segments, current product roadmap priorities, company stage, strategic goals, and product objectives.
• From the user: the raw feedback data (or access to it), the sources being analyzed, the time period, the product goal or desired outcomes guiding prioritization, and the decision this analysis will inform.

Workflow

1. Understand the goal -- Confirm the product objective and desired outcomes that will guide prioritization. Feedback analysis without a strategic lens produces noise, not signal.
2. Collect and normalize -- Gather feedback from all sources. If data is in structured formats (CSV, spreadsheet), create summary tables. Each piece of feedback becomes a row with source, date, customer segment, verbatim quote, and sentiment.
3. Categorize into themes -- Group related requests and feedback together. Name each theme. Focus on identifying the underlying opportunity (problem) rather than the surface-level feature request.
4. Assess strategic alignment -- For each theme, evaluate how well it aligns with the stated product goals and company strategy.
5. Score with Opportunity Score -- Use the Opportunity Score framework (Dan Olsen): Opportunity Score = Importance x (1 - Satisfaction), normalized to 0-1. This prioritizes problems that matter most and are least well-served today.
6. Prioritize top opportunities -- Select the top 3 themes based on impact (customer value and breadth of users affected), effort (development and design resources required), risk (technical and market uncertainty), and strategic alignment (fit with product vision).
7. Deep-dive top items -- For each top opportunity, document: rationale, alternative solutions worth considering, high-risk assumptions, and how to test those assumptions with minimal effort.
8. Present findings -- Deliver a structured synthesis with executive summary first, supporting data second, and recommended actions third.

Output Format

Synthesis Report Template

# Customer Feedback Synthesis -- [Period]

## Executive Summary
3-5 key findings. Lead with the most surprising or actionable insight.

## Product Goal Alignment
The stated product objective and how feedback themes map to it.

## Theme Map
| Theme | Frequency | Segments Affected | Opportunity Score | Strategic Alignment | Priority |
|-------|-----------|-------------------|-------------------|---------------------|----------|
| [Theme] | [Count] | [Segments] | [Score] | [High/Med/Low] | [H/M/L] |

## Top 3 Opportunities (Deep Dives)
### Opportunity 1: [Theme Name]
- **Rationale:** Customer needs and strategic alignment
- **Representative quotes:** Direct user language
- **Alternative solutions:** Other ways to address this need
- **High-risk assumptions:** What must be true
- **Cheapest test:** How to validate with minimal effort

## Quick Wins
Actions that address frequent feedback with low implementation effort.

## Not Prioritized (and Why)
Themes explicitly deprioritized with reasoning.

## Appendix: Raw Data Summary
Breakdown by source, segment, and time period.

Frameworks & Best Practices

Opportunities Over Features

Never let customers design solutions. Prioritize opportunities (problems), not features. When a user says "I want a Gantt chart," the underlying opportunity might be "I need to visualize project timelines and communicate status to stakeholders." Always dig for the job-to-be-done behind the request.

Opportunity Score (Dan Olsen)

Score each theme: Opportunity Score = Importance x (1 - Satisfaction), normalized to 0-1. This surfaces problems that are both important and underserved. A high-importance, high-satisfaction area is already well-served and should not be prioritized over a high-importance, low-satisfaction gap.

Signal vs. Noise Rules

• One customer saying it is not a pattern. Require 3+ independent mentions of a theme before treating it as a signal. Exception: if the one customer is a whale account citing it as a churn risk.
• Recency bias check. A flood of recent feedback about one issue can overshadow a persistent problem. Always compare against the prior period.
• Loudest does not equal most important. Power users and vocal customers generate disproportionate feedback. Weight by segment size and revenue contribution, not volume alone.
• Praise is data too. Track what users love. Knowing your strengths prevents you from accidentally breaking them during a redesign.

Assumption Testing

For each top-priority opportunity, identify the highest-risk assumption and design the cheapest possible test. Do not build the full solution to validate an assumption that could be tested with a prototype, survey, or Wizard of Oz experiment.

Source-Specific Guidance

Avoiding Common Mistakes

• Cherry-picking quotes that support a pre-existing hypothesis. Present the full distribution, including contradictory feedback.
• Conflating frequency with importance. A low-frequency issue that causes churn matters more than a high-frequency annoyance users tolerate.
• Delivering data without recommendations. A theme map without action items is a report, not a synthesis. Always end with what to do next.
• Ignoring the silent majority. Users who never complain may be happy or disengaged. Segment analysis helps distinguish the two.

Related Skills

• user-research-synthesis -- Chain when feedback analysis reveals gaps that need dedicated user research (interviews, usability tests).
• churn-analysis -- Chain when feedback themes correlate with churn patterns and need deeper retention analysis.
• prd-writing -- Chain when a clear opportunity emerges from the synthesis and needs to be specced into a PRD.

Examples

Example 1: Feature request prioritization

User: "Our feature request board has 150 items. Help me figure out what to build next quarter."

Good output excerpt:

Executive Summary: 150 requests cluster into 9 themes. The top opportunity is not the most-requested feature (SSO, 34 votes) but the most underserved need: "real-time collaboration on shared documents" (Opportunity Score: 0.82). SSO scores lower (0.45) because existing workarounds satisfy most users adequately.

Opportunity 1: Real-time collaboration

• Rationale: 22 requests across 4 segments. Cited as expansion blocker in 3 enterprise deals worth $85K ARR. Current satisfaction: 2/10.
• Alternative solutions: (a) Full real-time editing, (b) Lightweight commenting and presence indicators, (c) Async review workflow with notifications
• High-risk assumption: Users want simultaneous editing, not just awareness of others' changes
• Cheapest test: Add presence indicators only (show who is viewing a document) and measure whether collaboration-related tickets decrease

Example 2: Multi-source synthesis

User: "We have 200 support tickets, 50 NPS responses, and notes from 10 customer interviews from last month. What are customers telling us?"

Good output excerpt:

Theme 1: CSV export broken for large datasets (Opportunity Score: 0.91)

• 47 support tickets, 8 NPS detractors, 3 interviews. Users hitting the 10K row limit work around it by splitting exports manually.
• Strategic alignment: High -- data export is core to our "open platform" positioning.
• Cheapest test: Not needed; this is a clear bug/limitation. Fix directly.
• Quick win: Increase CSV export limit to 100K rows (engineering estimate: 2 days).

Founder Thought Leadership

When to Use

• Founder wants to build a personal brand that drives pipeline, recruiting, or fundraising
• Founder wants to establish IP (intellectual property in ideas, not legal) — original frameworks, contrarian takes, or proprietary insights
• Founder wants to grow a relevant audience on X or LinkedIn
• Founder wants to turn founder journey into content (building in public, lessons learned)

Context Required

• Founder's area of expertise and unique perspective
• Target audience (customers, investors, talent, peers)
• Platform priority (X, LinkedIn, or both)
• Current following size and engagement baseline
• Company stage and what they're optimizing for (pipeline, recruiting, fundraising, awareness)

Workflow

1. Define the founder's IP territory — identify 2-3 topics where the founder has genuine, earned insight that others don't. These must pass the "why should anyone listen to YOU on this?" test.
2. Audit existing content — review the founder's last 20 posts on each platform. Identify what got traction, what fell flat, and what's missing from their voice.
3. Build the content system — create a repeatable framework:
   • Pillar posts (1-2/week): original frameworks, data, or contrarian takes that establish IP
   • Proof posts (2-3/week): behind-the-scenes, customer wins, lessons from failure, building in public
   • Engagement posts (daily): replies, quote tweets, threads on others' content
4. Create the IP library — document the founder's original frameworks, mental models, and coined terms. These become the building blocks for all content.
5. Write a 2-week content calendar — draft actual posts with platform-specific formatting.
6. Set up the feedback loop — define which metrics to track (impressions, profile visits, inbound DMs, pipeline attributed to content).

Output Format

## Founder Thought Leadership Plan

### IP Territory
- Topic 1: [topic] — why you have authority here
- Topic 2: [topic] — why you have authority here

### Original Frameworks
- [Framework name]: [one-line description]
  - Origin story: [how you discovered/developed this]
  - Post format: [how to present it]

### Platform Strategy
**LinkedIn:** [posting cadence, format preference, audience]
**X/Twitter:** [posting cadence, format preference, audience]

### 2-Week Content Calendar
| Day | Platform | Type | Topic | Hook |
|-----|----------|------|-------|------|
| Mon | LinkedIn | Pillar | ... | ... |
| Tue | X | Proof | ... | ... |
| ... | ... | ... | ... | ... |

### Metrics to Track
- [metric]: [current baseline] → [30-day target]

Frameworks & Best Practices

The IP Test: A post builds IP if people screenshot it, reference your framework by name, or tag you when the topic comes up. If none of that happens, it's content — not IP.

Platform differences:

• LinkedIn: longer-form, professional framing, storytelling, carousels perform well. Algorithm rewards comments over likes. Post early morning (7-8am local).
• X/Twitter: shorter, punchier, thread format for depth. Algorithm rewards replies and quote tweets. Contrarian takes travel further. Consistency matters more than timing.

Building in public works when:

• You share specific numbers (revenue, users, churn), not vague "we're growing"
• You share failures and what you learned, not just wins
• You give away frameworks others can use immediately

Common mistakes:

• Writing for peers instead of customers (founder echo chamber)
• Posting generic startup advice instead of specific, earned insights
• Treating both platforms identically (different audiences, different formats)
• Optimizing for impressions instead of inbound conversations
• Abandoning after 2 weeks because "nothing happened" — compound effects take 90+ days

Related Skills

• social-content — for ongoing social media content beyond founder personal brand
• content-strategy — for broader content planning across blog, SEO, and channels
• landing-page — to convert audience attention into signups or leads

Examples

Prompt: "I'm a technical founder building a dev tools startup. Help me build thought leadership on X."

Good output includes: Identifying 2-3 IP territories based on the founder's unique technical insights, drafting 10 posts that establish original frameworks (not generic "startups are hard" content), platform-specific formatting for X (thread structure, hook patterns), and a system for turning daily building into content.

Prompt: "I want to grow my LinkedIn to attract enterprise buyers for our security product."

Good output includes: IP territory around security insights the founder has from building the product, pillar posts that demonstrate expertise to CISOs and security engineers, proof posts showing customer outcomes, and a strategy for engaging in security-focused LinkedIn discussions.

Fundraising Email

When to Use

• The founder needs to write a cold outreach email to an investor.
• The founder wants to draft a warm intro request (a "forwardable email").
• The founder needs a follow-up after an investor meeting.
• The founder is writing a monthly investor update.
• The founder wants to send a thank-you or round-closing notification.

Context Required

From startup-context: company one-liner, stage, key traction metrics, fundraising status, and any notable social proof (investors, customers, press).

From the user: email type, recipient (investor name and firm), prior relationship context, and desired outcome (meeting, intro, materials review).

Workflow

1. Read startup context — Pull the company narrative, metrics, and fundraising details from .agents/startup-context.md.
2. Determine email type — Classify as one of the five types below. Each has different structure, tone, and length.
3. Draft the email — Follow the type-specific template. Keep it short — investors scan, they don't read.
4. Add personalization — Include at least one specific reference to why this investor is a fit (thesis, portfolio company, blog post). Generic emails get ignored.
5. Review against principles — Check the draft against the quality checklist. Trim aggressively.
6. Deliver the final draft — Output subject line and email body, ready to copy-paste.

Output Format

**To:** [Investor Name]
**Subject:** [Subject line]

[Email body]

For investor updates, output a longer structured email with sections (see type 4 below).

Frameworks & Best Practices

The Five Email Types

1. Cold Outreach

Goal: Get a 30-minute meeting. Length: 5-7 sentences, under 150 words.

• Line 1: Why this investor specifically (1 sentence).
• Lines 2-3: What you do and for whom (no jargon).
• Lines 4-5: Strongest traction proof point — one number that makes them lean in.
• Line 6: Specific, low-commitment ask ("Would you have 30 minutes this week or next?").
• No attachments on first email. Subject line formula: [Specific hook] — [Company Name] (e.g., "$40K MRR in 6 months, AI contract review — Lexara").

2. Warm Intro Request (The Forwardable Email)

Goal: Make it effortless for your connector to intro you. Two parts:

• Note to connector (2-3 sentences): "Would you be willing to introduce me to [Partner] at [Firm]? Short blurb below you can forward directly."
• Forwardable blurb (4-6 sentences): Written so the connector sends it as-is. Include what the company does, strongest metric, why this firm is relevant, and what you're looking for. If the connector has to rewrite it, they won't send it.

3. Follow-Up After Meeting

Goal: Maintain momentum, deliver materials, set next steps. Length: 4-8 sentences.

• Thank them and reference one specific thing discussed. Attach requested materials. Address any open question. Propose a specific next step with a date. Send within 3 hours — speed signals competence.

4. Monthly Investor Update

Goal: Keep current and prospective investors informed. Length: 300-500 words.

• Highlights: Top 3 wins (metrics-first).
• KPIs: Table with this month, last month, MoM change.
• Challenges: 1-2 honest struggles (invites help; investors respect candor).
• Asks: 1-3 concrete requests (intros to specific customer types, candidates for a role).
• What's Next: Top 2-3 priorities for next month.
• Send on the same day each month. Monthly updates are the #1 way to convert a "not yet" into a future "yes".

5. Thank-You / Round Closing Note

Goal: Maintain the relationship. Length: 3-5 sentences.

• If invested: genuine thanks, confirm logistics, add to update list.
• If passed: thank them, leave the door open, ask if they want monthly updates. Never burn bridges — the investor who passes on seed may lead your Series A.

Core Principles

1. Brevity wins — Investors get 50-100 inbound emails weekly. Over 200 words in a cold email gets skimmed.
2. Specificity beats superlatives — "$42K MRR growing 25% MoM" beats "fast-growing revenue".
3. Social proof early — Recognizable customer, investor, or accelerator in the first two lines.
4. One clear CTA — Every email gets exactly one ask.
5. Personalization is mandatory — Reference their thesis, portfolio, or writing. Doubles response rates.
6. Subject lines are headlines — Lead with your best metric or most surprising fact.
7. Send Tuesday-Thursday, 8-10am investor's timezone — Open rates drop on Mondays and Fridays.

What Not to Do

• No "disruptive", "revolutionary", "game-changing", or "the Uber of X".
• No NDAs. No reputable investor signs them for startup pitches.
• Don't email multiple partners at the same firm. They compare notes.
• Don't follow up more than twice without new information.
• Don't CC multiple investors on the same email.

Related Skills

• pitch-deck — the email drives the meeting; the deck carries the meeting
• investor-research — research determines who to email and what personalization to use

Examples

Example prompt: "Write a cold email to Sarah Chen at Greylock. We're an AI code review startup with $55K MRR."

Good output:

Subject: $55K MRR — AI code review, 4 enterprise customers — CodeLens

Hi Sarah,

Your investment in Developer Infrastructure at Greylock — particularly the thesis in your "Next Wave of DevTools" post — is why I wanted to reach out to you specifically.

I'm the CEO of CodeLens. We automate code review for enterprise engineering teams using LLMs, catching security vulnerabilities and logic errors that slip past existing tools.

We launched 5 months ago: $55K MRR, 4 enterprise customers (two Fortune 500), growing 30% MoM. We're raising a $3M seed round.

Would you have 30 minutes this week or next?

Example prompt: "Help me write this month's investor update."

Good output approach: Pull metrics from startup context, ask the founder for this month's highlights and challenges, then produce the structured update. Flag any missing or stale KPIs.

Interview Kit

When to Use

• Designing a structured interview loop for a specific role and level
• Creating standardized question banks organized by interview round type
• Building scoring rubrics for consistent candidate evaluation across interviewers
• Reducing interviewer bias with process controls and calibration
• Turning a job description into a repeatable evaluation process
• Calibrating interview panels after quarterly hiring outcome reviews

Context Required

• From startup-context: Company stage, team size, engineering culture, current interview process (if any), hiring velocity
• From user: Role title, level (junior/mid/senior/staff), key competencies to evaluate, number of interview rounds the team can support, whether a take-home or live exercise is preferred

Workflow

1. Define competencies — Extract 4-6 core competencies from the job description. Split into technical skills, domain knowledge, collaboration traits, and startup-fit signals. Each competency must be evaluable with observable evidence.
2. Design the interview loop — Map competencies to interview stages with explicit, non-overlapping objectives per round. Typical startup loop: recruiter/founder screen, technical assessment, team interview, values interview. Assign timing and interviewers to each stage.
3. Write structured questions — For each stage, write 3-5 primary questions with follow-up probes. Every question must map to a specific competency. Include "what good looks like" answer guidance so interviewers know what signal they are looking for.
4. Build scorecards — Create a 1-4 rating scale (not 1-5 — it creates a "3 means fine" dead zone). Define behavioral anchors at each level specific to the role. Interviewers must score independently before the debrief.
5. Design take-home or live exercise — If applicable, create a practical assessment that mirrors real work. Time-cap it (2-4 hours max), share the evaluation rubric with the candidate upfront, and always follow up with a live walkthrough.
6. Add anti-bias guardrails — Require structured debrief instructions, independent scoring protocol, and a checklist of common bias traps. Every candidate for the same role gets the same core questions in the same order.
7. Plan calibration cadence — Set quarterly recalibration using hiring outcome data. Review whether loop design still surfaces the right signals based on quality-of-hire metrics.

Output Format

A complete interview kit document containing:

• Role summary and competency matrix (4-6 competencies with definitions)
• Interview loop overview (stages, duration, interviewers, competency mapping)
• Per-stage question sets with follow-up probes and scoring rubrics
• Take-home or live exercise brief with time cap and evaluation criteria
• Scorecard template (1-4 scale with behavioral anchors)
• Debrief protocol with independent scoring and evidence-based discussion rules
• Compensation benchmarking notes (if requested)

Frameworks & Best Practices

Competency Categories by Role Type

• Engineering: System design, code quality, debugging approach, technical communication, ownership/initiative
• Product: Customer empathy, prioritization frameworks, cross-functional communication, data-informed thinking, shipping velocity
• Go-to-market: Discovery/qualification, storytelling, objection handling, pipeline management, customer orientation
• Design: Design process, craft quality, user research fluency, systems thinking, collaboration with engineering

Scorecard Design (1-4 Scale)

• 1 — Does not meet bar: Could not demonstrate the competency. Clear concerns.
• 2 — Below bar: Showed partial ability but gaps are significant for the level.
• 3 — Meets bar: Demonstrated the competency at the expected level. Solid hire signal.
• 4 — Exceeds bar: Demonstrated exceptional strength. Would raise the team's capability.

Each score level must include 1-2 concrete behavioral anchors specific to the role being evaluated.

The STAR-B Question Framework

Structure behavioral questions to elicit complete, pattern-revealing answers:

• Situation: Set the scene
• Task: What was your responsibility
• Action: What specifically did you do
• Result: What happened
• Behavior pattern: Is this a repeatable pattern or a one-off

Example: "Tell me about a time you had to ship something with significant technical debt. What was the situation, what did you decide, and how did it play out? Would you make the same call again?"

Anti-Bias Techniques

• Structured questions: Every candidate for the same role gets the same core questions in the same order
• Independent scoring: Interviewers submit scores before the debrief meeting — no anchoring on a senior person's opinion
• Blind resume review: Strip names, photos, school names, and company names in the initial screen where possible
• Diverse interview panels: Include at least one interviewer from an underrepresented background when possible
• Language check: Before writing feedback, ask "Would I say this about a different candidate?" to catch biased framing
• Replace "culture fit" with "values alignment" and require specific behavioral evidence

Take-Home Assignment Guidelines

• Time-capped: 2-4 hours maximum. State this explicitly and mean it.
• Mirrors real work: The exercise should resemble an actual task the person would do in the role
• Transparent criteria: Share the rubric with the candidate upfront so they know what you value
• Equitable access: Offer a paid alternative if the candidate cannot invest unpaid time
• Debrief required: Always follow up with a live walkthrough where the candidate explains their choices

Common Pitfalls

• Overweighting one round while ignoring other competency signals
• Using unstructured interviews without standardized scoring
• Skipping calibration sessions for interviewers
• Changing the hiring bar without documenting rationale
• Letting round objectives overlap so multiple stages test the same thing

Compensation Benchmarking Framework

Use three inputs to triangulate:

1. Market data: Levels.fyi, Pave, Carta Total Comp, Glassdoor as directional
2. Stage multiplier: Seed pays 70-85% of big-co base with 0.5-2% equity; Series A narrows to 80-95%
3. Candidate calibration: Adjust for experience, competing offers, and location within the level band

Always present comp as a range with a target midpoint, not a single number.

Related Skills

• job-description — Use the JD's competency requirements as input for the interview loop
• sourcing-outreach — Align outreach messaging with the interview process so candidates know what to expect

Examples

Prompt: "Design an interview loop for a senior backend engineer. 15-person startup."

Good output snippet:

## Interview Loop — Senior Backend Engineer

### Competencies to Evaluate
1. System design & architecture (technical depth)
2. Code quality & testing practices (craft)
3. Debugging & production thinking (operational maturity)
4. Technical communication (collaboration)
5. Ownership & initiative (startup fit)

### Stage 1: Founder Screen (30 min)
- Evaluate: Motivation, communication, logistics
- Questions:
  - "What's drawing you to an early-stage company right now?"
  - "Walk me through the most impactful project you led in the last year."
- Scorecard: 1-4 on communication, motivation, startup-fit

### Stage 2: Technical Deep-Dive (60 min)
- Evaluate: System design, code quality
- Format: Live system design discussion + code review exercise
- Scorecard: 1-4 on architecture thinking, code craft, trade-off reasoning

Prompt: "Our interviewers keep disagreeing on candidates."

Good output snippet:

This usually means you lack structured evaluation criteria. Three-step fix:

1. Define 4-5 competencies per role with written behavioral descriptions
2. Give each interviewer a scorecard to fill out independently BEFORE debrief
3. In the debrief, discuss only scores that diverge by 2+ points —
   focus on evidence, not impressions

The goal is calibrated, evidence-based evaluation — not consensus.

Investor Research

When to Use

• The founder is preparing to fundraise and needs a target investor list.
• The founder has a list of investors and wants to qualify or prioritize them.
• The founder asks which VCs or angels are a good fit for their stage, sector, or geography.
• The founder wants to understand a specific fund's thesis, portfolio, or decision-making process.

Context Required

From startup-context: stage, sector/category, location, current round target (amount), business model, and any existing investor relationships or warm connections.

From the user: geographic preferences (if any), whether they want VC-only, angel-only, or both, any investors already in conversation, and any firms they want to explicitly avoid (e.g., portfolio conflicts they know about).

Workflow

1. Read startup context — Pull stage, sector, geography, round size, and existing investors from .agents/startup-context.md.
2. Define investor criteria — Based on context, establish the filtering parameters: stage match, sector focus, typical check size range, geographic relevance, and portfolio conflict exclusions.
3. Build the raw list — Research investors matching the criteria. For each investor, capture: firm name, partner name, fund stage focus, sector focus, typical check size, recent fund size/vintage, portfolio companies, geographic preference, and a source URL.
4. Check for conflicts — Flag any firm that has a portfolio company directly competing with the founder's startup. These go on a "conflicts" list, not the target list.
5. Score and tier — Assign each investor to Tier 1 (strong fit, prioritize), Tier 2 (good fit, pursue), or Tier 3 (acceptable fit, use as backfill) using the scoring framework below.
6. Identify warm paths — For each Tier 1 investor, suggest how the founder might get a warm intro: mutual connections, portfolio founder intros, accelerator networks, or conference overlap.
7. Deliver the target list — Output a structured, sortable list with tiers and recommended outreach order.

Output Format

A markdown table with the following columns, grouped by tier:

## Tier 1 — High Priority

| Firm | Partner | Stage Focus | Sector Fit | Check Size | Recent Fund | Conflict? | Warm Path | Notes |
|------|---------|-------------|------------|------------|-------------|-----------|-----------|-------|

Followed by a "Conflicts" section listing excluded firms and why.

Followed by a "Research Gaps" section listing anything that could not be verified and needs the founder's input.

Frameworks & Best Practices

Investor Qualification Criteria (The 7-Point Filter)

1. Stage fit — Does the firm invest at the founder's current stage? A Series B fund will not lead a seed round. This is the first filter and it is binary: pass or fail.
2. Sector focus — Does the firm have a stated thesis or track record in the founder's sector? Look at their last 10 investments, not just their website copy.
3. Check size match — Does the firm's typical check size align with what the founder needs? A $2B fund rarely writes $500K checks. A $50M fund rarely leads $20M rounds.
4. Portfolio conflicts — Does the firm already have a company in the same space? This is the most common reason pitches are dead-on-arrival. Check every portfolio company, including quiet ones.
5. Fund vintage — Is the firm actively deploying from a recent fund? A fund raised 4+ years ago is likely in harvest mode and not writing new checks. Prefer firms that closed a fund within the last 18 months.
6. Geographic relevance — Some firms only invest locally. Others require board seats that demand proximity. Remote-friendly firms have expanded, but geography still matters for many funds.
7. Partner-level interest — Is there a specific partner whose background, interests, or public writing aligns with the startup? Pitching the right partner at the right firm matters as much as pitching the right firm.

Tiering Framework

• Tier 1: Matches on 6-7 of the criteria above. The firm has invested in adjacent companies, the partner has spoken publicly about the space, and a warm intro path exists. Pursue first.
• Tier 2: Matches on 4-5 criteria. Good fit on stage and sector but may lack a warm path or have a slightly mismatched check size. Pursue in the second wave.
• Tier 3: Matches on 3 criteria. Acceptable as backfill if the round needs more participants. Do not spend significant time here until Tier 1 and 2 are exhausted.

Sourcing Investor Information

• Crunchbase / PitchBook: Fund size, recent investments, portfolio companies.
• Firm website: Stated thesis, partner bios, blog posts that reveal focus areas.
• Twitter/X and Substack: Many partners publish their current interests publicly. Recent posts are a better signal than old "About" pages.
• SEC filings: Fund size from Form D filings when not publicly disclosed.
• Portfolio founder back-channels: The single best diligence on an investor is talking to founders they have backed — both successes and companies that struggled.

Common Mistakes to Avoid

• Spraying 200 cold emails — Fundraising is a funnel. 30 well-targeted, well-introduced conversations beat 200 cold ones.
• Ignoring portfolio conflicts — Founders waste weeks pitching firms that will never invest because of a conflict.
• Pitching the wrong partner — At multi-partner firms, the wrong partner will say "interesting, let me introduce you to my colleague" at best, or just pass.
• Targeting only brand-name firms — Tier 2 and emerging funds are often faster to decide, more founder-friendly, and more willing to lead at earlier stages.
• Not tracking your pipeline — Use a simple spreadsheet or CRM: investor name, status (researching / intro requested / meeting scheduled / pitched / passed / term sheet), and next action.

Angel Investor Considerations

• Angels decide faster (days, not weeks) but write smaller checks ($25K-$250K typically).
• Look for angels with operational experience in your sector — they add value beyond capital.
• Angel syndicates (AngelList, etc.) can aggregate small checks into a meaningful allocation.
• Be cautious about taking angel money from potential acquirers or competitors without understanding the signaling implications.

Related Skills

• pitch-deck — tailor the deck narrative based on what specific investors care about
• fundraising-email — write targeted outreach once the investor list is built

Examples

Example prompt: "We're raising a $2.5M seed round for a developer tools company based in SF. Help me build an investor list."

Good output snippet (one Tier 1 entry):

| Boldstart Ventures | Ed Sim | Pre-seed/Seed | Developer tools, infrastructure | $1-3M | $160M Fund IV (2023) | None | Ed is active on Twitter re: dev tools; check if any portfolio founders overlap with your network | Led seed in [similar company]; blog post on "Why developer experience is the next platform shift" |

Example prompt: "I have a list of 15 VCs I want to pitch. Can you help me prioritize?"

Good output approach: Run each firm through the 7-point filter against the founder's startup context. Re-tier the list. Flag any portfolio conflicts the founder may have missed. Identify the 5 to pitch first and suggest the outreach sequence.

Job Description

When to Use

Activate when the user asks to create a new job posting, rewrite an existing one, or get feedback on a draft JD. Also activate when the user is preparing to hire for a new role and needs to define it clearly before sourcing candidates.

Context Required

• From startup-context: Company name, mission statement, stage/funding, tech stack (for eng roles), team size, remote/hybrid/onsite policy, benefits, and equity structure.
• From user: Role title, reporting structure, seniority level, key responsibilities, must-have vs. nice-to-have qualifications, compensation range (or willingness to include one), and hiring timeline.

Workflow

1. Clarify the role — Ask the user what problem this hire solves. A JD should start from business need, not a generic title. Confirm level, scope, and team placement.
2. Draft the hook — Write a 2-3 sentence opening that connects the company mission to why this role matters right now. Avoid generic openers like "We are looking for a rockstar..."
3. Structure the body — Organize into five sections: Mission & Impact, What You'll Do (6-8 bullets), What You Bring (5-7 bullets split into must-have and nice-to-have), What We Offer, and How to Apply.
4. Apply anti-pattern checks — Scan the draft for corporate jargon, unrealistic requirement stacking, gendered language, and exclusionary phrasing. Flag and fix.
5. Add startup-specific framing — Emphasize ownership, speed of impact, equity upside, learning velocity, and access to leadership. These are startup advantages over big-co offers.
6. Review comp and inclusivity — Ensure compensation transparency (range or "we'll share in first conversation"). Confirm language passes inclusive-language guidelines.
7. Final polish — Tighten to a scannable length (400-700 words). Ensure the tone matches the company voice from startup-context.

Output Format

A complete, ready-to-post job description in markdown with the following sections:

• Title and location/remote line
• Opening hook (2-3 sentences)
• About Us (3-4 sentences)
• What You'll Do (bulleted list)
• What You Bring (must-haves and nice-to-haves, clearly separated)
• What We Offer (bulleted list)
• How to Apply (1-2 sentences with clear next step)

Frameworks & Best Practices

The HERO Structure

• Hook: Why this role matters to the mission right now
• Expectations: What the person will actually do day-to-day
• Requirements: What they genuinely need to succeed (not a wish list)
• Offer: What the company gives back (comp, equity, growth, culture)

Anti-Patterns to Avoid

• Requirement inflation: Listing 15+ requirements signals you don't know what you need. Keep must-haves to 4-5.
• Corporate jargon: "Synergy," "leverage," "fast-paced environment" are empty. Use concrete language.
• Gendered language: Avoid "ninja," "rockstar," "aggressive." Use tools like the Gender Decoder or Textio guidelines as a reference.
• Years-of-experience gates: "7+ years of React" excludes strong candidates. Prefer demonstrated capability over tenure.
• Hidden role: If the job is actually three jobs, split it or be honest about the breadth.

Inclusive Language Guidelines

• Use "you" instead of "the ideal candidate" to feel inviting rather than evaluative.
• Replace "requirements" with "what you bring" to reduce self-screening by underrepresented candidates.
• Include an explicit encouragement to apply even if not a 100% match (research shows this matters for women and minority applicants).
• State accommodation availability for the interview process.

Compensation Transparency

• Include a salary range. Listings with ranges get significantly more applicants.
• If equity is offered, state the range in percentage or share count and mention the vesting schedule.
• Name benefits explicitly rather than saying "competitive benefits package."

Startup-Specific Framing

• Impact: "You'll be one of the first 10 engineers shaping the product architecture."
• Ownership: "You'll own the entire lifecycle of features, from design through production monitoring."
• Equity: "We offer meaningful equity because early employees take real risk and deserve real upside."
• Growth: "As we scale from 10 to 50, you'll grow into a leadership role if you want it."

Related Skills

• interview-kit — After posting the JD, design the interview loop and scorecards for this role.
• sourcing-outreach — Use the JD as the basis for personalized outreach messages to passive candidates.
• employer-brand — Ensure the JD tone and content align with your careers page and employer brand narrative.

Examples

Prompt: "We need to hire our first product designer. We're a 12-person B2B SaaS startup, Series A, remote-first."

Good output snippet:

# Product Designer — Remote (US/Canada time zones)

Join Acme as our founding designer and shape the product experience
from the ground up. You won't be handed a pixel-perfect spec — you'll
partner directly with engineering and customers to figure out what to
build and how it should feel.

## What You'll Do
- Own the end-to-end design process for our core B2B platform
- Run discovery calls with customers weekly to ground designs in real workflows
- Build and maintain our design system as the foundation for a future team
- Collaborate async-first with engineering using Figma and Loom
...

Prompt: "Review this JD for red flags."

Good output snippet:

Issues found:
1. "Must have 10+ years in Python" — This filters out strong mid-career
   candidates. Consider "deep fluency in Python" instead.
2. "Fast-paced environment" — This is vague. Replace with something
   concrete: "We ship weekly and iterate based on customer feedback."
3. No salary range listed — Adding a range will increase your applicant
   pool significantly.

Landing Page

When to Use

• Creating a new landing page from scratch (product launch, feature page, waitlist).
• Auditing an existing page for conversion rate optimization (CRO).
• Rewriting headlines, CTAs, or hero sections.
• Structuring page sections for a specific audience and traffic source.
• Generating A/B test variants for copy or layout changes.

Context Required

• From startup-context: product description, ICP (ideal customer profile), value proposition, competitive positioning, stage, tone of voice.
• From the user: page URL or current copy (if auditing), page type (homepage, landing page, pricing, feature, blog), primary conversion goal (signup, demo, purchase, subscribe, download), traffic source (organic, paid, email, social), any existing conversion data or user research.

Workflow

1. Identify page type and conversion goal -- Every page gets one primary conversion action. Determine whether this is a homepage, landing page, pricing page, feature page, or blog post -- each has a different CRO framework.
2. Assess value proposition clarity -- Can a visitor understand what this is and why they should care within 5 seconds? Check whether copy is benefit-focused (good) or feature-focused (common problem). Ensure it is written in the customer's language, not company jargon.
3. Evaluate headline effectiveness -- Does the headline communicate the core value proposition? Is it specific enough to be meaningful? Does it match the traffic source's messaging? Apply headline patterns:
   • Outcome-focused: "Get [desired outcome] without [pain point]"
   • Specificity: Include numbers, timeframes, or concrete results
   • Social proof: "Join [N] teams who [achieve outcome]"
   • Direct address: "You [do painful thing]. There's a better way."
4. Audit CTA placement, copy, and hierarchy -- Is there one clear primary action visible without scrolling? Does button copy communicate value, not just action? ("Start my free trial" beats "Submit"). Check CTA hierarchy: primary vs. secondary, repeated at key decision points.
5. Check visual hierarchy and scannability -- Can someone scanning the page get the main message? Are the most important elements visually prominent? Is there sufficient whitespace? Do images support or distract from the message?
6. Evaluate trust signals and social proof -- Look for: customer logos (especially recognizable ones), testimonials with specifics and attribution, case study snippets with real numbers, review scores, security badges. Place trust signals near CTAs and after benefit claims.
7. Identify objection handling -- Are common objections addressed? Price/value concerns, "will this work for me?", implementation difficulty, "what if it doesn't work?" Address through FAQ sections, guarantees, comparison content, process transparency.
8. Find friction points -- Too many form fields, unclear next steps, confusing navigation, required fields that should not be required, poor mobile experience, slow load times.

Output Format

• If auditing: Recommendations structured as: (1) Quick Wins -- easy changes with immediate impact, (2) High-Impact Changes -- bigger efforts with significant conversion improvement, (3) Test Ideas -- hypotheses worth A/B testing. For key elements, provide 2-3 copy alternatives with rationale.
• If drafting: Full page copy organized by section with 2-3 headline variants and CTA text options. Include layout and visual recommendations.

Frameworks & Best Practices

Page-Specific CRO

• Homepage: Clear positioning for cold visitors, quick path to primary conversion, handle both "ready to buy" and "still researching" visitors.
• Landing page: Message-match with traffic source, single CTA (remove navigation if possible), complete argument on one page.
• Pricing page: Clear plan comparison, recommended plan indication, address "which plan is right for me?" anxiety.
• Feature page: Connect feature to benefit, include use cases and examples, clear path to try/buy.
• Blog post: Contextual CTAs matching content topic, inline CTAs at natural stopping points.

Copy Principles

• The headline is the most important element on the page. If the headline does not stop the scroll, nothing else matters. Test headlines before anything else.
• Specificity beats cleverness. "Save 12 hours per week on reporting" outperforms "Work smarter, not harder" every time.
• The subheadline does the heavy lifting. The headline earns attention; the subheadline explains the value. Use it to clarify who the product is for, what it does, and why it matters.
• Awareness-level matching. Match copy depth to visitor awareness. Paid search visitors are typically solution-aware (want pricing and CTAs). Social ad visitors are typically problem-aware or unaware (need problem education first). Traffic source reveals awareness level.

Conversion Principles

• One page, one goal. Never give the visitor two equal choices. Every element should push toward the primary CTA.
• Above-the-fold rule. Visitor should understand what you do, who it is for, and what to do next within 5 seconds.
• Risk reversal near final CTA. Address "what if it doesn't work?" -- free trial, money-back guarantee, or no-commitment language.
• Social proof placement. Small proof element in hero section ("Trusted by 500+ teams"), dedicated proof section below the fold.
• Testimonial specificity. "This product is great" is worthless. "We reduced onboarding time from 3 weeks to 2 days" is persuasive. Seek specific, outcome-driven testimonials with numbers.
• Reduce cognitive load. Every additional choice, link, or piece of information adds friction. Cut anything that does not directly support the primary conversion.
• Mobile-first. Over 60% of traffic is mobile. Design for thumb zones. Ensure CTAs are tappable without zooming.

Related Skills

• content-strategy -- when the landing page needs supporting content to drive traffic
• seo-technical -- when the landing page needs to rank organically
• cold-outreach -- when the landing page is the destination for outbound campaigns and copy must align with email messaging

Examples

Example 1: Page audit

"Here's our landing page copy. We're getting 15k visitors/month but only 1.2% conversion. What's wrong?"

Good output: Quick wins (e.g., rewrite feature-focused headline to outcome-focused), high-impact changes (restructure page sections, add social proof to hero), and test ideas (3 headline variants, 2 CTA copy options). Each recommendation includes the specific issue, the fix, and expected impact.

Example 2: New page draft

"We're launching a waitlist page for our developer tool. Target audience is backend engineers frustrated with deployment complexity."

Good output: Full section-by-section copy. Hero headline: "Deploy to production in 3 commands, not 30 steps." Problem agitation naming the specific pain. 3-step "how it works" section. Social proof placeholder guidance. CTA: "Join 2,400 engineers on the waitlist." Two alternative headline options and layout notes.

Example 3: A/B test recommendations

"Our signup page converts at 3.5%. What should we test first?"

Good output: Priority-ordered test plan. (1) Headline -- 3 variants reframing value prop from feature-first to outcome-first. (2) CTA copy -- "Start free trial" vs. "See it in action" vs. "Get started in 2 minutes." (3) Hero trust element -- customer count or logo bar. Each test includes control, variant, hypothesis, and minimum sample size guidance.

Launch Strategy

When to Use

• Planning a launch for a new product, course, program, or major feature.
• Designing a pre-launch content sequence to build anticipation and desire.
• Structuring a launch funnel with cart open/close mechanics.
• Preparing a JV/affiliate launch with partner recruitment.
• Building an evergreen launch funnel for ongoing automated sales.
• Deciding between seed launch, internal launch, JV launch, or evergreen launch.
• Applying the Product Launch Formula or similar sequenced launch methodology.

Context Required

• From startup-context: product description, target audience, value proposition, existing audience size, email list size and engagement, brand voice.
• From the user: what is being launched and the core transformation it provides, launch type (seed, internal, JV, evergreen), launch timeline and cart open/close dates, pricing and offer stack (product + bonuses + guarantee), existing assets (testimonials, case studies, content), budget for ads or affiliate commissions, team capacity, and any previous launch experience.

Workflow

1. Define the offer — Clarify exactly what is being sold, the transformation it provides, the price point, and the offer stack (main product + bonuses). Total perceived value should be 10x+ the price.
2. Select the launch type — Based on audience size, product maturity, and goals:
   • Seed Launch — Small list, new product. Validate and get testimonials before going big.
   • Internal Launch — Launch to your own list with a full pre-launch content sequence.
   • JV Launch — Partner with affiliates who promote to their lists for broader reach.
   • Evergreen Launch — Automated version of a live launch, triggered by opt-in.
3. Build the launch list — Create a dedicated opt-in to identify the most interested prospects. This is your hottest segment. Build this list before creating pre-launch content.
4. Create pre-launch content (PLC) — Develop 3-4 pieces of high-value content using the Sideways Sales Letter structure (see framework below). Each piece delivers standalone value while advancing the sale.
5. Write the launch email sequence — Plan emails for every phase: PLC releases, cart open announcement, mid-launch social proof, final push urgency, and cart close deadline.
6. Build the sales page — Create the sales page with offer stack, testimonials, guarantee, and countdown timer. The page should make the buying decision feel obvious.
7. Recruit JV partners (if applicable) — Reach out to potential affiliates 4-6 weeks before launch. Provide swipe files, tracking links, and leaderboard incentives.
8. Execute the launch — Release PLCs on schedule, open cart, send emails, engage with prospects in real time. Most sales happen in the last 24 hours.
9. Close the cart and debrief — When the cart closes, it closes. Follow up with non-buyers. Analyze results and plan improvements for the next launch.

Output Format

• A complete launch plan with: launch type selection and rationale, pre-launch content outlines (PLC 1-4), email sequence for each phase, sales page structure, launch timeline with specific dates, and success metrics.
• If JV launch: affiliate recruitment plan, swipe file outlines, and leaderboard structure.
• If evergreen: automation trigger design and ongoing optimization plan.

Frameworks & Best Practices

The Sideways Sales Letter (Jeff Walker's Product Launch Formula)

Instead of one long sales letter, spread the sales message across 3-4 pieces of pre-launch content over 7-14 days. Each piece delivers value while building desire:

• PLC 1: The Opportunity — Why now? What is possible? Introduce the new opportunity or approach. Share proof and results. Open a loop teasing PLC 2.
• PLC 2: The Transformation — What will change when they embrace this? Deep dive with case studies, before/after results. Handle the "Is this for me?" objection. Tease PLC 3.
• PLC 3: The Ownership Experience — What is it like to have this solution? Walk through the product. Testimonials about the experience. Handle the "Can I do this?" objection. Tease the offer.
• PLC 4: The Offer — Full offer presentation with the value stack, bonuses, guarantee, and a clear call to action with urgency.

Results in Advance (Frank Kern)

Give away your best material for free during pre-launch. When you deliver massive value before asking for the sale, you build reciprocity and prove competence. Do not hold back your best content out of fear — generosity in pre-launch drives sales at cart open.

Launch Timeline Template

S-Tier Launch Tactics (Must-Do)

1. Create 3-4 pieces of pre-launch content. Do not just announce the product. Build desire over 7-14 days.
2. Build a launch list before launching. A dedicated opt-in identifies your hottest leads.
3. Create real scarcity. Use a genuine cart close date. When it closes, it closes. Fake deadlines destroy trust permanently.
4. Stack your offer. Present bonuses that eliminate objections. Total perceived value should be 10x+ price.
5. Send multiple emails during cart open. Send 2-3 emails per day during the final 48 hours. Most sales happen in the last 24 hours.
6. Do a seed launch first. For new products, launch to a small group to get testimonials and refine the offer before going big.

A-Tier Launch Tactics (Highly Effective)

1. Recruit JV partners with audiences matching your ideal customer. Provide swipe files and leaderboard prizes.
2. Create a launch event (webinar, challenge, live series) to build engagement during pre-launch.
3. Implement behavioral triggers. Track who watches PLCs, clicks, and visits the sales page. Send different follow-up based on behavior.
4. Use countdown timers on the sales page and in emails for visual urgency.
5. Plan your post-launch sequence. Non-buyers from this launch are warm leads for the next one.

Common Mistakes to Avoid

• Launching without pre-launch content — Announcing a product without building anticipation leads to weak sales.
• Fake scarcity — Extending a deadline after saying it is final destroys trust.
• Only emailing once during launch — You need multiple touchpoints. Under-emailing is the most common launch mistake.
• Skipping the seed launch — Launching an unvalidated product to a big list is high risk.
• No post-launch follow-up — Non-buyers are warm leads. Stay in touch.

Related Skills

• content-strategy — When the launch needs supporting content to sustain post-launch momentum
• social-content — When launch messaging needs to be adapted for social platforms
• email-marketing — When the launch relies on email sequences for waitlist nurture and follow-up
• landing-page — When the launch requires a dedicated sales page optimized for conversion

Examples

Example 1: Online course launch

"I have a 5,000-person email list and a new course on data analytics. Help me plan the launch."

Good output: Recommend an internal launch with full PLC sequence. PLC 1 (10 days before): video on "The 3 Myths Holding Back Your Data Career." PLC 2 (7 days before): case study of a student who achieved a specific result. PLC 3 (4 days before): walkthrough of the course modules and ownership experience. Cart open for 5 days with a fast-action bonus (first 48 hours get a live Q&A session). Email sequence: 2 emails per PLC release, daily emails during cart open, 3 emails on cart close day. Target: $100-150K launch based on list size and typical conversion rates.

Example 2: SaaS product with seed launch

"We have a new SaaS tool and only 200 beta users. Should we do a big launch or start small?"

Good output: Recommend a seed launch first — offer the product to 50-100 beta users at founding member pricing to validate demand, collect testimonials, and refine the offer. Use their feedback to build PLC content for the internal launch 6-8 weeks later. Only consider a JV launch after the internal launch proves the funnel converts.

Lead Scoring

When to Use

Activate when a founder needs to evaluate inbound prospects against ICP criteria, build a systematic qualification workflow, score and route leads, establish MQL/SQL definitions, or design pipeline stages. Also use when the user says "which leads should I focus on," "how do I qualify inbound leads," "define my ICP," "set up lead scoring," or "how do I route leads to the right person."

Context Required

From startup-context or the user:

• ICP definition — Who is the ideal customer (company size, industry, stage, geography, use case)
• Lead sources — Where inbound leads come from (website, events, content, referrals)
• CRM and tooling — Current stack for managing leads and deals
• Current customers — Who are the best existing customers and why
• Pipeline data — Existing deals, active customers, prior contacts
• Sales capacity — Who handles leads and what is their bandwidth

Work with whatever the user provides. If they have a clear problem area, start there. Do not block on missing inputs.

Workflow

1. Load ICP and configuration — Read startup-context if available. Establish the qualification criteria across company attributes, person attributes, and use case fit.
2. Parse the lead data — Accept leads in any format (CSV, list, CRM export, single name). Identify data gaps and flag what needs enrichment.
3. Check pipeline overlap — Before scoring, check for existing customers (route to upsell), active deals (flag for sales coordination), and prior contacts (note history). Pipeline overlaps are routing flags, not disqualifiers.
4. Score company fit — Evaluate against company size, industry, stage, geography, and use case alignment. Weight each dimension based on what predicts closed-won deals.
5. Score person fit — Evaluate title, seniority, department, and decision-making authority. A perfect company with the wrong contact still needs routing, not rejection.
6. Score use case alignment — Connect the lead's inferred intent to specific product capabilities. Inbound signals (demo requests, pricing page visits) tip borderline cases toward qualification.
7. Generate composite score and verdict — Produce a 0-100 composite score and assign a routing recommendation.
8. Export structured output — Deliver results in a table or CSV with all qualification data, scores, and routing.

Output Format

Deliver these documents:

1. Scored lead report — Each lead with composite score (0-100), sub-scores by dimension, verdict category, and routing recommendation
2. ICP definition — Firmographic and demographic criteria with priority tiers
3. Scoring model — Complete point-value table for company, person, and use case dimensions with threshold definitions
4. Pipeline routing rules — How each verdict category gets handled

Frameworks & Best Practices

Verdict Categories

Assign every lead to one of these routing buckets based on composite score:

Handling Unknown Data

Score unknown dimensions at 30 points (out of 100 for that dimension). This acknowledges data absence without automatically rejecting leads. A lead missing company size data is not the same as a lead with the wrong company size. Flag unknowns for enrichment rather than penalizing them.

Inbound Intent Premium

Prospects who initiate contact demonstrate genuine interest. For borderline cases (scores 50-74), inbound signals should tip the scoring decision toward qualification. A borderline lead who requested a demo is a better prospect than a slightly-above-threshold lead who has never engaged.

Pipeline Overlap Routing

Before scoring, check for overlaps and route accordingly:

• Existing customer — Route to account management for upsell/expansion conversation
• Active deal in pipeline — Flag for the assigned sales rep to coordinate, do not create a duplicate
• Prior contact with no deal — Note history and score normally, but include context for the sales rep
• Competitor employee — Auto-disqualify and log for competitive intelligence

Multi-Dimensional Scoring

Company evaluation — Score against: company size, industry vertical, company stage/funding, geography, and use case fit. Weight dimensions based on which most predict closed-won deals in your data.

Person assessment — Score against: job title, seniority level, department alignment, and decision-making authority. A Director of Engineering at a perfect-fit company scores higher than a junior developer at the same company.

Use case alignment — Map the lead's stated or inferred needs to specific product capabilities. Strong alignment on the core use case matters more than broad but shallow fit.

Dual-Threshold MQL Definition

An MQL requires BOTH fit and engagement. Neither alone is sufficient.

• Minimum fit score: 30 points (must have basic ICP match)
• Minimum engagement score: 20 points (must show some intent)
• Combined minimum: 60 points

A perfect-fit company that never engages is not an MQL. A student downloading every whitepaper is not an MQL. The dual-threshold prevents both failure modes.

Maintaining and Iterating

• Recalibrate quarterly. Pull closed-won data and check if the model correctly predicted winners.
• Watch for score inflation. If 80% of leads become MQLs, the threshold is too low.
• Track MQL-to-SQL acceptance rate. If sales rejects more than 30% of MQLs, adjust the model.
• Start simple. Score the first 50-100 leads by hand before automating.
• Speed-to-lead is critical. Contact within 5 minutes is 21x more likely to qualify.

Related Skills

• cold-outreach — Use the ICP and scoring to prioritize who to reach out to first
• sales-script — Use pipeline stage definitions to prepare the right script for each stage

Examples

Example prompt: "We get 200 inbound leads a month from our website and events. Most go nowhere. Help me build a system to score and route them."

Good output excerpt:

Lead Qualification Report (Sample)

Lead	Company Score	Person Score	Use Case Score	Composite	Verdict
Jane Smith, VP Eng @ Acme (200 emp, SaaS)	88	85	90	88	Qualified — Hot
Bob Lee, Developer @ TinyCo (15 emp, Agency)	35	40	50	40	Near Miss
Unknown Title @ MegaCorp (10K emp, Finance)	60	30 (unknown)	45	47	Near Miss — Enrich

Routing: Jane gets immediate sales outreach (AE assigned within 1 hour). Bob enters nurture sequence. MegaCorp lead flagged for enrichment — title and use case data needed before routing.

Example prompt: "A lead from a current customer's company just filled out our demo form. What do I do?"

Good output approach: Flag the pipeline overlap — check if this is a new department/team or the same buyer. If same account, route to the existing account manager for upsell coordination. If new department, score normally but include account context. Never create a duplicate deal.

Market Research

When to Use

Activate when a founder needs to size a market opportunity using TAM/SAM/SOM, validate market assumptions for a pitch deck, understand growth trends, evaluate market entry, or prepare for investor conversations about addressable market. Trigger phrases include "how big is our market," "TAM/SAM/SOM," "market size," "market opportunity," "is this market big enough," "market trends," "help me with the market slide," or "validate our market assumptions."

Context Required

• From startup-context: product description, target customer segments, pricing model, geographic scope, business model.
• From the user: the market or segment to analyze, known data points (industry reports, customer counts, pricing benchmarks), geographic and industry constraints, whether this is for internal decision-making or external presentation (investor deck), and any specific hypotheses about market dynamics.

Workflow

1. Define market boundaries -- Specify the problem space, customer segments, geography, and constraints. "Project management tools" is a different market than "team collaboration software." Precision determines whether the analysis is useful.
2. Top-down estimation -- Start from total industry size using industry reports, public company revenues, and government statistics. Narrow to the relevant segment by applying filters for geography, customer type, and product category.
3. Bottom-up estimation -- Build independently from unit economics: (number of potential customers) x (price per customer) x (purchase frequency). Cross-validate against the top-down estimate.
4. Scope the SAM -- Identify which portion of TAM is realistically serviceable given current product capabilities, pricing, distribution channels, and geographic reach.
5. Estimate the SOM -- Project achievable market share in 1-3 years based on competitive position, go-to-market capacity, and current traction.
6. Project growth -- Forecast how TAM, SAM, and SOM evolve over 2-3 years. Identify key growth drivers, technology shifts, regulatory changes, and demographic trends.
7. Map assumptions -- Surface every critical assumption underlying each estimate. Rate confidence levels and identify how to validate the most uncertain assumptions.

Output Format

Market Definition

One paragraph defining the problem space, customer need, geographic and segment boundaries, and key scoping decisions.

TAM / SAM / SOM

Sizing Methodology

Top-Down: Step-by-step calculation from industry totals to target segment. Show every filter and assumption applied.

Bottom-Up: Step-by-step calculation from unit economics up. Show: (number of target customers) x (expected conversion rate) x (annual contract value).

Reconciliation: Comparison of both approaches, explanation of any gaps, and reconciled estimate. If they diverge by more than 3x, investigate the assumptions driving the gap.

Growth Drivers & Trends

Key factors that could expand or contract the market -- technology shifts, regulatory changes, demographic trends, behavioral changes, and emerging adjacent segments.

Key Assumptions & Risks

Strategic Implications

Numbered list of what the market data means for product, pricing, and go-to-market decisions.

Frameworks & Best Practices

• Always do both top-down and bottom-up. Top-down is fast but abstract. Bottom-up is precise but assumption-heavy. The truth is where they converge. Providing both triangulates and builds credibility with investors.
• Beware vanity TAMs. "The global software market is $500B" is not useful. Define the market narrowly enough that you can name the buyer persona, their budget line item, and what they pay today.
• The "who writes the check" test. Market size should be based on the actual budget your product replaces or claims. A $50/month tool's market is (number of buyers) x ($600/year), not the total revenue of the industry you serve.
• Growth rate matters more than current size. A $500M market growing 40% annually is more attractive than a $5B market growing 3%. Investors and founders should optimize for tailwinds.
• Distinguish value-based from volume-based sizing. Revenue-based (dollars) and volume-based (users/units) tell different stories. Be explicit about which you are using and why.
• Assumption sensitivity analysis. Identify the 2-3 assumptions that most affect your estimate. Show what happens if each is 50% lower. If the market is still attractive at the pessimistic end, the thesis is robust.
• Source hierarchy for credibility: (1) Government statistics and census data, (2) Public company filings and earnings calls, (3) Industry association reports, (4) Analyst reports (Gartner, Forrester, IDC), (5) Startup databases (PitchBook, Crunchbase), (6) Your own primary research and customer data.
• Cite sources for market data. Avoid unsupported numbers. Label what is an estimate vs. what is sourced data. Flag where estimates have wide confidence intervals.
• Geographic specificity. Global TAMs are meaningful only if you plan to sell globally from day one. Start with the geography and segment you will actually target first.
• Adjacent market expansion. After sizing the core market, identify 1-2 adjacent markets you could expand into. This shows a growth path beyond the initial wedge.
• Consider currency and purchasing power parity for international market sizing.

Related Skills

• competitive-analysis -- Pair market sizing with competitive landscape analysis to understand both the size of the prize and how contested it is.
• prd-writing -- Use market segment data to ground the Market Segments section of a PRD in real numbers.
• roadmap-planning -- Use growth trend analysis to time roadmap investments. Build for fast-growing segments first.

Examples

Example 1: Market sizing for a pitch deck

User: "Help me size the market for our developer productivity tool. We need the TAM/SAM/SOM for our Series A deck."

Good output excerpt:

TAM: $[X]B -- Global developer tools market (source: [industry report], includes IDEs, testing, CI/CD, monitoring, and productivity tools).

SAM: $4.2B -- Code review and collaboration segment, filtered to teams of 10-500 developers at companies with >$5M revenue in North America and Europe.

SOM: $85M -- 2% penetration of SAM over 4 years, based on current growth rate of 15% QoQ and average ACV of $18K.

Bottom-up cross-check: 23,000 target companies x 12% expected conversion at maturity x $18K ACV = $49.7M.

Example 2: New segment validation

User: "We're thinking about expanding from SMB to mid-market. Is that market big enough?"

Good output should size the mid-market segment separately, compare unit economics (higher ACV but longer sales cycle), estimate the investment required to serve the segment (enterprise features, sales team), and calculate whether the segment-level SOM justifies the investment within the planning horizon.

MVP Scoping

When to Use

Activate when a founder or PM has an idea or a full feature spec and needs to distill it down to the smallest version worth building. Trigger phrases include "what's our MVP," "what should we cut," "scope this down," "what do we build first," "we only have 4 weeks," or "help me prioritize what to include." Also activate when a team is struggling with scope creep and needs to draw a clear line between must-have and nice-to-have.

Context Required

• From startup-context: company stage, team size, runway/timeline pressure, existing product (if any), technical stack and constraints.
• From the user: the full feature vision or spec, target user segment, the core hypothesis being tested, available timeline and resources, any non-negotiable requirements (compliance, security, contractual commitments).

Workflow

1. State the hypothesis — Define what the MVP is designed to learn or prove. Format: "We believe that [user segment] will [behavior] if we provide [capability], and we'll know we're right when [measurable signal]."
2. List all candidate features — Enumerate every feature, capability, and requirement from the full vision.
3. Apply MoSCoW prioritization — Classify every item as Must Have, Should Have, Could Have, or Won't Have (this time).
4. Identify risks — For each Must Have, identify technical, market, and execution risks. Flag any Must Have that carries high risk and may need a spike or prototype first.
5. Define the cut line — Draw a clear boundary. Everything above the line ships in v1. Everything below has a specific trigger for when it gets built.
6. Estimate and validate — Rough-size the Must Haves. If they exceed the available timeline by more than 20%, force-rank the Must Haves and demote the lowest.
7. Write the MVP spec — Produce a concise scope document with explicit inclusions, exclusions, and deferred items.

Output Format

Hypothesis Statement

One sentence stating what the MVP will test and how success is measured.

MoSCoW Classification

Must Have (v1 — ships or the product fails)

Should Have (v1.1 — ships within 2-4 weeks after launch)

Same table format. These improve the product meaningfully but are not required for the core hypothesis test.

Could Have (v1.2+ — ships if data supports it)

Same table format. These are enhancements contingent on v1 learnings.

Won't Have (not this product/quarter)

List with brief reasoning for each exclusion.

Risk Register

MVP Scope Summary

Concise paragraph describing what v1 does, who it's for, and what it explicitly does not do.

Success Criteria

Specific metrics and thresholds that determine whether the MVP validated the hypothesis.

Frameworks & Best Practices

• MoSCoW prioritization.
  • Must Have: Without this, the product does not work or the hypothesis cannot be tested. Apply ruthlessly. If more than 40% of features are Must Have, your bar is too low.
  • Should Have: Important but the product can launch without it. Users will notice the gap but can work around it.
  • Could Have: Nice-to-have. Include only if time permits with zero impact on Must Haves.
  • Won't Have: Explicitly out of scope this cycle. Naming these prevents scope creep.
• The "cupcake, not a layer of cake" principle. An MVP is a complete, small experience — not an incomplete large one. A cupcake is a whole dessert. A cake layer with no frosting is an unfinished project.
• Optimize for learning speed. The MVP's job is to test a hypothesis as fast as possible. Every feature should either be required for the test or removed.
• Manual before automated. If a process can be done manually for the first 50 users, do not build automation for it in the MVP. Concierge MVPs and Wizard-of-Oz MVPs are valid.
• One user segment. MVPs that try to serve multiple segments serve none well. Pick the segment with the strongest pain and the shortest sales cycle.
• Hard conversation forcing function. If the team cannot agree on Must Haves, ask: "If we could only build 3 features, which 3 would we pick?" Start from zero and add, rather than starting from everything and cutting.
• Deferred is not deleted. Maintain a deferred backlog with explicit triggers: "Build feature X when metric Y reaches threshold Z." This reassures stakeholders that their requests are heard.
• Risk-first sequencing. Build the riskiest Must Have first. If it fails, you learn early and cheaply. If it works, everything else is lower risk.
• Scope creep signals. Watch for: "while we're at it," "it would be easy to also," "users will expect," and "competitors have." Each phrase requires the response: "Does this change our hypothesis?"

Related Skills

• prd-writing — After scoping the MVP, write a PRD for the Must Have set.
• roadmap-planning — Place Should Have and Could Have items into the roadmap's Next and Later horizons.
• user-research-synthesis — Use customer insights to validate which features are truly Must Have vs. assumed Must Have.

Examples

Example 1: Scoping a new product MVP

User: "We're building a tool that helps freelancers send invoices, track time, manage expenses, handle taxes, and send contracts. We have 6 weeks and 2 engineers."

Good output excerpt:

Hypothesis: We believe freelancers earning $50K-$150K/year will send at least 3 invoices in their first month if we provide a simple invoice builder with payment tracking, and we'll know we're right when 40% of signups reach this threshold.

Must Have: Invoice creation, payment status tracking, email delivery. Should Have: Time tracking (linked to invoices), recurring invoices. Won't Have (this cycle): Expense management, tax calculations, contract management.

Rationale for cuts: Time tracking and expenses are adjacent workflows but not required to test the core invoicing hypothesis. Tax and contracts are separate products masquerading as features.

Example 2: Scoping down an existing feature

User: "Our PRD for the analytics dashboard has 15 chart types, custom date ranges, export to PDF/CSV, scheduled reports, and real-time data. Engineering says it's 3 months. We need it in 6 weeks."

Good output should classify the 15 chart types into 4-5 Must Have charts that cover 80% of use cases, defer scheduled reports and real-time data, keep CSV export but cut PDF, and identify that custom date ranges are Must Have because every user interview mentioned them.

Onboarding Flow

When to Use

Activate when a founder or product lead needs to design onboarding for new users, improve activation rates, reduce time-to-value, fix drop-off after signup, redesign a guided setup experience, or re-engage users who stalled during onboarding. This includes prompts like "design our onboarding flow," "users are dropping off after signup," "build an activation checklist," "our time-to-value is too long," "how do we get users to their aha moment faster," or "first sessions are not sticking."

Do NOT use for employee onboarding, service process design, or when the product lacks a stable value proposition. This skill is for in-product user activation only.

Context Required

• From startup-context: product type (B2B/B2C/PLG), target user persona, current activation rate, defined "aha moment," product complexity level, existing onboarding steps, and current tools (email platform, analytics, in-app messaging).
• From the user: where users currently drop off, the key action that correlates with retention (the activation event), number of steps currently required to reach value, any qualitative feedback from churned users about the setup experience, and what "healthy" first-session behavior looks like.

Workflow

1. Intake and goal-framing — Read startup-context if available. Establish the activation goal, current baseline metrics, and what success looks like. If the user does not know their activation event, help them hypothesize based on product type (see benchmarks below).
2. Map the current journey — Document every step from signup to activation event, including screens, emails, wait states, and decision points. Identify friction points, unnecessary steps, and moments of confusion.
3. Identify friction and drop-off — Pinpoint where users abandon the flow. Categorize blockers: too many steps, unclear value, technical obstacles, cognitive overload, or missing guidance.
4. Define behavioral activation moments — Identify the specific user actions that predict long-term retention. These become the milestones the onboarding flow drives toward.
5. Design the first experience — Apply the progressive onboarding framework to restructure the journey. Focus on the "first 30 seconds" experience and minimize steps before first value. Defer non-essential setup.
6. Build the milestone-based onboarding plan — Create a "first mile" plan with clear milestones from signup through habit formation, with coordinated in-app and email touchpoints.
7. Establish measurement and experiments — Set up tracking for each step in the funnel. Build an experiment backlog prioritized by impact, confidence, and effort. Design A/B tests for the highest-leverage changes.

Output Format

A comprehensive Onboarding & Activation Pack including:

1. Activation spec — Defined activation event with behavioral criteria and baseline metrics
2. First 30 seconds design — The immediate post-signup experience optimized for first value
3. First mile milestone plan — Stage-by-stage plan from signup through habit formation
4. Funnel map — Every step with expected conversion rates
5. In-app UX specifications — Checklists, tooltips, empty states, progress indicators
6. Email sequence copy — Welcome through re-engagement with timing and triggers
7. Experiment backlog — Prioritized list of onboarding experiments (impact/confidence/effort)
8. Measurement framework — Leading indicators, tracking plan, and success criteria
9. Risk documentation — Open questions, assumptions, and next-step recommendations

Onboarding Funnel Template

Stage 1: Signup -> Profile Setup            (Target: 90%+)
Stage 2: Profile Setup -> First Key Action  (Target: 60-70%)
Stage 3: First Key Action -> Aha Moment     (Target: 50-60%)
Stage 4: Aha Moment -> Habit Formation      (Target: 30-40%)

Frameworks & Best Practices

The Progressive Onboarding Framework

Structure onboarding in three layers that unlock sequentially:

1. Layer 1: Immediate Value (Minutes 0-5)

   • Get the user to one small win before asking for anything.
   • Pre-fill data where possible (import, templates, sample data).
   • Use empty states as onboarding — every blank screen should guide the next action.
   • Ask only for information required to deliver that first win. Defer everything else.

2. Layer 2: Core Setup (Day 1-3)

   • Introduce a checklist with 3-5 items (never more than 7). Show progress visually.
   • Each checklist item should unlock a visible capability ("Complete this to enable X").
   • Use contextual tooltips triggered by user behavior, not a grand tour on first login.
   • Send a Day 1 email reinforcing the first win and previewing the next step.

3. Layer 3: Expansion (Week 1-2)

   • Prompt team invites after the individual user has experienced value (not before).
   • Introduce advanced features through progressive disclosure, not feature dumps.
   • Trigger expansion prompts based on usage patterns, not arbitrary timelines.

Activation Event Benchmarks by Product Type

Inside-the-Product Onboarding

Prioritize onboarding that happens within the product experience itself, not detached from it. Product tours that overlay the UI without context are less effective than:

• Empty states that teach — Every blank screen guides the next action
• Inline prompts — Contextual guidance that appears when the user reaches a decision point
• Progressive disclosure — Reveal complexity as the user demonstrates readiness
• Sample data — Let users experience the product's value before investing their own data

Multi-Channel Coordination Rules

• In-app: Real-time guidance for active users. Checklists, tooltips, progress bars, empty state CTAs.
• Email: Async nudges for users who leave. Day 0 welcome, Day 1 reinforcement, Day 3 re-engagement, Day 7 value recap.
• Push/SMS: Reserve for high-intent signals only ("Your report is ready," "Your teammate just joined"). Never use for generic reminders.
• Suppression rule: If the user completed the action in-app, suppress the corresponding email. Nothing kills trust faster than "Complete your setup!" emails sent after setup is done.

Checklist Design Principles

• 3-5 items maximum. Completion rates drop sharply above 5.
• First item should be pre-completed. Starting with visible progress significantly increases completion rates (endowed progress effect).
• Each item takes under 2 minutes. If longer, break it into sub-steps.
• Show the reward. "Connect Slack -> Get instant notifications" not just "Connect Slack."
• Allow skipping with consequences. Let users skip but show what they lose.

Re-Engagement for Stalled Users

Diagnose before prescribing. Different stall points indicate different problems:

Quality Guardrails

All onboarding designs should include:

• Risk documentation identifying assumptions that could be wrong
• Open questions that need user research to answer
• Explicit next steps with owners and timelines
• Leading indicators to measure before waiting for retention data

Related Skills

• support-docs — Create help center articles and getting-started guides that support the onboarding flow
• email-marketing — Build the full lifecycle email program beyond onboarding (retention, expansion, win-back)
• churn-analysis — When onboarding completion data reveals early churn patterns needing deeper investigation

Examples

Example 1: Designing a new onboarding flow

User: "We're a B2B project management tool. Users sign up but only 20% create their first project. Help us fix onboarding."

Good output excerpt:

Activation Event: Create first project + add at least one task (correlates with 60-day retention).

First 30 Seconds Design: After signup, land on a pre-built sample project (not an empty dashboard). The user sees what the product looks like when populated. A single guided prompt says "Create your first real project" with 3 templates to choose from. After project creation, inline prompt to add a first task with an example. Celebration state: "Your project is live! Invite your team to collaborate."

Expected impact: Reducing pre-value steps from 4 to 2 should increase project creation from 20% to 45-55%.

Example 2: Activation is lagging

User: "We have 3,000 signups from last month and 60% never completed setup. How do we bring them back?"

Good output approach: Segment the 60% by where they stalled. Design different re-engagement emails for each stall point. Include subject lines, body copy, and CTAs linking directly to the abandoned step. Recommend a sunset policy (stop emailing after 30 days to protect deliverability). Build an experiment backlog testing different interventions at each stall point, prioritized by volume of stalled users and estimated recovery rate.

Partnership Outreach

When to Use

Activate when a founder needs to identify and reach out to potential partners, write partnership emails, propose integrations, or create co-marketing proposals. Also use when the user says "I want to partner with X," "help me write a BD email," "how do I propose an integration," "co-marketing opportunity," or "I need a channel partner strategy."

Context Required

From startup-context or the user:

• Your product and positioning — What you do and who you serve
• Partnership goal — Integration, co-marketing, reseller/channel, referral, or strategic alliance
• Target partner — Company name, relevant product/team, why they are a good fit
• Shared audience — The overlapping customer segment you both serve
• Your leverage — What you bring to the table (users, distribution, technology, content, brand)
• Current traction — Metrics that demonstrate your value as a partner (users, revenue, growth rate)

Workflow

1. Gather context — Read startup-context if available. Understand the product, traction, and partnership goals.
2. Identify partner fit — Use the Partner Evaluation Framework to assess whether this is a strong partnership opportunity.
3. Map the win-win — Define what each side gets from the partnership. If you cannot articulate both sides, the proposal will fail.
4. Find the right contact — Identify the BD, partnerships, or product person at the target company. Avoid generic inboxes.
5. Draft the outreach — Write the partnership email or LinkedIn message using the frameworks below.
6. Prepare the proposal — If the initial outreach gets a response, draft a lightweight partnership proposal (1-2 pages).
7. Define success metrics — Propose how both sides will measure whether the partnership is working.

Output Format

Deliver the appropriate materials based on the partnership stage:

• Partner evaluation — Fit assessment using the evaluation framework
• Initial outreach email/message — The first touch to the target partner
• Follow-up sequence — 2-3 follow-ups with different angles
• Partnership proposal — 1-2 page document outlining the partnership structure, mutual benefits, and next steps

Frameworks & Best Practices

Partner Evaluation Framework

Before reaching out, score the potential partner on these dimensions:

Score each dimension 1-5. A score of 20+ suggests a strong partnership opportunity. Below 15, reconsider whether it is worth pursuing.

Partnership Types and When to Use Each

Outreach Email Framework

Partnership emails differ from sales emails. You are proposing a collaboration, not selling a product. The tone should be peer-to-peer and the value proposition must be bilateral.

Structure: Shared Audience - Mutual Benefit - Proof - Lightweight Ask

1. Open with the shared audience — Show you understand who they serve and that you serve the same people
2. Name the mutual benefit — Be specific about what each side gains. Vague "synergies" get ignored.
3. Provide proof of your value — Traction metrics, shared customers, or a specific integration use case
4. Make a lightweight ask — Request a 20-minute call, not a signed partnership agreement

Email Principles for Partnership Outreach

• Lead with what you bring, not what you want. Partners care about your distribution, your users, and your brand — not your desire to partner.
• Be specific about the opportunity. "We should partner" means nothing. "30% of our 2,000 customers also use your product and have asked for an integration" means everything.
• Quantify when possible. Numbers make the opportunity tangible: user count, shared customers, potential revenue, audience size.
• Reference existing overlap. If you share customers, mention it. If their users have requested your product, say so. Evidence of demand is the strongest argument.
• Keep it short. 100-150 words for the initial email. The goal is to start a conversation, not close the deal.

Co-Marketing Proposal Structure

When proposing a co-marketing initiative, include:

1. Audience overlap analysis — Who you both serve and the size of the opportunity
2. Proposed initiative — Specific campaign: joint webinar, co-authored content, shared case study, cross-email promotion
3. Responsibilities — Who does what (be prepared to do more than half as the initiating party)
4. Lead sharing agreement — How captured leads will be distributed
5. Timeline — Proposed dates and milestones
6. Success metrics — How you will measure results (leads generated, registrations, content downloads)

Integration Pitch Framework

When proposing a product integration:

1. User demand signal — "X% of our users also use your product" or "We get asked about this integration Y times per month"
2. Technical feasibility — "Your API supports this and we have built similar integrations with Z"
3. User benefit — The specific workflow that becomes possible or better
4. Your investment — "We will build and maintain the integration on our side"
5. Their investment — "We would need API access and a technical contact for questions"
6. Distribution — "We will promote this to our X users and list on your marketplace"

Warm Introduction Strategy

Cold partnership emails work, but warm intros convert 3-5x better. Before going cold, check for shared investors, advisor connections, shared customers who could intro, or conference overlap. Engage with their content on LinkedIn before reaching out.

Follow-Up Sequence for Partnership Outreach

What to Avoid

• Vague partnership pitches. "We should explore synergies" gets deleted. Be specific about the opportunity.
• One-sided proposals. If your proposal mostly benefits you, the partner will see through it.
• Reaching out too early. If you have no traction, users, or distribution, you have nothing to bring to the table. Build first.
• Going to the wrong person. BD and partnership teams exist at most companies. Do not pitch the CEO of a 500-person company on a co-marketing webinar.
• Over-engineering the first conversation. The goal of the email is a 20-minute call. Do not send a 10-page partnership proposal as the first touch.
• Ignoring stage mismatch. A 5-person startup proposing a "strategic alliance" with a public company will not be taken seriously. Match your ask to your stage.

Related Skills

• cold-outreach — use for the underlying outreach mechanics (email structure, subject lines, follow-up cadence)
• proposal-generation — use when the partnership conversation advances to a formal proposal or agreement

Examples

Example prompt: "I want to reach out to Segment about building an integration. We are a customer data quality tool with 800 users. About 40% of our users also use Segment."

Good outreach email output:

Subject: segment integration — 320 shared users

Hi [Name],

We build [Product], a data quality tool used by about 800 companies. Roughly 40% of our users also use Segment, and "Segment integration" is our most-requested feature.

The integration would let shared customers automatically validate and clean data flowing through Segment before it hits downstream destinations — fewer bad records in warehouses and analytics tools.

We would build and maintain the integration on our end. We would need access to your partner API docs and a technical point of contact for a few questions.

Worth a 20-minute call to see if this makes sense?

Good partner evaluation output snippet:

Partner Fit: Segment

• Audience overlap: 5/5 — 40% of our users are Segment customers
• Complementary value: 5/5 — Data quality is a known pain point for Segment users; our products are better together
• Stage alignment: 3/5 — They are much larger, but they have an active partner/integration program
• Distribution leverage: 4/5 — Their marketplace and integrations page would give us significant visibility
• Strategic timing: 4/5 — They recently launched their new Protocols product, which aligns with data quality
• Total: 21/25 — Strong partnership opportunity

Pitch Deck

When to Use

• The founder is preparing a pitch deck for a fundraising round (pre-seed through Series A).
• The founder has an existing deck and wants structural or narrative feedback.
• The founder asks what slides to include or how to tell their story to investors.

Context Required

From startup-context: company one-liner, stage, product description, target customer, business model, traction metrics, team bios, fundraising history, and competitive landscape. If any of these are missing, prompt the founder before drafting slides.

From the user: target round size, target investor type (VC vs. angel), whether this is for a live pitch (fewer words, more visuals) or a send-ahead deck (more self-explanatory text).

Workflow

1. Read startup context — Pull from .agents/startup-context.md to populate slide content. Flag any gaps.
2. Determine deck type — Ask if this is a live-pitch deck (visual-heavy, 30-40 words per slide max) or a send-ahead deck (can include more explanatory text, 60-80 words per slide).
3. Draft the narrative arc — Before writing any slides, outline the story: what is the world like today (problem), what changes with your product (solution), why now, why this team, and what you need to get there.
4. Write slide-by-slide content — Produce content for each of the 10-12 slides below. Each slide gets a title, key message, supporting points, and a suggested visual or data element.
5. Review for investor lens — Check every slide against the question an investor would ask at that point. Flag weak spots.
6. Produce final output — Deliver the deck outline as structured markdown. If the user wants a .pptx, chain to the Anthropic pptx skill after content is finalized.

Output Format

Structured markdown with one H3 per slide. Each slide section contains:

• Title: The slide headline (concise, assertion-style, e.g., "Healthcare billing wastes $200B annually")
• Key message: The one thing the audience should remember from this slide
• Content: Bullet points or narrative text
• Visual suggestion: What chart, image, screenshot, or diagram belongs here
• Investor question this answers: The implicit question in the VC's mind

Frameworks & Best Practices

The 10-12 Slide Framework

Narrative Arc Rules

• Slide 1-3: Establish tension. The audience should feel the problem before you show the answer.
• Slide 4-7: Build credibility. Prove you have a real product with real traction in a real market.
• Slide 8-10: Prove defensibility. Show you can win against alternatives and scale.
• Slide 11-12: Make the ask and paint the vision. End with ambition, not logistics.

Stage-Specific Guidance

• Pre-seed / Seed: Emphasize problem depth, founder-market fit, and early signals (waitlist, LOIs, design partners). Financial projections can be lighter.
• Series A: Emphasize repeatable go-to-market, unit economics, and a clear path from current traction to 3-5x growth. Investors expect real revenue data.

Principles

• Every slide title should be an assertion, not a label. "We grew 30% MoM for 6 months" beats "Traction".
• Remove any slide that does not advance the narrative. If you cannot articulate why a slide exists, cut it.
• The deck should be understandable by a partner who reads it at 11pm on their iPad without you presenting.
• Use no more than 3 fonts and 2 brand colors. Clutter kills credibility.
• Data beats adjectives. Replace "fast-growing" with "3x YoY".

Related Skills

• investor-research — use before building the deck to tailor the narrative to specific investor interests
• data-room — prepare the backup materials investors will request after seeing the deck
• fundraising-email — write the outreach email that accompanies the deck

Examples

Example prompt: "Help me build a seed deck. We're raising $3M for an AI-powered contract review tool for mid-market legal teams. We have $40K MRR and 12 paying customers."

Good output snippet (Problem slide):

Slide 2: Problem

Title: Mid-market legal teams review 500+ contracts/month with 1990s tools Key message: Contract review is the #1 time sink for legal teams at companies with 200-2,000 employees, costing $180K+/year in paralegal hours per company. Content:

• 73% of mid-market companies still use manual redlining in Word
• Average contract review takes 45 minutes; 30 minutes is repetitive clause checking
• Errors in reviewed contracts cost companies 2-5% of deal value annually Visual suggestion: Side-by-side showing a paralegal buried in Word docs vs. your product highlighting risks in seconds Investor question this answers: Is this a real, painful, expensive problem?

Example prompt: "Review my existing deck — I keep getting passed on after the first meeting."

Good output approach: Read the deck, identify which of the 12 slides are missing or weak, check if the narrative arc has tension, and test every slide against the investor-question framework. Deliver specific rewrites, not vague advice.

PRD Writing

When to Use

Activate when a founder or PM needs to turn a product idea, feature request, or strategic initiative into a structured Product Requirements Document. This includes situations where the user says things like "write a PRD," "spec out this feature," "define requirements for X," or "I need to document what we're building."

Context Required

• From startup-context: company stage, target customer segments, current product state, team size, technical constraints.
• From the user: the feature or initiative to spec, known user problems it addresses, any prior research or customer feedback, desired timeline, and scope preference (lightweight vs. full PRD).

Workflow

1. Clarify scope level -- Ask whether this needs a lightweight PRD (early-stage exploration, 2-3 pages) or a full PRD (committed initiative, 5-8 pages). Default to lightweight if the company is pre-product-market-fit.
2. Gather inputs -- Collect the problem statement, target users, any existing research, success criteria, and known constraints. Identify key contacts and their roles.
3. Draft the 8-section PRD -- Write each section sequentially using the template below. Use accessible language suitable for a broad audience including engineering, design, and leadership.
4. Flag assumptions -- Explicitly list key assumptions underlying each section. For each, state what evidence supports it and what would invalidate it.
5. Review and refine -- Present the draft, invite feedback, and iterate on specific sections. State the PRD version and last-updated date.

Output Format

A structured PRD document with 8 sections:

Section Template

1. Summary -- 2-3 sentence overview of what is being built and why it matters. Write for a broad audience.
2. Contacts -- Key stakeholders with their roles and relevant context about their involvement.
3. Background -- Context on the problem space: why now, what changed, what enables this initiative. Include competitive context on how others handle the same problem.
4. Objective -- Goals, business and customer benefits, and strategic alignment. Define SMART success metrics tied to OKRs. Use the format: "Enable [user segment] to [action] resulting in [measurable outcome]."
5. Market Segment(s) -- Define target users by problems and needs, not demographics. Describe primary and secondary segments with size estimates.
6. Value Proposition(s) -- Map customer jobs addressed, gains provided, and pain points eliminated. Show competitive differentiation using frameworks like Value Curve analysis.
7. Solution -- Feature descriptions, UX/prototypes, wireframes, user flows, and technology details when relevant. Include out-of-scope items explicitly. Document assumptions. Enumerate at least 5 edge cases.
8. Release -- Phased rollout plan using relative timeframes (not exact dates). Define MVP vs. future iterations, feature flags, rollback criteria, and review checkpoints.

For lightweight PRDs, sections 2, 3, and 8 can be condensed to 2-3 sentences each.

Frameworks & Best Practices

• Problem before solution. Spend 40% of the document on sections 1-5 (the "why") before touching section 7 (the "what"). A PRD that jumps to the solution is a spec, not a PRD.
• One objective, not five. A PRD with multiple objectives is multiple PRDs. Split them. Each PRD should have a single primary metric it moves.
• Market segments defined by needs. Describe who this is for based on the problems they face and jobs they hire the product to do, not by demographics or firmographics alone.
• Value Proposition clarity. For each segment, explicitly state the customer jobs addressed, gains provided, and pains eliminated. Use the Value Curve to show where you differentiate from competitors.
• Data-driven specificity. Replace vague language with specific numbers. "Improve retention" is not a metric; "Increase D7 retention from 25% to 35% within 8 weeks of launch" is.
• Scope creep guard. Explicitly list what is NOT in scope. Revisit the out-of-scope list when stakeholders propose additions.
• Relative timeframes over dates. Use phases and relative windows rather than exact calendar dates. This prevents false precision and allows flexibility.
• Assumption tracking. List the top 3 assumptions underlying the PRD. For each, state supporting evidence and what would invalidate it.
• Audience awareness. Engineers need technical constraints and edge cases. Designers need user flows and personas. Executives need the summary and metrics. Write for all three in a single document.
• Living document. State the PRD version and last-updated date. PRDs that never change were never read.
• Lightweight PRD triggers: pre-PMF exploration, hackathon projects, internal tools, experiments with <2 week timelines.
• Full PRD triggers: cross-team initiatives, features with external dependencies, anything touching payments or compliance.

Related Skills

• roadmap-planning -- Chain after writing PRDs to slot the initiative into the broader roadmap with dependencies and timelines.
• mvp-scoping -- Chain before writing a PRD to determine what to include in v1 vs. defer to later releases.
• user-research-synthesis -- Chain before writing a PRD to ground the Background and Market Segments sections in real customer data.

Examples

Example 1: Lightweight PRD prompt

User: "We need a PRD for adding Slack notifications to our project management tool."

Good output excerpt:

Summary: Add configurable Slack notifications so that teams using ProjectFlow are alerted to task updates, mentions, and deadline changes without leaving their primary communication tool. This addresses the #1 feature request from our Q3 customer survey (38% of respondents).

Objective: Enable team leads on paid plans to receive real-time project updates in Slack, resulting in a 20% reduction in average response time to task assignments within 6 weeks of launch.

Market Segment: Teams of 10+ coordinating across tools, whose primary pain is context-switching between project management and communication platforms.

Out of scope: Microsoft Teams integration, custom notification templates, Slack bot commands.

Example 2: Full PRD prompt

User: "Write a full PRD for our new self-serve onboarding flow. We're losing 60% of signups before they complete setup."

Good output excerpt:

Background: Current onboarding requires 7 steps and takes an average of 12 minutes. Hotjar recordings show 45% of users abandon at the "connect data source" step. Competitor X reduced their onboarding to 3 steps in Q2 and reported a 2x improvement in activation. Our support team handles 30+ onboarding tickets per week, costing approximately $4,500/month.

Value Proposition: Eliminate the "connect data source" friction by offering a sample dataset that lets users experience core value before committing to integration. Differentiated from Competitor X which still requires immediate data connection.

Release:

• Phase 1: Internal dogfood with the team (2 weeks)
• Phase 2: 10% of new signups via feature flag
• Phase 3: 50% rollout if activation rate > 45%
• Phase 4: GA if no P0 bugs and support ticket volume decreases
• Rollback trigger: activation rate drops below current 40% baseline

Privacy Policy

When to Use

Activate when a founder needs to create a privacy policy for a new product launch, update an existing policy for new data practices or features, expand into a new jurisdiction (EU, California, etc.), or assess whether current data handling is properly disclosed. Also activate when the user asks about GDPR, CCPA, CPRA, or general data privacy compliance.

Context Required

• From startup-context: product type, platform (web/mobile/API), target customer segments, geographic markets, business model, tech stack.
• From the user: product name and URL, company legal name and address, contact email for privacy inquiries, what personal data is collected and how, which third-party services process data (analytics, payment processors, CRMs, AI providers), applicable jurisdictions, whether the product targets minors, and any existing privacy documentation.

Workflow

1. Research the product -- Visit the product website or review the product description. Identify all data collection methods, third-party integrations, and primary features that involve personal data.
2. Map data collection -- Categorize all data into: directly provided (forms, account creation), automatically collected (cookies, device info, usage data, IP addresses), third-party sources, and special/sensitive categories. Build a structured data inventory.
3. Identify applicable laws -- Based on where users are located and where the company operates, determine which privacy frameworks apply: GDPR, CCPA/CPRA, state privacy laws, COPPA, industry-specific regulations. Note specific obligations per jurisdiction.
4. Structure the policy -- Organize using the 15-section template below. Write in plain language at an 8th-grade reading level. Be specific about actual practices -- say "We collect your email address when you sign up" rather than "We may process identifiers."
5. Flag legal review areas -- Mark sections requiring attorney review with [LEGAL REVIEW REQUIRED] notation. These include legal basis determinations, international transfer mechanisms, and jurisdiction-specific rights.
6. Provide implementation context -- Explain why each section matters, what company decisions are needed, and what compliance considerations apply. Include a pre-publication checklist.
7. Generate compliance summary -- Produce a separate document with data inventory table, jurisdiction applicability matrix, risk flags, and implementation checklist.

Output Format

Three-part deliverable:

Part 1: Quick Reference Summary

Product details, data types collected, applicable jurisdictions, user rights summary, retention overview, and contact information.

Part 2: Full Policy Document (15 sections)

1. Preamble -- Who you are, what this policy covers, effective date, contact methods.
2. Information We Collect -- Categories: personal info, usage data, device information, location, payment info, communications, sensitive data.
3. How We Collect Information -- Methods: direct entry, automatic tracking, third parties.
4. How We Use Information -- Purposes: service provision, support, improvements, analytics, marketing, security, legal compliance.
5. Legal Basis for Processing -- Consent, contract performance, legal obligation, vital interests, legitimate interests (GDPR-focused).
6. Data Sharing and Third Parties -- Service providers, partners, legal authorities, with specifics on who and why.
7. International Data Transfer -- Cross-border transfer mechanisms (SCCs, adequacy decisions), storage locations.
8. Data Retention -- Specific timeframes for account data, logs, deleted content.
9. User Rights -- Access, deletion, correction, restrict processing, portability, opt-out, complaint procedures -- organized by jurisdiction.
10. Cookies and Tracking -- Tools used, purposes, management options, consent requirements.
11. Security -- Encryption, access controls, audits, incident response, limitations.
12. Children's Privacy -- Parental consent, age gates, COPPA/UK Children's Code compliance.
13. Contact and Rights Requests -- Privacy email, address, response timeframes, DPO info.
14. Policy Changes -- Notice period, notification methods, user opt-out options.
15. Additional Provisions -- Data sale disclosure, third-party link disclaimers, governing law, effective date.

Part 3: Compliance Notes

• Sections flagged for legal review with rationale
• Jurisdiction-specific considerations
• Pre-publication checklist (see below)
• Recommended modifications by product type

Frameworks & Best Practices

GDPR Core Requirements

• Lawful basis required for each processing activity (Art. 6).
• Data Protection Impact Assessment for high-risk processing (Art. 35).
• 72-hour breach notification to supervisory authority (Art. 33).
• Data Processing Agreements with all processors (Art. 28).
• Right to erasure with defined exceptions (Art. 17).
• Privacy by design and by default (Art. 25).

CCPA/CPRA Core Requirements

• "Do Not Sell or Share My Personal Information" link required if applicable.
• Right to know, delete, correct, and opt out of sale/sharing.
• 12-month lookback for data collection disclosures.
• Sensitive personal information: right to limit use (CPRA addition).
• Service provider vs. contractor vs. third party distinctions matter.

Plain Language Principles

• Write at an 8th-grade reading level with short sentences.
• Use concrete examples instead of abstract categories.
• Avoid "may" when you mean "do." Be specific about actual practices.
• The policy must match what your product actually does -- no over-disclosure and no under-disclosure.

Pre-Publication Checklist

• Attorney review completed
• Policy matches actual data practices
• User privacy request processes are accessible and functional
• Technical security measures implemented
• Data Processing Agreements in place with all third parties
• Legal basis documented for each processing activity
• Cookie consent mechanism implemented (EU users)
• User notification system for material policy changes

Common Startup Pitfalls

• Copying another company's privacy policy (their data practices are not yours).
• Missing analytics and advertising SDKs in disclosures (Google Analytics, Mixpanel, Facebook Pixel all collect personal data).
• No mechanism to actually fulfill deletion requests in the codebase.
• Assuming B2B means no privacy obligations (you still process individual user data).
• Listing data categories you do not actually collect (over-disclosure invites scrutiny).

Related Skills

• terms-of-service -- Draft alongside the privacy policy; they should cross-reference each other and use consistent definitions.
• soc2-prep -- SOC 2 Trust Service Criteria for Privacy directly overlaps with privacy policy commitments.
• security-review -- Security measures described in the privacy policy must reflect actual technical controls.

Examples

Example 1: New SaaS product launching in US and EU

User: "We're launching our project management SaaS next month with users from the US and Europe. We use Stripe, Mixpanel, and AWS."

Good output: A three-part deliverable. The data inventory table mapping each data category to collection method, purpose, legal basis, third parties, and retention. Jurisdiction analysis identifying GDPR applicability and CCPA threshold monitoring. Red flags for Mixpanel IP collection needing disclosure and DPA, and missing cookie consent mechanism for EU users.

Example 2: Updating policy after adding AI features

User: "We added an AI assistant that processes customer messages. Do we need to update our privacy policy?"

Good output: Identifies the new data processing (message content processed by AI models), new third party (AI provider as sub-processor), new legal basis analysis needed, and GDPR Art. 22 consideration for automated decision-making. Provides the specific policy sections that need updating with draft language.

Disclaimer: This skill generates draft privacy policies and compliance guidance for educational and planning purposes only. It does not constitute legal advice. Always have a qualified attorney licensed in your relevant jurisdictions review the final privacy policy before publication. Regulatory non-compliance can result in significant fines (up to 4% of global annual revenue under GDPR).

Process Documentation

When to Use

Activate when a founder or operator needs to document an internal process so it can be executed consistently by anyone on the team. This includes prompts like "write an SOP for X," "create a runbook for incident response," "document our onboarding playbook," "how do we standardize this process," or any request to turn tribal knowledge into a repeatable procedure.

Context Required

• From startup-context: company stage, team size, current tools and systems, organizational structure, compliance requirements.
• From the user: the process to document, who owns and executes it, current pain points or failure modes, frequency of execution, tools involved, and whether this replaces an existing (undocumented) process or is net-new.

Workflow

1. Identify document type — Determine whether this is an operational SOP (routine procedure), an incident runbook (reactive response), or an onboarding playbook (sequential learning path). Each uses a different template.
2. Map the process end-to-end — Walk through every step from trigger event to completion. Identify inputs, outputs, decision points, handoffs, and escalation paths.
3. Define ownership and RACI — Assign a single owner (Responsible), identify who Approves, who is Consulted, and who is Informed for each major step.
4. Draft the document — Write using the appropriate template below. Use imperative voice ("Open the dashboard," not "The dashboard should be opened").
5. Add decision trees — For any step with conditional logic, create explicit if/then branches. Never leave ambiguity at a fork.
6. Include failure modes — Document what to do when each step fails. A process doc without error handling is incomplete.
7. Set review cadence — Specify when this document should be reviewed and by whom (e.g., quarterly by the process owner).

Output Format

A structured markdown document following one of the three templates below. Every process doc includes a metadata header, and the body is written so that someone with no prior context can execute the process end-to-end.

Template 1: Operational SOP

# [Process Name] — Standard Operating Procedure
**Owner:** [Name / Role]
**Last Updated:** [Date]
**Review Cadence:** [Quarterly / Monthly]
**Version:** [1.0]

## Purpose
Why this process exists and what business outcome it supports.

## Scope
What this SOP covers and explicitly does not cover.

## Prerequisites
Tools, access, permissions, or context needed before starting.

## Procedure
1. Step with specific action
   - Sub-step with detail
   - **Decision point:** If [condition], go to Step X. Otherwise continue.
2. Next step...

## Escalation Path
| Condition | Escalate To | SLA |
|-----------|------------|-----|
| [Trigger] | [Person/Role] | [Timeframe] |

## Success Criteria
How to verify the process was completed correctly.

## Changelog
| Date | Author | Change |
|------|--------|--------|

Template 2: Incident Runbook

# [Incident Type] — Runbook
**Severity:** [P0-P3]
**On-Call Owner:** [Role]
**Last Tested:** [Date]

## Detection
How this incident is identified (alerts, customer reports, monitoring).

## Immediate Actions (First 5 Minutes)
1. Triage step...
2. Communication step...

## Diagnosis
Decision tree for identifying root cause.

## Resolution Steps
Step-by-step fix for each known root cause.

## Post-Incident
Checklist for after the incident is resolved.

Template 3: Onboarding Playbook

# [Role/Process] — Onboarding Playbook
**Duration:** [e.g., 2 weeks]
**Buddy/Owner:** [Role]

## Day 1-2: Orientation
Tasks, access setup, key introductions.

## Day 3-5: Core Training
Hands-on exercises, shadowing, tool walkthroughs.

## Week 2: Guided Practice
Supervised execution of real tasks with checkpoints.

## Graduation Criteria
What the person must demonstrate to be considered onboarded.

Frameworks & Best Practices

• The "bus factor" test. If the person who usually runs this process is unavailable, can someone else execute it from this document alone? If not, add more detail.
• Imperative voice only. Every step starts with a verb. "Click the Deploy button" not "The Deploy button should be clicked."
• One action per step. If a step contains "and," split it into two steps. Compound steps get skipped or half-done.
• Decision points are explicit. Use if/then language with clear conditions. "If the customer is on an Enterprise plan, skip to Step 7" not "Handle enterprise customers differently."
• Time estimates matter. Include expected duration for each major phase. This helps people plan and signals when something has gone wrong (step taking 3x longer than expected = escalate).
• Screenshots decay fast. Prefer text descriptions of UI paths (Settings > Integrations > Slack) over screenshots, which break every redesign. Use screenshots only for genuinely complex interfaces.
• Version and date everything. A process doc without a last-updated date is assumed to be wrong.
• Progressive detail. Lead each section with a one-line summary, then expand. Experienced operators scan; new hires read every word. Serve both.
• Link, don't duplicate. If another SOP covers a sub-process, link to it rather than copying steps inline. Duplication causes drift.
• Test with a newcomer. The best review is having someone unfamiliar with the process follow the doc and noting where they get stuck.

Related Skills

• support-docs — Chain when the process being documented is customer-facing and needs a corresponding help center article or troubleshooting guide.
• board-update — Chain when operational processes need to be summarized for investor or board reporting (e.g., "here is our incident response maturity").

Examples

Example 1: Operational SOP

User: "Write an SOP for processing customer refunds."

Good output excerpt:

Procedure

1. Open the refund request in Zendesk. Verify the ticket includes: order ID, reason for refund, and customer email.
2. Check eligibility in Stripe.
   • Decision point: If the order is older than 30 days, escalate to the Support Lead with a note explaining the customer's situation. Do not process the refund.
   • If within 30 days, continue to Step 3.
3. Issue the refund via Stripe Dashboard > Payments > [Order ID] > Refund. Select "Full refund" unless partial was approved by the Support Lead.
4. Update the ticket with the Stripe refund ID and set status to "Solved."
5. Log the refund in the Refund Tracker spreadsheet (column A: date, B: order ID, C: amount, D: reason code).

Estimated time: 5-8 minutes per refund.

Example 2: Incident Runbook

User: "We need a runbook for when our payment processing goes down."

Good output excerpt:

Immediate Actions (First 5 Minutes)

1. Acknowledge the alert in PagerDuty to stop re-escalation.
2. Check Stripe Status Page (status.stripe.com). If Stripe reports an outage, skip to "External Provider Outage" section.
3. Post in #incidents Slack channel: "Investigating payment processing failures. Updates every 15 min. DRI: [your name]."
4. Enable the maintenance banner via Admin > Feature Flags > payment_maintenance_mode = true. This shows users "Payments temporarily unavailable, please retry shortly" instead of raw errors.

Proposal Generation

When to Use

• Starting a new client engagement and need a contract or proposal fast
• Client asks for a proposal with pricing and timeline
• Partnership or vendor relationship requiring an MSA
• Protecting IP or confidential information with an NDA
• Need a Statement of Work with a deliverables matrix
• EU/DACH project requiring GDPR-compliant data clauses

Context Required

From startup-context or the user:

• Document type — Contract, proposal, SOW, NDA (mutual/one-way), or MSA
• Jurisdiction — US (Delaware), EU (GDPR), UK (post-Brexit), or DACH (German law)
• Engagement type — Fixed-price, hourly, or retainer
• Parties — Names, roles, business addresses
• Scope summary — 1-3 sentences describing the engagement
• Financial terms — Total value, hourly rate, or retainer amount
• Timeline — Start date, end date or duration, milestone dates
• Special requirements — IP assignment, white-label, subcontractors, exclusivity

Workflow

1. Gather requirements — Read startup-context if available. Collect all eight inputs listed above. Flag any missing item as REQUIRED.
2. Select document type — Match the engagement to the right format: fixed-price contract, consulting retainer, SaaS partnership, NDA, SOW, or full proposal.
3. Apply jurisdiction rules — Select clause variants based on governing law. US uses work-for-hire doctrine; EU requires explicit IP assignment deeds; DACH requires transfer of Nutzungsrechte since authors retain moral rights under BGB.
4. Draft the document — Fill all sections using structured Markdown with bracketed placeholders for client-specific data. Include the key clauses table below.
5. Add GDPR addendum if needed — For EU/DACH engagements handling personal data, attach a Data Processing Addendum per Art. 28 GDPR covering data categories, sub-processors, and cross-border transfer mechanisms.
6. Review for common pitfalls — Check for missing IP assignment language, vague acceptance criteria, no change order process, jurisdiction mismatches, and missing liability caps.
7. Provide conversion instructions — Include Pandoc commands for DOCX output with legal-style numbered sections.

Output Format

Deliver a complete document in structured Markdown containing:

1. Header block — Effective date, party names, addresses
2. Services / scope — Detailed deliverables with acceptance criteria and dates
3. Payment terms — Milestone-based, net-30, or retainer schedule with late payment interest
4. Intellectual property — Ownership assignment, pre-existing IP licenses, portfolio rights
5. Confidentiality — Duration (2-5 years standard, perpetual for trade secrets)
6. Warranties — As-is disclaimer or limited fix warranty (30/90-day)
7. Liability cap — 1x contract value standard, 3x for high-risk engagements
8. Termination — For cause (14-day cure) and for convenience (30/60/90-day notice)
9. Dispute resolution — Jurisdiction-appropriate arbitration (AAA/ICC/LCIA/DIS)
10. Signature block — Both parties with date lines

Frameworks & Best Practices

Key Clauses Reference

Jurisdiction-Specific Rules

• US (Delaware): Work-for-hire doctrine applies under Copyright Act 101. Arbitration via AAA Commercial Rules. Non-competes enforceable with reasonable scope/time.
• EU (GDPR): Must include Data Processing Addendum for any personal data. IP assignment may require separate written deed. Arbitration via ICC.
• UK (post-Brexit): Governed by English law. IP under Patents Act 1977 / CDPA 1988. UK GDPR applies. Arbitration via LCIA Rules.
• DACH: BGB governs contracts. Written form required for certain clauses (para 126 BGB). Authors retain moral rights — must explicitly transfer Nutzungsrechte. Non-competes max 2 years with compensation required (para 74 HGB). Include Schriftformklausel.

Pricing Presentation Strategy

Present three tiers to anchor the prospect and make the middle option feel natural:

Always lead with value before cost. Show ROI math: "This investment of $X saves $Y, paying for itself in Z months."

SOW-Specific Guidance

A Statement of Work is operational, not persuasive. Key sections:

• Deliverables table — Each deliverable gets a row: description, acceptance criteria, delivery date
• RACI matrix — Roles and responsibilities for each workstream
• Change management — How to handle scope changes and the approval process
• Payment schedule — Tied to milestones, not just calendar dates
• Assumptions — Conditions the timeline and price depend on

Common Pitfalls

1. Missing IP assignment language — "Work for hire" alone is insufficient in EU; DACH needs explicit Nutzungsrechte transfer
2. Vague acceptance criteria — Always define what "accepted" means with written sign-off and rejection windows
3. No change order process — Scope creep kills fixed-price projects; add a clause for out-of-scope work
4. Jurisdiction mismatch — Choosing Delaware law for a German-only project creates enforcement problems
5. Missing liability cap — Without a cap, one bug could mean unlimited damages
6. Oral amendments — Always require written amendments signed by both parties

Disclaimer: Not a substitute for legal counsel. Use these as strong starting frameworks; review with an attorney for high-value or complex engagements.

Related Skills

• sales-script — Use for the sales conversations that precede the proposal
• cold-outreach — Use to generate the initial conversations that lead to proposal-stage deals

Examples

Prompt: "I need a fixed-price contract for a $45K web app project with a German client."

Good output snippet:

# SOFTWARE DEVELOPMENT AGREEMENT

Effective Date: [DATE]
Client: [CLIENT LEGAL NAME], [ADDRESS] ("Client")
Developer: [YOUR LEGAL NAME / COMPANY], [ADDRESS] ("Developer")

Governing Law: German law (BGB)
Arbitration: DIS Rules, [CITY]

## 2. PAYMENT
Total Fee: EUR 45,000

| Milestone | Amount | Due |
|-----------|--------|-----|
| Contract signing | 50% (EUR 22,500) | Upon execution |
| Beta delivery | 25% (EUR 11,250) | [DATE] |
| Final acceptance | 25% (EUR 11,250) | Within 5 days of acceptance |

## 3. INTELLECTUAL PROPERTY
Upon receipt of full payment, Developer assigns all Nutzungsrechte
(usage rights) in the Work Product to Client. Developer retains moral
rights per German copyright law (UrhG).

Review Mining

When to Use

• Founder wants to understand real user pain points for a market or competitor product
• Founder wants voice-of-customer language to use in copy, emails, or pitch decks
• Founder wants to validate a product idea by finding recurring complaints
• Founder wants to identify gaps competitors aren't solving
• Founder wants to build a feature comparison based on what users actually care about

Context Required

• Competitor names or product category to research
• Review platforms to mine (Trustpilot, G2, Capterra, Product Hunt, App Store, Play Store, Reddit)
• What the founder is trying to learn (pain points, switching triggers, feature gaps, use cases)
• The founder's own product positioning (to identify opportunities)

Workflow

1. Define research scope — identify 3-5 competitors or products to analyze and which platforms have the most relevant reviews for the category (B2B → G2/Capterra, B2C → Trustpilot/App Store, developer tools → Reddit/HN).
2. Collect reviews — gather 1-3 star reviews (pain points) and 4-5 star reviews (what users love and would miss). Focus on reviews from the last 12 months for relevance. Aim for 50-100 reviews per competitor.
3. Extract pain point themes — categorize complaints into recurring themes. For each theme, capture:
   • The pain point in the user's own words (verbatim quotes)
   • Frequency (how many reviews mention it)
   • Severity (annoyance vs. deal-breaker vs. switching trigger)
   • Which competitor(s) it applies to
4. Extract switching triggers — find reviews where users explicitly say why they left or are considering leaving. These are gold for positioning and outreach.
5. Extract "jobs to be done" — from positive reviews, identify what users are actually hiring the product to do (often different from what the product markets itself as).
6. Map to opportunities — cross-reference pain points against your product's capabilities. Identify where you solve problems competitors don't.
7. Generate artifacts — produce the pain point report, voice-of-customer swipe file, and positioning recommendations.

Output Format

## Review Mining Report: [Category/Competitors]

### Research Scope
- Competitors analyzed: [list]
- Platforms: [list]
- Reviews analyzed: [count]
- Date range: [range]

### Top Pain Points (ranked by frequency x severity)

#### 1. [Pain Point Theme] — mentioned in [X]% of negative reviews
- **Severity:** [Annoyance / Frustration / Deal-breaker / Switching trigger]
- **Competitors affected:** [list]
- **User quotes:**
  - "[verbatim quote]" — [platform], [star rating]
  - "[verbatim quote]" — [platform], [star rating]
- **Your opportunity:** [how your product addresses or could address this]

#### 2. [Pain Point Theme] ...

### Switching Triggers
| Trigger | Frequency | From → To | Quote |
|---------|-----------|-----------|-------|
| ... | ... | ... | ... |

### Voice of Customer Swipe File
**Words users use for the problem:** [list of exact phrases]
**Words users use for the desired outcome:** [list of exact phrases]
**Emotional language:** [frustration words, relief words]

### Positioning Opportunities
- [Opportunity 1]: [what you can claim based on competitor weakness]
- [Opportunity 2]: [underserved use case you can own]

Frameworks & Best Practices

Where to mine by product type:

Review analysis principles:

• 1-2 star reviews reveal deal-breakers and switching triggers
• 3 star reviews reveal "good enough but frustrated" — the most persuadable users
• 4-5 star reviews reveal what users truly value (defend these in your product)
• Recent reviews (last 6-12 months) matter more than old ones
• Verified purchase/user reviews carry more weight

Verbatim language is the output. The exact words users use to describe their pain are more valuable than your summary. These become headlines, email subject lines, ad copy, and landing page copy.

Common mistakes:

• Only reading negative reviews (you miss what users actually value)
• Summarizing instead of quoting (you lose the authentic language)
• Treating all complaints equally (frequency x severity matters)
• Ignoring the context of who's reviewing (enterprise vs SMB, power user vs casual)
• Mining once and never returning (do this quarterly)

Related Skills

• competitive-analysis — for broader competitor research beyond reviews
• user-research-synthesis — for synthesizing your own customer interviews
• feedback-synthesis — for analyzing feedback from your own users
• cold-outreach — use voice-of-customer language in prospecting emails

Examples

Prompt: "I'm building a project management tool. What are the biggest pain points people have with Asana and Monday.com?"

Good output includes: Mining Trustpilot, G2, and Capterra for Asana and Monday.com, extracting the top 5-7 pain points with verbatim quotes, identifying switching triggers, and mapping them to positioning opportunities.

Prompt: "We're a Trustpilot alternative. Help me understand what businesses hate about Trustpilot."

Good output includes: Mining Trustpilot's own reviews (meta!), G2, and Reddit for complaints about Trustpilot, extracting themes like review gating, pricing, fake review handling, and producing a voice-of-customer swipe file the founder can use in outreach.

Roadmap Planning

When to Use

Activate when a founder or PM has a set of product ideas, feature requests, or strategic bets and needs to organize them into a coherent roadmap. This includes situations like "help me plan our Q2 roadmap," "prioritize this feature backlog," "what should we build next," or "create a roadmap for the next 6 months." Also activate when an existing roadmap needs restructuring from output-focused (feature lists) to outcome-focused (customer and business impact).

Context Required

• From startup-context: company stage, team size and composition, current product state, business model, key metrics, strategic goals, company OKRs.
• From the user: current roadmap or list of candidate initiatives, known customer needs, resource constraints, hard deadlines, strategy documents or company objectives for alignment, and any committed work already in progress.

Workflow

1. Gather the current state -- Collect the existing roadmap or feature list. If the user provides strategy documents or company objectives, review them to understand how the roadmap should align with broader goals.
2. Transform outputs to outcomes -- For each initiative, ask: What customer problem are we solving? What business metric will improve? Is there a better way to achieve the same outcome? Rewrite each item as an outcome statement.
3. Apply outcome statement format -- Use: "Enable [customer segment] to [desired customer outcome] so that [business impact]." Every roadmap item must pass this test.
4. Score and prioritize -- Apply RICE scoring (Reach, Impact, Confidence, Effort) to rank initiatives. Adjust for strategic alignment with company objectives and OKRs.
5. Identify dependencies and sequencing -- Map which initiatives depend on others. Note technical, data, design, and business dependencies.
6. Sequence into time horizons -- Place initiatives into Now (0-6 weeks), Next (6-12 weeks), and Later (12+ weeks). Use flexible release windows (quarters, not specific dates) for Later items.
7. Validate capacity -- Cross-check the plan against team capacity. A roadmap that requires 3x your engineering bandwidth is a wishlist, not a plan.
8. Add strategic context -- Document how outcomes align with company strategy, key assumptions about customer needs, and review cadence.

Output Format

Strategic Context

One paragraph restating the company's current strategic priorities and how this roadmap serves them. Include key assumptions about customer needs.

Outcome-Focused Roadmap

Now (0-6 weeks) -- Committed

Next (6-12 weeks) -- High Confidence

Same table format. Items here are planned but may shift based on learnings from Now.

Later (12+ weeks) -- Exploratory

Same table format. Items here are directional. Flexible time windows, no owners assigned yet.

Not Doing (and Why)

Initiatives explicitly excluded with reasoning. This section is as important as the roadmap itself.

Dependency Map

Visual or textual representation of which initiatives block or enable others.

Capacity Check

Summary of estimated effort vs. available capacity per time horizon.

Key Assumptions and Risks

Numbered list of what must be true for this roadmap to succeed.

Frameworks & Best Practices

• Outcomes over outputs. "Build advanced search filters" is an output. "Enable customers to find products 50% faster through intuitive discovery" is an outcome. Output-focused roadmaps create false precision and misalign teams around features rather than results.
• The outcome statement format. "Enable [customer segment] to [desired customer outcome] so that [business impact]." This forces clarity on who benefits, what changes, and why it matters.
• The "So What?" test. If you cannot articulate the outcome a feature drives, keep asking "So what?" until you reach real customer or business value. Multiple outputs may achieve one outcome -- focus on the outcome.
• RICE scoring.
  • Reach: How many users/accounts will this affect per quarter?
  • Impact: On a scale of 0.25 (minimal) to 3 (massive), how much will this move the target metric?
  • Confidence: As a percentage, how sure are you about reach and impact estimates?
  • Effort: Person-weeks required.
  • Score: (Reach x Impact x Confidence) / Effort.
• Three-horizon structure. Now/Next/Later avoids the false precision of Gantt charts. Commit to Now, plan for Next, explore Later.
• Outcome roadmaps are resilient to change. Because they describe the "why" rather than the "what," they survive strategy pivots and new information better than feature roadmaps.
• Say no explicitly. A roadmap is defined as much by what it excludes. Maintain a "Not Doing" list and share the reasoning.
• Align with OKRs. Every outcome statement should map to a company or product OKR. Orphan initiatives signal misalignment.
• Revisit quarterly. Roadmaps older than one quarter are stale. Build in review cadences.
• Stage-appropriate planning.
  • Pre-PMF: Roadmaps should be 4-6 week sprints focused on learning. No 12-month plans.
  • Post-PMF: Quarterly roadmaps tied to OKRs. Balance growth features with infrastructure and debt.
  • Scaling: Semi-annual roadmaps with cross-team coordination. Dependencies become the hard problem.
• Avoid roadmap theater. Do not create elaborate roadmaps to appease stakeholders if the team lacks the capacity or conviction to execute.

Related Skills

• prd-writing -- Once an initiative is committed in the Now horizon, write a PRD to spec it out.
• mvp-scoping -- Before placing an initiative on the roadmap, scope its MVP to get a realistic effort estimate.
• user-research-synthesis -- Use customer insights to validate which outcomes matter most to your target segments.

Examples

Example 1: Output-to-outcome transformation

User: "Our Q2 plan says: build advanced search filters, implement AI recommendations, redesign dashboard. Help me turn this into an outcome roadmap."

Good output excerpt:

Transformation:

• Output: "Build advanced search filters" --> Outcome: "Enable customers to find products 50% faster through intuitive discovery"
• Output: "Implement AI recommendations" --> Outcome: "Increase average order value by 20% through personalized discovery"
• Output: "Redesign dashboard" --> Outcome: "Help operators monitor all systems with 80% reduction in dashboard load time"

Each outcome is now testable, measurable, and opens the door to alternative solutions beyond the originally specified feature.

Example 2: Feature backlog to roadmap

User: "Here's our feature backlog: Slack integration, SSO, reporting dashboard, mobile app, API v2, onboarding wizard. Help me build a roadmap."

Good output excerpt:

Now (0-6 weeks): | Onboarding Wizard | Enable new signups to reach first value within 10 minutes so that activation rate increases from 35% to 55% | Activation rate | Growth team | None |

Not Doing This Quarter:

• Mobile app -- Current usage data shows <5% of sessions are mobile. Revisit when mobile demand signal is stronger. Asking "So what?" reveals no compelling customer outcome today.

Sales Script

When to Use

• Preparing for a discovery call, product demo, or closing meeting
• Responding to an RFP/RFI and need coverage gap analysis
• Building a competitive feature comparison matrix against rivals
• Planning or scoring a proof-of-concept (POC) engagement
• Preparing a technical demo script with stakeholder-specific talking points
• Handling objections or conducting win/loss analysis

Context Required

From startup-context or the user:

• Product/service — What you sell, who it is for, key capabilities
• Target persona — Role, seniority, typical pain points
• Deal context — Stage, deal size, stakeholders involved, known objections
• Competitive landscape — Who else they are evaluating, your differentiators
• Proof points — Metrics, case studies, customer quotes
• RFP/RFI details — If responding to a formal request, the requirement categories and priorities

Workflow

Phase 1: Discovery & Research

1. Gather context — Read startup-context. Identify the script type needed: discovery call, demo, RFP response, competitive analysis, or POC plan.
2. Map customer requirements — Document the prospect's current architecture, pain points, integration requirements, security/compliance needs, and business drivers.
3. Assess competitive landscape — Identify competitors in the deal. Map your product capabilities against theirs to find differentiators and vulnerabilities.
4. Score requirement coverage — For RFP/RFI responses, categorize each requirement as Full (100%), Partial (50%), Planned (25%), or Gap (0%). Weight by priority: Must-Have 3x, Should-Have 2x, Nice-to-Have 1x.

Phase 2: Solution Design & Positioning

5. Map pain to value — Connect each prospect pain point to a specific product capability with proof (metrics, case studies).
6. Build competitive differentiation — Identify at least one strong differentiator per customer priority. If none exist, flag for product team escalation.
7. Design the talk track — Structure the conversation or document around their priorities, not your feature list.

Phase 3: Script & Demo Preparation

8. Draft the script — Write the full script with timing, talk tracks, questions, transition cues, and stakeholder-specific talking points.
9. Prepare objection handling — Anticipate likely objections and write response frameworks using the LAER model.
10. Build demo environment — Create a pre-demo checklist: environment tested, sample data loaded, backup environment prepared, customer-specific branding applied.

Phase 4: POC & Closing (if applicable)

11. Define POC scope — Set success criteria, timeline (typically 5 weeks), phased testing plan. Evaluate across functionality, performance, integration, usability, support. Require >60% for a go recommendation.
12. Close the deal — Package POC results, demo feedback, and competitive positioning. Apply closing techniques appropriate to the deal stage.

Output Format

Deliver the format matching the request: Discovery call script (SPIN-phase questions, qualifying criteria, next-step framing), Demo script (scene-by-scene with timing, per-role talk tracks, pre-demo checklist, objection table), RFP response analysis (coverage score, gap count, bid/no-bid recommendation), Competitive matrix (feature comparison with weighted scores, differentiators, vulnerabilities), POC plan (phased timeline, success criteria, scorecard), Objection handling doc (table: objection, concern, response, proof, follow-up), or Closing playbook (decision criteria, techniques, timeline).

Frameworks & Best Practices

Discovery Call Framework (30 min)

Demo Script Structure

Pre-demo checklist: Environment tested, sample data loaded, backup environment ready, screen sharing tested, browser tabs pre-loaded, network/VPN verified, customer branding applied.

Attendee mapping: For each attendee, document their title, role in evaluation (decision maker / champion / technical evaluator / end user), and key interest area.

Demo principles: Demo after discovery, never before. Use their terminology and data. Leave time for questions. Share why you built the feature — origin stories resonate more than feature walkthroughs.

RFP Bid/No-Bid Framework

• Bid: Coverage >70% AND must-have gaps <=3
• Conditional Bid: Coverage 50-70% OR must-have gaps 2-3
• No-Bid: Coverage <50% OR must-have gaps >3

Objection Handling (LAER Model)

1. Listen — Let them finish. Do not interrupt or get defensive.
2. Acknowledge — "That makes sense" or "I hear that a lot."
3. Explore — Ask a follow-up to understand the real concern.
4. Respond — Address the real concern with proof, then confirm.

Demo Recovery

If demo breaks: switch to backup, explain what they would have seen, offer recorded follow-up. If question derails: acknowledge, note for follow-up, return to script. If audience disengages: pause and ask "Is this addressing what you need?", skip to most relevant section.

Closing Techniques for Founders

• Summary close: "We agreed [pain] costs [amount], our solution addresses [needs]. What would it take to move forward?"
• Timeline close: "You want this solved by Q3. Working backward, we need to start by [date]."
• Pilot close: "Start with a focused pilot on [use case], prove the value, expand from there."
• Founder close: "I will personally ensure your onboarding goes smoothly. You work directly with me for 30 days."

Post-Demo Actions

Send thank-you email with recording within 24 hours. Share demo environment access. Send follow-up addressing unanswered questions. Schedule next meeting. Update CRM with demo notes and next steps. Log objections for battlecard updates.

Related Skills

• cold-outreach — Use to generate the meetings that lead to these sales conversations
• proposal-generation — Use after a successful demo to create the formal proposal, SOW, or contract

Examples

Prompt: "I have a demo tomorrow with the Head of Engineering at a fintech. They care about reducing deployment failures."

Good demo opening output:

"Thanks for making time, [Name]. Last week you mentioned your team spends about 8 hours per sprint dealing with failed deployments and rollbacks. You said the biggest pain is that it slows release velocity and frustrates the team. Is that still the top priority, or has anything changed?

Great. I want to show you three specific workflows that address deployment reliability. About 25 minutes, with time for your questions. Sound good?

Let me start with how [Similar Fintech Customer] handled this before switching to us..."

Prompt: "We got an RFP from a large enterprise. Should we bid?"

Good output snippet:

RFP Coverage Analysis:
- Overall coverage score: 68% (Conditional Bid range)
- Must-have gaps: 2 (within threshold)
- Recommendation: CONDITIONAL BID

Action items before proceeding:
1. Confirm planned roadmap items cover the 2 must-have gaps
2. Build differentiator narrative around your 3 strongest categories
3. Flag gaps to product team for timeline confirmation

Security Review

When to Use

• The user wants a security audit of their application, infrastructure, or specific feature
• They need a threat model before launching or a penetration test preparation review
• They have a dependency vulnerability alert and need remediation guidance
• They are handling sensitive data (PII, payment, health) and need verification
• Code audit, secrets detection, or compliance assessment is requested

Context Required

From startup-context: tech stack, deployment environment, compliance requirements, data types. Also ask:

• Scope — Full app, feature, auth system, single PR, infrastructure, or cloud environment
• Data types — PII, payment, health, credentials, or other sensitive data handled
• Compliance requirements — SOC 2, HIPAA, PCI-DSS, GDPR, ISO 27001
• Authorization — Confirm written authorization exists before any active testing

Workflow

Follow a five-phase methodology. Automated scanning precedes manual review. Authorization verification is mandatory before active testing.

1. Scope definition — Establish attack surface boundaries. Identify all components, data flows, and trust boundaries. Confirm authorization. Define in-scope and out-of-scope.
2. Automated scanning — Execute tooling before manual review:
   • SAST: semgrep --config=auto across the codebase
   • Dependency audit: npm audit / pip-audit / govulncheck / trivy fs .
   • Secrets detection: Scan for hardcoded credentials, API keys, tokens in source
   • Container scanning: trivy image for containerized deployments
   • Record all automated findings for validation in the next phase.
3. Manual code review — Conduct contextual analysis that automated tools miss:
   • Authentication and authorization flow tracing end-to-end
   • Business logic vulnerabilities (price manipulation, race conditions, privilege escalation)
   • Data flow analysis for sensitive information (where does PII enter, transit, and persist?)
   • STRIDE threat modeling against each component and data flow
4. Validation and classification — Test findings and assign severity:
   • Validate automated findings to eliminate false positives
   • Assign CVSS v3.1 scores; assess exploitability in context
   • Classify by business impact, not just technical severity
5. Reporting — Document vulnerabilities with precise locations, business impact, and corrective actions. Deliver a prioritized remediation roadmap.

Output Format

# Security Review: [Scope Description]

## Executive Summary
Overall risk posture (Critical / High / Medium / Low), top findings count, and business impact summary.

## Threat Model (STRIDE)
| Threat | Category | Asset | Impact | Likelihood | Risk |

## Findings
### Critical / High / Medium / Low
- **[SEC-N] Title** — CVSS X.X — file:line — description, business impact, remediation with code example

## Auth Flow Assessment
End-to-end trace of authentication and authorization with findings.

## Dependency Vulnerabilities
| Package | Current Version | CVSS | Fix Version | Exploitable in Context? |

## Remediation Roadmap
Prioritized action list with timelines.

Frameworks & Best Practices

STRIDE Threat Modeling

Apply to every component and data flow:

• Spoofing — Can attackers forge tokens or impersonate users? Are API keys rotatable?
• Tampering — Can requests be modified in transit? Are webhooks signed? Is data integrity verified?
• Repudiation — Are critical actions logged? Are logs tamper-evident?
• Information Disclosure — Stack traces in error responses? PII encrypted at rest and in transit?
• Denial of Service — Rate limits in place? Can one user exhaust resources for all?
• Elevation of Privilege — Can regular users access admin functions? Are role checks server-side?

OWASP Top 10 Checks

1. Injection — Parameterize SQL/NoSQL; check OS commands, SSTI, LDAP
2. Broken Auth — argon2id/bcrypt, session timeout, rate limiting on login
3. Data Exposure — TLS 1.2+, PII encrypted at rest, HSTS headers
4. XXE — Disable DTD processing, prefer JSON over XML
5. Access Control — Server-side authz on every endpoint, no IDOR, CORS whitelist
6. Misconfig — Debug mode off, default credentials removed, security headers present
7. XSS — Output encoding, Content Security Policy, HTTP-only cookies
8. Deserialization — Validate schema, prefer JSON, reject untrusted serialized objects
9. Vulnerable Deps — npm audit, pip-audit, trivy, govulncheck
10. Logging — Auth events, admin actions, access violations logged with alerts

CVSS v3.1 Scoring Guide

• Critical (9.0-10.0): RCE, auth bypass, full data breach, complete system compromise
• High (7.0-8.9): Privilege escalation, significant data exposure, SSRF to internal services
• Medium (4.0-6.9): Stored XSS, CSRF, limited IDOR, information disclosure
• Low (0.1-3.9): Missing security headers, minor info disclosure, verbose errors

Auth Flow Checklist

• Passwords: argon2id or bcrypt (cost >= 10)
• JWT: 15-min access tokens, 7-day refresh tokens rotated on use
• Rate limiting: 5 attempts / 15 min on auth endpoints
• Sessions invalidated on password change
• OAuth state parameter validated, scoped API keys
• MFA enforced for admin accounts
• Password reset tokens are single-use and time-limited

Scanning Tools

• SAST: semgrep --config=auto (all stacks), bandit (Python), gosec (Go), eslint-plugin-security (Node)
• Dependencies: npm audit / pip-audit / govulncheck / trivy fs .
• Containers: trivy image

Mandatory Constraints

• Never test production without explicit written authorization
• Never exploit beyond proof-of-concept demonstration
• Always sequence automated scanning before manual review

Remediation Priority

1. Actively exploitable + critical data — immediately
2. Auth/authz bypass — 24 hours
3. Injection — 48 hours
4. Data exposure / critical CVEs — 1 week
5. Config hardening — 2 weeks
6. Defense-in-depth — next sprint

Related Skills

• code-review — chain when findings require code-level fixes and review
• architecture-design — chain when findings reveal architectural security flaws
• soc2-prep — chain when review is part of compliance preparation

Examples

Example prompt: "Review the security of our user authentication system. We use JWT with Express."

Good output snippet:

# Security Review: JWT Authentication System

## Executive Summary
Risk posture: **Critical**. Hardcoded JWT secret and non-expiring tokens.

## Findings
### Critical (CVSS 9.8)
- **[SEC-1] Hardcoded JWT secret** — auth/config.js:3 — Secret is
  "supersecret123". Attacker can forge any token.
  **Fix:** Move to env var, generate with `openssl rand -base64 64`.

### Critical (CVSS 9.1)
- **[SEC-2] Tokens never expire** — auth/jwt.js:12 — No `expiresIn`.
  **Fix:** Set `expiresIn: '15m'`, implement refresh token rotation.

Sentiment Monitoring

When to Use

• Founder wants to track what customers and the public are saying about their product
• Founder wants to catch bad reviews early and respond before they spread
• Founder wants to understand community sentiment trends over time
• Founder wants to monitor specific review platforms for new reviews

This is different from review-mining (mining competitor reviews for pain points). This skill monitors your OWN product's reputation.

Context Required

• Product name and any common misspellings or abbreviations
• Platforms to monitor — the founder must provide the list of places to watch. Common options:
  • Product Hunt (product page reviews and comments)
  • Google Maps / Google Business reviews
  • G2, Capterra, TrustRadius
  • Trustpilot
  • App Store / Play Store
  • Reddit mentions
  • Twitter/X mentions
  • Hacker News mentions
  • Industry-specific forums
• Monitoring frequency (daily for post-launch, weekly for steady state)
• Response policy — does the founder want draft responses for negative reviews?
• Escalation threshold — what severity warrants immediate attention?

Workflow

1. Set up the monitoring list — the founder provides which platforms to watch. For each platform, note:
   • Direct URL to the product's review/listing page
   • Current rating and review count (baseline)
   • How to check for new reviews (RSS, manual, API, or alert tool)
2. Define the severity scale — categorize incoming sentiment:
   • Critical (respond within 24h): public accusations of data loss, security issues, billing fraud, or legal threats. 1-star reviews with detailed complaints that could go viral.
   • Negative (respond within 48h): legitimate complaints about bugs, missing features, poor support, or pricing frustration. 1-2 star reviews.
   • Mixed (respond within 1 week): 3-star reviews with constructive feedback. "Good product but..."
   • Positive (acknowledge): 4-5 star reviews. Thank the reviewer, ask for referrals.
3. Scan platforms — check each platform on the founder's list for new reviews, mentions, or discussions since the last scan.
4. Analyze each finding — for every new review or mention:
   • Platform and date
   • Sentiment: positive / mixed / negative / critical
   • Core issue: what specifically is the person saying (quote verbatim)
   • Validity: is this a legitimate product issue, user error, or bad-faith review?
   • Impact: how visible is this? (high-traffic platform, many upvotes, or buried)
   • Pattern: does this match other recent complaints? (signals a systemic issue)
5. Draft responses — for negative and critical reviews, draft a response that:
   • Acknowledges the issue without being defensive
   • Shows the complaint was heard and understood
   • Offers a specific next step (DM, email, fix timeline)
   • Is written in the founder's voice, not corporate PR speak
6. Flag patterns — if 3+ reviews mention the same issue, escalate it as a product issue, not just a review problem.
7. Generate the sentiment report — summary of findings with trends.

Output Format

## Sentiment Report — [Date Range]

### Overview
- **Reviews scanned:** [count across all platforms]
- **New since last scan:** [count]
- **Sentiment breakdown:** [X positive, Y mixed, Z negative, W critical]
- **Average rating trend:** [up/down/stable vs. last period]

### Critical & Negative Items (action required)

**[Platform] — [Star Rating] — [Date]**
> "[Verbatim quote or summary]"
- **Core issue:** [what they're actually complaining about]
- **Validity:** [Legitimate / User error / Bad faith]
- **Pattern:** [First mention / Recurring — also seen on X, Y]
- **Suggested response:**
  > [Draft response in founder's voice]

### Emerging Patterns
| Issue | Mentions This Period | Platforms | First Seen | Trend |
|-------|---------------------|-----------|------------|-------|
| [Issue] | [count] | [platforms] | [date] | [new / growing / stable] |

### Positive Highlights
- [Platform]: "[positive quote]" — consider using as testimonial
- [Platform]: "[positive quote]" — share on social

### Recommended Actions
- [ ] Respond to [N] critical/negative reviews (drafts above)
- [ ] Investigate [issue] — mentioned [N] times across [platforms]
- [ ] Request reviews from happy customers to offset [negative trend]

Frameworks & Best Practices

Response principles for negative reviews:

• Speed matters — respond within 24-48 hours. Unanswered negative reviews signal "they don't care."
• Acknowledge, don't argue — "I hear you" beats "Actually, you're wrong" every time
• Take it offline — "I'd love to look into this — can you email me at founder@company.com?" moves the conversation out of public view
• Be the founder — sign with your name and title. "— Alex, CEO" hits differently than a generic support reply
• Fix the issue, then update — come back to the review after fixing the problem: "We shipped a fix for this last week"

Platform-specific notes:

When negative reviews are actually gifts:

• Specific, actionable complaints point to real product gaps — treat them as free user research
• A pattern of "love the product but X is broken" means you have product-market fit with a fixable issue
• No negative reviews at all usually means no one is using the product

Common mistakes:

• Monitoring without responding (worse than not monitoring)
• Getting defensive or arguing publicly with reviewers
• Only monitoring one platform (customers complain wherever they are, not where you're watching)
• Treating all negative reviews equally (a billing fraud accusation ≠ a UI complaint)
• Not feeding review insights back into the product roadmap

Related Skills

• review-mining — for mining COMPETITOR reviews (this skill monitors YOUR reviews)
• feedback-synthesis — for synthesizing feedback patterns into product decisions
• churn-analysis — negative reviews often correlate with churn signals
• community-discovery — to find communities where people discuss your product

Examples

Prompt: "Set up monitoring for our reviews. We're on Product Hunt, G2, Trustpilot, and the App Store."

Good output includes: Monitoring checklist for all 4 platforms with current baselines, severity scale customized to the product, and a template for the weekly sentiment report.

Prompt: "We got 3 bad reviews on G2 this week. Help me respond."

Good output includes: Analysis of each review (core issue, validity, pattern detection), draft responses in the founder's voice, and a flag if the issues point to a systemic product problem.

SEO Technical

When to Use

• Running a technical SEO audit on an existing site.
• Diagnosing why pages are not being indexed or ranked.
• Optimizing Core Web Vitals or page speed.
• Setting up site architecture (sitemaps, robots.txt, canonicalization).
• Implementing structured data / schema markup.
• Managing AI crawler access via robots.txt.
• Preparing a new site or migration for SEO readiness.
• Reviewing JavaScript rendering and its impact on indexation.

Context Required

• From startup-context: product description, target audience, primary keywords, current domain and site structure.
• From the user: site URL, access to Google Search Console data (if available), specific pages of concern, known issues, tech stack (static site, SPA, WordPress, etc.), whether the site has been previously audited.

Workflow

Audit across 9 technical dimensions. Score on a 100-point scale with category breakdowns.

1. Crawlability audit — Foundation; nothing else matters if search engines cannot crawl the site.
   • Check robots.txt for unintended disallow rules.
   • Verify XML sitemap exists, is submitted to Search Console, and is up to date.
   • Identify crawl errors (4xx, 5xx status codes).
   • Check for orphan pages (no internal links pointing to them).
   • Audit redirect chains — flatten to single hops. Chains of 3+ waste crawl budget and dilute link equity.
   • For sites with 10,000+ pages, analyze crawl budget efficiency and remove low-value pages from the index.
2. Indexation audit — Ensure crawled pages are actually indexed.
   • Check site:domain.com results vs. expected page count.
   • Look for noindex tags applied unintentionally.
   • Identify duplicate content issues and missing canonical tags.
   • Check for thin content pages that may be filtered out.
   • Review index coverage report in Search Console for excluded pages.
3. Security and HTTPS — HTTPS is a ranking signal and a trust requirement.
   • Verify HTTPS everywhere with proper redirects from HTTP.
   • Check for mixed content issues.
   • Validate SSL certificate and HSTS headers.
4. URL structure — Short, descriptive, hyphenated URLs without parameters.
   • Consistent URL patterns across the site.
   • No duplicate content from URL variations (trailing slashes, www vs. non-www).
   • Self-referencing canonical tags on every page.
5. Mobile optimization — As of July 2024, Google crawls and indexes ALL websites exclusively with the mobile Googlebot user-agent. Mobile-first is not optional.
   • Mobile and desktop content parity is mandatory.
   • Test with mobile-friendly tools.
   • Responsive design, no horizontal scroll, touch targets properly sized.
6. Core Web Vitals — Google uses these as ranking signals. Current targets:
   • LCP (Largest Contentful Paint): Target under 2.5 seconds. Fixes: optimize hero images, implement lazy loading, use CDN, reduce server response time.
   • INP (Interaction to Next Paint): Target under 200ms. INP replaced FID in March 2024. Fixes: reduce JavaScript execution time, break up long tasks, optimize event handlers.
   • CLS (Cumulative Layout Shift): Target under 0.1. Fixes: set explicit dimensions on images/embeds, avoid injecting content above existing content, use font-display: swap.
   • Check for render-blocking CSS/JS, unoptimized images, excessive third-party scripts.
7. Structured data — Implement schema markup for rich results.
   • Organization schema on the homepage.
   • Article/BlogPosting schema on content pages.
   • Product schema on product pages.
   • FAQ schema where applicable (boosts SERP real estate).
   • BreadcrumbList schema for navigation clarity.
   • Validate with Google's Rich Results Test.
8. JavaScript rendering — Critical for SPAs and JS-heavy sites.
   • Serve canonical tags, robots directives, and structured data in initial server-rendered HTML. Google may not reliably process these if injected via JavaScript.
   • Verify server-side rendering or pre-rendering is in place for critical content.
   • Test what Googlebot actually sees vs. what users see.
9. AI crawler management — Managing AI crawlers via robots.txt is a critical 2025-2026 consideration.
   • GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Bytespider (ByteDance), Google-Extended
   • Blocking Google-Extended does NOT affect Google Search indexing or AI Overviews — only Gemini training data.
   • Decide per-crawler based on business needs: allow, block, or rate-limit.

Output Format

A prioritized audit report scored on a 100-point scale:

• Critical issues (blocking indexation or causing major ranking loss): fix immediately
• High-impact improvements (will meaningfully improve rankings): fix within 2 weeks
• Medium improvements (incremental gains): fix within 30 days
• Low priority (minor optimizations): address when convenient

Each item includes: the issue, why it matters for rankings, how to fix it, and estimated effort (low/medium/high).

Frameworks & Best Practices

• Canonical tags are directives, not suggestions: While Google treats them as hints, properly implemented canonicals are followed in the vast majority of cases. Always self-canonical pages and canonical duplicates to the preferred version.
• JavaScript SEO: Critical metadata (canonical, robots, structured data) must be in initial server-rendered HTML. Google can render JS but with delays and reliability gaps.
• Mobile-first is complete: Since July 2024, there is no "desktop index." The mobile version IS the version Google indexes. Full content parity is non-negotiable.
• INP replaced FID: FID was fully removed from Chrome tools by September 2024. All performance optimization should target INP (under 200ms), not FID.
• Crawl budget: Rarely an issue for sites under 10,000 pages. For larger sites, prioritize by removing low-value pages and fixing redirect chains.
• Hreflang for international sites: Implement correctly or not at all. Errors cause worse indexation than no hreflang tags.
• Log file analysis: Server logs reveal what Googlebot actually crawls vs. what you want crawled. This is the ground truth of crawlability.
• Speed is a tiebreaker: Rarely causes dramatic ranking changes alone, but affects user behavior metrics (bounce rate, time on site) which indirectly impact rankings.
• E-E-A-T signals matter: Author bios with credentials, about page, contact info, links to authoritative sources, HTTPS, privacy policy, terms of service.

Related Skills

• content-strategy — when the audit reveals content gaps or thin content that needs a broader content plan
• landing-page — when key landing pages need both CRO and on-page SEO optimization

Examples

Example 1: Full audit

"We launched our site 6 months ago and we're barely showing up in Google. Can you audit our SEO?"

Good output: A structured audit across all 9 dimensions with a 100-point score. Identifies that robots.txt is blocking the /blog/ directory, sitemap is missing, several pages have duplicate title tags, Core Web Vitals are failing on mobile (LCP at 4.2s due to unoptimized hero image), canonical tags and structured data are injected via JavaScript instead of server-rendered HTML, and no AI crawler policy is defined. Prioritized fix list with critical, high, medium, and low items with effort estimates.

Example 2: Specific issue

"Our blog posts were ranking well but traffic dropped 40% last month."

Good output: Diagnostic checklist starting with Search Console data review (manual actions, crawl errors, index coverage changes), then checking for algorithm update timing, content cannibalization between similar posts, accidental noindex or broken canonicals, Core Web Vitals regression (especially INP after a JS-heavy deploy), lost backlinks, and mobile rendering issues. Recommends specific data to gather and steps to isolate the cause.

SOC 2 Prep

When to Use

Activate when a founder is preparing for SOC 2 certification, has been asked by a customer or prospect for a SOC 2 report, needs to quantify security risk for board or budget discussions, wants to build a compliance roadmap sequenced for business value, or needs to assess overall security posture. Also activate when the user mentions "SOC 2," "compliance audit," "trust service criteria," "security budget," "we need SOC 2 to close this deal," or "CISO."

Context Required

• From startup-context: product type, tech stack, cloud infrastructure provider, team size, current security practices, business model, customer segments (enterprise customers often require SOC 2).
• From the user: which Trust Service Criteria are in scope, current state of documentation and policies, existing security tooling (SSO, MDM, monitoring), whether targeting Type I or Type II, desired timeline, budget constraints, whether an auditor is selected, and top 3 prospects' compliance requirements.

Workflow

1. Quantify the business case — Frame security investment in dollars using ALE (Annual Loss Expectancy = Single Loss Expectancy x Annual Rate of Occurrence). Translate to board language: "This risk has $X expected annual loss. Mitigation costs $Y." Security is a sales enabler, not a checkbox.
2. Scope definition — Determine which Trust Service Criteria are in scope. Security (Common Criteria) is always required. Availability, Processing Integrity, Confidentiality, and Privacy are optional. Scope based on customer requirements and product type.
3. Current state assessment — Inventory existing policies, controls, and tooling. Identify what exists, what partially exists, and what is completely absent. Check the red flags list below.
4. Gap analysis — Map current state against each applicable TSC criterion. Produce a gap matrix showing compliant, partially compliant, and non-compliant areas.
5. Compliance roadmap — Sequence for business value: SOC 2 Type I (3-6 months) then SOC 2 Type II (12 months from start) then ISO 27001 or HIPAA based on customer demand. Do not pursue certifications before basic hygiene is in place.
6. Policy generation — Draft required policies tailored to the company's size. Early-stage startups need practical 2-5 page policies, not 50-page enterprise documents.
7. Control implementation plan — For each gap, define the control, the owner, the tooling, and the timeline.
8. Evidence collection guidance — Define what the auditor will request for each control and how to collect it systematically.
9. Readiness review — Perform a mock assessment before engaging the auditor.

Output Format

# Security & Compliance Assessment: [Company Name]

## Risk Quantification — top risks with ALE, mitigation cost, expected value
## Gap Analysis Matrix — TSC criterion, requirement, current state, gap, priority, remediation
## Compliance Roadmap — sequenced timeline: SOC 2 Type I > Type II > ISO 27001/HIPAA
## Policy Documents — generated as needed, each with purpose/scope/roles/statements/procedures
## Implementation Timeline — phased checklist with milestones
## Evidence Collection Checklist — per-control artifacts, storage location, refresh cadence
## Security Metrics Dashboard — table of key metrics with current values and targets

Frameworks & Best Practices

Risk Quantification (CISO Approach)

Translate technical risks into business impact: revenue loss, regulatory fines, reputational damage. Use ALE to prioritize.

Formula: ALE = SLE x ARO (Single Loss Expectancy x Annual Rate of Occurrence)

Board language: "A $200K security program preventing a $2M breach at 40% annual probability has $800K expected value. The program pays for itself 4x over."

Frame security spend as risk transfer cost, not overhead.

Security Metrics

Trust Service Criteria Overview

Security (Common Criteria -- always in scope): CC1-CC2 (control environment, communication), CC3 (risk assessment), CC4-CC5 (monitoring, control activities), CC6 (logical/physical access, encryption), CC7-CC8 (system ops, vulnerability mgmt, incident response, change mgmt), CC9 (vendor management, business continuity).

Optional: Availability (A1), Processing Integrity (PI1), Confidentiality (C1), Privacy (P1-P8).

Essential Policies (10 minimum)

Information Security, Access Control (MFA, least privilege, access reviews), Change Management (code review, rollback), Incident Response (detection through post-mortem), Risk Assessment (annual, with register), Vendor Management, Data Classification, Business Continuity/DR (RTO/RPO, backup testing), Acceptable Use, HR Security (background checks, onboarding/offboarding).

Vendor Security Assessment Tiers

Red Flags to Surface Proactively

• Security budget justified by benchmarks rather than risk analysis
• Certifications pursued before basic hygiene (patching, MFA, backups)
• No documented asset inventory -- cannot protect what you do not know you have
• IR plan exists but never tested; security reports to IT, not executive level
• Security questionnaire backlog > 30 days -- silently losing enterprise deals
• Vendor with sensitive data access has not been assessed

Startup-Specific Guidance

Type I vs Type II: Type I examines control design at a point in time (3-6 months, good for closing the first enterprise deal). Type II examines control operation over 3-12 months (what sophisticated buyers want, plan 12 months total). Start Type I immediately; begin Type II observation once controls are in place.

Right-Sizing by Stage: Seed (5-15): foundational controls, automation-heavy, concise policies, one part-time owner. Series A (15-50): dedicated compliance owner or fractional CISO, formal access reviews. Series B+ (50+): full-time security team, internal audit, GRC platform.

Cost-Effective Tooling: Compliance automation (Vanta, Drata, Secureframe — significantly reduces manual effort), SSO (Google Workspace or Okta), MDM (Kandji or Jamf), monitoring (Datadog, PagerDuty), vulnerability scanning (Dependabot, Snyk, Trivy).

Timeline Templates

• Type I Aggressive (3 months): Month 1 scope/gap/policies, Month 2 implementation, Month 3 readiness + audit.
• Type I Standard (6 months): Months 1-2 scope/policies, 3-4 implementation, 5 evidence, 6 audit.
• Type II (12 months): Months 1-6 complete Type I, 6-12 observation + evidence, Month 12 audit.

Output Confidence Tagging

All findings tagged before reaching decision-makers: Verified (confirmed against evidence), Medium (reported but not independently verified), Assumed (inferred, needs validation).

Related Skills

• privacy-policy — SOC 2 Privacy criteria (P1-P8) align directly with privacy policy commitments. Ensure consistency.
• security-review — Technical security controls from security-review map to SOC 2 Common Criteria (CC6, CC7, CC8). Use findings to inform gap analysis.

Examples

Example 1: Enterprise deal requires SOC 2

User: "A prospect wants SOC 2 before signing a $200K contract. We have nothing."

Good output excerpt:

Business case: This $200K deal justifies a $30-50K compliance investment. At your stage, every enterprise deal blocked by missing SOC 2 has an opportunity cost.

Area	Status	Key Gaps
Access Control	Partial	MFA not enforced on AWS root, no SSO, no formal reviews
Change Management	Partial	GitHub PRs used but no documented policy
Incident Response	Missing	No documented plan, no on-call rotation
Risk Assessment	Missing	No formal risk assessment conducted

Recommended approach: Type I in 3 months, then begin Type II observation. Immediate actions: (1) Sign up for compliance automation. (2) Enforce MFA everywhere. (3) Select an auditor with startup experience. Interim response to prospect: Share security questionnaire response, SOC 2 Type I commitment timeline, and a signed mutual NDA with security addendum.

Example 2: Security posture assessment

User: "We already use Okta for SSO and do code reviews. Where are we relative to SOC 2?"

Good output excerpt:

Gap Analysis Summary: 55% ready

Compliant: CC6.1 Okta SSO with MFA, CC8.1 code reviews via PRs. Partial: CC6.2 no quarterly access reviews documented, CC7.2 IRP never tested, CC6.3 no formal offboarding checklist. Missing: CC3.1 no annual risk assessment, CC2.1 no security training, CC9.2 no vendor management, CC4.1 no control monitoring, all 10 required policies need drafting.

Disclaimer: This skill provides SOC 2 preparation guidance for planning purposes only. It does not constitute legal, audit, or professional compliance advice. SOC 2 reports can only be issued by a licensed CPA firm. Engage a qualified auditor to confirm readiness before scheduling an audit.

Social Content

When to Use

• Building a LinkedIn authority or thought leadership system from scratch.
• Defining content pillars and weekly posting rhythm.
• Writing individual posts with strong hooks.
• Creating a content calendar with real dates and ready-to-write hooks.
• Establishing positioning before content creation begins.
• Reviewing 30-day performance and adjusting content ratios.

Context Required

From startup-context or the user:

• Positioning statement — Your one-liner: who you help, what you do, how you are different. If the user lacks this, help them clarify it before building a content system.
• Target audience — Specific titles, company stages, industries on LinkedIn
• Historical performance — Past posting data, what worked, what fell flat (if any)
• Content goal — Leads, job opportunities, speaking invitations, partnerships, or community
• Time commitment — Realistic weekly hours available for content creation and engagement

A critical gate: positioning clarity must come first. An unfocused content system produces unfocused results. If the user cannot articulate who they serve and why they are different, address that before building pillars.

Workflow

1. Clarify positioning — Confirm or develop the user's one-liner. This is the foundation. Every pillar, hook, and post must connect back to this positioning.
2. Select mode based on need:
   • Quick: 3 content pillars + 1-week starter plan (for getting unstuck)
   • Standard: Full system with pillars, formats, rhythm, and first week of posts written (default)
   • Deep: Complete 90-day calendar with 10 written posts and engagement strategy
3. Build content pillars — Each pillar must satisfy four criteria:
   • You have genuine expertise in this area
   • Your target audience genuinely cares about this topic
   • You can sustain 6+ months of content on this pillar
   • It connects to your revenue or stated objective
4. Allocate pillar ratios:
   • 70% core expertise — Authority-building content that demonstrates deep knowledge
   • 20% adjacent insights — Differentiation content connecting your expertise to unexpected areas
   • 10% personal content — Relatability, behind-the-scenes, founder journey
5. Assign format strategy per pillar:
   • Story posts — Drive connection and high engagement through narrative tension and personal insight
   • Framework/list posts — Establish authority and credibility through structured thinking
   • Case studies — Build trust through proof and results
   • Hot takes — Generate visibility through informed contrarian opinions
   • Behind-the-scenes — Create relatability and relationship depth
   • Recommended weekly mix: 2-3 frameworks, 1-2 stories, 1 proof point
6. Build the calendar — Use actual dates (YYYY-MM-DD), not generic placeholders. Provide 4-week calendars with real hooks ready for immediate writing. Include 5 starter post hooks to eliminate blank-page paralysis.
7. Write the first batch — For standard and deep modes, write complete posts with hooks, body, and CTAs. Posts should be 150-300 words, short paragraphs (1-2 sentences), end with a question or discussion prompt.

Output Format

• Positioning statement — Confirmed or refined one-liner
• Content pillars — 3-5 pillars with rationale, percentage allocation, and format assignments
• 4-week calendar — Real dates, assigned pillar, format, and hook for each post
• Written posts — Complete ready-to-publish posts (quantity depends on mode)
• Engagement strategy — Daily engagement routine with time allocation
• 30-day review criteria — What to measure and how to adjust

Frameworks & Best Practices

The Core Philosophy

"Being remembered by the right 500 people when they need what you do — that pays your bills." This is not about going viral. It is about consistent, positioned content that makes you the obvious choice when your audience has a need.

Content Pillar Validation

Reject any pillar that fails even one of these tests:

• Do you have genuine expertise here? (Not "interested in" — actually expert)
• Does your target audience search for, discuss, or struggle with this?
• Can you generate 50+ unique post ideas in this space?
• Does it connect to how you make money or achieve your stated goal?

Hook Formulas

The first 1-2 lines determine whether anyone reads the rest:

• Contrarian: "Most [people] think [common belief]. They're wrong."
• Specific result: "I [did X] and [got Y result] in [timeframe]."
• Curiosity list: "5 things I wish I knew about [topic] before [experience]."
• Story opener: "Last week, a [person] told me something that changed how I think about [topic]."
• Bold claim: "[Counterintuitive statement]. Here's why:"

Platform-Native LinkedIn Rules

• Start with a hook line that earns the "see more" click
• Short paragraphs (1-2 sentences), generous line breaks
• 150-300 words optimal length
• End with a question to drive comments
• No hashtags in body text; add 3-5 relevant hashtags at the end
• Personal accounts consistently outperform brand accounts in B2B