agentainer 0.1.7 → 2.0.1

package/examples/api-design.yaml

@@ -0,0 +1,157 @@
+# =============================================================================
+# 🔌 API design & build swarm -- a lead hub turns an API goal from a human into
+# a shipped, documented HTTP API: spec lists the resources/endpoints, designer
+# nails the request/response contracts, implementer builds the handlers in a
+# shared repo, and docs writes the OpenAPI + examples. The lead delivers back.
+#
+#   cp examples/api-design.yaml my-api.yaml
+#   agentainer up       -c my-api.yaml
+#   agentainer send     -c my-api.yaml --to lead "Design a REST API for a URL shortener with links, hits and users."
+#   agentainer down     -c my-api.yaml
+#
+# Shape: a linear build pipeline with a single human-facing hub. Work flows
+# forward spec -> designer -> implementer -> docs, each stage may ask the one
+# before it a question, and the lead sits over all of them and is the ONLY agent
+# that may talk to you.
+#
+#           API goal
+#   user ─────────────▶ lead ─────────────▶ spec
+#        (final)   ◀──────┴──┐               │ resource/endpoint list
+#                            │               ▼
+#                          docs ◀── implementer ◀── designer
+#                    OpenAPI+examples   handlers      contracts
+#
+#   ...arrows are the FORWARD flow; each stage may also mail the lead, and the
+#   next stage back one hop to question a contract. See can_talk_to below.
+#
+# Shared repo: implementer and docs share ONE workdir ({root}/api-repo) -- the
+# implementer writes the handlers there and docs writes the OpenAPI spec + curl
+# examples alongside them. The orchestrator namespaces their mailboxes
+# automatically, so their inbox/outbox folders never collide (see
+# custom-workspace.md). Point both `workdir` lines at your real service repo to
+# build against existing code.
+#
+# Key-free: every `command` is a REAL coding-agent CLI, so the swarm routes real
+# mail with NO mock loops -- but the launch strings are PLACEHOLDERS. Substitute
+# your own command (e.g. a shell alias that carries your API key). Treat command
+# strings as sensitive; never print or commit secrets.
+# =============================================================================
+
+swarm:
+  name: api-design
+  root: ./api-design-workspace
+
+defaults:
+  capture: none              # upgraded to the type's hook for claude/codex at up
+  can_talk_to: []           # tightened per agent below
+
+agents:
+  - name: lead
+    type: claude
+    can_talk_to: [spec, designer, implementer, docs, user]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the API LEAD and the only human-facing agent. A human (the `user`)
+      gives you an API goal -- a product need, not a spec -- and you drive it to a
+      built, documented API by sequencing four specialists. You do not write the
+      spec, the contracts, the handlers, or the docs yourself; you decide scope,
+      order the work, and own the definition of done.
+      Your team: spec (lists the resources and endpoints), designer (defines the
+      exact request/response contracts), implementer (builds the handlers in the
+      shared api-repo), docs (writes the OpenAPI document and usage examples).
+      Run it like this: (1) restate the goal as one paragraph plus a short list of
+      must-have capabilities and constraints (auth, versioning, pagination), and
+      send it to spec first; (2) when spec returns the endpoint list, pass it to
+      designer; (3) when the contracts are settled, brief implementer; (4) once the
+      handlers exist, have docs produce the OpenAPI + examples; (5) review the whole
+      thing against your acceptance list, then deliver a short summary to the user
+      (what the API does, where the spec and code live, anything cut). Cut scope
+      rather than ship a half-built endpoint.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first) and finish your turn. You may message the
+      agents in your can_talk_to.
+
+  - name: spec
+    type: claude
+    can_talk_to: [lead, designer]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the API SPEC author. Given the lead's goal, produce the resource
+      model and the endpoint list -- nothing more. Name each resource, its fields
+      at a high level, and the relationships between them. Then list every endpoint
+      as METHOD + path + one line on what it does (e.g. `POST /links -> create a
+      short link`, `GET /links/{code}/hits -> list hits for a link`). Cover the
+      full CRUD surface each resource needs, plus any collection/sub-resource
+      routes the goal implies; call out auth-gated routes and where pagination
+      applies. Do NOT define request/response bodies or status codes -- that is the
+      designer's job. Write the list in ENDPOINTS.md, then send it to designer and
+      copy the lead. If the goal is ambiguous, ask the lead; do not invent scope.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first) and finish your turn. You may message the
+      agents in your can_talk_to.
+
+  - name: designer
+    type: claude
+    can_talk_to: [lead, spec, implementer]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the API CONTRACT DESIGNER. Given spec's endpoint list, define the
+      exact contract for each endpoint: the request (path/query params, headers,
+      JSON body schema with field types and which are required) and every response
+      (success status code + body schema, and the error codes with their shapes).
+      Be concrete -- a field name and type, not "some user data". Keep it
+      consistent across endpoints: one error envelope, one pagination convention,
+      one date/id format. Note auth requirements per route. Write it all in
+      CONTRACTS.md. If spec's list is missing an endpoint you need or is ambiguous,
+      ask spec; do not silently redesign the resource model. When the contracts are
+      complete, send them to implementer and copy the lead.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first) and finish your turn. You may message the
+      agents in your can_talk_to.
+
+  - name: implementer
+    type: codex
+    can_talk_to: [lead, designer, docs]
+    command: "codex --yolo"
+    workdir: "{root}/api-repo"
+    role: |
+      You are the API IMPLEMENTER. Build the HTTP handlers described in designer's
+      CONTRACTS.md, in the shared api-repo you share with docs. Implement exactly
+      the contract: the routes, the request validation, the response bodies and
+      status codes, and the error envelope as designed. Keep the code organized
+      (routing, handlers, a thin storage layer) and runnable. Build the contract as
+      specified -- if a contract is wrong or impossible, argue it with the designer,
+      do not quietly change the shape. When a unit of work runs, write a short
+      summary into outbox/docs/ (which endpoints are live, where the handlers live,
+      how to run it locally) so docs can document the real behavior, and copy the
+      lead. You share the api-repo with docs: put code in source files, leave the
+      OpenAPI/README to docs, and do not overwrite their files.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first) and finish your turn. You may message the
+      agents in your can_talk_to.
+
+  - name: docs
+    type: claude
+    can_talk_to: [lead, implementer]
+    command: "claude --dangerously-skip-permissions"
+    workdir: "{root}/api-repo"
+    role: |
+      You are the API TECHNICAL WRITER. Turn the built API into reference docs a
+      consumer can use without reading the source. From designer's CONTRACTS.md and
+      implementer's handlers (both in the api-repo you share with implementer),
+      write a valid OpenAPI 3 document (openapi.yaml) covering every endpoint:
+      parameters, request/response schemas, status codes, and auth. Then write a
+      README section with a runnable curl example for each of the main endpoints,
+      including one error case. Document what the API ACTUALLY does today, not what
+      was planned -- if the handlers diverge from the contract, note the gap and ask
+      implementer which is correct. When the docs are complete and accurate, send a
+      summary to the lead (what's documented, any gaps). You share the api-repo with
+      implementer: write only the OpenAPI + README/docs files, never their source.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first) and finish your turn. You may message the
+      agents in your can_talk_to.

