Claude-code-skills ln-913-community-debater
Launches RFC and debate discussions on GitHub. Use when proposing changes that need community input or voting.
git clone https://github.com/levnikolaevich/claude-code-skills
T=$(mktemp -d) && git clone --depth=1 https://github.com/levnikolaevich/claude-code-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills-catalog/ln-913-community-debater" ~/.claude/skills/levnikolaevich-claude-code-skills-ln-913-community-debater && rm -rf "$T"
skills-catalog/ln-913-community-debater/SKILL.mdPaths: File paths (
,shared/,references/) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If../ln-*is missing, fetch files via WebFetch fromshared/.https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}
ln-913-community-debater
Type: L3 Worker (standalone) Category: 9XX Community Engagement Launches structured debate discussions in GitHub Discussions for decisions that benefit from community input.
Phase 0: GitHub Discovery
MANDATORY READ: Load
shared/references/community_github_discovery.md
Execute the discovery protocol. Extract:
for URLs and codebase context{owner}/{repo}
for GraphQL mutationrepo.id
for RFC/Proposal discussionscategories["Ideas"]
for Prioritization pollscategories["Polls"]- Verify required categories exist
Load strategy: check
docs/community_engagement_strategy.md in target project, fallback to shared/references/community_strategy_template.md. Extract Section 3 (Debate Triggers) and Section 1 (Decision Matrix).
MANDATORY READ: Load
shared/references/community_discussion_formatting.md
MANDATORY READ: Load shared/references/humanizer_checklist.md
Phase 1: Define the Topic
If
$ARGUMENTS provided, use as the topic seed. Otherwise, ask the user what they want to debate.
Gather context:
- Read strategy Section 3 -- verify this qualifies as a debate
- Grep the codebase for files related to the topic
- Read relevant SKILL.md files, docs, or shared references
- Identify existing patterns that the proposal might change
Phase 2: Classify Debate Type
| Type | Prefix | Category | When to use |
|---|---|---|---|
| Maintainer RFC -- design mostly done, seeking validation | | Ideas | End of design process, soft announcement |
| Community RFC -- early stage, genuinely open to alternatives | | Ideas | Beginning of design, kickstart discussion |
| Proposal -- new feature or restructuring | | Ideas | Concrete idea with use case |
| Workflow Change -- pipeline, task flow, or conventions | | Ideas | Affects multiple areas or user workflows |
| Prioritization -- what to build next, feature ranking | | Polls | Multiple options, need community vote |
If type is Prioritization, switch to Polls flow (Phase 4).
Phase 3: Compose RFC Discussion
Use the RFC Structure Pattern from
discussion_formatting.md (loaded in Phase 0).
Skill-specific additions beyond the shared pattern:
- Add
section after Open Questions — implementation details not yet decided, to be resolved during development## Unresolved Details - Add
section — how the decision will be made (metrics, feedback threshold)## Decision Criteria - Minimum 2 alternatives in the Alternatives table
Phase 4: Compose Poll (for Prioritization type)
GitHub Discussions Polls are created via UI only. Instead, compose a reaction-based voting discussion:
## {Topic} {1-2 sentence context} **Vote by reacting to the options below** (each option is posted as a separate comment -- use :+1: to vote). ### Context {Why this decision matters now}
After creating the discussion, post each option as a separate comment for reaction-based voting.
Phase 5: Fact-Check
Before presenting to user, verify every verifiable claim in the draft:
- File paths & links -- verify each linked file exists:
. Remove or fix broken links.ls {path} - Code references -- verify mentioned functions/patterns exist:
.grep -r "{name}" - Alternatives accuracy -- re-read source files to confirm the Alternatives table accurately describes tradeoffs. No hallucinated pros/cons.
- Names -- verify skill names, directory names, config keys match actual repo state.
- Humanizer audit -- run the audit protocol from
. If 3+ AI patterns found, rewrite flagged sections.humanizer_checklist.md
Gate: If any check fails, fix the draft before proceeding.
Phase 6: Review and Publish
Present the composed title + body to the user. Wait for explicit approval before publishing.
After approval, publish via GraphQL using discovery context:
gh api graphql -f query=' mutation($title: String!, $body: String!, $repoId: ID!, $catId: ID!) { createDiscussion(input: { repositoryId: $repoId, categoryId: $catId, title: $title, body: $body }) { discussion { url id } } } ' -f title="TITLE_HERE" -f body="BODY_HERE" -f repoId="{repo.id}" -f catId="{categories.Ideas or categories.Polls}"
For Polls, after creating the discussion, post each option as a comment:
gh api graphql -f query=' mutation($discussionId: ID!, $body: String!) { addDiscussionComment(input: { discussionId: $discussionId, body: $body }) { comment { url } } } ' -f discussionId="DISCUSSION_NODE_ID" -f body="**Option N:** {description}"
Report the discussion URL to the user.
Rules
- Always present the full composed text for user approval before publishing
- Never publish without explicit user confirmation
- Title: descriptive, under 80 chars, prefixed with [RFC], [Proposal], or [Poll]
- Body: factual, not persuasive -- present options neutrally
- Include links to relevant code/docs in the repository
- Set a decision timeline when applicable
- Minimum 2 alternatives in the Alternatives table
- Tone: "We're considering X. Here are the tradeoffs. What's your take?"
Definition of Done
- Topic defined with codebase context gathered
- Debate type classified (RFC/Proposal/Workflow/Prioritization)
- RFC or poll composed with minimum 2 alternatives
- Fact-checked (links, code references, alternatives accuracy, names)
- Humanizer audit passed (< 3 AI patterns)
- User approved final draft
- Published via GraphQL mutation, URL reported
Version: 1.0.0 Last Updated: 2026-03-13