surveys
Manages the founder's survey-based validation — crafting the right questions, deploying a survey to the internet, and analyzing results against hypotheses. Use when the founder wants to run a survey, create survey questions, validate hypotheses at scale, check how a survey is going, understand whether a survey is the right tool right now, or deploy a question set to get quantitative signal. Also bring this up if you believe that creating a survey to collect quantitative evidence may be useful at this point.
What this skill does
# Surveys
Help the founder use surveys as a quantitative validation layer — to confirm patterns found in interviews, prioritize among competing hypotheses, or reach people they can't interview one-on-one.
Surveys are powerful when they're targeted, short, and posted somewhere with the right audience. They're much weaker when deployed before any qualitative discovery, when the distribution channel is vague, or when the questions fish for validation instead of testing assumptions. Part of this skill's job is to help the founder assess fit before building anything.
This skill covers two modes:
1. **Just the questions** — crafting a tight, hypothesis-linked question set the founder can paste into any survey tool or share however they like.
2. **Active Tally mode** — creating the survey in Tally via the Tally MCP, returning a shareable link, and later fetching and analyzing results.
---
## Before you start
Read `startup/core.md` to load project context.
Check prior qualitative work: scan `startup/hypotheses/` and `startup/interviews/`. It is sometimes ok to go for a survey without doing interviews, especially if the user knows and/or has access to a good channel to distribute the survey to aquire diverse responses. Procceeding to survey without hypotheses is not recommended. If no hypotheses present, invoke the `hypotheses` skill and strongly suggest the user to talk about them first.
Scaffold the surveys folder if it doesn't exist yet:
```bash
mkdir -p startup/surveys
```
---
## Applicability assessment
Use judgment when assessing whether surveys make sense right now. This is advisory — never a gate.
**Good signals:**
- The founder has run at least a few interviews (surveys confirm patterns, they rarely discover them)
- There are untested or partially-tested hypotheses that quantitative signal would clarify
- The founder has (or can reach) a channel with a relevant, targetable audience
**Caution signals — raise these, don't block:**
- No interviews done yet: surveys without prior qualitative discovery often surface misleading signal — people answer what sounds good, not what they actually do
- No identified distribution channel: a well-crafted survey shared with the wrong audience (or no audience) is wasted effort
- The idea is still being shaped: surveys freeze assumptions; if core.md is still in flux, hypothesis-testing surveys may be premature
If the founder insists on a survey despite caution signals, help them build a good one. The goal is to inform, not gatekeep.
---
## When no surveys exist
Share a brief applicability assessment (2–3 sentences): what's looking solid, what the risk is, whether this is a good moment for surveys. Then ask if they'd like to proceed.
If proceeding, load the reference file:
```
.claude/skills/surveys/references/initial-survey-questions.md
```
The reference file's instructions take over from this point.
---
## When surveys already exist
Load and read the relevant files for context. Infer intent from the conversation — don't mechanically ask "what do you want to do?" If the founder is:
- **Reviewing or editing a survey** — load the file, discuss, propose the specific changes, get confirmation, write back
- **Adding a new survey** — load `initial-survey-questions.md`
- **Activating a questions-only survey in Tally** — load the relevant survey file to confirm the question set, then load:
```
.claude/skills/surveys/references/tally-survey.md
```
- **Checking results or asking how a survey is going** — for now, fetch the Tally submission count via the Tally MCP if configured and share a quick status. Full results analysis workflow (dispatching the `survey-analyst` subagent) is coming in a later version of this skill.
- **Archiving a survey** — read the file, set `status: archived`, propose the change, get confirmation, write back
When adding or updating surveys, follow these file conventions:
**File location:** `startup/surveys/{YYYY-MM-DD}-{short-descriptor}.md`
**Slug convention:** lowercase, replace spaces and non-alphanumeric characters with hyphens, collapse multiples. "Invoice chasing validation" → `invoice-chasing-validation`.
**Frontmatter:**
```yaml
---
status: draft|ready|active|closed|archived
mode: questions-only|tally
date_created: YYYY-MM-DD
target_persona: One-line segment descriptor
hypothesis_slugs:
- slug-one
- slug-two
response_goal: 30
tally_form_id: abc123 # tally mode only — omit if questions-only
tally_url: https://tally.so/r/abc123 # tally mode only — omit if questions-only
---
```
**Required sections:**
- `## Purpose` — why this survey exists and what decisions it will inform
- `## Target Audience` — who should fill it out, response goal, and why that sample size
- `## Distribution Plan` — where to post it and what value is offered to respondents
- `## Questions` — numbered list with question type annotated
**Optional sections:**
- `## Notes` — founder comments, links to related interviews, context for later
- `## Results` — populated after fetching Tally data
Read before writing, propose before saving, get confirmation.
---
## After saving a survey
Briefly confirm: "Saved to `startup/surveys/{slug}.md`."
Mention natural next steps without pushing:
- If `mode: questions-only` — when ready, the agent can deploy to Tally and return a shareable link
- If `mode: tally` and `status: active` — remind the founder they can ask "how's the survey going?" at any time
- Triangulating with interviews tends to give the strongest signal: survey results show what, interviews show why
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.