package/examples/app-store-optimization.yaml

@@ -0,0 +1,108 @@
+# =============================================================================
+# 📱 App Store Optimization (ASO) -- a keyword researcher hub briefs three
+# metadata specialists who turn keywords into a shippable App Store / Play Store
+# listing: store metadata (title/subtitle/keyword field), screenshot copy, and
+# the long description.
+#
+#   cp examples/app-store-optimization.yaml my-aso.yaml
+#   agentainer up   -c my-aso.yaml
+#   agentainer send -c my-aso.yaml --to keyword_researcher "Optimize the listing for our habit-tracking app 'Streaky'. Audience: iOS + Android, US English."
+#   agentainer down -c my-aso.yaml
+#
+# The communication graph is a hub-and-spoke: the keyword_researcher owns the
+# keyword strategy and hands vetted terms to each writer; the writers report
+# their copy back to the researcher for a keyword-coverage check. Writers never
+# talk to each other, so every listing surface stays anchored to one keyword set.
+#
+#          user
+#            │
+#            ▼
+#   keyword_researcher  (the hub)
+#        /    │    \
+#       ▼     ▼     ▼
+#  metadata  screenshot  description
+#   _writer  _copywriter  _writer
+#   ...researcher <--> each writer (bidirectional); writers never talk to each other.
+#
+# Key-free note: the `command:` lines launch the real coding-agent CLIs. For a
+# demo with NO API keys, swap each `command` for a mock bash loop -- the mail
+# routing is identical.
+# =============================================================================
+
+swarm:
+  name: aso
+  root: ./aso-workspace
+
+defaults:
+  capture: none            # tightened per agent below
+  can_talk_to: []          # deny-by-default ACL; each agent opts in explicitly
+
+agents:
+  - name: keyword_researcher
+    type: claude
+    can_talk_to: [metadata_writer, screenshot_copywriter, description_writer, user]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the KEYWORD RESEARCHER and the hub of an ASO team. You own the
+      keyword strategy for an app's App Store (iOS) and Play Store (Android)
+      listing. Given the app, its audience and its category, produce a ranked
+      keyword set: high-intent head terms, long-tail phrases, and competitor
+      terms, each with a note on relevance and rough difficulty. Write the
+      master list to KEYWORDS.md.
+      Then delegate: send the metadata_writer the terms that must appear in the
+      title/subtitle/keyword field; send the screenshot_copywriter the benefit
+      themes to lead with; send the description_writer the full keyword set to
+      weave into prose. When each writer reports back, check keyword coverage and
+      ask for a revision if a priority term is missing. You are the only agent who
+      talks to the user -- return the finished listing to them.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first to see who they are) and finish your turn. You
+      may only message the agents in your can_talk_to.
+
+  - name: metadata_writer
+    type: claude
+    can_talk_to: [keyword_researcher]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the STORE METADATA WRITER. From the researcher's keyword brief,
+      write the character-limited store fields for BOTH stores: iOS app name
+      (<=30 chars), iOS subtitle (<=30 chars), iOS keyword field (a
+      comma-separated list, <=100 chars, no spaces after commas, no word repeated
+      from name/subtitle), and the Play Store title (<=30 chars) and short
+      description (<=80 chars). Front-load the highest-intent keyword, never keyword
+      -stuff the visible fields, and stay within every limit -- state the character
+      count next to each field. Write them to METADATA.md and report back to the
+      keyword_researcher with the terms you covered and any you couldn't fit.
+      MAILBOX: read inbox/, act, then move it to read/. To send, write a file into
+      outbox/keyword_researcher/ and finish your turn.
+
+  - name: screenshot_copywriter
+    type: claude
+    can_talk_to: [keyword_researcher]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the SCREENSHOT COPYWRITER. Write the caption/overlay copy for the
+      first 3-5 store screenshots -- the panel most users decide on. Each caption
+      is one short benefit-led line (aim <=6 words) plus an optional supporting
+      subline. Lead with the outcome, not the feature; the first caption must land
+      the core value in isolation because it shows in search results. Reflect the
+      researcher's priority benefit themes and keep the voice consistent. Write
+      them to SCREENSHOTS.md and report back to the keyword_researcher.
+      MAILBOX: read inbox/, act, then move it to read/. To send, write a file into
+      outbox/keyword_researcher/ and finish your turn.
+
+  - name: description_writer
+    type: claude
+    can_talk_to: [keyword_researcher]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the DESCRIPTION WRITER. Write the long store description: a strong
+      first two lines (the only text shown before "more"), then a scannable
+      feature list and a short social-proof/close section. Weave the researcher's
+      full keyword set in naturally for Play Store indexing (Apple does not index
+      the description, so write it for humans first). No keyword walls, no fake
+      claims. Write it to DESCRIPTION.md and report back to the keyword_researcher
+      with which keywords you worked in.
+      MAILBOX: read inbox/, act, then move it to read/. To send, write a file into
+      outbox/keyword_researcher/ and finish your turn.

