Tracks developer-tool rivals on features, pricing, GitHub traction, content, community sentiment, and six-section sales battlecards. Use for competitive intelligence, battlecards, pricing comparisons, or a response to a rival launch. Not a consumer-brand listening playbook; do not use for SEO keyword research or writing positioning copy as the main deliverable.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Tracks developer-tool rivals on features, pricing, GitHub traction, content, community sentiment, and six-section sales battlecards. Use for competitive intelligence, battlecards, pricing comparisons, or a response to a rival launch. Not a consumer-brand listening playbook; do not use for SEO keyword research or writing positioning copy as the main deliverable.
Create migration content if there's genuine demand
Let your product speak for itself
Examples
Social Listening Alert Patterns
Set up these alert queries in your monitoring tool:
Competitor sentiment overview (last 30 days, by sentiment)
Churn signals: "alternative OR migrating OR switching" + [competitor name]
Feature gaps: "wish OR need OR missing" + [competitor name]
Comparison mentions: "[competitor] vs"
GitHub Repo Snapshot (PowerShell)
# Get star count and open issues for a competitor repo
gh api repos/competitor-org/competitor-repo --jq '.stargazers_count, .open_issues_count'
# Search for recent issues mentioning the competitor
gh search issues "competitor-name" --limit 50
Archive.org for Pricing History
Navigate to https://web.archive.org/web/*/https://competitor.com/pricing
Compare snapshots from 6 months ago vs today
Document tier changes, price increases/decreases, and feature re-packaging
Pitfalls
Tracking too many competitors — Focus on 3–5 direct competitors plus 2–3 indirect. Diluting attention across 20 competitors means none are tracked well.
Ignoring DIY alternatives — "Just build it yourself" is often the largest competitor by volume for developer tools. Don't skip this category.
Stale battlecards — Battlecards that are 6 months old are worse than no battlecard because they create false confidence. Follow the review cadence.
Confirmation bias in sentiment analysis — Don't only collect negative sentiment about competitors. Track praise signals too — they reveal what you should learn from.
Overreacting to minor feature parity — Not every competitor feature launch warrants a response. Reserve responses for moves that materially affect positioning.
Sleazy crisis exploitation — When a competitor has an outage or crisis, piling on damages your brand. Be helpful, not opportunistic.
Not verifying GitHub CLI auth — gh commands will fail silently or with confusing errors if not authenticated. Run gh auth status first.
Forgetting platform alternatives — Cloud-native services (AWS, GCP, Azure) are often the real competition for enterprise deals, not other startups.
Verification
GitHub CLI is authenticated:
gh auth status
Expected output: Logged in to github.com as [username]
Competitor repo data is accessible:
gh api repos/[competitor]/[repo] --jq '.stargazers_count'
Expected: A numeric value (e.g., 15423)
Battlecard completeness check — Verify each battlecard contains all 6 sections: Overview, When We Win, When We Lose, Common Objections, Competitive Differentiation, Landmines to Set.
Monitoring alerts are active — Confirm your social listening tool shows results for each competitor alert query within the last 7 days.
Pricing snapshot exists — Confirm you have at least one Archive.org snapshot of each major competitor's pricing page saved for historical comparison.
Related Skills
developer-listening — Broader monitoring beyond just competitors
alternatives-pages — Turn competitive intelligence into content
positioning — Differentiate based on competitive insights
Limitations
Use this skill only when the task clearly matches its upstream source and local project context.
Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
