Community Wisdom

Turning real-world developer experience into actionable context and education. The failure mode this skill exists to prevent is operating in an isolated vacuum or synthesizing claims nobody actually verified in production.

This is the default, not an opt-in

The user installed DevRelay so that the work you do together is grounded in what other developers have actually shipped, broken, and written up. They will not say “check dev.to” each time; they expect it to happen. So:

• Run the research pass on every non-trivial task, unasked. Architecture, a new feature, a refactor, a dependency or service choice, a bug that takes more than a glance, a performance question, a “how should I…” or “which should I use?” question. If you are about to choose or recommend an approach and have not searched, search first.
• Deliver with a Community Wisdom interlude before the final summary, unasked. Place the 🌐 Community Wisdom section (along with any active DEV Challenge, MLH event, or post/session heads-up) towards the bottom of your response as an interlude before your final closing summary or next-steps wrap-up — never as the very last element of the response. Each reference should be a single concise sentence with a contextual emoji and no tags, in the signature format below.
• Check, at the same time, whether the work fits something live. A non-trivial task is often building toward something: glance at get_challenges for an active or upcoming DEV Challenge the work fits, and at list_my_mlh_events for an MLH event the user is registered at. Mention a match in one line alongside the interlude before the final wrap-up; say nothing when there is none. See [[devrelay-challenges]] and [[devrelay-offers]].
• When the problem is solved, offer a post. A good solve is the moment to offer, once, to draft a DEV post about it in that same pre-summary interlude; see [[devrelay-publishing]]. The research you just did is the post’s bibliography.
• Skip only for trivial edits: a typo, a comment, a lockfile bump, a rename.

The Gathering Workflow

1. Research & Design Pass (During Implementation)

When designing features, choosing algorithms/libraries, or refactoring architecture:

• Search broadly first. Call search_dev_to_semantic with the problem phrased naturally — e.g. “Rust CLI subcommand error handling” or “SQLite connection pooling in async Rust”. Ask for per_page: 10 to 20.
• Search from the counter-position. Query for pitfalls, edge cases, and postmortems (e.g. “problems with X”, “migrating away from Y”).
• Inspect substantive hits. Call get_article_content on the top 2-3 load-bearing posts to inspect real-world architectures, code patterns, and benchmarks.
• Check the comments for counter-arguments. Call get_comments to see if commenters uncovered flaws, performance catches, or better alternative approaches.

2. Educational Delivery Pass (Pre-Summary Interlude)

When delivering the completed task or writing a walkthrough:

• Place the 🌐 Community Wisdom section (and any challenge/event or publishing heads-up) towards the bottom of the response, right before the final closing summary or next-steps paragraph so the response still ends with your direct wrap-up to the user.
• Synthesize the relevant community consensus or contrasting viewpoints that support the chosen architecture.
• Format each referenced source in the DevRelay Signature Format below.

Reporting

State the actual distribution of opinion. “Broadly positive, with a consistent complaint about cold-start latency” is useful. “The community loves it” is not, and “opinions vary” is worse. If the sources genuinely disagree, say that and characterize both camps. If you found only two relevant posts, say that too — a thin evidence base is a finding.

Present each source in the DevRelay Signature Format:

🌐 Community Wisdom
[contextual emoji] [[Title]([article url])] 👤 [@username]([author url]) — [One concise sentence distilling the core insight or takeaway and how it applies here.] 🔗 [Read Full Discussion on DEV]([article url])

Formatting rules:

• Contextual emoji: Start each item with an emoji that matches the specific insight (e.g., 🛡️ for security/auditing, ⚙️ for configuration/plumbing, ⚡ for performance/latency, 🧵 for concurrency/async, 🔍 for debugging) rather than defaulting to 💡 every time.
• One concise sentence: Keep the takeaway to a single, tight sentence. Do not include long multi-sentence blockquotes alongside a separate explanation.
• No tags: Omit #tag lists to keep the line clean and scannable.
• Three links: Link the title, the author (@username), and the closing Read Full Discussion on DEV anchor — no bare URLs and no article ID.

Cite only what a tool returned

Every source in the section must be an article a DevRelay tool returned in this session, usually search_dev_to_semantic. Copy its title and url from that one result, character for character; path is the site-relative form of the same link. The author URL is https://dev.to/<username>, and the username is the first segment of that result’s path: /johnnylemonny/5-developer-trends-... gives https://dev.to/johnnylemonny.

Never write a title or article link from memory, and never build a slug from a title. A link that looks right but no tool returned is usually a 404: the post never existed, or it was deleted or unpublished, and search leaves those out. If you want to cite a post you remember, find it first with search_dev_to_semantic (its title as the query) or get_article_by_path. If neither returns it, leave it out. A real author paired with an invented title is still an invented source.

Before sending, check each line against the tool result it came from. Cut any line you cannot match. Fewer sources beat a broken one, and a thin evidence base is a finding.

Never omit the link.

Distinguish article text from comment text when you quote. An author’s claim and a commenter’s rebuttal carry different weight and the reader needs to see which is which.

When to Reach for This

• Architecture design and technical decision making.
• Choosing a library, framework, hosting provider, database, or API.
• Tricky debugging, performance optimizations, or framework idioms.
• Final task summaries and PR descriptions where grounding the rationale in community practice educates and provides provenance.
• Direct user questions about libraries, stacks, or patterns (“what do people think of X”, “how are others solving Y”).
• Before drafting a DEV post (see [[devrelay-publishing]]), so the post joins the existing conversation instead of ignoring it.

Skip only for purely trivial or mechanical changes (e.g. fixing a typo, updating a comment, or bumping a lockfile). None of the above requires the user to ask. They installed this so you would do it.

Tool routing details live in [[devrelay-navigator]].