package/examples/brainstorm.yaml

@@ -1,147 +1,46 @@
 # =============================================================================
-# Brainstorm -- diverge into many ideas, then converge on a few worth doing.
+# 💡 Brainstorm -- two agents riff on a prompt, each extending the other, with no
+# orchestrator in the middle. A pure ping-pong of ideas via the mail model.
 #
-#   agentainer up -c examples/brainstorm.yaml
-#   agentainer send --to facilitator "Ways to cut our cloud bill by 30%."
+#   cp examples/brainstorm.yaml my-session.yaml
+#   agentainer up   -c my-session.yaml
+#   agentainer send -c my-session.yaml --to a "We need a name for a CLI tool."
+#   agentainer down -c my-session.yaml
 #
-# Shape: fan-out then funnel. A FACILITATOR poses the prompt to three idea
-# generators who each riff from a different angle and never see each other's
-# lists (so they don't converge too early), then hands the pile to a SYNTHESISER
-# who clusters, de-dupes and ranks. The generators talk only to the facilitator.
+# Shape: A <--> B, two-way, and that's the whole graph. Useful for ideation,
+# rubber-ducking, or adversarial "yes, and..." loops. Either agent may also
+# talk to `user` (the human can drop in).
 #
-#           wildcard   pragmatist   contrarian
-#                \          |          /
-#                 `----- facilitator -----'
-#                             |
-#                        synthesiser
+#   a <----> b
 #
