Prioritize GitHub issues by ROI, solution sanity, and architectural impact. Use when triaging or ranking issues to identify quick wins, over-engineered proposals, and actionable bugs. Don't use when managing forks (use fork-manager) or general GitHub queries (use github). Read-only — never modifies repositories.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Prioritize GitHub issues by ROI, solution sanity, and architectural impact. Use when triaging or ranking issues to identify quick wins, over-engineered proposals, and actionable bugs. Don't use when managing forks (use fork-manager) or general GitHub queries (use github). Read-only — never modifies repositories.
metadata
{"openclaw":{"requires":{"bins":"[Truncated]"}}}
Issue Prioritizer
Analyze issues from a GitHub repository and rank them by Adjusted Score — ROI penalized by Tripping Scale (solution sanity), Architectural Impact, and Actionability.
This is a read-only skill. It analyzes and presents information. The user makes all decisions.
When to use
Triaging or ranking issues in a repository
Identifying quick wins for contributors
Filtering out non-actionable items (questions, duplicates)
Detecting over-engineered proposals
Matching issues to contributor skill levels
When NOT to use
Managing forks or syncing with upstream → use fork-manager instead
General GitHub CLI queries (PR status, CI runs) → use github instead
Reviewing code changes before publishing → use pr-review instead
Requirements
gh CLI authenticated (gh auth login)
Instructions
Step 1: Get Repository
If the user didn't specify a repository, ask which one to analyze (format: owner/repo).
Step 2: Fetch Issues
Basic fetch (most recent):
gh issue list --repo {owner/repo} --state open --limit {limit} --json number,title,body,labels,createdAt,comments,url
Default limit is 30. Store the full JSON response.
Targeted fetch with --topic:
When the user specifies --topic <keyword> (e.g. --topic telegram, --topic agents), use GitHub search to find issues matching that topic instead of just fetching the most recent:
# Search by topic keywords in title and body
gh issue list --repo {owner/repo} --state open --limit {limit} --search "{topic} in:title,body" --json number,title,body,labels,createdAt,comments,url
Multiple topics can be combined: --topic "telegram agents" searches for issues containing either term.
Targeted fetch with --search:
When the user specifies --search <query>, pass it directly as a GitHub search query for full control:
gh issue list --repo {owner/repo} --state open --limit {limit} --search "{query}" --json number,title,body,labels,createdAt,comments,url
No issues → report and exit (if using --topic/--search, suggest broadening the query)
Missing fields → treat null/missing body and labels as empty
Step 3: Filter Issues with Existing PRs
Note: If user specified --include-with-prs, skip this entire step and proceed to Step 4 with all fetched issues.
Before analyzing, check for open PRs that already address issues to avoid duplicate work.
gh pr list --repo {owner/repo} --state open --json number,title,body,url
Detect linked issues using ALL of these methods:
Method 1 — Explicit Keywords (high confidence):
Scan PR title and body (case-insensitive):
fixes #N, fix #N, fixed #N
closes #N, close #N, closed #N
resolves #N, resolve #N, resolved #N
Method 2 — Issue References (medium confidence):
#N anywhere in text
issue N, issue #N, related to #N, addresses #N
Method 3 — Title Similarity (fuzzy):
Normalize titles (lowercase, remove punctuation/common words). If 70%+ word overlap → likely linked.
Method 4 — Semantic Matching (ambiguous cases):
Extract key terms from issue (error names, function names, components). Check if PR body discusses same things.
Confidence icons:
🔗 Explicit link (fixes/closes/resolves)
📎 Referenced (#N mentioned)
🔍 Similar title (fuzzy match)
💡 Semantic match (same components)
Remove linked issues from analysis. Report them separately before the main report.
If all issues have PRs, report that and exit.
Step 4: Analyze Each Issue
For each remaining issue, score the following:
Difficulty (1-10)
Base score: 5. Adjustments:
Signal
Adjustment
Documentation only
-3
Has proposed solution
-2
Has reproduction steps
-1
Clear error message
-1
Unknown root cause
+3
Architectural change
+3
Race condition/concurrency
+2
Security implications
+2
Multiple systems involved
+2
Importance (1-10)
Range
Level
Examples
8-10
Critical
Crash, data loss, security vulnerability, service down
Red Flags (+score): "rewrite", "refactor entire", new framework for existing capability, changes across >5 files, breaking API changes, scope creep
Green Flags (-score): single file fix, uses existing utilities, follows established patterns, backward compatible, easily revertible
Critical: If a simple solution exists, architectural changes are wrong. Don't create a "validation framework" when a single if-check suffices.
Actionability (1-5) — Can it be resolved with a PR?
--search <query>: Raw GitHub search query for full control (e.g. --search "label:bug telegram in:title")
--label <name>: Filter by GitHub label (e.g. --label bug)
--include-with-prs: Skip PR filtering, include all issues
LLM Deep Analysis (Optional)
For higher-quality scoring, use an LLM to analyze each issue individually. For each issue, prompt the model with the issue details and scoring criteria, requesting structured JSON output:
{"number":123,"difficulty":5,"difficultyReasoning":"base 5; has repro (-1); unknown cause (+3) = 7","importance":7,"importanceReasoning":"broken functionality affecting users","tripScore":2,"tripLabel":"Grounded with Flair","tripRedFlags":[],"tripGreenFlags":["minimal change","standard approach"],"archScore":2,"archLabel":"Localized","archRedFlags":[],"archGreenFlags":["uses existing patterns"],"archSimplerAlternative":null,"actionScore":4,"actionLabel":"Ready to Work","actionBlockers":[],"actionReadySignals":["has proposed solution"],"issueType":"bug","suggestedLevel":"intermediate","roi":1.40,"adjustedScore":0.96}
Truncate issue bodies longer than 2000 characters before sending to the model.
When to use LLM Deep Analysis:
Complex repositories with nuanced issues
When accuracy matters more than speed
For repositories you're unfamiliar with
Tradeoffs: Slower (~2-5s per issue) but more accurate. 1 API call per issue.
Integration: For each issue, call the LLM with the analysis prompt, parse the JSON response, and merge into results before Step 5 (Categorize).
