segment-profile
Builds a data-based comparison profile of a subgroup (segment/persona) versus the rest of the sample from quantitative survey data (CSV): who they are, how they differ, what characterizes them. Result
SKILL.md.agents/skills/segment-profile/SKILL.md
GitHubSegment Profile
Goal: Characterize the subgroup described in the user's request with data and
contrast it against the rest of the sample — a basis for personas/audiences. Result as
Markdown in reports/.
Tool
python3 scripts/survey.py <cmd> [...] [--file CSV]
Run these from the project root. If scripts/survey.py is not there, check .claude/scripts/survey.py or locate survey.py in the project.
profile— column overview (always first).freq COL [--filter "COL=VALUE"]— distribution within the segment (filter) vs. overall.freq COL --by SEGMENT_COLUMN --sig— segment as a column against a trait, with the significance test, to separate real differences from noise.text COL [--filter ...] [--sample N]— verbatims from the segment.
COL = index (from profile) or an unambiguous name part.
Survey context
If a context document sits next to the CSV (<name>.context.md, or survey-context.md
when the folder holds exactly one CSV), read it before defining the segment. Its column
notes often name the segments the business actually cares about and which column carries
them — check there before inventing your own cut. The glossary keeps the profile in the
organization's own vocabulary. Figures still come only from the engine.
The "Who is missing" section matters doubly here: a segment profile describes a
subgroup of the respondents, and if the recruiting route already excluded a group, the
profile silently describes a filtered population. Put that in the method section.
Expectations listed in the document are something to test, never something to support —
a persona must not be shaped to match what someone assumed it looks like. If no such
document exists, proceed as before and mention survey-context once at the end.
Approach
- Define the segment. Translate the description into a concrete filter (e.g. usage frequency = "Daily"). Determine the segment size (n and % of the sample).
- Profile and pick characterizing traits (demographics, behavior, roles, tasks).
- Contrast. For each trait: distribution in the segment vs. overall/rest. The
interesting statements are the deviations ("above-average share of …"). Where
possible, check with
--sigwhether the difference is reliable. - Enrich qualitatively. Segment free text for typical needs/quotes.
- Save the report to
reports/(date +%F+ kebab title, never overwrite) and give a short characterization + path in your reply.
Report format
# Segment profile: <segment name>
**Data basis:** <file> · segment n = <…> (<…% of the sample>) · <date>
## Short characterization
2–3 sentences: who is this segment, what defines it?
## Traits compared
| Trait | Segment | Overall/rest | Notable |
|---|---:|---:|---|
| … | …% | …% | ↑ above average / ↓ / ≈ |
(Clear and, where checked, significant deviations first.)
## Behavior & needs
What the segment does (tasks/usage) and what it needs (free-text themes, 1–2 quotes).
## What this means in practice
Implications for product/communication/prioritization.
## Method
Segment definition (filter), traits compared, tests used, and — from the survey context —
which population the sample covers and who it does not.
Rules
- Always report relative: segment vs. overall/rest — the segment's absolute numbers alone say little. Deviations are the story.
- State segment size; caution when n < ~30.
- Use significance to separate chance from real differences.
- Report language = language of the request (default English). Keep it short.