StartupSprints

View saved version →

---
name: startupsprints-assets-and-launches
description: Use when a StartupSprints founder asks to create or revise a Distribution Kit asset, product description, demo, screenshot brief, listing, launch package, destination-specific submission, reusable resource, content draft, or launch readiness check.
---

# StartupSprints assets and launches

Produce a usable artifact or launch package grounded in the confirmed product and the founder's mission. A draft, submitted listing, approved listing and measured acquisition remain separate.

Read [MCP workflow](references/mcp-workflow.md) before work. Use [asset and launch preparation](references/asset-and-launch-preparation.md) for concrete deliverables and readiness checks; [prompt examples](references/prompt-examples.md) provide entry points.

## Inputs

Resolve startup/action, audience, confirmed product facts/limitations, existing approved assets, intended destination, current requirements, time/budget, identity/public preferences and any explicit publication or purchase approval.

## Read → select → act → save → review

1. **Read:** Discover actual tools. Resolve startup with `list_startups` and returned `actionId` with `list_actions`; read `get_startup_profile`, `get_execution_brief`, `get_action_workspace`, and `get_distribution_kit`. Use explicit `startupId` for all-startup grants. Read relevant previous results when choosing claims or launch scope.
2. **Select:** Choose the artifact that unblocks the action or tests its audience/mission hypothesis. Honor prerequisites and the live required description variant. Verify current destination eligibility, fees, promotion rules and submission requirements. Missing facts stay unresolved; a generated image or draft is not proof of product behavior.
3. **Act:** Create the actual copy, artifact or authorized artifact reference, with source-backed claims, affiliation, permissions, accessible caption/instructions and honest limitations. Prefer existing approved assets. Confirm each actual authenticated account before account-dependent work; preserve previous explicit confirmation. Prepare the destination, account, exact content/assets, fees and volume before missing authorization to publish, submit, book or buy. Reuse bounded prior approval; do not infer approval from readiness or public-identity preference.
4. **Save:** Save when included in the task. Action work uses the live template and full merged entries/notes with current `workRevision`; reread/merge conflicts and verify. Distribution Kit text/link content uses `save_asset_content` with actual `assetId` and current `expectedUpdatedAt`; this replaces content. Read current content and preserve relevant material. Logo/screenshot upload occurs in the app; text cannot create an uploaded image. Saving does not publish or establish readiness, execution or results.
5. **Review:** Return actual readiness gaps, draft/submission/publication state and evidence needed to evaluate audience response. Recommend the smallest next step toward the mission. On ambiguous “wrap up,” prepare a summary and clarify actual-result recording and completed/failed intent before `record_action_result`. That call ends the attempt; use current `attemptNumber`/`outcomeRevision` and only observed metrics in `measuredMetrics`. Unknown analytics is not measured zero; no inferred vote.

## Output and fallback

Return the usable artifact, claims/sources, current destination requirements, remaining gaps, save status and approval scope. If creation/upload/submission tools are unavailable, deliver honest text/specification or manual-ready materials and name the remaining step. Do not invent hosted links, uploads, accepted submissions or persistence.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: startupsprints-customer-discovery
description: Use when a StartupSprints founder asks to find people who recently had a problem, recruit interview participants, prepare problem or pricing interviews, observe onboarding, investigate switching or lost signups, or analyze actual customer research notes.
---

# StartupSprints customer discovery

Create supported recruitment work and learn from real behavior toward the founder's mission. A shortlist, invitation, scheduled call, and completed interview are separate states.

Read [MCP workflow](references/mcp-workflow.md) before work and [problem interviews](references/problem-interviews.md) for strategy 11, `problem-interviews`. That reference also explains adjacent discovery adaptations. Use [prompt examples](references/prompt-examples.md) as starting points.

## Inputs

Use the confirmed audience/problem, action, hands-on decision, effort/budget, outreach limits, current work and available tools. Ask for a missing fact only when it changes qualification or the next dependent action.

