feat: add /community-review — prioritized PR inbox for maintainers

[johnbanr]

Summary

/community-review scores every open PR by value, risk, effort, and contributor quality — then tells you exactly what to do with each one.

Three modes: /community-review (digest), --post (auto-comment on each PR with actionable feedback), --issue (weekly GitHub Issue).

How it works

Each PR is scored on 4 dimensions:

Dimension	Scale	What it measures
Value	1-10	User impact (10 = new capability, 1 = noise)
Risk	1-5	Could it break things? (5 = hard gate, never auto-merge)
Effort	1-5	Review time (1 = glance, 5 = half-day)
Signal	1-3	Contributor quality (repeat? template compliant? responsive?)

Priority = Value x Signal / (Risk x Effort). High value + low effort = review first.

Five priority buckets

Bucket	Meaning
🟢 Merge Now	High value, low risk, low effort, compliant
🟡 Fix Then Merge	High value, minor template/code issues
🟠 Review Carefully	High value BUT high risk or effort
⚪ Backlog	Low urgency or niche
❌ Recommend Close	Stale, duplicate, or no user value

Template compliance (6 checks)

• .tmpl file exists
• {{PREAMBLE}} used (no hardcoded preamble)
• <!-- AUTO-GENERATED --> marker in SKILL.md
• Description under 1024 chars (Codex compat)
• eval "$(gstack-slug)" not source <(gstack-slug) (bash compat)
• Telemetry analytics line present

Auto-comments (--post mode)

For each PR, posts respectful, actionable feedback with specific file paths and fixes needed. Examples:

Merge Now:

Your PR looks good. Template compliance 6/6. Recommendation: merge as-is.

Fix Then Merge:

The concept is solid. To fix before merge: [specific items with file paths]. Once done, ready to merge.

Recommend Close:

[Specific reason]. Thank you for the contribution! If you'd like to revisit, [specific guidance].

Duplicate detection

Flags PRs that solve the same problem, recommends which to merge and which to close.

Context

Built this after running gstack on our CI pipeline. When you maintain an open-source project with many community PRs, the bottleneck isn't review quality — it's knowing which PRs to review first. This skill answers "which 3 PRs should I look at in the next 20 minutes?" by surfacing the ones where minimal review time unlocks maximum user value.

[sevastyanovio]

Re: "#405 /meditate (unclear purpose)"

Respectfully disagree — /meditate solves the #1 problem reported in this repo's issues:

Context doesn't survive across sessions. Issue #401 (compaction deletes learnings), issue #341 (can't resume workflows), issue #280 (skill chain state breaks across branches). Three different reporters, same root cause: every new session starts blind.

/meditate fixes this with a compiled binary that scans repo structure, git history, and past AI conversations (Claude Code + Codex + Gemini) to produce .gstack/context.md. Every skill reads it via the preamble. It survives compaction because it's a file on disk, not conversation history.

The purpose in one sentence: every new Claude Code session instantly knows your project — hotspots, conventions, your preferences, recurring problems — without you telling it anything.

More importantly — this is essential for gstack to get from L7 to L8. gstack is already at L7 (10+ agents, skill orchestration). But L8 is "Build your own orchestrator" — and an orchestrator that dispatches skills blindly is just a router. An orchestrator with repo consciousness can make autonomous decisions about what to scan harder, what to skip, what to flag — because it has priors. /meditate is the self-awareness layer that makes that possible.

That's not unclear — it's the missing infrastructure layer. Happy to walk through the PR if the summary didn't convey this.

[sevastyanovio]

One more piece of feedback on the architecture: the skill fetches all PRs and processes them sequentially in a single context. That's probably why #405 got "unclear purpose" — when you're scoring 15 PRs in one pass, each gets surface-level attention. The diff for #405 is 950 lines with a 780-line design doc, 10 unit tests, and addresses 3 open issues. A single-pass scan can't catch that.

gstack already has the infrastructure for multi-agent analysis — /review uses adversarial subagents, /autoplan dispatches parallel reviewers. A triage skill should follow the same pattern:

• 1 agent per PR — reads the full diff, design doc if referenced, maps against open issues
• 1 agent per issue — reads the full thread, checks if any open PR addresses it
• 1 synthesis agent — takes all individual analyses and produces the prioritized digest with cross-references

The Agent tool is already in your allowed-tools but never dispatched. Using it would turn a shallow scan into a deep triage.

[johnbanr]

Context on this PR: saw 30 open community PRs and figured with 42K stars that number is only going up. The idea is to automate first-pass triage so you spend review time on the ones that matter most.