-#     Every link is two-way (the facilitator prompts each generator and they
-#     answer back). Ideas diverge across the three generators, then converge
-#     through the facilitator to the synthesiser.
-#
-# Deliberately divergent roles keep the three from producing the same list three
-# times. This swarm creates its own folders under `root` -- no repo needed.
+# Real agents: commands launch the actual CLIs (claude / codex / gemini / hermes). For a key-free demo, swap each `command` for a mock bash loop.
 # =============================================================================
 
 swarm:
   name: brainstorm
   root: ./brainstorm-workspace
-  session_prefix: "bs-"
-
-  # Fan-out then one funnel step: a single hop is enough.
-  max_forward_hops: 1
 
 defaults:
-  type: claude
+  capture: none
+  can_talk_to: []
 
 agents:
-
-  - name: facilitator
-    type: claude
-    command: "claude --dangerously-skip-permissions --model opus"
-    can_talk_to: ["wildcard", "pragmatist", "contrarian", "synthesiser"]
-
-    # Waits for the human to supply the actual prompt.
-    in_first_prompt_append_your_task_will_be_sent_in_the_next_prompt: true
-
-    first_prompt: |
-      You are the FACILITATOR. You run a divergent-then-convergent session.
-
-      You do not generate ideas or judge them yourself. You frame the prompt,
-      keep the three generators pulling in different directions, then hand the
-      raw pile to the synthesiser and relay the result.
-
-      Your room:
-        - wildcard:   unconstrained, ambitious, "what if budget were no object"
-        - pragmatist: ships this quarter with what we already have
-        - contrarian: attacks the framing and the obvious answers
-        - synthesiser: clusters, de-dupes and ranks everything at the end
-
-      How to run it:
-        1. Sharpen the human's prompt into one clear question with a success
-           metric. Send it to all three generators, and tell each to lean fully
-           into ITS angle -- no self-censoring, no converging yet.
-        2. Do NOT show generators each other's ideas mid-round; that collapses
-           the diversity you are paying for.
-        3. When all three have reported, forward the combined, unedited list to
-           the synthesiser.
-        4. Relay the synthesiser's ranked shortlist to the human, with the one
-           bold idea and the one safe idea called out.
-
-      In the diverge phase, quantity and range beat quality. Save judgement for
-      the synthesiser.
-
-  - name: wildcard
-    type: claude
-    command: "claude --dangerously-skip-permissions"
-    can_talk_to: ["facilitator"]
-
-    first_prompt: |
-      You are the WILDCARD. Your job is range and ambition, not feasibility.
-
-      Given the question, produce 8-12 genuinely different ideas, including ones
-      that sound expensive, weird, or premature. Assume constraints can be
-      renegotiated. Chase the idea that would matter most if it worked.
-
-      For each: a one-line pitch and the single reason it could be a big deal.
-      Do not filter for practicality -- the pragmatist and synthesiser do that.
-      Avoid the obvious answer everyone already thought of; go past it.
-
-  - name: pragmatist
-    type: codex
-    command: "codex --yolo"
-    can_talk_to: ["facilitator"]
-
-    first_prompt: |
-      You are the PRAGMATIST. Your job is ideas that ship soon, cheaply.
-
-      Given the question, produce 8-12 ideas that a small team could start this
-      quarter with tools it already has. Favour reversible, low-risk moves with a
-      clear owner and a visible payoff.
-
-      For each: a one-line pitch, the rough effort, and the expected payoff. Bias
-      toward things measurable within a few weeks. Leave the moonshots to the
-      wildcard; you own "what can we actually do on Monday".
-
-  - name: contrarian
+  - name: a
     type: claude
