What it does
This skill takes a target company's website URL (and optionally a LinkedIn page or a recent news link) and produces a one-page brief built for the two minutes before a rep dials. The job it replaces is the half-hour of tab-flipping every rep does badly and inconsistently: skim the homepage, guess the business model, half-read the careers page, and walk into the call with a vague sense of the account and no actual hook. The skill forces Claude to read the live pages and organize what it finds into the exact sections a rep uses in the moment, what the company does, how it makes money, what changed recently, who to call, and three things to open with.
The line between a good version and a bad version of this is entirely about discipline, not length. A bad account brief is a wall of facts scraped off the homepage with no point of view, where the rep can't tell what's a confirmed fact versus a guess, so they either repeat a hallucinated detail on the call (instant credibility loss) or ignore the brief entirely. A good one is short, opinionated, and ruthless about provenance: every claim is tagged as Confirmed (read from a named page) or Inferred (the model's reasoning), and the Inferred items are framed as hypotheses to test on the call rather than statements to assert. That single Confirmed-vs-Inferred split is what makes the output trustworthy enough to actually use live.
It beats doing the task manually in three ways. First, consistency, every brief has the same structure, so a rep's pre-call ritual becomes a 30-second scan instead of a fresh research project each time. Second, signal extraction, the model is good at noticing that five open BDR roles plus a new product page implies an outbound build-out, a connection most reps make only after the call. Third, it maps the research to what you sell: give it your one-line value prop and the talking points stop being generic and start pointing at the specific reason this account might buy now.
Where it does not help: it is not an enrichment tool and will not invent firmographics, funding amounts, or headcounts it can't read. If web access is off or the pages are thin, it says so and degrades to clearly-labeled inferences rather than fabricating specifics. Treat it as a reading-and-structuring layer on top of public pages, not a data provider.
Inputs & outputs
Inputs
- Company website URL (required)
- Optional: LinkedIn company page URL
- Optional: a recent press release, funding announcement, or news link
- Optional: your product's one-line value prop and the outcome you drive, so talking points map to what you sell
- Optional: the persona/title you expect to reach on the first call
Outputs
- A one-page brief with: Snapshot, What they do, Business model, Signals & timing, Who to talk to, Pain hypothesis, Three talking points, and Open questions
- An explicit Confirmed vs. Inferred tag on every non-obvious claim, plus a recap section
- A list of the exact pages the brief was built from, so a rep can spot-check anything
- Talking points written as spoken lines, each referencing a specific detail from the brief
How to set it up
Decide where the skill lives
You have three options and they all work. (1) If you use claude.ai, create a Project named something like "Account Briefs", open Project settings, and paste the entire SKILL.md body below into the custom instructions box. Every chat started in that Project will now behave as the skill. (2) If you use Claude Code or the Claude Desktop skills feature, create a folder named account-brief, save the content below as account-brief/SKILL.md, and drop the folder into your skills directory so Claude loads it on demand. (3) Lightest weight: save the SKILL.md text somewhere handy and paste it as the first message of a new chat, then send the URL as the second message.
The Project approach is the one most reps should use, it means the value prop and voice context persist, and invoking the skill is just pasting a URL.
Turn on web access
This skill is only as good as the pages Claude can actually read. In your Claude environment, enable web search/fetch. If your environment can't fetch pages, paste the homepage and About-page text directly into the chat as an attachment or block of text, the skill handles that fine. With no source material at all, it will still produce the structure but mark every claim as Inferred and tell you it's working blind; that is the correct failure mode, not a bug.
Calibrate it once with your value prop
The first time you use it in a Project, add one line: "We sell
Invoke it with a URL
Send: "Run the account-brief skill on https://example.com." If you didn't set a value prop in the Project, add it inline. To sharpen the brief, attach any extra signal you already have, a LinkedIn post from the buyer, a funding article, a job posting. The more real signal you feed it, the less it has to infer.
Read the Inferred section first, then prep
Before the call, glance at the Confirmed-vs-Inferred recap. Treat everything under Inferred as a hypothesis to test, never a fact to assert, this one habit prevents the most common research-brief failure, which is a rep confidently repeating something the model guessed. Memorize the three talking points and the single pain hypothesis. That's the whole pre-call ritual.
The SKILL.md
Save this as SKILL.md inside a folder named account-brief, or paste the body into a Claude Project's custom instructions. Then ask Claude to run it on any company URL.
---
name: account-brief
description: Use when a rep needs a first-call brief on a target account from just a company URL. Reads the live company pages and produces a one-page, source-grounded brief covering company, business model, buying signals, stakeholders, a pain hypothesis, and three talking points, with an explicit split between confirmed facts and inferences. Never fabricates firmographics.
---
# Account Brief
You produce a tight, first-call account brief for a B2B sales rep. The rep will read this in under two minutes right before dialing, and may reference it live. Be concrete, opinionated, and short. Never pad. A brief that is long and hedged is a failed brief.
## Inputs
- A company website URL (required).
- Optionally: a LinkedIn company page, a news/funding link, the rep's one-line value prop and the outcome they drive, and the target persona.
## Method
1. Read the source. Fetch the homepage first. Then attempt, in order: an About / Company page, a Customers / Case Studies page, a Pricing page, a Product page, and a Careers / Jobs page. Note which pages you actually fetched. If a fetch fails or a page does not exist, do not invent its contents and do not guess what it would have said.
2. Extract facts only from what you actually read. For every fact you record, know which page it came from, you will need this for the sources list and the Confirmed/Inferred tagging.
3. Determine the business model: who pays, for what, and roughly how (self-serve vs sales-led; per-seat vs usage-based; one-time vs subscription). State it in one or two sentences. If the signals are ambiguous, say so and tag it Inferred rather than picking one confidently.
4. Read growth and timing signals: open roles (especially in the function you sell to), recent product launches, funding events, new markets or geos, leadership changes, and pricing/packaging changes. These are the "why now" raw material.
5. Form exactly ONE pain hypothesis: given what they do and the signals you found, what is the single problem they are most likely feeling that the rep's product addresses? If no value prop was provided, frame the pain in the company's own terms rather than around a product. Keep it to one or two sentences and mark it Inferred.
6. Pick the 2-3 personas worth contacting. For each, say in one clause why they would feel the pain now.
7. Write three opening talking points the rep can say out loud, verbatim. Each must reference something specific from the brief, a page, a role count, a launch, not a platitude. "I see you're growing" is banned. "Saw you opened five BDR seats this quarter" is the standard.
8. List 3-5 open questions the rep should ask on the call to confirm or kill the hypothesis.
## Hard rules
- Confirmed vs Inferred. Every non-obvious claim is tagged. Confirmed = you read it on a named page. Inferred = your reasoning from what you read. If you did not read it and cannot reason to it, it does not appear.
- Never fabricate. No invented funding amounts, customer logos, employee counts, revenue figures, or executive names. If a number is unknown, write "unknown", do not estimate a specific figure and present it as fact. A rounded range tagged Inferred (e.g. "~80-120 employees, Inferred from 14 open roles") is acceptable; a precise fabricated number is not.
- If you could not fetch any pages, say so plainly at the top, produce the structure anyway from whatever the user gave you, and tag everything Inferred.
- Keep the whole brief to roughly one page. Cut adjectives before you cut facts.
## Output template
**Account Brief: <Company>, <today's date>**
Sources read: <comma-separated list of the actual URLs/pages fetched, or "none, working from limited input">
**Snapshot**
- Category / industry: <...> (Confirmed/Inferred)
- Size estimate: <employees or stage> (Confirmed/Inferred)
- HQ / markets: <...> (Confirmed/Inferred)
**What they do**
<2-3 plain-language sentences. No marketing copy.>
**Business model**
<1-2 sentences. Tag Inferred if ambiguous.>
**Signals & timing**
- <signal> (Confirmed/Inferred)
- <signal> (Confirmed/Inferred)
**Who to talk to**
- <Persona / title>, why now
- <Persona / title>, why now
**Pain hypothesis** (Inferred)
<1-2 sentences.>
**Three talking points** (spoken lines)
1. "<...>"
2. "<...>"
3. "<...>"
**Open questions for the call**
- <...>
- <...>
- <...>
**Confirmed vs Inferred recap**
- Confirmed: <the 2-3 load-bearing facts you actually read>
- Inferred: <the key guesses the rep should test, not assert>
Run it from the terminal
Example run
An SDR runs the skill on a fictional API-observability startup before a first call, having set the value prop in the Project once.
Prompt: Run the account-brief skill on https://acme-observe.com. We sell an AI SDR that books meetings while new reps ramp; we sell to VP Sales and Head of RevOps.
Output:
Account Brief: Acme Observe, 2026-06-10
Sources read: homepage, /product, /customers, /careers
Snapshot
- Category: API observability / tracing (Confirmed, homepage)
- Size estimate: ~80-120 employees, likely Series B (Inferred from 14 open roles + investor logos on /customers)
- HQ / markets: US HQ, EU customers listed (Confirmed, /customers)
What they do
They sell a monitoring and distributed-tracing platform for engineering teams running API-heavy backends. New on the homepage: an "AI tracing" feature that auto-surfaces anomalies.
Business model
Sales-led, seat-plus-usage SaaS, pricing page gates higher tiers behind "contact us" and mentions data-volume tiers (Confirmed, /pricing).
Signals & timing
- 5 open Sales/BDR roles posted this quarter (Confirmed, /careers), Inferred: scaling outbound now
- New AI tracing product front-and-center on homepage (Confirmed), Inferred: pushing into a new buyer/segment
- EU logos added to /customers (Confirmed), Inferred: recent geo expansion
Who to talk to
- VP Sales, owns the outbound build-out the careers page implies
- Head of RevOps, would feel pipeline-coverage pain first as headcount ramps
Pain hypothesis (Inferred)
They're hiring reps faster than those reps can generate pipeline, so coverage will dip during ramp, exactly the gap an AI SDR fills.
Three talking points
1. "Saw you opened five BDR seats this quarter, usually that means pipeline coverage gets tight before the new reps are productive."
2. "Your new AI tracing launch reads like a fresh ICP motion; teams seeding outbound into a new segment are who we tend to help most."
3. "We run an AI SDR that books meetings so your new hires inherit pipeline instead of starting cold, worth 15 minutes?"
Open questions for the call
- How are you measuring pipeline coverage as the new BDRs ramp?
- Is the AI tracing launch aimed at your existing base or a new segment?
- Who signs off on a tool that touches the SDR workflow?
Confirmed vs Inferred recap
- Confirmed: API observability category; 5 BDR roles open; new AI tracing product; EU customers.
- Inferred: Series B stage, ~80-120 employees, the coverage-gap pain, the new-segment motion, all hypotheses to test, not facts to state.