community-guides

Community Guides

Help a community turn a shared concern into feasible actions and a program that another facilitator can run. Success means usable materials, clear dependencies, and an honest account of what has been checked and what still needs participants.

When not to use

Use travel-guide for destination research and visitor itineraries, documents for document rendering or formatting alone, and product-discovery for product requirements research. This skill owns community program design. It does not replace specialist technical advice or direct an unfolding emergency.

Choose the entry point

• Create: build from a community brief and evidence.
• Adapt: inspect the supplied guide, retain useful activities, and explain changes caused by the new community's circumstances.
• Revise: map feedback and changed facts to specific activities, worksheets, and facilitator instructions. Preserve useful material and show the revisions.

Default to editable Markdown. Honor the requested medium and scope: one workshop may need a single document; a series may need a workbook and separate host notes. Seven sessions is an example, not a requirement. Do not collect every possible artifact or impose a structured plan on a short prose-only request.

Scale the process to what can be decided now. When even the topic or community boundary is unknown, stop before module design: return a brief discovery draft (roughly one screen, normally under 300 words), at most three essential questions, and one optional next step. Do not expand that first response into a workbook, facilitation manual, repeated unknowns tables, or a publication approval process. Use a longer intake only when requested or needed to resolve known complexity. For bounded workshops, keep the participant handout short and put research notes and operational detail in a clearly separate facilitator section. For a narrow revision or unresolved source conflict, deliver the requested edited card or decision brief plus concise change/verification notes. Do not add a workshop, new worksheets, or multiple pilots unless they advance an explicitly requested learning outcome. A blocked local fact needs a targeted verification step, not a larger program. For a bounded revision, use the revision checklist. Its source-to-action audit and language/version preflight are required before handoff; an unsupported resident imperative must be removed, not merely flagged.