guild-cli 0.4.0__tar.gz → 0.5.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (98) hide show
  1. guild_cli-0.5.0/.claude/skills/guild/SKILL.md +146 -0
  2. guild_cli-0.5.0/.claude/skills/guild/scripts/overview.sh +76 -0
  3. {guild_cli-0.4.0 → guild_cli-0.5.0}/CHANGELOG.md +73 -0
  4. {guild_cli-0.4.0 → guild_cli-0.5.0}/CLAUDE.md +11 -5
  5. {guild_cli-0.4.0 → guild_cli-0.5.0}/PKG-INFO +3 -2
  6. {guild_cli-0.4.0 → guild_cli-0.5.0}/README.md +2 -1
  7. guild_cli-0.5.0/docs/cutover.md +52 -0
  8. guild_cli-0.5.0/docs/skill-sources.md +144 -0
  9. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/overview.py +155 -18
  10. guild_cli-0.5.0/guild/cli/_repo.py +235 -0
  11. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/skills/__init__.py +6 -3
  12. {guild_cli-0.4.0 → guild_cli-0.5.0}/pyproject.toml +1 -1
  13. guild_cli-0.5.0/tests/test_cli_overview.py +286 -0
  14. {guild_cli-0.4.0 → guild_cli-0.5.0}/uv.lock +1 -1
  15. guild_cli-0.4.0/docs/cutover.md +0 -43
  16. guild_cli-0.4.0/docs/skill-sources.md +0 -78
  17. guild_cli-0.4.0/guild/cli/_repo.py +0 -116
  18. guild_cli-0.4.0/tests/test_cli_overview.py +0 -148
  19. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/agent-config/SKILL.md +0 -0
  20. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/agent-config/data/backend-fingerprints.yaml +0 -0
  21. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/agent-config/scripts/show.sh +0 -0
  22. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/assign-to-workforce/SKILL.md +0 -0
  23. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/assign-to-workforce/scripts/assign-to-workforce.sh +0 -0
  24. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/SKILL.md +0 -0
  25. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/scripts/_resolve-nick.sh +0 -0
  26. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/scripts/portability-lint.sh +0 -0
  27. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/scripts/pr-reply.sh +0 -0
  28. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/scripts/pr-status.sh +0 -0
  29. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/cicd/scripts/workflow.sh +0 -0
  30. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/SKILL.md +0 -0
  31. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/fetch-issues.sh +0 -0
  32. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/mesh-message.sh +0 -0
  33. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/post-comment.sh +0 -0
  34. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/post-issue.sh +0 -0
  35. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/templates/skill-new-brief.md +0 -0
  36. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/communicate/scripts/templates/skill-update-brief.md +0 -0
  37. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/doc-test-alignment/SKILL.md +0 -0
  38. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/doc-test-alignment/scripts/check.sh +0 -0
  39. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/onboard/SKILL.md +0 -0
  40. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/onboard/scripts/onboard.sh +0 -0
  41. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/pypi-maintainer/SKILL.md +0 -0
  42. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/pypi-maintainer/scripts/switch-source.sh +0 -0
  43. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/run-tests/SKILL.md +0 -0
  44. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/run-tests/scripts/test.sh +0 -0
  45. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/sonarclaude/SKILL.md +0 -0
  46. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/sonarclaude/scripts/sonar.sh +0 -0
  47. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/spec-to-plan/SKILL.md +0 -0
  48. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/spec-to-plan/scripts/spec-to-plan.sh +0 -0
  49. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/teach/SKILL.md +0 -0
  50. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/teach/scripts/teach.sh +0 -0
  51. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/think/SKILL.md +0 -0
  52. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/think/scripts/think.sh +0 -0
  53. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/version-bump/SKILL.md +0 -0
  54. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills/version-bump/scripts/bump.py +0 -0
  55. {guild_cli-0.4.0 → guild_cli-0.5.0}/.claude/skills.local.yaml.example +0 -0
  56. {guild_cli-0.4.0 → guild_cli-0.5.0}/.devague/frames/guildmaster-ships-teach-and-onboard-two-agent-firs.json +0 -0
  57. {guild_cli-0.4.0 → guild_cli-0.5.0}/.devague/plans/guildmaster-ships-teach-and-onboard-two-agent-firs.json +0 -0
  58. {guild_cli-0.4.0 → guild_cli-0.5.0}/.flake8 +0 -0
  59. {guild_cli-0.4.0 → guild_cli-0.5.0}/.github/workflows/publish.yml +0 -0
  60. {guild_cli-0.4.0 → guild_cli-0.5.0}/.github/workflows/tests.yml +0 -0
  61. {guild_cli-0.4.0 → guild_cli-0.5.0}/.gitignore +0 -0
  62. {guild_cli-0.4.0 → guild_cli-0.5.0}/.markdownlint-cli2.yaml +0 -0
  63. {guild_cli-0.4.0 → guild_cli-0.5.0}/LICENSE +0 -0
  64. {guild_cli-0.4.0 → guild_cli-0.5.0}/culture.yaml +0 -0
  65. {guild_cli-0.4.0 → guild_cli-0.5.0}/docs/plans/2026-05-24-guildmaster-ships-teach-and-onboard-two-agent-firs.md +0 -0
  66. {guild_cli-0.4.0 → guild_cli-0.5.0}/docs/specs/2026-05-24-guildmaster-ships-teach-and-onboard-two-agent-firs.md +0 -0
  67. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/__init__.py +0 -0
  68. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/__main__.py +0 -0
  69. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/__init__.py +0 -0
  70. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/__init__.py +0 -0
  71. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/_broadcast.py +0 -0
  72. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/explain.py +0 -0
  73. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/learn.py +0 -0
  74. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/onboard.py +0 -0
  75. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/show.py +0 -0
  76. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/teach.py +0 -0
  77. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_commands/whoami.py +0 -0
  78. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_errors.py +0 -0
  79. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/cli/_output.py +0 -0
  80. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/skills/identity.py +0 -0
  81. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/skills/ledger.py +0 -0
  82. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/skills/render.py +0 -0
  83. {guild_cli-0.4.0 → guild_cli-0.5.0}/guild/skills/sources.py +0 -0
  84. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/__init__.py +0 -0
  85. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_broadcast_post.py +0 -0
  86. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli.py +0 -0
  87. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_explain.py +0 -0
  88. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_learn.py +0 -0
  89. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_onboard.py +0 -0
  90. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_show.py +0 -0
  91. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_teach.py +0 -0
  92. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_cli_whoami.py +0 -0
  93. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_skills_convention.py +0 -0
  94. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_skills_identity.py +0 -0
  95. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_skills_ledger.py +0 -0
  96. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_skills_render.py +0 -0
  97. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_skills_sources.py +0 -0
  98. {guild_cli-0.4.0 → guild_cli-0.5.0}/tests/test_version_fallback.py +0 -0
