소스 정보
- 저장소
- gastownhall/gascity
- 최근 소스 활동
- 2026년 8월 10일 21:37
- 감지된 SKILL.md 언어
- 영어
- 스타
- 1,175
- 포크
- 379
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/gastownhall/gascity --skill gc-work명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | gc-work |
| description | Finding, creating, claiming, and closing work items (beads) |
Everything in Gas City is a bead — tasks, messages, molecules, convoys.
The gc bd CLI is the primary interface for bead CRUD.
Each rig has its own .beads/ database with its own ID prefix (e.g.
fe- for frontend, be- for beads). A bead must live in the
same database as the agent that will work on it. When you sling a bead
to a rig-scoped agent, sling operates on the agent's rig database — so
the bead must already exist there. The bead ID prefix tells you which
rig it belongs to.
Use gc rig list to see rig names, paths, and prefixes.
Use --rig to create beads in the right database. If the work will
be dispatched to a rig-scoped agent, create the bead in that agent's rig:
gc bd create "title" --rig frontend # Create in frontend's db (fe- prefix)
gc bd create "title" --rig beads # Create in beads db (be- prefix)
gc bd create "title" # Create in current directory's .beads/
gc bd create "title" -t bug # Create with type
gc bd create "title" --label priority=high # Create with labels
gc bd list # List beads in current .beads/
gc bd list --rig <rigname> # List beads in a specific rig
gc bd ready # List beads available for claiming
gc bd ready --label role:worker # Filter by label
gc bd show <id> # Show bead details
gc ready # Same frontier, federated over every store the city uses
On a city that serves a coordination class from its own [storage] binding,
gc bd ready (and gc bd list --ready) is refused with exit 1: it reads one
ledger and the city's ready set spans more than one. Use gc ready there. It
takes --assignee, --unassigned, --metadata-field, --exclude-type,
--exclude-label, --sort, --limit, --include-ephemeral, --status and
--json — not the label, parent, type or priority selectors gc bd ready
forwards.
gc bd update <id> --claim # Claim a bead (sets assignee + in_progress) — races in a multi-agent city; prefer `gc hook --claim` there
gc bd update <id> --status in_progress # Update status
gc bd update <id> --add-label <key>=<value> # Add/update labels
gc bd update <id> --append-notes "progress..." # Append a note (does not replace existing notes)
gc bd close <id> # Close a completed bead
gc bd close <id> --reason "done" # Close with reason
gc hook [agent] # Show routed work for an agent (defaults to $GC_AGENT)
gc hook --claim # Atomically claim one routed work item onto this agent's hook
Routing work to agents with gc sling and formulas
Project conventions for writing, editing, restructuring, or reviewing the Gas City user documentation — the Mintlify site under docs/. Use this whenever you touch anything in docs/ (pages, tutorials, guides, reference, concept pages, diagrams, navigation) or write/edit prose about Gas City, even when the request is just "fix the docs", "write a docs page", "the docs are wrong/confusing", "rename X across the docs", or an edit to a file under docs/. It defines the canonical six-primitive model, required terminology (orchestrator not controller, platform not SDK, formulas v2 as the value), the prose / emphasis / diagram conventions, the information architecture, the rule that generated docs are edited at their source, and the gates to run before docs work is done.
City lifecycle — status, start, stop, init
SOC 직업 분류 기준