## Read → select → act → save → review

1. **Read:** Discover tools; resolve the startup through `list_startups`, then the returned action through `list_actions`. Read `get_startup_profile`, `get_execution_brief`, and `get_action_workspace`; inspect prior attempts and legacy findings. Use explicit `startupId` for all-startup grants. Live brief and field definitions override reference examples.
2. **Select:** Define a recruitment screen for audience context, a recent real problem, current workaround, and disqualifiers. Respect hands-on, cold-outreach, public-identity and community constraints. Choose the venue because the audience uses it. Prefer available ChatGPT Chrome research when useful; respect the founder's chosen browser. Confirm the actual service/account separately before authenticated research, preserving prior explicit confirmation.
3. **Act:** Find up to five qualified candidates within the effort limit. Record sources, observation date, fit evidence, uncertainty, and a permitted route. Return fewer when evidence is insufficient. Discussion authors without a verified route are audience evidence, not recruitable candidates. Draft exact individual invitations and a neutral last-occurrence interview guide. Present account, recipients, content, cost and contact/follow-up limit for any missing send authorization; reuse prior approval only within its bounds. Founder participation remains required where the brief requires it. Analyze only real notes, with participant references, supported patterns and contradictions.
4. **Save:** When authorized by the task, merge the current `research` work and notes; send the complete replacement with current `workRevision`, reread/merge on conflict, and verify. Candidate identity, source/date/fit/uncertainty belong in `participant`; invitation/route in `recommendation`; keep `status: draft` and interview observations empty before an interview. Use only live allowed keys; preserve old findings and entries.
5. **Review:** Report recruitment, scheduled calls and actual interviews separately. Five candidates do not meet a five-interview target. Do not invent three patterns to meet a goal. On ambiguous “wrap up,” prepare a summary and ask only the necessary verdict/outcome clarification. Never call `record_action_result` until the founder explicitly requests recording actual outcomes and supplies or confirms completed/failed intent. Reread current `attemptNumber`/`outcomeRevision`; list only measured metrics in `measuredMetrics`. Absent interviews or analytics do not establish measured zero. Never infer a feedback vote.

## Output and fallback

Return a source-backed partial shortlist, exact invitations, guide, evidence gaps, progress/save status and next action; after actual interviews, add supported patterns. Missing Chrome or sending access still allows permitted public research, a founder-provided contact list and preparation. MCP unavailable: deliver usable work without claiming it was saved.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: startupsprints-measurement-and-review
description: Use when a StartupSprints founder asks to define first value or activation, verify tracking, review actual experiment or cohort evidence, assess costs and retention, compare results with a mission, record outcomes, or wrap up an experiment.
---

# StartupSprints measurement and review

Make results interpretable and decide the next useful step toward the mission. Missing data, a measured zero and a proposed target carry different meanings.

Read [MCP workflow](references/mcp-workflow.md) before work. Follow [measurement review](references/measurement-review.md) for definitions, evidence and result-write checks; [prompt examples](references/prompt-examples.md) provide entry points.

## Inputs

Resolve startup/action and current attempt, mission qualification, success/stop criteria, cohort and source, observation window, event definitions, denominators, real measurements, prior attempts and actual time/cost. Ask only for missing information necessary for the requested decision or write.

## Read → select → act → save → review