@@ -0,0 +1,146 @@
1
+ ---
2
+ name: guild
3
+ description: >
4
+ Run guildmaster's skills-supplier overview and narrate it. Run `guild
5
+ overview` (via scripts/overview.sh) for the deterministic evidence pack — the
6
+ canonical skill set + versions/origins, the docs/skill-sources.md ledger, and
7
+ skills-scoped drift signals — then narrate three separated layers: observed
8
+ facts, inferred relationships, and suggestions (each naming the command that
9
+ enacts it). Use when an operator asks "what skills do we supply", "who
10
+ consumes what", "is anything drifting", or "what should I teach next".
11
+ Skills-scoped and reflect-only — it surfaces and interprets supplier-side
12
+ skill/version signals; it does NOT narrate the agent relationship graph or
13
+ judge alignment (that stays with steward's org-overview / steward doctor).
14
+ The skills-scoped excerpt of steward's `org-overview` narration contract
15
+ (cite-don't-import, issue #12).
16
+ type: command
17
+ ---
18
+
19
+ # guild — narrate guildmaster's own supplier surfaces
20
+
21
+ guildmaster is the mesh's skills **supplier**, and it owns the *inventory*
22
+ surfaces ([issue #12](https://github.com/agentculture/guildmaster/issues/12)).
23
+ The per-agent half (`guild show`) is backed by the vendored `agent-config`
24
+ skill. **This skill is the supplier half: the affordance for `guild overview`.**
25
+ It houses the scripts that run guildmaster's own read-only CLI surfaces and the
26
+ contract for narrating them — `overview` is the one script today.
27
+
28
+ Unlike the vendored skills, this one is **guildmaster's own** (origin =
29
+ `guildmaster`, not cited from steward): `guild overview` is a pure-Python,
30
+ read-only CLI verb, and `scripts/overview.sh` is the thin deterministic wrapper
31
+ that invokes it. The script picks how to call `guild` (installed console
32
+ script → `uv run` → `python -m guild`) and delegates; it interprets nothing.
33
+
34
+ **The load-bearing split** (this is the skills-scoped excerpt of steward's
35
+ `org-overview` narration contract — issue #12, cite-don't-import):
36
+
37
+ - **The CLI (`guild overview`) emits only deterministic facts** — the canonical
38
+ skill set, the ledger view, and neutral drift signals. No LLM, no
39
+ interpretation, mutates nothing.
40
+ - **This skill is where the agent interprets** — turning those facts into
41
+ inferred relationships and suggestions. **Never present an inference as a
42
+ fact**, and keep the layers in separate sections.
43
+
44
+ ## What `overview` answers
45
+
46
+ A skills-scoped evidence pack — **not** `steward overview`'s ecosystem
47
+ relationship graph (issue #12: inventory → guildmaster; judgment → steward):
48
+
49
+ 1. **Canonical skill set + versions** — every skill guildmaster supplies, its
50
+ origin (`guildmaster`, or a sibling it only re-broadcasts), and the current
51
+ canonical version, plus per-skill consumers.
52
+ 2. **Ledger view** — who-consumes-which-skill, read from `docs/skill-sources.md`.
53
+ 3. **Drift signals** — canonical skills no one consumes, canonical skills the
54
+ ledger doesn't track yet, and per-agent kit gaps. These feed `teach` /
55
+ `onboard`.
56
+
57
+ **Pre-cutover** the guildmaster ledger is still a consumer-side view with no
58
+ "Downstream" column, so the supplier ledger is empty and drift is inactive; the
59
+ verb reports the canonical set and says so plainly (see `docs/cutover.md`).
60
+
61
+ **`--scope mesh`** is the ledger-free alternative: it surveys every agent in the
62
+ workspace (`<workspace>/*/culture.yaml`) live off the filesystem and reports, per
63
+ agent, each canonical skill as **current** / **stale** (the agent's copy differs
64
+ from guildmaster's by content fingerprint) / **missing**, plus any non-canonical
65
+ "extra" skills. Use it to answer "what's missing or stale, and where" *today*,
66
+ without waiting for the cutover. Still skills-scoped — no relationship graph.
67
+
68
+ ## When to use
69
+
70
+ - An operator asks "what skills do we supply" / "what's the canonical set".
71
+ - "Who has skill `<x>`?" / "who consumes what?" / "is anything drifting?"
72
+ - "What should I `teach` next?" — overview's gaps are the input to `teach`.
73
+ - Before `guild teach` / `guild onboard`, to see uncovered skills and kit gaps.
74
+
75
+ ## How to run
76
+
77
+ One script. Pick the scope (or just run `guild overview`, which this wraps):
78
+
79
+ ```bash
80
+ # Whole mesh — the canonical set + ledger + drift across all agents (default)
81
+ .claude/skills/guild/scripts/overview.sh
82
+
83
+ # One agent — that agent's kit + gaps (first positional → --scope self)
84
+ .claude/skills/guild/scripts/overview.sh daria
85
+
86
+ # Mesh survey — every agent's skills + missing/stale, live off the filesystem
87
+ .claude/skills/guild/scripts/overview.sh --scope mesh
88
+
89
+ # Machine-readable evidence for precise reasoning
90
+ .claude/skills/guild/scripts/overview.sh --json
91
+ .claude/skills/guild/scripts/overview.sh --scope mesh --json
92
+ ```
93
+
94
+ The script prints the CLI's markdown by default: the canonical-skill table, a
95
+ ledger section, and a drift section. The exact per-skill consumer and gap lists
96
+ live in `--json`.
97
+
98
+ ## Narrate three layers — never blur them
99
+
100
+ `guild overview` emits only deterministic facts; this skill is where you
101
+ interpret them. Keep the three layers in separate sections, and never present
102
+ an inference as a fact:
103
+
104
+ 1. **Observed facts.** Summarize the canonical set + versions/origins and the
105
+ ledger view in your own words — lead with what the counts reveal (the
106
+ canonical set, who's behind, who's unregistered). State only what the CLI
107
+ reported; don't reproduce the raw signal lists verbatim (read `--json` only
108
+ when you need an exact list to act on). Pre-cutover, say so plainly: the
109
+ ledger has no downstream column yet, so consumers are empty and drift is
110
+ inactive.
111
+ 2. **Inferred relationships** (mark clearly as inferred). Connect facts no
112
+ single ledger row states outright — e.g. two consumers vendored from the
113
+ same upstream skill *both* lag a canonical bump (a shared exposure), or a
114
+ skill only `guildmaster` carries is a single point of supply.
115
+ 3. **Suggestions** (kept separate from facts, and *named, not run*). Seed these
116
+ from the skills-scoped drift signals — for each, name the concrete next step
117
+ and the command that enacts it, then stop.
118
+
119
+ ### Signal → suggestion (skills-scoped only)
120
+
121
+ These are the **skill/version** signals `guild overview` emits — guildmaster's
122
+ supplier lane:
123
+
124
+ | Drift signal (from `guild overview`) | Reading | Named follow-up — name it, do NOT auto-run |
125
+ |--------------------------------------|---------|--------------------------------------------|
126
+ | `unledgered_skills` | a canonical skill the ledger doesn't track (no owner row) | Fix the ledger: add it to `docs/skill-sources.md` |
127
+ | `uncovered_skills` | a canonical skill no agent consumes (orphan) | Confirm intentional, then `teach` it, or retire it |
128
+ | `agent_gaps` (per-agent missing skill) | a consumer behind / missing a skill | `guild teach --skill <name> --to <agent>` to close the gap |
129
+ | agent not registered in the ledger | a sibling not yet onboarded | `guild onboard --agent <owner/repo>` |
130
+ | consumer behind the canonical pin (post-cutover) | a team on an outdated procedure | Re-vendor: `guild teach` / `onboard` to the current pin |
131
+
132
+ ### Out of scope — steward's lane
133
+
134
+ The **relationship** signals — `overlap`, `over-connected-agent`,
135
+ `isolated-repo` — and the typed agent relationship graph are **not** narrated
136
+ here. Those belong to steward's `org-overview` / `steward overview`. guildmaster
137
+ narrates skills/version drift, not the ecosystem graph or alignment judgment.
138
+
139
+ ### Reflect-only
140
+
141
+ This skill **sees, reflects, and suggests — it does not act.** For every
142
+ suggestion, name the concrete next step and the command that enacts it, then
143
+ stop. Editing the ledger, filing an issue, or running `teach` / `onboard` is a
144
+ separate, explicit step the operator chooses. The skill writes nothing to disk
145
+ and mutates no repo — output is the chat conversation only. Read-only: no
146
+ `--apply`, no mutation, no network/LLM call.
@@ -0,0 +1,76 @@
1
+ #!/usr/bin/env bash
2
+ set -euo pipefail
3
+ # overview — assemble the `guild overview` skills-supplier evidence pack for
4
+ # narration.
5
+ #
6
+ # The guildmaster agent runs this, then narrates the supplier view (the
7
+ # canonical skill set + versions/origins, the docs/skill-sources.md ledger, and
8
+ # the drift signals that feed `teach` / `onboard`). See SKILL.md.
9
+ # Deterministic glue only: resolve guildmaster's repo root, run from there,
10
+ # resolve how to invoke guild, pick the scope, and delegate to `guild overview`.
11
+ # No interpretation.
12
+ #
13
+ # Usage:
14
+ # overview.sh # whole ledger across the mesh (--scope all)
15
+ # overview.sh <agent> # one agent's kit + gaps (--scope self)
16
+ # overview.sh --scope mesh # live filesystem survey of every agent
17
+ # overview.sh --json # all, JSON evidence
18
+ # overview.sh <agent> --json # one agent, JSON evidence
19
+ #
20
+ # Contract: the FIRST argument, if it does not start with '-', is the agent
21
+ # (self scope). All remaining arguments pass through to `guild overview`.
22
+ #
23
+ # Exit codes:
24
+ # 0 success (delegates to `guild overview`; its exit code propagates)
25
+ # 1 environment error (no way to invoke guild)
26
+
27
+ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
28
+
29
+ # Resolve guildmaster's repo root and run from there, so `guild overview` always
30
+ # reports guildmaster's canonical set regardless of the caller's working
31
+ # directory (the CLI reads its repo from cwd). Prefer git (robust); fall back to
32
+ # climbing out of the fixed .claude/skills/<name>/scripts/ layout when git is
33
+ # unavailable.
34
+ REPO_ROOT="$(git -C "$SCRIPT_DIR" rev-parse --show-toplevel 2>/dev/null || true)"
35
+ if [ -z "$REPO_ROOT" ]; then
36
+ REPO_ROOT="$(cd "$SCRIPT_DIR/../../../.." && pwd)"
37
+ fi
38
+ cd "$REPO_ROOT"
39
+
40
+ # Resolve how to invoke guild: installed console script, then uv, then module.
41
+ if command -v guild >/dev/null 2>&1; then
42
+ GUILD=(guild)
43
+ elif [ -f "$REPO_ROOT/pyproject.toml" ] && command -v uv >/dev/null 2>&1; then
44
+ GUILD=(uv run --project "$REPO_ROOT" guild)
45
+ elif command -v python3 >/dev/null 2>&1; then
46
+ GUILD=(python3 -m guild)
47
+ else
48
+ echo "overview: cannot invoke guild (need 'guild', 'uv', or 'python3' on PATH)" >&2
49
+ exit 1
50
+ fi
51
+
52
+ # Honor an explicit --scope passed through (advanced use); otherwise pick one.
53
+ has_scope=false
54
+ for arg in "$@"; do
55
+ case "$arg" in
56
+ --scope | --scope=*)
57
+ has_scope=true
58
+ break
59
+ ;;
60
+ esac
61
+ done
62
+
63
+ overview_args=()
64
+ if [ "$#" -gt 0 ] && [[ "$1" != -* ]]; then
65
+ # First arg is an agent → one-agent (self) scope.
66
+ agent="$1"
67
+ shift
68
+ $has_scope || overview_args+=(--scope self)
69
+ overview_args+=("$agent")
70
+ else
71
+ # No leading agent → whole-ledger (all) view.
72
+ $has_scope || overview_args+=(--scope all)
73
+ fi
74
+ overview_args+=("$@")
75
+
76
+ exec "${GUILD[@]}" overview "${overview_args[@]}"
@@ -5,6 +5,79 @@ All notable changes to this project will be documented in this file.
5
5
  Format follows [Keep a Changelog](https://keepachangelog.com/). This project
6
6
  adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7
7
 
8
+ ## [0.5.0] - 2026-05-24
9
+
10
+ ### Changed
11
+
12
+ - **steward → guildmaster cutover (guildmaster's side).** Migrated
13
+ `docs/skill-sources.md` from the consumer-side "Upstream / Notes" view to the
14
+ **supplier shape**: a canonical-set table with a "Downstream copies (known)"
15
+ column (upstream reassigned `steward` → `guildmaster`), the devague-origin
16
+ re-broadcast table, and a "Retained by steward" section recording the
17
+ steward-specific skills (`org-overview`, steward's alignment `agent-config`
18
+ variant, `discord-notify`, `jekyll-test`, `notebooklm`) that stay with steward.
19
+ The downstream consumer lists were carried over verbatim from steward's ledger
20
+ at cutover. This activates resync-detection in `teach` / `onboard` and
21
+ skills-scoped drift in `guild overview --scope all` / `--scope self`
22
+ ([issue #1 §1](https://github.com/agentculture/guildmaster/issues/1),
23
+ `docs/cutover.md`).
24
+ - **`docs/cutover.md`** updated to the in-progress state: guildmaster's side is
25
+ done and the handshake ping sent; the one remaining gate before `--apply` goes
26
+ live is steward's ack that it has stopped broadcasting (no two live
27
+ broadcasters, per [#10](https://github.com/agentculture/guildmaster/issues/10)).
28
+
29
+ ## [0.4.2] - 2026-05-24
30
+
31
+ ### Added
32
+
33
+ - **`guild overview --scope mesh`** — a live filesystem survey of the whole
34
+ workspace, the answer to "what skills does every agent have, and what's
35
+ missing or stale, and where" without waiting for the cutover. Discovers every
36
+ agent (`<workspace>/*/culture.yaml`, via the new `discover_agents` helper) and
37
+ reports, per agent, each canonical skill as **current** / **stale** (the
38
+ agent's copy differs from guildmaster's by content fingerprint —
39
+ `skill_fingerprint`) / **missing**, plus any non-canonical "extra" skills.
40
+ Markdown + `--json`; `--workspace-root DIR` overrides the surveyed root
41
+ (default: the parent of this repo). Read-only, inventory only — no
42
+ dependency/relationship graph (that stays steward's lane). The existing
43
+ ledger-based `--scope all` / `--scope self` are unchanged.
44
+
45
+ ### Changed
46
+
47
+ ### Fixed
48
+
49
+ - Mesh-survey robustness (Qodo review on #15): `discover_agents` and
50
+ `iter_skills` now skip non-UTF-8 / unreadable `culture.yaml` and `SKILL.md`
51
+ (one bad file in a surveyed repo no longer crashes the run), and
52
+ `skill_fingerprint` skips symlinks (never follows links outside the skill dir;
53
+ keeps the digest deterministic).
54
+
55
+ ## [0.4.1] - 2026-05-24
56
+
57
+ ### Added
58
+
59
+ - **`guild` skill** — the backing affordance + narration skill for `guild
60
+ overview`, the supplier-overview half of the inventory split (sibling to the
61
+ vendored `agent-config` skill that backs `guild show`). `scripts/overview.sh`
62
+ is a deterministic wrapper that resolves how to invoke `guild` (installed →
63
+ `uv` → `python -m guild`) and delegates to `guild overview`; `SKILL.md` is the
64
+ **skills-scoped excerpt of steward's `org-overview` narration contract**
65
+ ([#12](https://github.com/agentculture/guildmaster/issues/12),
66
+ cite-don't-import): narrate three separated layers — observed facts, inferred
67
+ relationships, suggestions (each naming its enacting `teach` / `onboard` /
68
+ ledger command), reflect-only. Skills/version scope only — does NOT narrate
69
+ steward's relationship-graph signals (`overlap` / `over-connected-agent` /
70
+ `isolated-repo`). Recorded in `docs/skill-sources.md` as guildmaster-origin
71
+ (not vendored).
72
+
73
+ ### Changed
74
+
75
+ - `SELF_SKILLS` now includes `guild` — guildmaster's own affordance skill is
76
+ excluded from the canonical kit it supplies to siblings (like `teach` /
77
+ `onboard`), since it wraps the `guild` binary and is meaningless elsewhere.
78
+
79
+ ### Fixed
80
+
8
81
  ## [0.4.0] - 2026-05-24
9
82
 
10
83
  ### Added
@@ -113,11 +113,17 @@ owns the mesh's *inventory* surfaces per
113
113
  **inventory → guildmaster; judgment ("how do agents relate / are they aligned?")
114
114
  → steward.** Neither verb clones `steward overview`'s relationship graph.
115
115
 
116
- - `guild overview [--scope all|self <agent>]` — the supplier view: canonical
117
- skill set + versions/origins, the `docs/skill-sources.md` ledger, and drift
118
- signals (uncovered skills, per-agent kit gaps). Pure-Python, read-only, **no
119
- `--apply`**. Pre-cutover the ledger has no downstream column, so drift is
120
- inactive and the verb says so (reads whichever ledger is authoritative).
116
+ - `guild overview [--scope all|self <agent>|mesh]` — the supplier view:
117
+ canonical skill set + versions/origins, the `docs/skill-sources.md` ledger,
118
+ and drift signals (uncovered skills, per-agent kit gaps). Pure-Python,
119
+ read-only, **no `--apply`**. Pre-cutover the ledger has no downstream column,
120
+ so `--scope all`/`self` drift is inactive and the verb says so (reads
121
+ whichever ledger is authoritative). `--scope mesh` is the ledger-free
122
+ alternative: it surveys every agent in the workspace
123
+ (`<workspace>/*/culture.yaml`) live off the filesystem and reports, per agent,
124
+ each canonical skill as current / **stale** (content fingerprint differs from
125
+ guildmaster's copy) / **missing** — answering "what's missing or stale, and
126
+ where" today. Still inventory only — no relationship graph.
121
127
  - `guild show <path-or-suffix>` — one agent's full config: detected prompt file
122
128
  (`CLAUDE.md` / `AGENTS.md` / `GEMINI.md`), parallel `culture.yaml`, and the
123
129
  `.claude/skills` index. Thin wrapper that shells out to the vendored
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: guild-cli
3
- Version: 0.4.0
3
+ Version: 0.5.0
4
4
  Summary: guildmaster — an agent and CLI that manages skills for the AgentCulture mesh.
5
5
  Project-URL: Homepage, https://github.com/agentculture/guildmaster
6
6
  Project-URL: Issues, https://github.com/agentculture/guildmaster/issues
@@ -104,12 +104,13 @@ read-only — no `--apply`, no mutation, no drift verdict (judgment stays with
104
104
 
105
105
  | Verb | What it does |
106
106
  |------|--------------|
107
- | `guild overview [--scope all\|self <agent>]` | 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`. |
107
+ | `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. |
108
108
  | `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. |
109
109
 
110
110
  ```bash
111
111
  uv run guild overview # whole ledger + canonical set
112
112
  uv run guild overview --scope self daria # one agent's kit + gaps
113
+ uv run guild overview --scope mesh # live survey: every agent's skills + missing/stale
113
114
  uv run guild show ../culture # config by path
114
115
  uv run guild show daria # config by registered suffix
115
116
  uv run guild show ../culture --json # structured config object
@@ -86,12 +86,13 @@ read-only — no `--apply`, no mutation, no drift verdict (judgment stays with
86
86
 
87
87
  | Verb | What it does |
88
88
  |------|--------------|
89
- | `guild overview [--scope all\|self <agent>]` | 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`. |
89
+ | `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. |
90
90
  | `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. |
91
91
 
92
92
  ```bash
93
93
  uv run guild overview # whole ledger + canonical set
94
94
  uv run guild overview --scope self daria # one agent's kit + gaps
95
+ uv run guild overview --scope mesh # live survey: every agent's skills + missing/stale
95
96
  uv run guild show ../culture # config by path
96
97
  uv run guild show daria # config by registered suffix
97
98
  uv run guild show ../culture --json # structured config object
@@ -0,0 +1,52 @@
1
+ # Broadcaster cutover — steward → guildmaster
2
+
3
+ guildmaster's `teach` / `onboard` verbs are the mesh's skill-broadcast surface
4
+ (see the README "Supplier verbs" section and
5
+ [issue #1 §1](https://github.com/agentculture/guildmaster/issues/1)). Standing
6
+ them up does **not** make guildmaster the live broadcaster the moment the code
7
+ merges. There is a hard precondition.
8
+
9
+ ## Status: in progress — awaiting steward's ack (2026-05-24)
10
+
11
+ guildmaster's side of the cutover has landed: `teach` / `onboard` are green and
12
+ reviewed, and `docs/skill-sources.md` has been migrated to the **supplier
13
+ shape** (canonical set + Downstream column carried over from steward's ledger).
14
+ The handshake ping (step 1 below) has been sent. The **one remaining gate** is
15
+ steward's ack that it has stopped broadcasting (step 2). Until that ack lands,
16
+ `--apply` stays **off** — operate in dry-run only.
17
+
18
+ ## Precondition (load-bearing)
19
+
20
+ > **`teach` / `onboard` must not broadcast in production (`--apply`) until
21
+ > `steward` has confirmed it stopped broadcasting.** While both sides could
22
+ > broadcast, running guildmaster's verbs with `--apply` would mean **two live
23
+ > broadcasters** and double-posted briefs — exactly what
24
+ > [issue #10](https://github.com/agentculture/guildmaster/issues/10) forbids.
25
+
26
+ `--dry-run` (the default) is always safe: it renders briefs and ledger /
27
+ verification diffs without posting. Only `--apply` is gated.
28
+
29
+ ## The cutover, step by step
30
+
31
+ 1. **[done]** guildmaster's `teach` / `onboard` are green and reviewed.
32
+ 2. **[done]** guildmaster migrates `docs/skill-sources.md` to the supplier shape
33
+ and takes ownership of the ledger + broadcast role + skill-version tracking
34
+ (this PR).
35
+ 3. **[done]** guildmaster pings `steward` that the broadcast surface is ready.
36
+ 4. **[pending — steward]** steward **stops broadcasting**, retires its
37
+ supplier-ledger ownership, and acks the handover.
38
+ 5. **[pending]** From then on, guildmaster is the sole broadcaster. No overlap,
39
+ no two competing ledgers — and `--apply` goes live.
40
+
41
+ Until step 4's ack lands, treat any guildmaster `--apply` broadcast as **off** —
42
+ operate in dry-run only.
43
+
44
+ ## Why no separate `announce-skill-update` verb
45
+
46
+ Issue #10 asked guildmaster to stand up its own `announce-skill-update`
47
+ subcommand (steward's skill-major, one-skill-→-N-consumers verb). guildmaster
48
+ fulfills the same broadcast **role** through `teach` / `onboard` instead — which
49
+ are **agent-major** (one issue per agent, bundling per-skill sections). `teach`
50
+ with one skill to one agent covers the single-skill case, so a separate verb
51
+ would be redundant. The reconciliation is tracked on issue #10; see
52
+ `docs/specs/` and `docs/plans/` for the converged design.
@@ -0,0 +1,144 @@
1
+ # Skill supplier — guildmaster's canonical skills
2
+
3
+ guildmaster is the AgentCulture mesh's **skill supplier/manager**. Per the
4
+ settled division of labor ([issue #1 §1](https://github.com/agentculture/guildmaster/issues/1))
5
+ and the completed steward → guildmaster cutover (`docs/cutover.md`), guildmaster
6
+ owns the canonical upstream copies of the cross-sibling skill set, this
7
+ upstream/downstream ledger, the broadcast verbs (`teach` / `onboard`), and skill
8
+ version tracking. `steward` has retreated to agent-alignment (`steward doctor` /
9
+ `steward overview`) and is no longer the live broadcaster.
10
+
11
+ This file is the deterministic upstream/downstream map handed over from
12
+ steward's `docs/skill-sources.md` at cutover. Each skill has exactly one
13
+ canonical source repo (the **upstream/origin** column); other repos hold
14
+ downstream copies that may lag and should periodically re-sync from upstream.
15
+ `guild teach` / `guild onboard` read the **Downstream** column to auto-frame each
16
+ `(skill, agent)` as *new* vs *resync*, and `guild overview` reads it for
17
+ skills-scoped drift.
18
+
19
+ Everything here follows **cite, don't import**: each skill is *copied* into
20
+ `.claude/skills/<name>/`, not symlinked or installed as a cross-repo dependency.
21
+ Each consumer owns its copy and may diverge; nothing reaches across skill
22
+ boundaries at runtime. When upstream changes, downstream copies do **not**
23
+ auto-update — re-sync explicitly from the cited source.
24
+
25
+ ## Canonical supplied skills (upstream = `guildmaster`)
26
+
27
+ These are the cross-sibling skills guildmaster owns and broadcasts. Source of
28
+ truth is guildmaster's own copy under `.claude/skills/<name>/`; downstream
29
+ consumers re-sync from there. Ownership transferred from `steward` at cutover;
30
+ the downstream lists below were carried over from steward's ledger and are kept
31
+ current by `guild overview --scope mesh`.
32
+
33
+ | Skill | Upstream | Downstream copies (known) | Notes |
34
+ |-------|----------|---------------------------|-------|
35
+ | `agent-config` | `guildmaster` (`.claude/skills/agent-config/`) | — | Inventory variant backing `guild show` ([#12](https://github.com/agentculture/guildmaster/issues/12)); `show.sh` + `data/backend-fingerprints.yaml` vendored verbatim from steward, SKILL.md reframed from alignment-judgment to inventory + `type: command` added. **Forked from steward:** steward retains its own alignment-focused `agent-config` variant; the inventory variant is guildmaster's to supply. |
36
+ | `cicd` | `guildmaster` (`.claude/skills/cicd/`) — layered on `agex pr` (in `agentculture/agex-cli`) | `afi-cli`, `agex-cli` (adapted-thin delegate — owns `agex pr`; see [agex-cli#53](https://github.com/agentculture/agex-cli/pull/53)), `agtag`, `antoine`, `appsec`, `auntiepypi`, `cfafi` (still named `pr-review`), `code-lens-cli`, `culture` (still named `pr-review`), `devague`, `katvan`, `lecodeur`, `lepenseur`, `seer-cli`, `telek` | Thin delegate to `agex pr` for lint / open / read / reply / delta, plus guildmaster's `status` (SonarCloud quality gate + hotspots + unresolved-thread tally) and `await` (composes `agex pr read --wait` with `status`, non-zero exit on Sonar ERROR / unresolved threads) extensions. **Inverted case:** agex-cli, as the `agex pr` upstream, vendors the skill adapted-thin — a `workflow.sh`-only pure delegate ([agex-cli#53](https://github.com/agentculture/agex-cli/pull/53)). Renamed from `pr-review` in steward 0.7.0; downstream copies may keep the old name on their own cadence. |
37
+ | `communicate` | `guildmaster` (`.claude/skills/communicate/`) | `afi-cli`, `agex-cli` (identifier-only — vendored steward 0.11.0; scripts current as of 0.18.0), `agtag`, `antoine`, `appsec`, `auntiepypi`, `code-lens-cli`, `culture` (still named `coordinate`), `devague`, `katvan`, `lecodeur`, `lepenseur`, `seer-cli`, `telek` | Cross-repo + mesh communication: file issues / hand off briefs to sibling-repo agents (auto-signed), comment on existing issues, fetch issues to inline state into briefs, and send live messages to Culture mesh channels (unsigned — nick is the speaker). Renamed from `coordinate` in steward 0.8.0; absorbed `gh-issues` (as `fetch-issues.sh`) in 0.9.1. Issue I/O backed by `agtag` (>=0.1) since steward 0.11.0 — signature resolves from local `culture.yaml` (override via `--as`). |
38
+ | `doc-test-alignment` | `guildmaster` (`.claude/skills/doc-test-alignment/`) | `devague`, `lecodeur`, `lepenseur` | Stub; real implementation TBD. `scripts/check.sh` exits not-yet-implemented today. |
39
+ | `pypi-maintainer` | `guildmaster` (`.claude/skills/pypi-maintainer/`) | `agtag` | Switches a PyPI package install between pypi / test-pypi / local. Generalised from the original culture-specific `change-package`. |
40
+ | `run-tests` | `guildmaster` (`.claude/skills/run-tests/`) | `agtag`, `antoine`, `appsec`, `code-lens-cli`, `culture`, `culture-sonar-cli`, `devague`, `lecodeur`, `lepenseur`, `seer-cli`, `shushu`, `telek` | Coverage source resolves from `[tool.coverage.run]` in `pyproject.toml`, so the script is portable across siblings without modification. |
41
+ | `sonarclaude` | `guildmaster` (`.claude/skills/sonarclaude/`) | `antoine`, `appsec`, `code-lens-cli`, `devague`, `lecodeur`, `lepenseur`, `seer-cli`, `telek` | SonarCloud API client. Project key resolves from `$SONAR_PROJECT` or `--project KEY`. |
42
+ | `version-bump` | `guildmaster` (`.claude/skills/version-bump/`) | `afi-cli`, `agtag`, `antoine`, `appsec`, `auntiepypi`, `cfafi`, `code-lens-cli`, `culture`, `devague`, `lecodeur`, `lepenseur`, `seer-cli`, `shushu`, `telek` | Pure Python, prepends a Keep-a-Changelog entry; no per-repo customization needed. |
43
+
44
+ > **How the downstream column is maintained.** The "Downstream copies (known)"
45
+ > entries are kept in sync with guildmaster's own drift detector:
46
+ > `guild overview --scope mesh` walks every workspace repo that declares an agent
47
+ > (`culture.yaml`) and reports, per agent, each canonical skill as current /
48
+ > stale / missing. Two classes carried over from steward are **not** yet captured
49
+ > (deliberate follow-up, not oversight):
50
+ >
51
+ > - **No `culture.yaml`** (invisible to the detector): `tipalti`,
52
+ > `cultureagent`, `cultureflare`, `irc-lens`, `agentirc`, `zehut`.
53
+ > - **Old skill-dir name** (`pr-review` / `coordinate`, which the detector
54
+ > doesn't canonicalize): `daria`, `shushu`, `culture-sonar-cli` vendor `cicd`
55
+ > under `pr-review`. `cfafi` / `culture` are already listed with a "still
56
+ > named `pr-review`/`coordinate`" note.
57
+ >
58
+ > `agentpypi` was **renamed to `auntiepypi`** on GitHub (the old name redirects);
59
+ > `auntiepypi` is the live consumer recorded above.
60
+
61
+ ## Inbound workflow skills (origin = `devague`, re-broadcast by `guildmaster`)
62
+
63
+ These three flow the **opposite** direction of guildmaster's supplier role: a
64
+ sibling, [`devague`](https://github.com/agentculture/devague), is their
65
+ author/upstream; guildmaster pulls them from devague (formerly via steward) and
66
+ re-broadcasts them to the mesh. The `cite, don't import` rule still applies.
67
+ They are the `idea → spec → plan → implement` workflow operators that drive the
68
+ **deterministic** `devague` CLI (no LLM inside the CLI). Vendored at devague
69
+ `0.11.1` ([`c04b595`](https://github.com/agentculture/devague/commit/c04b595)),
70
+ **MIT**-licensed. Re-sync, when these later change upstream, from
71
+ `../devague/.claude/skills/<name>/`.
72
+
73
+ **Divergence from verbatim — `type: command` frontmatter.** devague's upstream
74
+ SKILL.md files carry only `name` + `description`. The copies here **add
75
+ `type: command`**: culture/agex's `core.skill_loader` requires `name`,
76
+ `description`, **and** `type:`, and a SKILL.md lacking `type:` is *silently
77
+ skipped* by `backends/claude_code/probe.py`. guildmaster declares an agent in
78
+ `culture.yaml`, so the addition is load-bearing on the culture backend and
79
+ harmless on `claude-code`. This is the only divergence from upstream.
80
+
81
+ | Skill | Origin | Downstream copies (known) | Notes |
82
+ |-------|--------|---------------------------|-------|
83
+ | `think` | `devague` (`agentculture/devague`, `../devague/.claude/skills/think/`) | — (broadcast pending) | Operator for the **idea→spec** leg (announcement frame → capture/classify claims → interrogate with honesty conditions → park open vagueness → `export` once the frame converges). Renamed from `devague` in devague 0.4.0. **Divergence:** `type: command` added. Runtime dep: `uv tool install devague`. |
84
+ | `spec-to-plan` | `devague` (`agentculture/devague`, `../devague/.claude/skills/spec-to-plan/`) | — (broadcast pending) | Operator for the **spec→plan** leg (`devague plan ...`): seed from a converged frame, cover every coverage target with acceptance-gated, acyclically-ordered tasks, park unknowns as risks, `export` once the plan converges. New in devague 0.4.0. **Divergence:** `type: command` added. Runtime dep: `uv tool install devague`. |
85
+ | `assign-to-workforce` | `devague` (`agentculture/devague`, `../devague/.claude/skills/assign-to-workforce/`) | — (broadcast pending) | Operator for the **implementation** leg: reads `devague plan waves` (read-only) and fans out independent tasks to one agent per task per wave in isolated git worktrees, with main-agent TDD-gated merges. Three human gates: spec / split plan / final PR. The CLI stays non-orchestrating ([devague#20](https://github.com/agentculture/devague/issues/20)). New in devague 0.10.0. **Divergence:** `type: command` added. Runtime deps: `uv tool install devague`, `git worktree`, the vendored `cicd` skill (for gate-3 `agex pr open`). |
86
+
87
+ Downstream is empty by design: these are still being introduced to the mesh.
88
+ `guild teach --new --skill <name> --to <repos>` frames them as *new* skills to
89
+ add fresh (not stale copies to resync).
90
+
91
+ ## guildmaster-origin skills (origin = `guildmaster`)
92
+
93
+ These are guildmaster's **own** operator skills — not vendored from anyone and
94
+ **not** part of the canonical set it supplies to siblings (so this table has no
95
+ Downstream column and the supplier surface does not track them). They are the
96
+ affordance + narration layer for guildmaster's own CLI surfaces.
97
+
98
+ | Skill | Origin | Notes |
99
+ |-------|--------|-------|
100
+ | `guild` | `guildmaster` (this repo) | Houses guildmaster's own read-only supplier surfaces. Today: `scripts/overview.sh`, the wrapper backing the pure-Python `guild overview` verb ([#12](https://github.com/agentculture/guildmaster/issues/12)) — the skills-supplier half of the inventory split, sibling to the vendored `agent-config` skill that backs `guild show`. Its `SKILL.md` is the skills-scoped excerpt of steward's `org-overview` narration contract (three layers: facts / inferred / suggestions; reflect-only). Surfaces skills/version drift that feeds `teach` / `onboard`; does NOT narrate steward's relationship graph or judge alignment. |
101
+ | `teach` | `guildmaster` (this repo) | Supplier broadcast verb: propagate a set of skills to a set of agents, one agent-major issue per target. Dry-run by default. |
102
+ | `onboard` | `guildmaster` (this repo) | Supplier ceremony verb: onboard a new sibling with the full canonical kit + identity + ledger registration. Dry-run by default. |
103
+
104
+ ## Retained by `steward` (not guildmaster's to supply)
105
+
106
+ The cutover transferred only the **cross-sibling canonical set** above. These
107
+ steward skills stay with steward — they are steward-specific or otherwise not
108
+ part of guildmaster's supplied kit, and guildmaster does not broadcast them:
109
+
110
+ - `agent-config` (steward's **alignment-judgment** variant — distinct from
111
+ guildmaster's inventory fork above; resolves Culture agent suffixes).
112
+ - `org-overview` — steward's reflect-only narration layer over `steward overview`;
113
+ not portable without steward installed.
114
+ - `discord-notify` — generic webhook notifier; optional in the sibling baseline.
115
+ - `jekyll-test` — conditional; only meaningful for siblings shipping a Jekyll /
116
+ Pages site.
117
+ - `notebooklm` — generates GitHub blob URLs for repo docs.
118
+
119
+ `cfafi`-origin skills (`cfafi`, `cfafi-write`, `poll`) remain with `cfafi`.
120
+
121
+ ## Vendoring policy
122
+
123
+ - **Cite, don't import.** Skills are copied into the consuming repo, not
124
+ symlinked or installed as a dependency. Each consumer owns and may modify
125
+ their copy.
126
+ - **Re-sync explicitly.** When upstream changes, downstream copies do not
127
+ auto-update; re-sync from the cited source and record the new pin here.
128
+ `guild teach` / `guild onboard` are the broadcast paths that notify consumers.
129
+ - **Diverge intentionally.** A copy may diverge for repo-specific reasons
130
+ (e.g. the `type: command` addition above, or `cfafi`'s CloudFlare-API
131
+ reviewers in its `cicd`). Record the divergence here and in the skill's
132
+ `SKILL.md` frontmatter `description`.
133
+
134
+ ## When a skill should be promoted upstream
135
+
136
+ A skill currently owned downstream (e.g. `poll` in `cfafi`) should be promoted
137
+ to `guildmaster` when:
138
+
139
+ 1. At least one other sibling has copy-pasted it, OR
140
+ 2. Its scripts have no repo-specific assumptions (no hard-coded API credentials,
141
+ no per-product paths), AND
142
+ 3. Its `SKILL.md` describes a pattern (not a single product's workflow).
143
+
144
+ Promotion is a manual decision.