Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Prioritize GitHub issues by ROI, solution sanity, and architectural impact. Identifies quick wins, over-engineered proposals, and actionable bugs. Use for is...
Prioritize GitHub issues by ROI, solution sanity, and architectural impact. Identifies quick wins, over-engineered proposals, and actionable bugs. Use for is...
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run.
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.
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
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
gh CLI authenticated (gh auth login)
If the user didn't specify a repository, ask which one to analyze (format: owner/repo).
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 Examples: --search "telegram in:title" โ only title matches --search "label:bug telegram" โ bugs mentioning telegram --search "label:bug,enhancement telegram agents" โ bugs or enhancements about telegram/agents --search "comments:>5 telegram" โ active discussions about telegram Label-based fetch with --label: gh issue list --repo {owner/repo} --state open --limit {limit} --label "{label}" --json number,title,body,labels,createdAt,comments,url All fetch modes can be combined: --topic telegram --label bug --limit 50 fetches up to 50 open bugs about telegram. Error handling: Auth error โ tell user to run gh auth login Rate limited โ inform user, suggest reducing --limit Repo not found โ check format owner/repo No issues โ report and exit (if using --topic/--search, suggest broadening the query) Missing fields โ treat null/missing body and labels as empty
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.
For each remaining issue, score the following: Difficulty (1-10) Base score: 5. Adjustments: SignalAdjustmentDocumentation only-3Has proposed solution-2Has reproduction steps-1Clear error message-1Unknown root cause+3Architectural change+3Race condition/concurrency+2Security implications+2Multiple systems involved+2 Importance (1-10) RangeLevelExamples8-10CriticalCrash, data loss, security vulnerability, service down6-7HighBroken functionality, errors, performance issues4-5MediumEnhancements, feature requests, improvements1-3LowCosmetic, documentation, typos Tripping Scale (1-5) โ Solution Sanity (How "Out There" Is It?) ScoreLabelDescription1Total SanityProven approach, standard patterns2Grounded w/FlairPractical with creative touches3Dipping ToesExploring cautiously4Wild AdventureBold, risky, unconventional5TrippingQuestionable viability Red Flags (+score): rewrite from scratch, buzzwords (blockchain, AI-powered, ML-based), experimental/unstable, breaking change, custom protocol Green Flags (-score): standard approach, minimal change, backward compatible, existing library, well-documented Architectural Impact (1-5) Always ask: "Is there a simpler way?" before scoring. ScoreLabelDescription1SurgicalIsolated fix, 1-2 files, no new abstractions2LocalizedSmall addition, follows existing patterns exactly3ModerateNew component within existing architecture4SignificantNew subsystem, new patterns, affects multiple modules5TransformationalRestructures core, changes paradigms, migration needed 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? ScoreLabelDescription1Not ActionableQuestion, discussion, duplicate, support request2Needs TriageMissing info, unclear scope, needs clarification3Needs InvestigationRoot cause unknown, requires debugging first4Ready to WorkClear scope, may need some design decisions5PR ReadySolution is clear, just needs implementation Blockers (-score): questions ("how do I?"), discussions ("thoughts?"), labels (duplicate, wontfix, question), missing repro Ready signals (+score): action titles ("fix:", "add:"), proposed solution, repro steps, good-first-issue label, specific files mentioned Derived Values issueType: "bug" | "feature" | "docs" | "other" suggestedLevel: - "beginner": difficulty 1-3, no security/architecture changes - "intermediate": difficulty 4-6 - "advanced": difficulty 7+ OR security implications OR architectural changes Calculation Formulas ROI = Importance / Difficulty AdjustedScore = ROI ร TripMultiplier ร ArchMultiplier ร ActionMultiplier Tripping Scale Multiplier: ScoreLabelMultiplier1Total Sanity1.00 (no penalty)2Grounded w/Flair0.853Dipping Toes0.704Wild Adventure0.555Tripping0.40 Architectural Impact Multiplier: ScoreLabelMultiplier1Surgical1.00 (no penalty)2Localized0.903Moderate0.754Significant0.505Transformational0.25 Actionability Multiplier: ScoreLabelMultiplier5PR Ready1.00 (no penalty)4Ready to Work0.903Needs Investigation0.702Needs Triage0.401Not Actionable0.10
Quick Wins: ROI โฅ 1.5 AND Difficulty โค 5 AND Trip โค 3 AND Arch โค 2 AND Actionability โฅ 4 Critical Bugs: issueType = "bug" AND Importance โฅ 8 Tripping Issues: Trip โฅ 4 Over-Engineered: Arch โฅ 4 (simpler solution likely exists) Not Actionable: Actionability โค 2 Sort all issues by AdjustedScore descending.
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ ISSUE PRIORITIZATION REPORT Repository: {owner/repo} Filter: {topic/search/label or "latest"} Analyzed: {count} issues Excluded: {excluded} issues with existing PRs โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ Quick Wins: {n} | Critical Bugs: {n} | Tripping: {n} | Over-Engineered: {n} | Not Actionable: {n} โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ TOP 10 BY ADJUSTED SCORE โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #123 [Adj: 3.50] โญ Quick Win Fix typo in README โโ Difficulty: 1/10 | Importance: 4/10 | ROI: 4.00 โโ Trip: โ Total Sanity (1/5) | Arch: โ Surgical (1/5) โโ Act: โ PR Ready (5/5) | Level: beginner โโ https://github.com/owner/repo/issues/123 โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ QUICK WINS (High Impact, Low Effort, Sane & Actionable) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #123: Fix typo in README [Adj: 3.50] Difficulty: 1 | Importance: 4 | beginner โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ RECOMMENDATIONS BY LEVEL โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ BEGINNER (Difficulty 1-3, no security/architecture): - #123: Fix typo - Low risk, good first contribution INTERMEDIATE (Difficulty 4-6): - #456: Add validation - Medium complexity, clear scope ADVANCED (Difficulty 7-10 or security/architecture): - #789: Refactor auth - Architectural knowledge needed โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ CRITICAL BUGS (Importance โฅ 8) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #111 [Adj: 1.67] ๐ด Critical App crashes on startup with large datasets โโ Difficulty: 6/10 | Importance: 9/10 | ROI: 1.50 โโ Trip: โ (2/5) | Arch: โ (2/5) | Act: โ ๏ธ (3/5) โโ https://github.com/owner/repo/issues/111 โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ TRIPPING ISSUES (Trip โฅ 4 โ Review Carefully) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #999 [Trip: ๐จ 5/5 โ Tripping] Rewrite entire backend in Rust with blockchain storage โโ Red Flags: "rewrite from scratch", "blockchain" โโ Adjusted Score: 0.12 (heavily penalized) โโ Consider: Is this complexity really needed? โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ OVER-ENGINEERED (Arch โฅ 4 โ Simpler Solution Likely Exists) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #777 [Arch: ๐๏ธ 5/5 โ Transformational] Add form validation โโ Proposed: New validation framework with schema definitions โโ Simpler Alternative: Single validation function, 20 lines โโ Ask: Why create a framework for one form? ๐ก TIP: Maintainers often reject PRs that change architecture unnecessarily. Always start with the simplest fix. โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ NOT ACTIONABLE (Actionability โค 2) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ - #222: "How do I deploy to Kubernetes?" (Act: 1/5 โ question) - #333: Duplicate of #111 (Act: 1/5 โ duplicate) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ EXCLUDED โ EXISTING PRs โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ #123: Login crashes on empty password โโ ๐ PR #456: "Fix login validation" (explicit: fixes #123) Detection: ๐ Explicit link | ๐ Referenced | ๐ Similar title | ๐ก Semantic match โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ SCALE LEGEND โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ Trip (Solution Sanity): Arch (Structural Impact): โ 1-2 = Sane โ 1-2 = Minimal change โ ๏ธ 3 = Cautious โ ๏ธ 3 = Moderate ๐จ 4-5 = Risky ๐๏ธ 4-5 = Over-engineered Actionability: โ 4-5 = Ready for PR โ ๏ธ 3 = Needs Investigation โ 1-2 = Not Actionable AdjustedScore = ROI ร TripMult ร ArchMult ร ActionMult Higher = Better (prioritize first) ๐ฏ SIMPLICITY PRINCIPLE: If a 10-line fix exists, a 200-line refactor is wrong. Mode: SKILL (read-only) โ analyzes only, never modifies. โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
--json: Raw JSON output --markdown / --md: Markdown table output --quick-wins: Show only quick wins --level beginner|intermediate|advanced: Filter by contributor level --limit N: Number of issues to analyze (default: 30) --topic <keywords>: Search issues by topic (e.g. --topic telegram, --topic "agents telegram") --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
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).
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.