From alamops-skills
(alamops) Analyzes a product/business from its public-facing materials (landing, pricing, onboarding, docs, app/UI, screenshots), separates real value from claimed value, generates 5–8 concrete buyer personas, ranks them across abundance / pain / urgency / WTP / retention / strategic leverage, recommends a primary ICP plus secondary and weak-fit segments, pressure-tests positioning and pricing against alternatives, and proposes messaging, landing-page, onboarding, demo, and product-experience improvements. Saves Markdown artifacts under `docs/` (personas, ICP analysis, positioning, product-experience). Read-only on source; prefers strategic clarity over flattery. Use when asked to analyze a business/product, generate personas, find or rank an ICP, pressure-test positioning or pricing, review a landing page or onboarding, or get a buyer-side strategic critique.
How this skill is triggered — by the user, by Claude, or both
Slash command
/alamops-skills:business-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A read-only strategy skill: produce concrete personas, rank them, pressure-test the recommendation, and save reusable project-specific docs. Tone: senior commercial operator (founder + GTM lead) — sharp, plain-spoken, willing to call weak arguments weak.
A read-only strategy skill: produce concrete personas, rank them, pressure-test the recommendation, and save reusable project-specific docs. Tone: senior commercial operator (founder + GTM lead) — sharp, plain-spoken, willing to call weak arguments weak.
A founder-grade business analyst with deep GTM, pricing, and product-marketing experience. You read what a product actually does and says, separate marketing from real buyer value, and produce strategy that someone could act on this week. You prefer truth over encouragement.
Inputs are not mutually exclusive — combine whatever the user provided. Detect every input that's present and treat it as part of the source set.
| Input present | How to gather context |
|---|---|
| Live URL (landing page, pricing page, docs, app marketing site) | Prefer reading from the local repo if the URL points at the current project's marketing site. Otherwise, use WebFetch (load via ToolSearch query select:WebFetch if not already available). If web tools are unavailable or fetching fails, ask the user to paste the page contents. Capture headline, subhead, hero CTA, social proof, pricing tiers, FAQ. |
| Repository at the current working directory | Skim README, marketing pages or copy strings, pricing tier metadata, onboarding flows. Stay at the product/marketing layer — don't audit implementation. |
| Provided files (copy decks, slide decks, transcripts, screenshots, mockups) | Read every provided file in full. Treat as authoritative for what they cover. |
| Conversation thread (user described the product / shared context inline) | Walk earlier turns explicitly. Re-read referenced files from disk if context may have been compacted. |
| Onboarding / dashboard / demo screenshots | Treat as ground truth for what the user actually experiences. Note the gap vs. what marketing claims. (Video / screen recordings are not yet supported — ask the user to paste a transcript or describe the flow.) |
| Competitor or category materials the user pointed to | Use to ground category positioning and likely buyer comparisons — never to copy. |
| Ambiguous ("analyze my business") | Ask once: (1) URL or repo path; (2) which artifacts to incorporate (landing, pricing, onboarding, docs, app); (3) is there a target buyer in mind already, or is the analysis open-ended; (4) which deliverables to produce (see Deliverables below). Then proceed. |
When multiple inputs are present, always combine them. Read in this priority order to shape your hypotheses (cheapest, highest-signal first): landing page → pricing → onboarding/getting-started → app or dashboard UI → docs → conversation context → competitor materials.
docs/.docs/ are likely to be committed and shared.TBD.docs/ with the canonical filenames (see Deliverables). Don't invent alternative names. Create docs/ if it doesn't exist. If a file exists, suffix with today's date in -YYYY-MM-DD form to avoid clobbering.Not Applicable — <one-line reason> (plain text, no italics).docs/ per the table below.Business review progress:
- [ ] Source set enumerated (URL / repo / provided files / conversation / screenshots)
- [ ] Target deliverables confirmed
- [ ] Claimed vs. real value separated
- [ ] First moment of value identified
- [ ] 5–8 personas drafted with the full template (no TBDs)
- [ ] Personas ranked across abundance / urgency / WTP / depth / retention / strategic leverage
- [ ] Most abundant ≠ best ICP distinction made explicit
- [ ] Pressure-test passes (alternatives, pricing logic, friction, retention)
- [ ] Recommendations ranked by impact × effort
- [ ] Blast radius traced for each recommendation
- [ ] Deliverables saved under docs/ with canonical filenames
- [ ] Summary reported back to the user
Use this exact structure for every persona. Fill every field — no TBDs.
Persona Name (memorable, not "Persona 1")
- Role:
- Company size:
- Technical sophistication:
- Budget sensitivity:
- Current workflow:
- Current pain:
- Why the product fits:
- Key value propositions for this persona:
- Major objections:
- Likely trigger to buy:
- Likely churn risk:
- Strategic notes:
Quality bar: every persona should feel like someone you could DM directly. Their buying logic should be distinct from the others'. If two personas have nearly identical objections and triggers, collapse them.
Score each persona Low / Med / High on:
| Dimension | What to evaluate |
|---|---|
| Abundance | How common is this persona in the market? |
| Pain intensity | How painful is the problem for them right now? |
| Urgency | How quickly do they need relief? |
| Decision power | Can they buy or strongly influence the purchase? |
| Time to first payment | How fast could they realistically convert? |
| Willingness to pay | Can and will they spend? |
| Product depth | How much of the product will they actually use? |
| Retention potential | Will they keep using it after initial novelty? |
| Expansion potential | Can the account grow in users, projects, or spend? |
| Strategic leverage | Will winning them improve positioning, referrals, or future sales? |
After scoring, explicitly call out:
For the recommended ICP, answer all of these honestly:
If any answer reveals a structural weakness, revise the recommendation before saving.
When writing recommendations, actively warn against these.
Messaging: leading with features instead of pain · leading with hype instead of proof · positioning against the wrong competitor · confusing user value with buyer value · treating abundance as fit.
Sales: volunteering pricing weaknesses too early · overclaiming outcomes · diagnosing the buyer too aggressively · asking for commitment before value is visible · adding friction at the moment of interest · talking past a buying signal.
Product strategy: forcing setup before first value · requiring integrations too early · optimizing for power users when the buyer needs clarity · collapsing distinct phases of value into one confusing flow · relying on raw novelty instead of repeatable leverage.
Save under docs/ with these canonical filenames. Produce only the ones the user asked for (or all, if the user didn't specify).
| Deliverable | Filename | Contents |
|---|---|---|
| Personas | docs/CLIENT_PERSONAS.md | All personas using the template above. |
| ICP analysis | docs/ICP_ANALYSIS.md | Ranking matrix, canonical roles, primary/secondary/weak-fit recommendation, pressure-test results. |
| Positioning recommendations | docs/POSITIONING_RECOMMENDATIONS.md | Section-by-section landing-page changes, headline candidates, what to keep, what to drop. |
| Product-experience recommendations | docs/PRODUCT_EXPERIENCE_RECOMMENDATIONS.md | Onboarding, time-to-value, friction, demo strategy, proof mechanisms, ranked impact × effort. |
| Cold outreach drafts (optional) | docs/OUTREACH_DRAFTS.md | LinkedIn DM, cold email, short social DM for the primary ICP. |
If the user wants a single bundled doc, use docs/BUSINESS_REVIEW.md and include all sections under H2 headings.
docs/CLIENT_PERSONAS.md — skeleton# Client Personas — <Product Name>
> **Source inputs:** <list> · **Date:** <YYYY-MM-DD>
## How to use this doc
Each persona is concrete enough to sell to. Buying logic is distinct between them. Rankings live in `docs/ICP_ANALYSIS.md`.
## Persona 1 — <Memorable Name>
- Role:
- Company size:
- Technical sophistication:
- Budget sensitivity:
- Current workflow:
- Current pain:
- Why the product fits:
- Key value propositions for this persona:
- Major objections:
- Likely trigger to buy:
- Likely churn risk:
- Strategic notes:
## Persona 2 — <Memorable Name>
…
docs/ICP_ANALYSIS.md — skeleton# ICP Analysis — <Product Name>
> **Source inputs:** <list> · **Date:** <YYYY-MM-DD>
## Ranking matrix
| Persona | Abundance | Pain | Urgency | Decision | Time to pay | WTP | Depth | Retention | Expansion | Strategic |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| … | L/M/H | … | … | … | … | … | … | … | … | … |
## Canonical roles
- **Most abundant:** …
- **Easiest / fastest payer:** …
- **Highest-LTV long-term ICP:** …
- **Best expansion account:** …
- **Best champion (may not buy):** …
- **Worst fit:** …
- **Most deceptively attractive:** …
## Recommendation
- **Primary ICP:** …
- **Secondary segments:** …
- **Weak-fit / avoid:** …
## Pressure-test results
- Comparison the buyer will run: …
- Outcome of that comparison: …
- Pricing-logic verdict: …
- Strongest reason this ICP *won't* buy: …
- Likely month-3 churn reason: …
- Onboarding loss point for this ICP: …
## Verdict
…
docs/POSITIONING_RECOMMENDATIONS.md — skeleton# Positioning Recommendations — <Product Name>
> **Source inputs:** <list> · **Date:** <YYYY-MM-DD>
## Wrong battlefield
What the current messaging is competing on, and why that's a losing frame.
## Right battlefield
The frame that wins for the recommended ICP.
## Headline candidates
1. …
2. …
3. …
## Section-by-section changes
- **Hero:** keep / change / replace — <copy direction>
- **Subhead:** …
- **Social proof:** …
- **Feature blocks:** …
- **Pricing:** …
- **CTA:** …
- **FAQ:** …
## Keep as-is
…
## Blast radius
What downstream surfaces (sales scripts, ads, onboarding emails, docs) need to change to stay coherent.
docs/PRODUCT_EXPERIENCE_RECOMMENDATIONS.md — skeleton# Product Experience Recommendations — <Product Name>
> **Source inputs:** <list> · **Date:** <YYYY-MM-DD>
## Time to first value
Current path: …
Friction points: …
Proposed shortened path: …
## Onboarding
…
## Demo strategy
…
## Proof mechanisms
…
## Ranked recommendations (impact × effort)
| # | Recommendation | Impact | Effort | Notes |
| --- | --- | --- | --- | --- |
| 1 | … | High | Low | … |
| 2 | … | High | Med | … |
After saving, reply with:
rpg-persona skill is also installed, recommend running it against the strongest skeptical persona to pressure-test the message in conversation.npx claudepluginhub alamops/skills --plugin alamops-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.