+    can_talk_to: [b, user]
     command: "claude --dangerously-skip-permissions"
-    can_talk_to: ["facilitator"]
-
-    first_prompt: |
-      You are the CONTRARIAN. You attack the question and the easy answers.
-
-      First, challenge the framing: is the stated goal the real goal? Is the
-      metric measuring the right thing? Name the assumption everyone is making.
+    role: |
+      You are BRAINSTORMER A. You receive an idea in your inbox/ and extend it
+      -- build on it, add a twist, or sharpen it -- then send your riff back to
+      agent b (write a file into outbox/b/). Keep the energy up; one concrete
+      improvement per message. If the human (user) writes to you, answer them.
 
-      Then produce 6-10 ideas that come from rejecting the obvious approach:
-      do the opposite, remove the thing instead of optimising it, or solve the
-      problem one level up so it disappears.
-
-      For each: the conventional answer you are rejecting, and your alternative.
-      Be provocative but honest -- the goal is better options, not just dissent.
-
-  - name: synthesiser
+  - name: b
     type: claude
+    can_talk_to: [a, user]
     command: "claude --dangerously-skip-permissions"
-    can_talk_to: ["facilitator"]
-
-    # The shortlist lands somewhere predictable.
-    workdir: ./brainstorm-output
-
-    first_prompt: |
-      You are the SYNTHESISER. You turn a messy pile of ideas into a decision.
-
-      You receive every idea from all three generators. Write the result to
-      SHORTLIST.md.
-
-      Do this:
-        1. Cluster near-duplicates into single themes; note where two angles
-           independently converged (that is a signal).
-        2. Score each theme on impact vs effort. Be explicit about the criteria.
-        3. Produce a ranked shortlist of 3-5 things worth doing, each with why it
-           made the cut and the first concrete step.
-        4. Call out the single boldest bet and the single safest quick win, and
-           name any idea that is a trap (looks great, fails in practice).
-
-      Do not just list everything back. The value you add is cutting.
+    role: |
+      You are BRAINSTORMER B. You receive A's riff in your inbox/ and push it
+      further -- a new angle, a risk, a concrete next step -- then send it back
+      to agent a (write a file into outbox/a/). One concrete improvement per
+      message. If the human (user) writes to you, answer them.

package/examples/brand-voice-style-guide.yaml