1. **Read:** Resolve the startup with `list_startups` and returned `actionId` with `list_actions`; read `get_startup_profile`, `get_execution_brief`, `get_action_workspace`, and relevant `get_results`. Explicitly target `startupId` with all-startup grants. Discover available analytics/data capabilities. Confirm the intended identity separately before authenticated account-dependent analysis; reuse valid prior confirmation.
2. **Select:** Define what counts toward the mission and this strategy: first meaningful use, qualified conversation, retained member of a specific cohort, or a paid outcome. Choose a bounded test/check with real denominators and a window. Popularity, profiles, draft messages and scheduled calls do not become activations, sales or completed interviews.
3. **Act:** Inspect actual authorized sources and compute reproducible values. Separate observed/founder-reported data, assumptions and missing evidence. Verify tracking using a real test journey when authorized, exclude internal traffic and expose attribution gaps. Do not execute external tests, change instrumentation or incur costs beyond existing authorization. Compare attempts without double-counting people or outcomes.
4. **Save:** Preserve requested definitions, calculations and review drafts through full merged work/notes in the live template with current `workRevision`; reread/merge conflicts and verify. These saves leave the attempt open.
5. **Review:** Give a supported repeat/repair/stop recommendation with the mission implication. “Wrap up,” “finish,” “we're done,” or “save the review” does not by itself authorize an attempt-ending result write. First prepare the summary; if recording intent or completed/failed verdict is unclear, ask only that necessary clarification and continue independent review work. Call `record_action_result` only after explicit instruction to record actual outcomes and explicit completed/failed intent, rereading current `attemptNumber` and `outcomeRevision` immediately before it. It replaces this attempt's outcome and ends it. Require `measuredMetrics`; omit unknown metrics from this list. Required unknown numeric fields may need `0` placeholders, but only a zero listed in `measuredMetrics` is a measured zero. Reread and verify the result. Record feedback only from an explicit founder thumbs-up/down.

## Output and fallback

Return definitions, cohort/window, source-backed values and denominators, missing evidence, actual effort/cost, recommendation and save status. Without analytics, audit the measurement plan and supplied evidence; request the smallest relevant export or observation. Never turn unavailable data into zero or claim a completed experiment from preparation.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: startupsprints-outreach-and-communities
description: Use when a StartupSprints founder asks to prepare targeted outreach, relevant follow-up, introductions, editor or podcast pitches, community research, answers to discussion threads, or participation in a specific community.
---

# StartupSprints outreach and communities

Prepare useful, relevant contact and community contributions within the founder's mission and approved limits. Willingness to consider outreach is separate from permission to send it.

Read [MCP workflow](references/mcp-workflow.md) before work. Follow [outreach preparation](references/outreach-preparation.md) for recipient/thread qualification and output; [prompt examples](references/prompt-examples.md) provide entry points.

## Inputs

Resolve the startup/action, confirmed audience and offer, founder identity/outreach preferences, current channel rules, existing contacts/work, time/budget and approved contact/follow-up limits. Ask only for facts required by the next step.

## Read → select → act → save → review

1. **Read:** Use `list_startups`, `get_startup_profile`, and `list_actions` to resolve the returned `actionId`; read `get_execution_brief` and `get_action_workspace`, plus relevant `get_distribution_kit`/`get_results`. Pass explicit `startupId` with all-startup grants.
2. **Select:** Choose recipients or threads using observed audience/problem relevance and a permitted route. Check current venue rules, affiliation disclosure and promotion limits. Respect opt-outs, no-cold-contact choices and “existing communities only.” Inspect only enough authenticated context to identify the account and obtain missing confirmation for that service; reuse the existing explicit identity confirmation while the account/scope is unchanged.
3. **Act:** Draft actual individual messages or complete useful thread replies. Ground personalization in observed facts; disclose the relationship and make one easy next step. Do not claim a prior relationship or pad a shortlist. Before any send/post/invitation, prepare the account, named destinations/recipients, exact content, costs and volume/follow-up limit. Execute only an existing explicit bounded authorization or obtain the missing one. Account confirmation alone does not authorize sending. Stop on declines, access denial or platform restrictions; do not compensate for non-response with more volume.
4. **Save:** When the task includes saving, merge existing entries and complete notes according to the live `outreach`, `content`, `shortlist` or other template. Use current `workRevision`, reread/merge conflicts, and verify. Keep draft content separate from actual send receipts, responses and links. Preserve legacy findings. A save does not publish or end the action.
5. **Review:** Report qualified recipients, drafted/sent messages and actual responses separately. Compare observed signal, effort and window with the strategy's stop condition and mission. Ambiguous “wrap up” produces a summary and necessary clarification before an attempt-ending call. `record_action_result` requires explicit actual-result instruction and completed/failed intent, current `attemptNumber` and `outcomeRevision`, and accurate `measuredMetrics`; unknown is not zero. Use `record_action_feedback` only for an explicit founder vote.

