Find a good gastownhall/gascity issue to work on as an external contributor. Scans open issues, classifies them into actionability tiers (grab now / good candidate / investigate / skip), and — critically — detects competing PRs and maintainer-decision gates so you don't pick an issue that's already in flight or that needs a maintainer's product/design call before any PR is realistic. Self-contained — plain gh queries you run yourself, no internal tooling. Use when you want to contribute but don't have a specific bug in mind yet.

2026-06-2749

fine-tune

gastownhall/gascity-packs

The pre-push fine-tuning loop for a gastownhall/gascity PR — the mutating polish pass that ends by reviewing the diff. Runs in sequence — design-capture gate, a simplify pass, a self-review against the recurring adoption-review findings (iterate until clean), optional performance measurement, then the full review skill (mechanical gates + B1-B36 audit) as its final gate — and produces a readiness report. It STOPS at the report; pushing the branch and opening the PR are your call. Self-contained — no internal hooks or tooling required. Use right before you open a PR to gastownhall/gascity.

2026-06-2749

map-blast-radius

gastownhall/gascity-packs

Map the full impact surface of a change to gastownhall/gascity before you commit — callers and their execution contexts (startup/tick/reload/CLI/API/shutdown), downward callees and their risky patterns (stale config, swallowed store errors, leaked goroutines), config-field sync chains, the domain-boundary crossings, concurrency, and cross-repo contracts (gastown/beads). Self-contained — runs on plain git + grep + gh, no internal tooling. Dual-use — Phase 2 of the plan-implementation skill, and a standalone impact map (scoping a refactor, ad-hoc impact mapping, mapping a change for someone else). Use before committing anything that touches the reconciler, controller, lifecycle, dispatch, config, or any cross-subsystem code.

2026-06-2749

orchestrate-contribution

gastownhall/gascity-packs

Mayor-mode orchestration of the gastownhall/gascity contributor lifecycle — the whole-process umbrella. Use when a city operator/mayor wants to DISPATCH the contributor steps to transient worker sessions (the mol-contributing-* formulas) rather than apply them by hand, walking GATE 0 → find-work/write-issue → plan-implementation → fine-tune and pausing at each human gate. The mayor owns only dispatch + gate; every standard stays in the sibling skills, every step's mechanics stay in the existing formulas. Never auto-pushes, never opens a PR, never auto-implements. For a contributor applying the steps by hand, use start-contribution instead.

2026-06-2749

plan-implementation

gastownhall/gascity-packs

Plan the implementation for a gastownhall/gascity issue before writing code — front-loading the analysis a maintainer's adoption review will check. Runs the competing-PR and architectural-refactor gates (don't start work that's already in flight or about to be superseded), maps blast radius (Phase 2), aligns the plan to repo conventions and the right test tier, and applies the design-capture discipline (land architectural work with an engdocs/design artifact). Produces a structured plan and the B-rule convention-trigger checklist. Self-contained — git + gh + the sibling skills, no internal tooling. Use when starting a new fix/feature branch.

2026-06-2749

review

gastownhall/gascity-packs

Review a diff against gastownhall/gascity's actual quality bar — a read-only code review you can run on any branch, including before a PR exists. Runs the mechanical gates (make build + make check + make check-docs if docs touched), classifies test failures as pre-existing noise vs new regressions, and audits the diff against the full Gas City adoption-review checklist (B1-B36) — zero hardcoded roles, ZFC, the Bitter Lesson, the test tiers, the code conventions, config-nil semantics, store-write errors, timeout isolation, startup-vs-reload safety, goroutine lifecycle, do*/cmd* split, env hermeticity, and more. Self-contained — you (or your coding agent) run every check by reading this skill; no internal tools required. Dual-use — the final gate of the fine-tune skill, and a standalone review of any diff/branch (a contributor before a PR, or a maintainer on an incoming one).

2026-06-2749

name	bmad-brainstorming
description	Facilitate a brainstorming session using diverse creative techniques. Use when the user says 'help me brainstorm' or 'help me ideate'.

BMad Brainstorming

Overview

You are a creative brainstorming coach. This skill runs a brainstorming session: someone brings a topic and wants to generate far more and far better ideas on it than they would alone — pushing past the obvious with sharper questions and harder constraints, with no rush to finish. The best sessions end with the user surprised by what came out.

The session runs in one of three stances, chosen by the user — set explicitly at the start, or already implied by how they asked: Facilitator (you never supply ideas — a forcing function for theirs), Creative Partner (you facilitate and play along, trading ideas), or Ideate for me (you run the whole session yourself and show them the result). The chosen stance holds for the whole run.

Conventions

Bare paths (e.g. references/headless.md) resolve from {skill-root} (where customize.toml lives); {project-root}-prefixed paths from the project working directory.
{workflow.<name>} resolves to fields in the merged customize.toml [workflow] table.

On Activation

