gh-issue-to-demand-signal
Takes a competitor's public GitHub repo URL, fetches their open issues via the GitHub REST API, filters noise locally, clusters issues into 6 demand categories, computes a demand score per issue and per cluster, and outputs a ranked demand gap report with a GTM messaging brief. Use when asked to scan a competitor's GitHub issues, find what their users are begging for, turn GitHub complaints into product positioning, identify competitor feature gaps, or generate messaging from real user demand. Trigger when a user says "scan competitor issues", "what are users asking for on X repo", "find deman
npx skills add Varnan-Tech/opendirectory --skill gh-issue-to-demand-signal --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Takes a competitor's public GitHub repo. Fetch their open issues. Filter noise locally. Cluster into 6 demand categories. Score by real engagement. Output a ranked demand gap report and GTM messaging brief.
How it works
- Step 1 checks token and environment, then Step 2 parses the GitHub repo input.
- Step 3 fetches up to 200 open issues from the GitHub REST API, handling rate limits and possible errors.
- Step 4 pre-processes locally: filters out pull requests, bots, bot-pattern titles, zero-signal issues, and computes a demand score; filters issues with ignored demand criteria; requires at least 10 issues to proceed.
- Step 5 prints filtered issues and classifies each into one of six categories, extracting a one-sentence pain statement from the exact issue title and producing cluster themes. Outputs to /tmp/ghd-clusters.json.
- Step 6 computes total demand by cluster, prints top 3 themes, and generates a GTM messaging brief to /tmp/ghd-brief.json using the top clusters.
- Step 7 provides a self-QA step to verify content.
When to use it
Use when asked to scan a competitor's GitHub issues, find what users are begging for, turn GitHub complaints into product positioning, identify competitor feature gaps, or generate messaging from real user demand. Trigger phrases include: "scan competitor issues", "what are users asking for on X repo", "find demand gaps in Y", "turn GitHub issues into messaging", or "what should I build based on competitor complaints".
What it can touch
No external human inputs beyond the GitHub REST API. Requires tools: "claude-code, gemini-cli, github-copilot" and environment variable GITHUB_TOKEN for higher rate limits.
Caveats
If fewer than 10 issues remain after filtering, the process stops with a message that the repo is too small for reliable clustering. Output relies on verbatim issue titles for each cluster item and forbids paraphrasing in cluster labeling.
# GitHub Issue Demand Signal Take a competitor's public GitHub repo. Fetch their open issues. Filter noise locally. Cluster into 6 demand categories. Score by real engagement. Output a ranked demand gap report and GTM messaging brief. --- **Critical rule:** Every issue title in the output must be verbatim from the GitHub API response. Every cluster theme name must be derived from actual issue titles in that cluster. If fewer than 10 issues remain after noise filtering, stop and tell the user -- the repo is too small for reliable clustering. No invented issue content anywhere. --- ## Common Mistakes | The agent will want to... | Why that's wrong | |---|---| | Send all 200 raw issues to the AI without filtering | Bot issues, PRs, and zero-engagement noise inflate cluster counts and waste context. Filter locally first. | | Use comment count as the primary demand signal | Comments include maintainer responses, off-topic discussion, and spam. reactions["+1"] is the cleanest buyer signal. | | Paraphrase issue titles when summarizing clusters | Paraphrasing loses the buyer's exact language, which is the entire point. Use verbatim issue titles. | | Continue past Step 4 if fewer than 10 iss
- Common Mistakes
- Step 1: Setup Check
- Step 2: Gather Input
- Step 3: Fetch Issues from GitHub REST API
- Step 4: Pre-Process Locally -- Filter, Score, Detect Ignored Demand
- Step 5: Cluster Issues
- Step 6: Messaging Brief
- Step 7: Self-QA
- Step 8: Save and Present Output
echo "GITHUB_TOKEN: ${GITHUB_TOKEN:-not set, unauthenticated rate limit applies (60 req/hr)}"
python3 << 'PYEOF'
python3 -c "
import json
d = json.load(open('/tmp/ghd-clusters.json'))
d = json.load(open('/tmp/ghd-brief.json'))
rm -f /tmp/ghd-target.txt /tmp/ghd-raw-issues.json /tmp/ghd-filtered-issues.json \What does the gh-issue-to-demand-signal skill do?
Takes a competitor's public GitHub repo URL, fetches their open issues via the GitHub REST API, filters noise locally, clusters issues into 6 demand categories, computes a demand score per issue and per cluster, and outputs a ranked demand gap report with a GTM messaging brief. Use when asked to scan a competitor's GitHub issues, find what their users are begging for, turn GitHub complaints into product positioning, identify competitor feature gaps, or generate messaging from real user demand. Trigger when a user says "scan competitor issues", "what are users asking for on X repo", "find deman
How do I install it?
Run `npx skills add Varnan-Tech/opendirectory --skill gh-issue-to-demand-signal --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From Varnan-Tech/opendirectory, a repository with 571 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.