# Track Startup Competitors > Track startup competitors across public websites, pricing pages, product pages, changelogs, documentation, public X posts, GitHub organizations and repositories, package registries, search engines, news, public communities, review platforms, job listings, and web archives. Use when Codex needs to create a competitor baseline, compare historical snapshots, find recent market moves, monitor a watchlist, investigate one competitor, detect pricing or positioning changes, verify product launches, distinguish confirmed changes from rumors, or generate an evidence-linked Competitor Change Map with recommended responses. - Skill: `kappaemme-git/track-startup-competitors` (Agent Skill, multi-file: 12 files) - Install (CLI): `npx skillmds@latest add kappaemme-git/track-startup-competitors` - Raw SKILL.md: https://api.skillmd.com/api/skills/kappaemme-git/track-startup-competitors/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: kappaemme-git (https://skillmd.com/u/kappaemme-git) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kappaemme-git/track-startup-competitors --- # Track Startup Competitors Build durable competitive intelligence from public evidence. Search broadly, conclude conservatively, and keep every observation, change, inference, and recommendation traceable to its source. ## Language - Conduct research, analysis, labels, exports, and reports in English. - Preserve non-English source text separately from a labeled English translation. - Never translate, paraphrase, or summarize a statement and present it as a verbatim quote. ## Read the relevant references - Read [references/source-strategy.md](references/source-strategy.md) before researching any competitor. - Read [references/identity-and-deduplication.md](references/identity-and-deduplication.md) before resolving domains, handles, repositories, people, or duplicate coverage. - Read [references/evidence-and-confidence.md](references/evidence-and-confidence.md) before classifying observations, changes, or inferences. - Read [references/impact-scoring.md](references/impact-scoring.md) before ranking changes or recommending a response. - Read [references/snapshot-schema.md](references/snapshot-schema.md) before creating or updating a snapshot. - Read [references/report-schema.md](references/report-schema.md) before generating the analysis JSON or report. - Read [references/research-safety.md](references/research-safety.md) before accessing social, community, archived, blocked, or login-gated sources. ## Choose the mode - `baseline` — Create the first verified snapshot. Never claim change detection without an earlier comparable snapshot. - `pulse` — Find material activity within a stated window, normally 7 or 30 days. - `compare` — Compare two saved snapshots and explain confirmed additions, removals, and modifications. - `deep-dive` — Investigate one competitor across all accessible public source groups. - `market-shift` — Find a pattern supported across multiple competitors without treating correlation as causation. - `watchlist` — Refresh every competitor and produce a change map. Do not schedule recurring runs unless the user explicitly asks. ## Run the workflow ### 1. Establish the watchlist - Inspect the startup URL, supplied competitor list, previous snapshots, and existing research before asking questions. - Record the startup's product, target segment, geography, business model, and decisions this research should inform. - Resolve each competitor's canonical name, domain, public social handles, GitHub organization, product names, and known aliases. - Keep direct competitors, adjacent alternatives, incumbents, and substitutes visibly separate. - Ask only for missing context that materially changes the scan or response. ### 2. Create a source plan - Search official product surfaces first, then code and release surfaces, search discovery, social and community sources, company signals, and archives. - Allocate a bounded source budget per competitor. Prioritize material surfaces over exhaustive low-value crawling. - Record every attempted source group as `available`, `partial`, `blocked`, `not_found`, or `not_applicable`. - Treat Google and other search results as discovery only. Open the underlying page before using it as evidence. - If X, LinkedIn, a review site, or an archive is inaccessible, mark it unavailable. Never reconstruct missing content from snippets or memory. ### 3. Build an immutable evidence ledger - Create one evidence item per source observation with a stable ID. - Preserve source URL, source type, authority, competitor, captured time, published time when available, title, exact short excerpt, normalized observation, and access status. - Separate facts from public opinions and from analyst interpretation. - Prefer primary sources. Use secondary sources to discover or corroborate, not to overwrite official evidence. - De-duplicate syndicated announcements, reposts, copied reviews, mirrored documentation, and the same claim repeated across pages. ### 4. Create or refresh the snapshot - Represent every comparable fact as a stable signal key such as `pricing:pro:monthly`, `positioning:primary-audience`, or `github:api-sdk:latest-release`. - Store normalized values separately from display text. - Cite the evidence IDs behind every signal. - Preserve unknown values as `unknown`; absence of evidence is not evidence of removal. - Save the snapshot before interpreting it. ### 5. Detect changes deterministically - When two snapshots exist, run: ```bash node track-startup-competitors/scripts/compare_snapshots.mjs ``` - Treat a signal as added, removed, or modified only when both snapshots had comparable source coverage. - Downgrade or suppress changes caused by blocked pages, missing scans, reordered text, cookie banners, dates, counters, tracking parameters, or cosmetic markup. - Never claim that a strategy changed solely because a page changed. ### 6. Corroborate and interpret - Classify each item as `confirmed_change`, `corroborated_signal`, `unconfirmed_signal`, `community_reaction`, or `noise`. - Connect signals only when their timing, entity identity, and business meaning align. - Label strategic interpretations explicitly as inferences. - Look for counter-evidence and unchanged signals that weaken the interpretation. - Distinguish what changed, why it may matter, and what remains unknown. ### 7. Score impact and choose a response - Score relevance, magnitude, strategic proximity, commercial consequence, persistence, evidence strength, and urgency. - Keep confidence separate from impact. A high-impact rumor remains low confidence. - Place each change into `act`, `investigate`, `watch`, or `ignore`. - Recommend customer research, measurement, messaging changes, product work, or no action as appropriate. - Never recommend copying a competitor merely because it launched something. ### 8. Create the deliverables - Save snapshots as `competitor-radar/snapshots/-.json`. - Save the structured analysis as `outputs/-competitor-analysis.json`. - Generate the interactive report: ```bash node track-startup-competitors/scripts/generate_report.mjs ``` - Export the evidence ledger: ```bash node track-startup-competitors/scripts/export_evidence.mjs ``` - Save the report as `outputs/-competitor-change-map.html`. - Save the ledger as `outputs/-competitor-evidence.csv`. - Create `outputs/-response-brief.md` when the analysis supports actionable responses. - Return clickable absolute links to every artifact. ### 9. Verify before delivery - Open the report and test search, filters, evidence links, responsive layout, and empty states. - Confirm that every displayed change points to both old and new evidence when applicable. - Confirm that every inference is labeled and includes counter-evidence or uncertainty. - Confirm that blocked sources are shown as coverage gaps, not silently omitted. - State the strongest confirmed move, the most important weak signal, the most dangerous uncertainty, and the next monitoring step. ## Enforce research integrity - Never bypass authentication, private accounts, paywalls, CAPTCHAs, robots restrictions, or access controls. - Never invent a post, page, price, release, quote, date, handle, metric, or archived version. - Never use a search-result snippet as final evidence. - Never treat stars, followers, likes, hiring counts, or posting frequency as business success without support. - Never treat a feature announcement as proof of availability, adoption, quality, or revenue impact. - Never treat community sentiment as representative market research. - Never infer a removal when the current source was blocked or not scanned. - Prefer `INSUFFICIENT_EVIDENCE` to a confident unsupported conclusion. ## Default report order 1. Executive market pulse 2. Coverage and source health 3. Material changes 4. Market movement timeline 5. Cross-competitor themes 6. Act / Investigate / Watch / Ignore board 7. Competitor profiles 8. Uncertainty and counter-evidence 9. Filterable evidence ledger 10. Snapshot and methodology details