guildmaster
An agent and CLI that manages skills for the AgentCulture mesh.
guildmaster is a sibling to steward
(resident-agent alignment), culture
(the IRC-based agent mesh), and daria
(the awareness agent) in the Organic Development framework. Its mission is skill
and skillversion management plus an overview surface for the mesh: per the
settled division of labor (issue #1),
guildmaster becomes the skills supplier/manager while steward retreats to
agent-alignment. It onboards as a consumer first — vendoring the canonical
skills like every other sibling — before taking over the upstream ledger,
broadcast, and version tracking.
The repo and the Culture agent are named guildmaster; the CLI ships as
guild-cli on PyPI and installs the guild binary.
Install
# From PyPI (Trusted Publishing):
uv tool install guild-cli
# From source (dev):
uv sync
uv run guild --version
Commands
All verbs are read-only, offline, and deterministic — safe to call in agent
loops. Add --json to any of them for structured output.
| Verb | What it does |
|---|---|
guild whoami |
Report this agent's identity — suffix + backend (from culture.yaml) + version. The smallest identity probe. |
guild learn |
Survey the repo: the CLI verbs, the vendored skills under .claude/skills/, and a pointer to CLAUDE.md. |
guild explain <topic> |
Explain one topic in depth — print a vendored skill's SKILL.md, or a verb's summary. |
uv run guild whoami
uv run guild learn
uv run guild explain cicd
Supplier verbs — teach & onboard
As the mesh's skills supplier, guildmaster propagates skills to sibling agents
through two agent-first write verbs. Both default to dry-run (render the
issues and the ledger/verification diffs); --apply files them.
| Verb | What it does |
|---|---|
guild teach --skill <name> … --to <agent> … |
Teach a chosen set of skills to a chosen set of mesh agents. |
guild onboard --agent <owner/repo> |
Welcome a brand-new sibling with the full canonical kit, an identity-setup section, ledger registration, and a verification record. |
Agent-major, not skill-major. A run files one GitHub issue per target
agent, bundling a per-skill section for every skill that agent receives —
not one issue per skill. New-vs-resync framing is auto-detected per
(skill, agent) from the docs/skill-sources.md ledger. Skills must be chosen
explicitly (--skill, repeatable, or --all) — there is no implicit default.
These supersede a separate announce-skill-update verb. teach is the
single render-and-post engine; onboard is "teach the whole canonical kit"
plus ledger registration, the identity section, and a verification record. There
is no standalone broadcast verb (cf.
issue #10, which asked
for one — guildmaster fulfills the broadcast role via these two verbs instead).
Before → after. Today guildmaster has no broadcast verb of its own —
steward runs the live broadcaster, and teaching a set of skills or standing up
a new sibling is manual (hand-rendered briefs, hand-edited ledger, no
verification). After: one command propagates a skill set, or onboards a
sibling end-to-end. Going live is gated on the staged steward→guildmaster
cutover — see docs/cutover.md.
Inventory verbs — overview & show
guildmaster owns the mesh's inventory surfaces (the read-only "what kit +
config does an agent have?" view) per
issue #12. Both are
read-only — no --apply, no mutation, no drift verdict (judgment stays with
steward overview / steward doctor).
| Verb | What it does |
|---|---|
guild overview [--scope all|self <agent>|mesh] |
The supplier view: the canonical skill set + versions/origins, the docs/skill-sources.md ledger, and drift signals (uncovered skills, per-agent kit gaps). Feeds teach / onboard. --scope mesh instead surveys every agent's vendored skills live off the filesystem and flags what's missing/stale per agent. |
guild show <path-or-suffix> |
One agent's full config in one view — its detected prompt file (CLAUDE.md / AGENTS.md / GEMINI.md), its parallel culture.yaml, and its .claude/skills index. |
uv run guild overview # whole ledger + canonical set
uv run guild overview --scope self daria # one agent's kit + gaps
uv run guild overview --scope mesh # live survey: every agent's skills + missing/stale
uv run guild show ../culture # config by path
uv run guild show daria # config by registered suffix
uv run guild show ../culture --json # structured config object
guild show resolves a registered suffix via the Culture server manifest
(culture_server_yaml in .claude/skills.local.yaml); pass an explicit
directory path to skip the lookup. Pre-cutover the ledger is still a
consumer-side view with no downstream column, so overview's drift signals
activate only after the steward→guildmaster cutover — the verb says so plainly.
guild harness use — switch the mesh-resident harness
guild harness use <name> writes one thing: the harness a clone's
culture.yaml declares — the backend/model/acp-command combination the
Culture daemon starts for that resident agent. Dry-run by default (renders the
culture.yaml diff); --apply writes.
This is deliberately narrow. Two different "which harness" selections exist over one clone, and this verb touches only one of them:
| Selection | What it means | Changed by |
|---|---|---|
| Interactive harness | Whichever binary you run in the repo right now (claude, colleague, qwen, …). All four can be run at will; it is never a config change. |
Invoking that binary directly — never this verb. |
| Mesh-resident harness | The single backend culture.yaml declares, which the Culture daemon starts for this clone. |
guild harness use <name> |
| Verb | What it does |
|---|---|
guild harness use <name> [--agent SUFFIX] |
Rewrite culture.yaml's backend/model/acp_command fields to match the named harness (claude, colleague, associate, qwen, acp — see guild/scaffold/harness.py). --agent picks which declared agent to switch when culture.yaml lists more than one. |
uv run guild harness use qwen # dry-run: show the culture.yaml diff
uv run guild harness use qwen --apply # write culture.yaml
uv run guild harness use claude --apply --agent daria # multi-agent culture.yaml
The write touches culture.yaml only — no file is created, fetched, or
re-provisioned, and no network call is made. Commit the result normally; a
fresh clone runs the new harness with no local setup step. This is not the
force path for an interactive session — forcing which binary you run right now
is invocation-level and never goes through culture.yaml.
Develop
uv sync
uv run pytest -n auto -v
uv run black --check guild tests && uv run isort --check-only guild tests
uv run flake8 guild tests && uv run bandit -c pyproject.toml -r guild
Every PR bumps the version (CI's version-check enforces it):
python3 .claude/skills/version-bump/scripts/bump.py patch
See CLAUDE.md for the full project shape, conventions, and the
build/test/publish toolchain.
1 maintainer
Metadata
1 maintainer
Release files for guild-cli 0.26.18
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| guild_cli-0.26.18.tar.gz | 457.0 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| guild_cli-0.26.18-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 541.1 kB
Release files / guild_cli-0.26.18.tar.gz
| Download URL | guild_cli-0.26.18.tar.gz |
|---|---|
| Size | 457.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a7f152c140f28d6345e665c0af40626ae218c5398c25077721c3bbb03e4494b5
|
|
BLAKE2b-256 checksum How to use checksums |
dc8e27b63e75068012b40f18543f02ade179f2f6736d8f72b2aaf315fc677953
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.3 {"installer":{"name":"uv","version":"0.13.3","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"26.04","id":"resolute","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / guild_cli-0.26.18-py3-none-any.whl
| Download URL | guild_cli-0.26.18-py3-none-any.whl |
|---|---|
| Size | 84.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
da69e157526a05e0d10d9fbbe8f5140dac3ae490a2dc6bd44be784997087e710
|
|
BLAKE2b-256 checksum How to use checksums |
84eace707d39c0d9ea13d500f9e6b8ead4292ec29e2f56bdcbb5328159615e47
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.3 {"installer":{"name":"uv","version":"0.13.3","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"26.04","id":"resolute","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for guild-cli 0.26.18
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