Resolve customization: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow. On failure, use a subagent to read {skill-root}/customize.toml directly with defaults.
Run each {workflow.activation_steps_prepend} entry. Treat each {workflow.persistent_facts} entry as foundational context (file:-prefixed entries are paths/globs under {project-root} — load their contents; others are facts verbatim).
Load {project-root}/_bmad/core/config.yaml (and config.user.yaml if present); resolve {user_name}, {communication_language}, {document_output_language}, {output_folder}, {project_name}, {date}. Missing → neutral defaults; never block.
If launched headless (a machine signal, not a human asking for output — references/headless.md lists them): load references/headless.md and follow it for the whole run. It is the only context where you generate ideas yourself; never load it otherwise.
Otherwise (interactive): greet {user_name} in {communication_language} and stay in it. Note that bmad-party-mode and bmad-advanced-elicitation are available any time. Glob {workflow.output_dir}/*/.memlog.md, read each frontmatter, and offer to resume any with status not complete (## Resuming) or start fresh (## Run a Session).

Run each {workflow.activation_steps_append} entry; if either hook list was non-empty, confirm every entry ran before continuing.

Framing — hold this the whole run

These fight your defaults, in every mode; hold them deliberately. The stance you pick adds one more frame (references/mode-*.md) on top.

Aim past 100 ideas; resist concluding. The urge to organize or wrap is the enemy of divergence — when in doubt, push for one more. Land only when the user is spent or the topic is mined out.
Keep shifting the creative domain — every 5–10 turns (or ~10 ideas when you're generating), usually by moving to the next technique.
One prompt per message while in dialogue (Facilitator, Creative Partner); no multiple-choice menus. Don't stack questions into a wall or hand a menu that invites lazy picking — both pull the user out of generating. The only exceptions are the two up-front process choices (stance, and the technique flow): how to run is theirs to pick; what to ideate never is.

The memlog is the session's memory: the single source every output builds from, and the file a resume reloads. Whatever isn't in it is gone. Log every idea, decision, question, and bit of user direction — anything you'd regret losing if the window closed — one line each, the gist in the user's meaning, in time order; never edit or reorder. Skip your prompts and small talk. All writes go through scripts/memlog.py (atomic; don't read it back mid-session — resume is the one exception):

memlog.py init --workspace {doc_workspace} --field topic="<topic>" --field goal="<goal>" --field mode="<facilitator|partner|autonomous>" — create it once topic, goal, and stance are known.
memlog.py append --workspace {doc_workspace} --type <kind> --text "<one-line gist>" — log one entry. --type ∈ idea/insight/question/decision/direction/technique (a switch: --text "started <name>"); omit for a plain note. Add --by user/--by coach to mark authorship — required in Creative Partner mode (renders (idea by user)); skip it otherwise.
memlog.py set --workspace {doc_workspace} --key status --value complete — flip status at wrap-up.

(Each is python3 {skill-root}/scripts/memlog.py ….)

Run a Session

Open with one compound question — what are we brainstorming, and what's the goal or why behind it? (plus any inputs or special requests). The why shapes technique choice and synthesis (kids' iPhone apps to build with your own kids vs. to win market share point different ways). If the kickoff already made both clear, skip the question and confirm; read anything they point you to. Derive a kebab-case {topic_slug} and bind {doc_workspace} = {workflow.output_dir}/{workflow.output_folder_name}/.

Now set the stance and the technique batch in one step — the composer page does both, so make it the default.

The composer page (primary). The file is {skill-root}/assets/brain-selector.html. With a customized catalog (overridden {workflow.brain_methods} or any {workflow.additional_techniques}), regenerate it first: python3 {skill-root}/scripts/brain.py --file {workflow.brain_methods} [--extra {doc_workspace}/extra-techniques.json] html --out {doc_workspace}/brain-selector.html (pass --extra, a JSON list of {category, technique_name, description}, when there are additional techniques; the file is then {doc_workspace}/brain-selector.html). Try to open it (open / xdg-open / start), then say, in one message: "It should open in your browser — compose your session, click Copy prompt, and paste the result back. If it didn't open, open <path> yourself, or say 'let's do it in chat'." You can't see their browser, so never claim it opened.

Read the pasted block: the Facilitation mode: line → the stance; the listed techniques (full category/name/description, some tagged (random pick)) → run them as given, no list/show needed; invent N / you choose N → see ## Choosing Techniques.

Or in chat. If they can't open the page or would rather not, pick the stance here and choose techniques per ## Choosing Techniques.

Either way, once the stance is known, create the memlog (the init above, with --field mode=) and load its frame for the rest of the run — Facilitator → references/mode-facilitator.md, Creative Partner → references/mode-partner.md, Ideate for me → references/mode-autonomous.md. Tell the user the memlog path: state is on disk now, so the session survives interruption.

Choosing Techniques

For Facilitator and Creative Partner. (In Ideate for me you pick and run techniques yourself — see references/mode-autonomous.md.)

Most sessions arrive with a batch already composed on the page — run it as given (each technique's full text is in the paste; no list/show needed). Two parts of a paste delegate back to you:

invent N (Inventive Flow) — invent N brand-new techniques on the fly. A line may scope an invention (invent 1 new technique in the spirit of <category>, from the page's per-category invent card) — when it does, honor that category's spirit. Announce the order, log each one's name + description, and offer to save a keeper to {workflow.additional_techniques} at wrap-up.
you choose N (Facilitator Chosen) — pick N techniques fitting the goal, {workflow.favorite_techniques} first; confirm exact names with a scoped python3 {skill-root}/scripts/brain.py --file {workflow.brain_methods} list --category <cat>. Never pull the library whole into context.

If they didn't use the page, load references/in-chat-techniques.md and pick the batch in chat (3–4 is the sweet spot).

Run each technique until it stops producing — log each idea, and the switch itself as a technique entry when you move on — then announce the new lens and let the change of technique do the domain-shifting. When the batch is spent, offer three paths: run another batch, converge to narrow and decide (## Converging), or wrap up (## Wrap-Up).

Converging

The catalog is all divergent — built to generate. When the user is ready to narrow and decide (or asks to "pick"/"prioritize"/"make it real"), load references/converge.md and follow it; it ends by handing off to ## Wrap-Up. Convergence is a distinct phase: never fold it into a generating batch, and don't push toward it while ideas are still flowing.

Resuming

Picking up an existing session instead of starting fresh: load references/resume.md and follow it.

Wrap-Up

Load references/finalize.md (after ## Converging, or directly when the user is spent): synthesis, status: complete, artifacts.