skills/battlecard-doc/SKILL.md
Visual competitive battlecard document rendered as interactive HTML with expandable sections and color-coded comparisons. Use when user says "battlecard document", "visual battlecard", "competitive reference doc", or wants a formatted HTML version of competitive intelligence. Do NOT use for text-based competitive analysis — use /octave:battlecard-doc instead.
npx skillsauth add octavehq/lfgtm battlecard-docInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate polished, self-contained HTML deal cards powered by your Octave GTM knowledge base. Deal-specific competitive weapons designed to be picked up before a call and immediately tell you what to say. Side-by-side comparison grids, scannable sub-cards, and layered pitch sections make these documents usable under pressure.
Unlike /octave:battlecard-doc which outputs text-based competitive intelligence, this skill renders that intelligence as a styled, interactive HTML document with visual hierarchy. Unlike /octave:deck which builds presentations for audiences, this is an internal reference document for individual use.
Resolve the brand before generating (do not skip this step). The document brand should be the workspace company's brand — that is, the Octave customer whose workspace you are operating in. The target company's logo (the prospect/competitor) can appear in the deal context section (1-2 places) but does not control the document's design system.
Step 1: Identify the workspace company. Call get_workspace_company to get the company name, domain/URL, and positioning. This is the company whose brand the document should use (whatever get_workspace_company returns is the brand, not the target account).
Step 2: Resolve the workspace company's brand kit. Slugify the workspace company name and check for a cached brand kit at ~/.octave/brands/<slug>/manifest.json. If a complete kit exists (has manifest.json and tokens.css), use it automatically:
tokens.css (:root + the embedded @font-face) and get-brand-components/assets/kit_base.css into the output <style>;brand-kit.md → Signature moves, and reuse the kit's real logo for topbar and footer, images/, and icons.json.
If no complete kit exists → build one. Run the get-brand-components skill (read ../../skills/get-brand-components/SKILL.md and follow it) for the workspace company's domain. If the first attempt returns incomplete results (no logo, no colors, partial data) → retry up to 3 times with different approaches (root domain, www. prefix, /about subpage). Only fall back to a generic preset after 3 genuine failures.Step 3: Fetch the target company's logo. Use get_external_brand_logo or get_external_brand_assets to get the prospect's logo. Place it in the topbar "prepared for" area and optionally in the deal context section. Do not use it for the document's overall design system — that uses the workspace company's brand.
Step 4: Only use a generic preset as a last resort — after the workspace company's brand kit cannot be built.
⚠️ STRONG DEFAULT: The document is always branded as the workspace company (the Octave customer). The prospect's logo appears in the topbar and content to personalize the battlecard, but the overall look and feel — fonts, colors, topbar, footer — is the workspace company's brand. This is not the prospect's document; it is the workspace company's document about them.
Read these files before writing any HTML. They govern language, layout, and content decisions during generation -- not just during review.
Apply these rules during generation, not just at review. After generating, the review pipeline is a mandatory gate (see Step 4) -- the battlecard is not opened or delivered until the scorecard is produced.
/octave:battlecard-doc [--competitor <name(s)>]
/octave:battlecard-doc --competitor "Gong" # Deal card vs Gong
/octave:battlecard-doc --competitor "Auth0,FusionAuth" # Multi-competitor deal card
/octave:battlecard-doc # Pick account + competitors interactively
/octave:battlecard-doc --competitor "all" # Full competitive landscape doc
When the user runs /octave:battlecard-doc:
Parse the user's request for:
If the account and competitors are clear from the user's message or conversation context, proceed directly. Do NOT present a competitor picker, scope selector, or outline approval gate. The goal is zero ceremony -- just output the card.
The document adapts to competitor count and deal shape:
If truly ambiguous (no account or competitors identifiable), ask once:
Who's the account and which competitor(s) are you facing?
Use Octave MCP tools to build rich competitive context. Always tell the user what you're researching and why.
Call as many tools as needed to build a complete picture. The best battlecard documents come from layering multiple sources -- competitor profiles + deal outcomes + conversation evidence + proof points all combine to create a reference grounded in real data. Don't stop at one tool when three would give you a stronger document.
See tool-reference.md for the list-vs-search guidance and the tool reference tables for single-competitor and landscape modes.
Do NOT present an outline for approval. Proceed directly to generation.
Build a single, self-contained HTML file. No external dependencies except Google Fonts. Everything else inlined.
Save the battlecard under .octave-decks/:
.octave-decks/
└── battlecard-<competitor-kebab>-<YYYY-MM-DD>/
└── battlecard-<competitor-kebab>.html
Example: /octave:battlecard-doc --competitor "Gong" produces .octave-decks/battlecard-gong-2026-02-11/battlecard-gong.html
For landscape: .octave-decks/battlecard-landscape-2026-02-11/battlecard-landscape.html
The entire .octave-decks/ directory is in .gitignore -- nothing here gets committed.
See single-competitor-sections.md for the deal card document section specs (handles 1-N competitors).
See landscape-sections.md for the landscape overview document section specs.
See html-architecture.md for the full HTML/CSS scaffold, landscape-mode component swaps, and key HTML/CSS principles.
After writing the file, proceed immediately to Step 4 (Review Pipeline). Do NOT open the file in the browser or present the delivery summary yet.
Do NOT open the deal card in the browser, present the delivery summary, or tell the user it is ready until the review pipeline has completed and you have a scorecard.
Load the review protocol and execute the review loop against the generated HTML file. Battlecard-specific wiring:
4a: Mechanical lint (before spawning reviewers):
bash <skill-dir>/scripts/lint.sh <path-to-battlecard.html>
Fix every violation the lint surfaces.
4b: Spawn two reviewers in parallel (both Task calls in a single message):
Editorial reviewer:
Task tool:
subagent_type: "octave-editorial-reviewer"
prompt: "Review the file at [FILE PATH].
Read these principle docs and run each Review Checklist:
1. [skill-dir]/../shared/editorial-rules.md
2. [skill-dir]/../shared/information-principles.md
Fix violations inline. Return scorecard."
Presentation reviewer:
Task tool:
subagent_type: "octave-presentation-reviewer"
prompt: "Review the file at [FILE PATH].
Read these docs and run each Review Checklist:
1. [skill-dir]/../shared/presentation-principles.md
2. [skill-dir]/../shared/formats/html-document.md
3. [skill-dir]/references/html-architecture.md
(skill CSS/structure to reproduce)
4. [skill-dir]/references/single-competitor-sections.md
(skill's document section spec)
Fix violations inline. Return scorecard."
4c: Loop decision. Read both scorecards:
| Cycle | 0 fixes | 1-2 fixes | 3+ fixes | |---|---|---|---| | Cycle 1 | CLEAN → 4d | Apply, loop | Apply, loop | | Cycle 2 | CLEAN → 4d | Apply, STOP | Apply, loop | | Cycle 3 (cap) | CLEAN → 4d | Apply, STOP | Apply, STOP |
Max 3 cycles. Re-run both reviewers each loop (back to 4b).
4d: Output combined scorecard to the user. This is proof the pipeline ran. Step 5 cannot start without it.
REVIEW PIPELINE COMPLETE
=========================
Editorial: [N fixes / PASS]
Presentation: [N fixes / PASS]
Total fixes: [N]
Cycles: [1-3]
Status: [CLEAN / N remaining issues]
After the review pipeline scorecard has been output:
DEAL CARD READY
================
Folder: .octave-decks/battlecard-<competitor>-<date>/
File: .octave-decks/battlecard-<competitor>-<date>/battlecard-<competitor>.html
Size: [file size]
Account: [Account name]
Competitors: [Competitor name(s)]
Sections: Deal Situation → [N] Competitor Panels → Our Pitch
Data sources: [N] deals, [N] conversation mentions, [N] proof points
Win rate: [X%] vs [Competitor] (last 180 days)
---
Want me to:
1. Go deeper on any section
2. Create displacement outreach for a specific person
3. Create a presentation version (/octave:deck)
4. Export as PDF
5. Done
If user requests PDF export:
To save as PDF:
PDF (recommended): bash "${CLAUDE_PLUGIN_ROOT:-.}"/scripts/export-pdf.sh .octave-decks/battlecard-<competitor>-<date>/battlecard-<competitor>.html
— or use the manual print dialog below:
1. Open the file in your browser (should already be open)
2. Press Cmd+P (Mac) or Ctrl+P (Windows)
3. Select "Save as PDF" as the destination
4. Set margins to "Minimum" or "None" for best results
5. The sidebar navigation will be hidden in print
list_entities (competitor) -- List all competitors for selection or landscapelist_entities (competitor) -- Full competitor profiles with dataget_entity -- Deep dive on a specific competitorsearch_knowledge_base -- Competitive positioning, Motion ICP matching, proof point discoverylist_findings -- Real conversation mentions, objections, competitor references from callslist_events -- Deal win/loss outcomes against specific competitorsget_event_detail -- Deep dive into specific competitive deals for evidencesearch_call_transcripts -- Verbatim quotes about this competitor, filterable by dealOutcome (WON/LOST) -- for trap questions and objection counters grounded in real languageget_entity_evidence -- Best verbatim quotes evidencing the competitor entity itselflist_motions -- List Motions in the workspacelist_motion_playbooks -- Find Custom Motion Playbooks with narrative type COMPETITIVEget_motion_playbook -- Full details for a Custom Motion Playbook (competitive narrative)list_motion_icps -- Motion ICP cells (persona × segment) under a Motionfind_motion_icp -- Motion ICP narrative + Learning Loop learningslist_entities (product) -- Product capabilities for comparisonlist_entities (proof_point) -- Competitive win proof points and switching storieslist_entities (reference) -- Customer references who switched from competitorssearch_resources -- Search uploaded analyst reports, battlecards, competitive docslist_findings -- Conversation-based competitive insights and objection patternslist_events -- Deal stage changes, win/loss events with competitor filtersget_event_detail -- Full details on specific competitive dealsNo Competitors in Library:
No competitors found in your library.
To build a battlecard, I need at least one competitor in your Octave library.
Options:
- Add a competitor first:
/octave:library create competitor- Tell me the competitor name and I'll create a basic comparison from web research (limited data)
No Deal Data for This Competitor:
No win/loss data found against [Competitor] in the last 180 days.
I'll build the battlecard from library data, conversation mentions, and positioning. The win/loss scorecard and deal evidence sections will be limited.
As you log deals with this competitor tagged, the battlecard will get richer with real evidence.
Competitor Not in Library:
"[Name]" isn't in your competitor library yet.
Options:
- Create the competitor entity first:
/octave:library create competitor "[name]"- I'll generate a basic battlecard from available information (Motion ICPs, conversations, web research)
Octave Connection Failed:
Could not connect to your Octave workspace.
The battlecard builder needs Octave data to generate competitive intelligence. Without it, I can't pull competitor profiles, deal outcomes, or conversation evidence.
To reconnect: check your Octave MCP configuration and reconnect
No Conversation Evidence:
No conversation mentions found for [Competitor].
The objection handlers and trap questions will be based on library data and general competitive positioning rather than real conversation evidence. They'll improve as your team logs more calls where this competitor comes up.
/octave:battlecard-doc -- Text-based competitive intelligence (this is the visual version)/octave:research -- Account-focused dossier (when dealing with a specific account in a competitive deal)/octave:deck -- Competitive presentation for an audience (this is a reference doc)/octave:win-loss-report -- Text-based win/loss analysis across competitors/octave:generate -- Competitive displacement outreach content/octave:research -- Deep account research (feeds into account-specific competitive context)/octave:insights -- Surface competitive mentions from conversationsdevelopment
Turn one or more Octave GTM Explorer / Beats reports into a branded, shareable digest with selectable insight scope, evidence depth, and output format. Use when the user asks for a report digest, weekly or monthly insight recap, executive intelligence brief, magazine-style insight story, report deck, or a recurring published summary of Octave insights.
content-media
Product and feature launch planning with full content kit generation across channels and audiences. Use when user says "launch plan", "product launch", "feature announcement", "GTM plan for launch", "launch content kit", or mentions launching something new.
development
A dense internal deal room a rep hands to a champion so they can run the buying-committee sell without you in the room. Quantified business case, stakeholder map with per-seat ammo, objection handling, and a path to yes, rendered as self-contained HTML. Use when user says "champion deal room", "arm my champion", "help my champion sell internally", "internal business case for [deal]", or wants a champion enablement doc. For a customer-facing top-of-funnel page use /octave:microsite; for the formal closing proposal use /octave:proposal.
data-ai
Analyze email threads, call transcripts, and conversations for resonance, adherence to messaging, and competitive differentiation. Use when user says "analyze this call", "how did the email land", "score this thread", "conversation analysis", or pastes conversation content to evaluate.