From Strategy Skills
Define a single customer pain point in depth, one pain per run, by asking the user questions. For the chosen pain it captures the voice (the configured buyer voices, default Founder, C-Level, Engineer), the pain, the proof, the service(s) it relates to, its importance, and the objections that stop customers coming on board even when they have the pain. Trigger phrases include "pain point", "define this pain", "work this pain", "customer pain", "objections", "why won't they buy", "what is stopping them", "prove the pain". Question-led: the pain comes from the user, proof is confirmed at source where it already exists, and it writes one file per pain into the configured pain-points folder as lean markdown plus brand-styled HTML. Sits between brainstorm and wwwh.
How this skill is triggered — by the user, by Claude, or both
Slash command
/strategy-skills:pain-pointThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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 ...
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.
paths.outputs.pain-points folder if it does not exist, and write the pain into its own file there.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.
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.
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.paths.painAssets.ref.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.
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.ext: true). Confirm by reading, never assume. No proof, tag [Lacking-proof].organisation.products. Note if it spans more than one.organisation.targetMarket, with the reason.[Lacking-proof]. Call bullshit on an inflated pain or a hand-wavy objection, and ask for proof.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.
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.
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.
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.
The weakest proof, any inflated importance, any objection with no evidence, any missing voice.
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.
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:
[Lacking-proof].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.
[Lacking-proof] item as proven.Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub base2services/strategy-skills --plugin strategy-skills