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/<topic-slug>/. 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/<topic-slug>/ 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:

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-<topic>.md file. Instead:

1. Use the deep-research skill to produce or update the topic workspace at .research/<topic-slug>/.
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:

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 <org>/<repo> --title "<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