AI Blocks › Teach and train people
Community workshop guide builder
Share a community goal, local facts, and time available. The skill designs useful activities, then drafts editable worksheets and facilitator notes. It marks local roles and facts that still need review, so the host can confirm details before the workshop.
Share a community goal and local facts. Get practical activities, worksheets, and clear notes for the host.
Free · No account · MIT licence · Made by Magnus Hedemark · Thinking: high · Safety checked · Updated 3 Nov 2026
For: Courses and coaching
What you get
What goes in
- Your community and the goal you share
- Local facts you already have, like surveys or notes from residents
- How much time you have and how you will meet
- Access needs, like paper copies or other languages
- An existing guide to adapt or revise (optional)
Before you start
- An AI that can read the skill folder and its reference files
- Python 3.10 or newer, only if you want the optional plan checker to run
What comes out
- Community brief: Who the guide serves, the goal, local setting, time, medium, owner, and which voices are still missing.
- Participant worksheet: Short fields that turn each activity into a decision, map, plan or other usable result.
- Facilitator notes: Timings, preparation, supplies, instructions, debrief questions, completion checks and fallbacks for each activity.
- Sources and adaptation notes: Where local facts came from, what was changed for this community, and what still needs checking.
- Maintenance record: Who owns the guide, when to review it, and how feedback leads to changes.
Is it for you?
Skip it when
- You want a travel guide or visitor plan for a place: use a travel writer or a local tourism office.
- You only need a document formatted or turned into a PDF: use your word processor or a simple formatting step.
- A real emergency is happening now: call local emergency services. This tool does not direct live incidents.
Fill it in
Add what this task works from, then copy the request.
- Community and goal, local evidence, available time, participation needs, and any existing guide.
- Source text (optional)
- Document (optional)
Run it
Download the complete instructions and supporting files. Add them to Claude, ChatGPT or Gemini once, then ask for it by name in any chat. Pasting the instructions into a chat works too.
Before and after this skill
Choose the steps you need. Bring your own material when you have it.
Before
Bring the material listed under Fill it in.
After
- Backwards unit planner
Use it if you have the document.
- Perspective-taking activity builder
Use it if you have the document.
Details
From Magnus Hedemark. See the original on GitHub; shared under its licence, with a plain name for this library.
What goes in and out
You give it
- Community and goal, local evidence, available time, participation needs, and any existing guide.
- Source text (optional)
- Document (optional)
You get
- A workshop guide or focused revision, worksheets, host notes, and maintenance details where needed.
More for Teach and train people
- Lesson observation form builder
- Skill breakdown teaching planner
- Volunteer training clearance reviewer
- Course scope and sequence planner
Every teach and train people skill
How the task works
- Set the community brief. Use known facts first and ask only what changes the guide. Record whose views are still missing.
- Design useful activities. Link each need to an activity and a real next step. Put essential preparation first.
- Write coordinated materials. Make worksheets and host notes agree on timing, roles, supplies, access needs, and fallbacks.
- Walk through and revise. Check each activity and reference. Report what still needs local verification or a real community pilot.
Full instructions
- Add the downloaded skill folder to an AI that can read its reference files.
- Give the community, shared goal, time available, local facts, and access needs.
- For one short session, ask for only a brief participant worksheet and separate host notes. Set a length limit if needed. Expect the pieces in this order: the brief, the activities, the worksheet, then the host notes.
- Check that section names, timings, and worksheet fields agree. Keep roles proposed until someone accepts them; review drafts before use.
- After the first run, give the worksheet and host notes to the person who will host. Try the session with a few community members, then revise from what they say.
Full instruction file
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.
Before you start
Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.
What you need (use your own material or the linked skill):
- Your question (yours): the decision or problem, and what a good outcome looks like.
Makes it better (optional):
- Source text (yours): a long source in full: an article, a video or talk transcript, or notes from a book, with its title, author and link.
- A document (yours): a finished document, such as a Word file, a PDF or a page of notes.
How to start:
- Look first. Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
- Check what's missing. Look for your question, source text, a document. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
- Do the job. Follow the skill below with the facts and tools you have. Mark each gap with
MISSING:where it belongs and never invent a fact to fill it.
Tools that do this best:
- A chat AI that can read the bundled reference files: Use the supplied references and templates for the chosen task. Scripts are optional unless that task specifically needs them.
When not to use
For destination research and visitor itineraries, use a travel writer or a local tourism office. For document formatting alone, use a word processor. For product requirements research, do the research first, then come back. 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.
Workflow
Short run sheet: (1) write the community brief, (2) set outcomes and what each depends on, (3) write the worksheet and host notes so they agree, (4) walk through it as a new host would and revise, (5) hand it off with an owner and an update plan. Each step is explained below.
1. Establish the community brief
Extract known facts before asking questions. Use the brief template. Identify who the guide serves, the desired capability, local setting, existing assets, participation constraints, available time, delivery medium, and guide owner. Ask only about missing facts that materially change the program. Continue useful drafting with explicit assumptions when possible; leave location-dependent advice unresolved when the location or evidence is missing.
An organizer's account is one perspective. Record whose experience is represented and whose input is still needed. Never invent consultation, consensus, accepted volunteer roles, or a local service's willingness to help.
Read localization and evidence when researching or adapting local content. Public research supports factual claims; residents' accounts support lived constraints and priorities. Both need attribution and appropriate limits.
When the user restricts research to supplied sources, honor that boundary for technical advice too. If feedback exposes an unsupported safety instruction, remove or quarantine it and mark the replacement for qualified verification; do not invent a new procedure from general knowledge. A provisional draft must not describe proposed verification or services as work already underway. Keep unsupported safety prose out of resident-facing copy; state that the replacement is unresolved until an authoritative source is supplied. Any editorial placeholder belongs in verification notes, not in instructions residents might act on.
2. Establish outcomes and dependencies
For each need, trace:
need → capability → activity → usable output → real action → check
Choose only modules that support the requested outcomes. Put prerequisite actions first: inventory before purchasing; agreement about sharing before a directory; accepted roles before reliance on a contact chain. Use low/no-cost entry actions and more involved options where useful, without defining effort solely by money.
Read activity and facilitation design before writing a new program. A brief explanation, reflection, shared exercise, debrief, and feasible next action form the default loop. Adapt it to the available time.
3. Write coordinated materials
Use the module template as the common record for participant and facilitator instructions. Include a completed fictional example and a blank copy of any unfamiliar worksheet. Make each exercise produce a decision, practice, map, plan, or other usable result; discussion alone needs a stated purpose.
Provide timing including introductions, interpretation, transitions, and closing. Name preparation, supplies, instructions, debrief questions, completion checks, and a fallback when prerequisites or helpers are unavailable. Distinguish private household records from voluntary shared information.
Translate constraints into actual alternatives: renters need actions within their control; offline participants need the essential instructions on paper; people who miss meetings need a catch-up route. Do not assume purchasing power, literacy, transportation, home ownership, or comfort disclosing personal needs. Translation needs competent language review; machine translation alone is not evidence of that. When revising an existing multilingual guide, retain its language coverage unless the user changes scope. Provide labeled draft translations where needed and identify the review still required; a promise to translate later does not supply the missing copy. For source-only revisions, translating supported content is allowed: the source boundary forbids adding facts, not expressing those facts in another language. Check the delivered resident copy language by language before handoff. An English card plus a note promising Spanish later is an incomplete bilingual revision.
Use the worksheet template, facilitator template, and maintenance template as needed. Every proposed shared role needs a way to obtain acceptance and a fallback if nobody accepts it.
For multi-module or multi-file guides, maintain one structured plan following the plan contract. Use it to keep module IDs, worksheets, timing, and evidence consistent across materials; do not expose JSON to participants.
4. Check and revise
Perform a cold walkthrough: can a new facilitator prepare and run the session using only these materials? Can a participant complete each worksheet? Check that the guide and host notes agree, every decision has a next step, and necessary information is accessible in the intended medium. Resolve each named or numbered reference against the actual delivered worksheet: do its sections, checkbox counts, and field labels exist as described? Do not infer agreement just because both documents discuss the same activity. For responsibility maps, check for contradictory acceptance claims, overlapping assignments that exceed stated availability, and backups that rely on the same unavailable person. Preserve existing accepted scope; mark additional work proposed.
For source-only revisions, audit each resident-facing imperative against a supplied source. Remove unsupported directions even when they sound prudent (for example, an invented interim reporting route, waiting instruction, or emergency process). Use a factual unresolved-status notice instead. Keep historical unsafe wording only in a clearly labeled retired-source record, never in the active card.
For structured plans, run the read-only checker (Python 3.10+, standard library):
python3 scripts/validate_guide.py /path/to/guide/plan.json
Run from the skill root or resolve the script from its installed location. Read its JSON diagnostics, fix errors, and account for warnings. This checks records, file references, and timing; it does not verify facts, prose agreement, translation, or community usability. Its tests run with:
python3 -m unittest discover -s scripts -p 'test_*.py'
For PDF/Word output, use available documents tooling and inspect rendered pages,
especially worksheets, page breaks, and print readability. If unavailable, deliver
editable content and name the uncompleted rendering check.
Read review and evaluation for independent walkthroughs, pilot design, or skill evaluation. An agent simulation must be labeled as such.
5. Hand off and maintain
The entry-point scope rules take precedence over this full-program checklist. For discovery or a narrow card/decision-brief revision, supply only the requested artifact and concise verification/change notes. Add maintenance and ownership records only when the requested artifact or existing package calls for them.
For a full program, deliver the requested guide, relevant facilitator material, sources and adaptation notes, and a maintenance record. List unresolved local facts and proposed roles where they affect use. Name an owner or mark ownership unconfirmed, a review date or trigger, and how feedback should produce revisions.
Completion means requested artifacts exist, applicable checks are reported, and open dependencies are visible. Say ready for a community pilot when only agent checks have occurred. Claim participant-tested usability only with actual evidence. If an essential unknown prevents a usable guide, finish independent parts and ask the specific question needed to proceed; do not invent an answer or claim completion.
This skill produces local artifacts. Sending invitations, collecting residents' details, changing shared records, or publishing externally changes external state: Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation. Existing explicit authorization can supply that confirmation; guide creation alone does not authorize those actions.
Worked example and provenance
Read the original apartment example when a complete brief-to-guide model would help. Its plan and host notes demonstrate coordination. All people, constraints, and local evidence in it are fictional; it is not a technical outage manual.
Read source pattern and attribution when adapting Ready Together. Retain the participatory method while researching technical content afresh. Do not reproduce the source handbook's text, images, or worksheets without appropriate permission.
After this
When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:
- The Backwards unit planner. It takes the document.
- The Perspective-taking activity builder. It takes the document. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.