## Output and fallback

Return qualified destinations with evidence/rules, exact drafts, approval scope still needed, actual execution evidence, save status and one next step. Missing browser/email capabilities: use another permitted integration, public research, or manual-ready messages with a response log. Missing MCP write access: keep the deliverable available without claiming persistence or broadening consent.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: startupsprints-strategy-execution
description: Use when a StartupSprints founder asks to advance a mission, continue a strategy or action, choose the next useful task, resolve a blocker, or work on a strategy without a specialist workflow.
---

# StartupSprints strategy execution

Advance the founder's mission by completing the next useful deliverable within the current strategy and constraints. User instructions and prior explicit approvals take precedence over recommendations.

Read [MCP workflow](references/mcp-workflow.md) before startup-specific work. Use [mission coordination](references/mission-coordination.md) for selection and specialist routing; [prompt examples](references/prompt-examples.md) provide reusable entry points.

## Inputs

Resolve the accessible startup, its confirmed mission and audience, selected action, current attempt, blockers, time/budget, founder preferences, existing work, and available capabilities. Ask only for missing facts or permissions that affect the next step; never ask the founder to type internal IDs that tools can resolve.

## Read → select → act → save → review

1. **Read:** Discover actual StartupSprints tools. Use `list_startups`; read `get_startup_profile`. For a requested strategy, find its returned `actionId` through `list_actions`. For “what next,” read `get_next_actions` and relevant `get_results`. Read `get_execution_brief` and `get_action_workspace` for the chosen action; read `get_distribution_kit` when needed. Keep `startupId` explicit on every startup-specific call with an all-startup connection.
2. **Select:** Relate the next deliverable to the mission and the uncertainty or prerequisite it resolves. Respect the founder's selected action and the server's eligibility. The focused plan has at most three actions; respect two actions in progress and three live experiments. Missing browser capability does not alter business eligibility.
3. **Act:** Produce the actual artifact, qualified evidence, repair, or operational measurement definition. Route to a relevant installed specialist when available; use the live brief and the local mission reference when it is absent. Complete independent preparation while a required decision or capability is pending. Confirm each authenticated service identity separately. Reuse a prior explicit confirmation and bounded approval; obtain any missing authorization before sending, publishing, booking, submitting, or spending.
4. **Save:** When requested or included in the task, merge current work and notes using live allowed fields. Send full replacements with current `workRevision`; reread and merge conflicts, then verify persistence. Reusable asset replacements require current `expectedUpdatedAt`. Preserve legacy findings. Saving a draft never starts or completes an experiment.
5. **Review:** Distinguish prepared, executed, and measured states. Compare observed evidence with the mission, success criteria, effort, window, and stop condition. Recommend one concrete next step. “Wrap up,” “done,” or “finish this task” is ambiguous: prepare a summary and clarify the intended completed/failed verdict before `record_action_result`. That call requires an explicit instruction to record actual outcomes, current `attemptNumber` and `outcomeRevision`, and only observed metrics in `measuredMetrics`. Unknown is not measured zero; never infer a usefulness vote.

## Output and fallback

Return the deliverable, why it advances the mission, evidence/uncertainty, actual progress, save status, and the smallest next action. If an integration is unavailable, use another permitted route or prepare work in chat/an authorized file; never claim unavailable access or persistence.

Referenced files: 3 — file references are metadata, not package contents.