competitive-profile
Skill0 starsChanged 3 months agoMITView on GitHub
Creates or updates competitive-profile.md — the one file describing your own company that every battlecard, deep-dive and one-pager reads from. Interviews the user about what they sell, who buys it, their value-promise axis, their defensible differentiators, where they honestly lose, pricing, and where internal evidence lives, then writes the profile. Use when someone asks to set up competitive intelligence, set up the battlecard skills, configure the competitor plugin, add or change their company profile, or fix the "us" column in competitive documents; and use it automatically, before doing anything else, whenever a battlecard, deep-dive or one-pager is requested and no competitive-profile.md exists yet.
In this repository3 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Every document in this set compares a competitor against your company.
- Distinctive: line 12
Run it once. Re-run it when the product, the pricing or the positioning changes.
- Very specific: line 16
Write it to competitive-profile.md in the folder the user is working in — the same place their competitor documents will be built.
- Distinctive: line 21
Before starting, look for an existing one:
- Distinctive: line 25
Ask, if the user seems likely to have one elsewhere.
- Distinctive: line 27
If a profile exists, read it and offer to update it rather than starting from scratch.
- Distinctive: line 37
Ask in this order. Don't dump all nine sections at once — go in small groups and let earlier answers sharpen later questions.
- Distinctive: line 89
When it's written, tell the user in plain language what it covers, where it is, and that they can hand it to a colleague — one profile …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Competitive profile setup
Every document in this set compares a competitor against your company. This skill produces the file that supplies your half. Without it, the "us" column is guesswork, and guesswork in a battlecard gets repeated out loud in a live deal.
Run it once. Re-run it when the product, the pricing or the positioning changes.
Where the profile lives
Write it to competitive-profile.md in the folder the user is working in — the
same place their competitor documents will be built. Never write it inside the
plugin directory: plugin files are a read-only cache that gets replaced on
update, so a profile written there is silently lost.
Before starting, look for an existing one:
./competitive-profile.mdin the working folder.- Any connected folder the user has open.
- Ask, if the user seems likely to have one elsewhere.
If a profile exists, read it and offer to update it rather than starting from scratch. Show what's already there, ask what changed, and edit in place.
How to run the interview
The template is at ../../shared/references/company-profile-template.md
(the plugin's shared/ folder — also reachable as
${CLAUDE_PLUGIN_ROOT}/shared/references/company-profile-template.md). Read it
first: it is the target shape, and it explains what each section is for.
Ask in this order. Don't dump all nine sections at once — go in small groups and let earlier answers sharpen later questions.
Round 1 — the basics. Company name, what they sell in one sentence, the category they compete in, and whether they're repositioning into a different one. Two minutes of conversation, not a form.
Round 2 — what ships. The products or modules a prospect can see in a demo, and for each, two or three named mechanisms. Push past adjectives: "intuitive" is not a mechanism, "approvals route by contract value with a documented escalation path" is. Ask explicitly what's on the roadmap versus shipped, and keep those apart — a roadmap item that leaks into a battlecard as a capability is the single most expensive error this whole set can make.
Round 3 — the axis. Most categories have one binary that separates vendors: automation vs. intelligence, speed vs. assurance, breadth vs. depth, tool vs. outcome. Ask which one theirs is and which side they're on. If they can't name one, say plainly that this is a positioning gap worth closing, and record it as open rather than inventing an axis for them.
Round 4 — differentiators, ranked by how hard they are to answer. Not by how much the user likes them. For each, get the mechanism and the internal document that proves it. Then ask, for each: what question would expose this if it were hollow? A differentiator with no good answer to that question isn't ready to go on a card, and it's much cheaper to find out here.
Round 5 — where they lose. Segments to avoid, capabilities competitors genuinely do better, known gaps, deal shapes they lose. Users often resist this one; it is the section that makes every other section believable, and sellers only trust a card that tells them when to stop. Ask directly: "what's the last deal you lost to a competitor, and why did they win it?"
Round 6 — buyers, pricing, and where evidence lives. Segment and scale in their own numbers, the buying committee, pricing model and what's disclosable, and which internal tools hold deal debriefs, capability docs, win/loss data and call notes. Record the actual tool names — the research steps in the other skills will go looking there first.
Round 7 — house style (optional). Brand colours as hex, the standing
prepared-for line, and any confidentiality marking. Colours feed the theme
block so every document in the set matches.
Writing the file
Fill the template's structure, keep its headings, and delete nothing — a section
the user couldn't answer stays in the file marked [not established], because
an empty heading is a visible prompt and a deleted one is forgotten.
Quote the user's own phrasing where it's good. This file gets read by whoever writes the next document, and a sentence in the founder's words beats a paraphrase.
When it's written, tell the user in plain language what it covers, where it is, and that they can hand it to a colleague — one profile serves the whole team.
Then what
Offer the natural next step: research a specific competitor with
competitor-deep-dive, or go straight to competitor-battlecard if they only
need the short card. Don't build anything without being asked.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