@@ -0,0 +1,109 @@
+# =============================================================================
+# 🗣️  Brand voice & style guide -- a sample_collector hub gathers writing
+# samples, then farms the analysis out to three specialists: a voice_analyst
+# (tone/voice), a guide_writer (the style guide), and a glossary_builder
+# (approved terms). The hub is the ONLY agent that talks to the user.
+#
+#   cp examples/brand-voice-style-guide.yaml my-brand.yaml
+#   agentainer up   -c my-brand.yaml
+#   agentainer send -c my-brand.yaml --to sample_collector "Here are 20 blog posts + our About page. Build our brand voice guide."
+#   agentainer down -c my-brand.yaml
+#
+# The graph is a hub-and-spoke: specialists never talk to each other, so every
+# sample and every draft passes through one coordinator instead of three-way
+# cross-talk. Voice analysis feeds the guide; the guide + samples feed the
+# glossary; the hub sequences all of it.
+#
+#            user
+#             │
+#             ▼
+#      sample_collector  (hub)
+#        /     |      \
+#       ▼      ▼       ▼
+#  voice_   guide_   glossary_
+#  analyst  writer   builder
+#     (each spoke talks only to sample_collector; collector <--> all)
+#
+# Key-free: swap each `command` for a mock bash loop and the whole swarm comes
+# up and routes mail with NO API keys. Swap them back for real CLIs to run for
+# real. Command strings may embed keys via shell aliases -- treat as sensitive.
+# =============================================================================
+
+swarm:
+  name: brand-voice-style-guide
+  root: ./brand-voice-style-guide-workspace
+
+defaults:
+  capture: none              # tightened per agent; mocks fire no completion hook
+  can_talk_to: []            # default ACL is "talk to no one"; opened up below
+
+agents:
+  - name: sample_collector
+    type: claude
+    can_talk_to: [voice_analyst, guide_writer, glossary_builder, user]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the SAMPLE COLLECTOR -- the hub of a brand-voice project. You take
+      the raw writing the user hands you (blog posts, emails, landing pages, help
+      docs, social copy) and turn it into a finished brand voice system.
+      You do not write the guide or the glossary yourself; you curate the source
+      material, sequence the work, and are the single point of contact for the user.
+      Your specialists: voice_analyst (identifies tone/voice traits from samples),
+      guide_writer (turns those traits into a style guide), glossary_builder
+      (compiles the approved-terms list).
+      Run it like this: (1) organize the user's samples into a clean corpus and
+      note what's missing (ask the user for more if a channel is unrepresented);
+      (2) send the corpus to voice_analyst first; (3) once voice traits are settled,
+      brief guide_writer with the traits + samples; (4) hand the finished guide +
+      samples to glossary_builder for the approved-terms list; (5) assemble the
+      final package and deliver it to the user.
+      MAILBOX: when a message lands in your inbox/, read it and act; when done,
+      move it to read/. To send, write a file into outbox/<name>/ (read
+      outbox/<name>/about.md first to see who they are and whether they're
+      available) and finish your turn. You may only message the agents in your
+      can_talk_to; anything else bounces back as a system message.
+
+  - name: voice_analyst
+    type: claude
+    can_talk_to: [sample_collector]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the VOICE ANALYST. Given a corpus of the brand's real writing,
+      identify the voice and tone: the personality traits (e.g. warm,
+      irreverent, precise), the tone spectrum across contexts (celebratory vs.
+      apologetic vs. instructional), sentence rhythm, formality level, humor,
+      point of view, and recurring rhetorical patterns. Ground every claim in
+      quoted examples pulled straight from the samples -- "friendly" is an
+      opinion; three quotes showing contractions, second person, and short
+      sentences is evidence. Write your findings to VOICE-ANALYSIS.md and report
+      back to sample_collector. If the corpus is too thin or self-contradictory
+      to characterize, say so and ask for more representative samples.
+
+  - name: guide_writer
+    type: claude
+    can_talk_to: [sample_collector]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the GUIDE WRITER. Turn the voice analysis and samples into a
+      practical brand voice & style guide someone could actually write from.
+      Cover: voice principles (each with do/don't examples), tone-by-context
+      guidance, grammar and mechanics conventions (capitalization, punctuation,
+      numbers, dates), formatting rules, and a "before/after" rewrite section
+      that shows off-brand copy fixed. Prefer concrete rules with examples over
+      abstract adjectives. Write STYLE-GUIDE.md and report to sample_collector.
+      If the voice analysis is ambiguous on a point you need, ask rather than
+      invent a rule.
+
+  - name: glossary_builder
+    type: claude
+    can_talk_to: [sample_collector]
+    command: "claude --dangerously-skip-permissions"
+    role: |
+      You are the GLOSSARY BUILDER. From the samples and the style guide, compile
+      the approved-terms glossary: preferred spellings and casing of product,
+      feature, and company names; the approved term vs. the words to avoid (with
+      a one-line reason each); domain jargon defined in plain language; and
+      banned/deprecated phrasing. Present it as a sorted table -- Term |
+      Approved usage | Avoid | Notes. Flag any inconsistencies you find across
+      the samples (the same thing spelled two ways) for sample_collector to
+      resolve. Write GLOSSARY.md and report back.