# Community Post > Use this skill when you want to research a topic and produce a post as a durable artifact — GitHub issue, GitHub discussion, Discord message, Reddit/X post, or Asana task. - Skill: `cyberuni/community-post` (Agent Skill) - Install (CLI): `npx skillmds@latest add cyberuni/community-post` - Raw SKILL.md: https://api.skillmd.com/api/skills/cyberuni/community-post/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: cyberuni (https://skillmd.com/u/cyberuni) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/cyberuni/community-post --- # Community Post ## When to use When you have something to say — a finding, proposal, question, or update — and want to back it with research before publishing. The post can go anywhere: a GitHub issue or discussion, a Discord channel, a social media post (Reddit, X), or an Asana task. ## Modes This skill operates in three modes depending on what research exists: - **New** — no prior research exists. Run the `deep-research` skill first (durable mode), then draft the post from the resulting artifacts. - **Existing** — research already lives in `.research//`. Read `conclusion.md` and `evidence.md` directly; skip to step 4. - **Follow-up** — a post has already been filed and new research updates exist. Run the `deep-research` skill in update mode, then draft a follow-up post referencing the original issue URL. Choose the mode by checking whether `.research//` exists and whether a prior issue URL is recorded in `conclusion.md`. ## Steps ### 1. Identify the primary venue Pick the venue where the audience who can act on this post actually is. Common choices: | Goal | Venue | | --- | --- | | Bug report, feature request, spec change | GitHub issue in the relevant repo | | Open-ended design question, RFC | GitHub discussion | | Real-time community dialogue | Discord channel | | Public awareness, broader audience | Reddit or X | | Internal task or decision record | Asana task | If the topic spans multiple venues, pick one as primary and cross-reference from the others after the primary is live. ### 2. Research existing discussions Search the venue and related sources for prior posts, issues, threads, or discussions on the same topic. For each find, record: - URL or reference - Author handle (for `@mention` where the platform supports it) - The core claim or position - Current status (open, closed, resolved, stalled) - Whether it agrees with, partially overlaps with, or contradicts your post Aim for 3–5 direct prior-art references. Stop when additional searches return nothing new. ### 3. Categorize positions Separate what you found into two groups: **Agreements** — issues/comments that independently converge on the same conclusion or identify the same problem. These are your supporting evidence; cite them directly. **Counterarguments** — objections, alternative proposals, or explicit disagreements. Do not ignore them. For each, determine whether it is: - Fully addressed by your proposal (state how) - Partially addressed (acknowledge the gap) - Out of scope (say so without dismissing it) ### 4. Save research with the deep-research workbench Do not create a `docs/research/YYYY-MM-.md` file. Instead: 1. Use the `deep-research` skill to produce or update the topic workspace at `.research//`. 2. The research must capture, at minimum: - Author handles (`@username`) for every prior-art reference found in steps 2–3 - Community position table (agreements vs. counterarguments) - Open questions and confidence level 3. `conclusion.md` becomes the primary input for drafting the post (step 5). Read it in full before writing anything. 4. After the post is filed, append the live issue URL to `conclusion.md` under a `## Filed` section. ### 5. Draft the post Structure: 1. **Opening** (2–3 sentences) — acknowledge what the project already got right before stating the problem. Establishes credibility and good faith. 2. **Ideas** (not "Positions" or "Demands") — one section per idea, each with a concrete example (code, table, or quote). 3. **What I'd love to see clarified** — a numbered list of specific, actionable asks. Use "Clarify" or "Recommend", not "Must" or "Require". 4. **Prior art and community support** — bullet list, one per reference, with `@handle` for authors. 5. **Anticipated pushback — and my take** — address each known objection directly. Acknowledge before countering. 6. **Closing** (2 sentences) — offer to contribute spec language; end with an open question to invite dialogue. ### 6. Calibrate the tone Apply throughout the post: | Area | Do | Avoid | | --- | --- | --- | | **General register** | Casual, collegial — "feels like", "I think", "Sharing in case it's useful" | Formal position papers, "I propose that the spec shall" | | **Technical positions** | Firm and specific — blockquotes, tables, concrete JSON examples | Hedging technical claims with "maybe" or "possibly" | | **Objection responses** | Open with acknowledgment — "Fair concern." / "Agreed —" before the counter | Terse or dismissive rebuttals | | **Voice** | First-person singular — "I", "I'm already shipping…" | "We" unless writing on behalf of a named team | | **Author handles** | `@username` on all referenced authors so GitHub notifies them | Bare usernames that don't trigger notifications | | **Closing** | End with a question that opens dialogue | Ending on a demand or deadline | ### 7. Final review before filing Check: - [ ] Title is firm and specific (the proposal is clear, even if the body is humble) - [ ] Every referenced issue has a link and `@handle` - [ ] No "we" when writing as an individual - [ ] Counterarguments section addresses every objection found in step 3 - [ ] Closing includes an offer to contribute and an open question - [ ] Own repo or implementation is mentioned to show skin in the game - [ ] Draft presented to user and explicit approval received — do not file unless the user confirms or has explicitly authorized auto-posting upfront ### 8. File File to the venue identified in step 1. Capture the URL or reference and update `conclusion.md` with a link to the live post under a `## Filed` section. See **References** for platform-specific commands. ## Anti-patterns - **Defaulting to a low-impact venue when none was specified** — if the user has not identified a venue, pick the place where the people who can act are present, not the most convenient one. - **Listing objections without addressing them** — makes the post look incomplete; readers will raise them anyway. - **"Position 1 / Position 2" headings** — sounds like a formal debate brief; use "Idea 1 / Idea 2" instead. - **Ending with demands** — "this MUST change" closes the conversation; "I'd love to see this clarified" opens it. - **Skipping the prior art section** — wastes reader time and signals you haven't done the homework. - **Cross-posting to multiple venues simultaneously** — pick the primary venue; cross-reference from secondary venues after the primary post is live. ## References - **GitHub issue:** `gh issue create --repo / --title "" --body "$(cat <<'BODY'\n<post body>\nBODY\n)"` - **GitHub discussion:** `gh api graphql` with a `createDiscussion` mutation - **Asana task:** use the Asana MCP tools; set the post body as the task description - **Discord / Reddit / X:** draft the post body, then paste manually or via the relevant API/MCP tool