pain-point

pain-point — define one pain point, by asking

What this skill does

Works a single customer pain point in depth, one pain per run, so the focus stays on that one pain. It is question-led: you answer, the corpus proves. For the chosen pain it pins down six things: the voice who feels it, the pain, the proof, the service(s) it relates to, its importance, and the objections that stop a customer acting on it even though they have it. It writes one file per pain into the pain points folder, and ends locked as trusted when you are satisfied.

Run it again for the next pain. Each pain is its own file.

Hard rules for this skill

• One pain per run. Do not build a multi-pain register. Stay on the single pain in scope.
• One file per pain. Create the configured paths.outputs.pain-points folder if it does not exist, and write the pain into its own file there.
• The pain comes from the user, not a list. This skill is question-led. The pain is whatever the user names and describes. Do not default to a pre-built pain list or spreadsheet as the source of pains.
• Never write to research files. Any research, corpus or spreadsheet file is read-only reference. Never edit them.
• Ask, do not assume. The purpose is that you ASK the questions. You may review a specific transcript and analyse it when the user tells you to, but the default mode is questions, not bulk analysis.

Before anything else

Read the shared backbone in full. It is at ${CLAUDE_PLUGIN_ROOT}/reference/shared.md, or if that variable is unset, at <paths.pluginRoot>/reference/shared.md resolved against ${CLAUDE_PROJECT_DIR}/.strategy-skills/config.json. It covers loading the config, the work stages, the evidence discipline, the phase gate and the voice rules, all mandatory here. If .strategy-skills/config.json does not exist, stop and run the setup skill first. Read the voices, products, target market, folders and facts from the config, never hardcode them.

Where proof might already exist (optional, not the source of pains)

The pain itself always comes from the user. These are only places a confirming quote might already exist. Use them to prove a pain, never as the go-to list of pains. They apply only if paths.painAssets is set in the config; otherwise skip straight to asking.

• Proof quotes: paths.painAssets.evidence. A list of {svc, pain, voice, ext, q, who, src}. ext: true is an external customer quote, the strongest proof. If a quote for the pain already sits here, confirm it at source and use it.
• Articulations by voice: paths.painAssets.ref.
• On request only: a transcript the user names from the configured paths.research corpus. Review and analyse it only when the user asks.

If no proof exists, ask the user, and if none comes, mark it [Lacking-proof]. Do not go hunting a spreadsheet for the pain.

The six fields (capture all six for the one pain)

1. Voice — the configured organisation.voices (default Founder, C-Level, Engineer). Capture how the pain reads to each voice that feels it. Extend to another voice only with evidence.
2. Pain — one clear sentence, in the voice's language.
3. Proof — a confirmed quote, with who said it and the source. Prefer external customer quotes (ext: true). Confirm by reading, never assume. No proof, tag [Lacking-proof].
4. Service(s) — one or more of the configured organisation.products. Note if it spans more than one.
5. Importance — High, Medium or Low for the configured organisation.targetMarket, with the reason.
6. Objections — why a customer who has this pain still does not come on board, and why they object. Drawn from the user, evidence-checked, rated on how common and how strong each one is.

Operating principles (non-negotiable)

1. Two-way Q&A, and it is mostly you asking. If you have not asked the user real questions, you are not running this skill.
2. Open questions first. Lead with open questions the user answers in their own words. Multiple choice only to confirm or narrow.
3. Do not force. The pain and the objections are confirmed or supplied by the user, not invented by you.
4. Evidence or it is not fact. Confirm every proof at source. A pain or objection with no proof is [Lacking-proof]. Call bullshit on an inflated pain or a hand-wavy objection, and ask for proof.
5. Visualise with small tables, and 2 to 3 option choices only where a real call is needed.
6. The user holds the gate. Draft until the user locks it.
7. Delegate corpus filtering and proof verification to sub-agents, keep the questions in the main thread.
8. Lean output. A concise pain file, not a transcript.
9. Honest on pain. Do not inflate a pain to make a service look needed. The strongest pain file is the true one.

The flow (one pain)

1. Scope the one pain

Confirm the single pain in scope and why we are doing it now, in the user's words. The pain is whatever the user names, not a row picked from a list. Do not widen to other pains.

2. Evidence on hand (optional)

If paths.painAssets is configured and a confirming quote for this pain already exists in paths.painAssets.evidence, pull it and confirm it at source. If the user points you at a transcript, review and analyse that one. Otherwise, go straight to asking. Proof supports the pain, it does not supply it.

3. Ask through the fields

One open question at a time: the voice and how they feel it, the pain in their words, the service, the importance and why. Confirm any proof at source as you go.

4. Objections (the heart of this skill)

Ask openly: who has this pain but still does not come on board, what do they object to, and why. Draw it out in the user's words. Evidence-check against the record where it exists, mark [Lacking-proof] where it is opinion, and rate each objection on how common and how strong.

5. Pressure-test

The weakest proof, any inflated importance, any objection with no evidence, any missing voice.

6. Lock-in gate (user only)

Ask: "Are you satisfied to lock this pain point in as trusted, or do you want to keep going?" Only the user locks it. On the yes, write the single pain file.

Output (one file per pain)

Folder: paths.outputs.pain-points from the config (create it if missing). Never the spreadsheet, never a corpus file.

File: YYYY-MM-DD-<service>-<pain-slug>.md plus the matching brand-styled .html. One pain, one file.

Sections, in order:

• Purpose — the one pain and why it is being defined now.
• What the user provided — the user's input, especially the objections, in their words.
• The pain — Voice(s), Pain, Service(s).
• Proof — the confirmed quote(s), who and source, or [Lacking-proof].
• Importance — rating and the reason.
• Objections — table: objection | why they object | evidence | how common and how strong.
• Evidence ledger — table with tags.
• Open questions and lacking-proof.
• Lock status — Draft or Locked / Trusted, with date.

Render the HTML. ${PLUGIN_ROOT} is ${CLAUDE_PLUGIN_ROOT} when set, else ${CLAUDE_PROJECT_DIR}/<paths.pluginRoot>. Write into paths.outputs.pain-points. The renderer reads the config for brand, organisation and author:

python "${PLUGIN_ROOT}/scripts/generate-html.py" \
  "${CLAUDE_PROJECT_DIR}/<pain-points>/YYYY-MM-DD-<service>-<pain-slug>.md" \
  "${CLAUDE_PROJECT_DIR}/<pain-points>/YYYY-MM-DD-<service>-<pain-slug>.html" \
  --title "<Pain> (<Service>)" --subtitle "Pain point" --status "Locked / Trusted"

Use --status "Draft" until the user locks it.

Red flags — stop

• Building a multi-pain register instead of one focused pain file.
• Writing to any research or corpus file, or treating a pre-built spreadsheet as the source of pains.
• Analysing a transcript when the user has not asked you to, instead of asking questions.
• A pain with no voice, or proof assumed from a filename instead of read.
• Inflating importance to justify a service, or inventing objections rather than drawing them from the user.
• A bloated file, declaring it done yourself, or carrying a [Lacking-proof] item as proven.