Plan customer reach
Skill kimsanguine/signal-to-growth/skills/plan-customer-reach
Evidence-driven skills that turn customer signals into measurable growth.
npx -y skills add kimsanguine/signal-to-growth --skill plan-customer-reachAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 12 days oldThe repository was created 12 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Plan consent-aware customer research recruitment and draft-only outreach without sending messages. Use when defining interview segments, recruiting participants, selecting channels, or preparing 고객 인터뷰 대상자·모집·컨택 초안.
SKILL.md
2.6 KB, 476 tokens by cl100k_base, as published. Nobody here has run it
Plan Customer Reach
Create a research recruitment plan that separates who to learn from, why their experience matters, and what requires human approval.
Inputs
Require:
- a research question;
- candidate segment hypotheses;
- inclusion and exclusion criteria;
- channel and capacity constraints;
- consent, privacy, incentive, and retention policies.
If the research question asks which feature people want, restate it around a past behavior or unresolved decision before planning recruitment.
Workflow
- Define the decision the research will inform.
- Describe candidate segments by recent behavior, context, and role. Do not define a segment only by demographics.
- Separate B2B buyer, user, approver, and administrator roles when they can experience different jobs.
- State inclusion, exclusion, and sampling-bias risks.
- Choose channels based on where the target behavior is observable.
- Draft a short invitation that states purpose, time, incentive, data use, and voluntary participation.
- Create a recruitment log with status, consent state, and no unnecessary personal data.
- Stop at drafts. Ask for explicit approval before any email, direct message, form submission, or public post.
Boundaries
- Let the model propose segments, channels, and wording.
- Use deterministic checks for required consent fields, duplicated candidates, private-data patterns, and
external_send=false. - Require a person to approve targets, incentives, channel rules, and every external send.
- Do not invent response-rate benchmarks or treat a participant count as universal evidence sufficiency.
- Do not scrape or enrich private contact information.
Outputs
Create:
reach-plan.jsoncontact-drafts.mdrecruitment-log.csv
Read references/output-contract.md before writing them.
Stop conditions
Stop and report the missing decision when:
- consent or retention policy is absent;
- the segment cannot be connected to the research question;
- recruitment depends on restricted data;
- an invitation makes a product or payment promise;
- the user asks to send without naming targets and approving the final draft.
Verification
Run:
python3 scripts/stg.py scan-privacy contact-drafts.md
Confirm that every external action remains a draft and that observed facts, assumptions, and recommendations are labeled separately.
Gives 0 of the 12 instructions most plan spec skills give in 476 tokens
Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06
- ask one question at a timein 46 of 1100, across 38 files
- Break plans into vertical slicesin 28 of 1100, across 10 files
- Publish issues in dependency orderin 27 of 1100, across 9 files
- Iterate until user approves the breakdownin 24 of 1100, across 6 files
- Explore the repository to understand the codebase statein 24 of 1100, across 7 files
- Use domain glossary vocabularyin 23 of 1100, across 5 files
- Apply correct triage labels to published issuesin 23 of 1100, across 5 files
- Write failing tests before implementation codein 23 of 1100, across 18 files
- Prefer AFK slices over HITLin 22 of 1100, across 7 files
- ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
- Respect existing architecture decision recordsin 20 of 1100, across 5 files
- write a specification before writing any codein 20 of 1100, across 12 files
Said here and by no other author read
- Require a research question
- Restate feature questions around past behavior
- Define the decision the research informs
- Describe segments by recent behavior and context
- Separate B2B buyer and user roles
- State inclusion, exclusion, and bias risks
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.