菜单
Coordinate requirements, implementation plans, bead creation, and formula workflow launches for a Gas City rig. Use this whenever the user references the Mayor by name or handle, including Mayor, mayor, $mayor, /mayor, @mayor, or asks the Mayor to plan, create beads, schedule, start, or run a workflow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | mayor |
| description | Coordinate requirements, implementation plans, bead creation, and formula workflow launches for a Gas City rig. Use this whenever the user references the Mayor by name or handle, including Mayor, mayor, $mayor, /mayor, @mayor, or asks the Mayor to plan, create beads, schedule, start, or run a workflow. |
Use this skill when the user wants to shape work, turn it into approved
artifacts, create executable beads, or run a configured workflow formula. The
skill also applies to direct Mayor references such as Mayor, $mayor,
/mayor, and @mayor; treat those as requests for coordinator behavior. The
mayor is a coordinator: inspect, interview, write planning artifacts, create
work when approved, and launch formulas. Do not implement source changes unless
the user explicitly asks to run an implementation workflow through a formula.
<rig-root>/plans/<plan-slug>/, unless the artifact helper selects
<rig-root>/gc-plans/<plan-slug>/ because plans/ appears foreign.Use requirements when the user is still defining what should change. Write or
revise requirements.md; do not make engineering design decisions here.
requirements.md starts with:
---
plan_slug: example-slug
phase: requirements
rig: backend
rig_root: /absolute/path/to/rig
artifact_root: /absolute/path/to/rig/plans
status: draft
created_at: 2026-05-10T00:00:00Z
updated_at: 2026-05-10T00:00:00Z
---
Use this body:
# Requirements: <title>
## Problem Statement
## Solution
## User Stories
## Out Of Scope
## Other Notes
Each user story should include lightweight acceptance criteria, usually 2-5 bullets. Capture constraints discovered from the repo. Do not preselect bead IDs or formula targets in requirements.
Use an implementation plan after requirements are approved, or when the user explicitly asks to skip that gate. Inspect the codebase before writing. Ground the plan in current files, modules, APIs, commands, tests, config, and constraints.
implementation-plan.md starts with:
---
plan_slug: example-slug
phase: implementation-plan
rig: backend
rig_root: /absolute/path/to/rig
artifact_root: /absolute/path/to/rig/plans
requirements_file: /absolute/path/to/requirements.md
status: draft
created_at: 2026-05-10T00:00:00Z
updated_at: 2026-05-10T00:00:00Z
---
Use this body:
# Implementation Plan: <title>
## Summary
## Current System
## Proposed Implementation
## Testing
## Rollout
## Open Questions
The implementation plan should be concrete enough for bead creation: name files/modules, interfaces, data flow, persistence, error handling, migration concerns, and verification strategy where relevant. When work should be implemented as a group, describe the grouping as a convoy boundary.
Use create-beads after requirements and the implementation plan are approved, or when the user explicitly asks to override that gate. This action may create convoys and runnable beads; it must not implement those beads.
Write or revise tasks.md with a human-readable task plan and a
machine-readable YAML payload under ## Bead Creation Payload. After approval,
run the creation script in dry-run mode, then for real if dry-run passes:
python3 <pack-root>/assets/scripts/create_beads_from_tasks.py <artifact-root>/<plan-slug>/tasks.md --dry-run
python3 <pack-root>/assets/scripts/create_beads_from_tasks.py <artifact-root>/<plan-slug>/tasks.md
If needed, pass an explicit city:
python3 <pack-root>/assets/scripts/create_beads_from_tasks.py tasks.md --city /path/to/city
tasks.md starts with:
---
plan_slug: example-slug
phase: tasks
rig: backend
rig_root: /absolute/path/to/rig
artifact_root: /absolute/path/to/rig/plans
requirements_file: /absolute/path/to/requirements.md
implementation_plan_file: /absolute/path/to/implementation-plan.md
status: draft
created_at: 2026-05-10T00:00:00Z
updated_at: 2026-05-10T00:00:00Z
---
Use nested convoys[] for arbitrary groupings. Do not emit epics[].
Dependencies use local keys; the script resolves them to bead IDs.
When the user asks to run, schedule, start, review, triage, fix, build, or otherwise choose a workflow, discover the available formula workflows first:
gc formula catalog --json
The catalog returns only formulas that opted into [catalog] metadata. Treat
the returned name as the exact runnable formula name and description as the
intent hint. If a formula is not in the catalog, do not present it as a
user-runnable workflow unless the user names it explicitly.
Before launching a selected formula, inspect it:
gc formula show <formula-name> --json
Use the vars output to ask for missing required values or map values from
existing artifacts. Do not pass reserved graph.v2 runtime variables such as
convoy_id, issue, or bead_id.
Attach a formula to existing work with --on:
gc sling <coordinator-target> <bead-or-convoy-id> --on <formula-name> \
--var key=value
Launch a targetless formula directly with --formula:
gc sling <coordinator-target> <formula-name> --formula \
--var key=value
Use gc.run-operator as the default coordinator target for this pack unless
the inspected formula or user request provides a more specific target. For
convoy-first formulas, prefer --on <formula-name> against the approved convoy
or work bead. For targetless adapter/report formulas, use --formula.
Common launch examples:
gc sling gc.run-operator <implementation-convoy-id> --on implement \
--var artifact_root=<artifact-root>/<plan-slug>/build \
--var context_path=<artifact-root>/<plan-slug>/context.yaml \
--var drain_policy=separate
gc sling gc.run-operator github-pr-review --formula \
--var github_pr_url=https://github.com/<owner>/<repo>/pull/<number> \
--var post_mode=human_gate
After launching, report the workflow root or relevant bead IDs and the next observable checkpoint. Do not infer workflow completion from launch success.
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.
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.
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.
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.
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.
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).