competitive-intelligence

Competitive Intelligence

Stand up an ongoing competitive monitoring system: watch-list + signal taxonomy + alert cadence + intel-to-action workflow + battle-card refresh cycle. The output of competitor-analysis is a snapshot; this skill produces a system that prevents competitive moves from surprising the GTM team.

Framework(s) used: signal taxonomy + intel workflow (custom in-house framework) + watch-list construction — purpose-built to flow into competitor-analysis updates and battle-card refreshes. If multiple frameworks apply, trigger Clarification Protocol so the user picks.

Clarification Protocol

When you encounter any of the following, STOP and ask the user — do NOT make a silent assumption, and do NOT flatly refuse:

• Ambiguous or missing input
• A fork in approach (multiple valid frameworks, segments, scopes, or sources)
• A rule that would block progress
• An assumption that materially shapes the output
• Unverified data that a downstream step depends on

Present 2–4 concrete options with trade-offs and your recommendation.

Format:

Decision needed: <what's being decided> Options:

• A) <option> — trade-off
• B) <option> — trade-off
• C) <option> — trade-off My recommendation: <X> because <reason>. Confirm or pick a different option before I continue.

Refusing to proceed is NEVER the final answer. Every "block" must come with an override option. If the user picks an override, honor it on the first request — do not re-prompt the same block multiple times in one run.

Scope

This skill ONLY produces operationalized competitor monitoring (signal log, alerts, refresh cycle, intel routing). Do not expand into adjacent topics. If the user's request implies adjacent scope, trigger Clarification Protocol with options to (A) stay in scope, (B) note the adjacent need as a follow-up, (C) hand off to a different skill.

Verification Requirements

Before producing the final output, every factual claim about external entities (markets, competitors, people, companies, technologies, pricing, benchmarks) MUST be verified via web search.

• Use a quick lookup for single-fact checks (one company, one stat).
• Use a deep search for landscape/trend questions (multi-source synthesis).
• Tag every verified claim inline as [H/M/L][Sn].
• End the report with a ## Sources section.
• Unverified claims belong in ## Assumptions to Validate, NOT in the main analysis.

Sources are mandatory. If you cannot cite a source for a factual claim, do not state it as fact — move it to Assumptions to Validate or trigger Clarification Protocol.

When to Use

• User wants ongoing competitor tracking / monitoring setup
• Alert system design ("How should we be notified when X happens?")
• Signal interpretation ("Is this competitor move actually meaningful?")
• Battle-card refresh cadence decisions
• Win-rate diagnostic ("Are we losing more deals to X — what changed?")
• Quarterly competitive review prep

Quick Reference

Concept	Detail
Signal score	Strength (1–5) × Decision-relevance (1–5) = 1–25
Action thresholds	≤4 log only / 5–9 weekly digest / 10–15 24h alert / 16–20 leadership immediate / 21–25 strategic event
Watch-list ceiling	8 competitors max; 4 is often the sweet spot
Signal categories	Product / Positioning / Pricing / Capital / Hiring / Customer / Channel-GTM / Content / Sentiment / Win-Loss
Battle-card refresh	Quarterly minimum; touch-up on score ≥10; full refresh on ≥16
Ownership rule	One person owns the system or it dies

Procedure

0. Test Mode prompt (pre-run). Before full run, ask the user: "Do you want a dry run on a single competitor to validate output? (A) Dry run on one competitor (B) Full run across the watch-list (C) Cancel." Honor the user's choice.
1. Confirm and tier the watch-list. Pull from competitor-analysis. Top 3 Direct → heavy. Direct 4–6 → medium. Substitute → light. Cap at 8 actively monitored. See ${HERMES_SKILL_DIR}/references/watch-list-construction.md.
2. Select 4–6 categories per competitor. Direct top-3: Product + Positioning + Pricing + Hiring + Sentiment + Win/Loss. Others: subset. See ${HERMES_SKILL_DIR}/references/signal-taxonomy.md.
3. Map detection methods. Per (competitor × category): detection tool, URL/query, cadence, owner. This is the operating manual.
4. Set up alerts and infrastructure. Visualping on top-3 homepage/pricing/about. LinkedIn Sales Nav alerts. Crunchbase alerts. RSS for blogs/changelogs. Slack #ci-alerts. Signal log in Notion/Linear.
5. Define alert routing rules. Per signal type: recipient, channel, SLA. Override: score ≥16 → leadership immediately. See ${HERMES_SKILL_DIR}/references/alert-routing.md.
6. Define cadences. Real-time / Daily (15 min) / Weekly (digest) / Bi-weekly (card touch-up if ≥10) / Monthly (synthesis) / Quarterly (re-tier + full refresh).
7. Build intel-to-action workflow. Detected → Scored → Logged → Routed → Triaged → Action (None / Card update / Positioning review / Product input / Strategic decision) → Tagged for quarterly. See ${HERMES_SKILL_DIR}/references/intel-workflow.md.
8. Set battle-card refresh cycle. Quarterly calendar + score-driven + pattern-driven + new-Direct trigger. See ${HERMES_SKILL_DIR}/references/refresh-cycle.md.
9. Build the signal log. Standard format. Pre-populate from competitor-analysis. See ${HERMES_SKILL_DIR}/references/signal-log-format.md.
10. Define quarterly review template. Watch-list re-tier + top-5 signals + win/loss shifts + battle-card refreshes + strategic implications.

Pitfalls

• Building a system the team won't use — over-engineering kills CI faster than under-engineering
• Watching too many competitors — 8 is ceiling; 4 is often the sweet spot
• Confusing volume with insight — 50 signals/week is not better than 10 if 40 score ≤4
• Skipping the log — patterns over time are the value; one-off alerts aren't
• Reacting to every signal — 70%+ should result in "no action — log only"
• Annual battle-card refresh — quarterly minimum; markets move faster
• Treating CI as marketing-only — it's GTM-wide: marketing, sales, product all consume it

Verification

1. Watch-list tiered with monitoring intensity per tier
2. Every watched competitor has 4–6 named detection categories
3. Alert routing defines who-reads-what-when
4. Signal log has ≥5 historical entries
5. Battle-card refresh has trigger rules
6. One person owns the whole system

Legend — Signal Strength

• [H] High — first-party / official statement / public filing / >2 secondary sources
• [M] Medium — single secondary source, recent
• [L] Low — inferred or rumor

Output Format

• Sections required: Watch-list, Signal Log entries, Alert Routing, Refresh Cycle Status, Sources, Assumptions to Validate
• Tables / fields:
  • Signal Log table = Date | Competitor | Signal | Strength [H/M/L] | Source [Sn] | Action
• Length target: 400–800 words per intel pull
• File type: markdown
• Mandatory closing sections: Verification Notes, Sources, Assumptions to Validate, Next Step