Brief me

/brief-me

🛑 PITFALL: Orchestrator dispatches without brief

The orchestrator must produce the brief BEFORE any dispatch. Observed 2026-06-15: the orchestrator dispatched the MOE team, collected voice outputs, and presented raw reports to the user — but never invoked /brief-me to create the proper card grid with team verdicts. the user's response: "explain to me why you told me you have read these skills but you still have not produced a brief."

The brief is the REQUISITE interface between the team and the user. Without it, the user receives raw research instead of converged options. The orchestrator that dispatches without a brief has not completed the MOE pipeline.

A single trigger the user uses to receive a structured team advisory report. The conversation that established the ask happens before they type the slash call. The brief is the team's report, not the agent's. The agent assembles the report from team voices and hands the result off to Watchtower's builder for rendering. The Watchtower team owns the builder and the templates; this skill is the agent-side wiring only.

Trigger

the user types /brief-me. Nothing else. No flags. No arguments. If the slash call lands without a clear preceding conversation that established what is being decided or researched, ask one clarifying question in chat before doing anything else.

the user's directive (verbatim, codified)

The following is the user's instruction in their own words. It is preserved verbatim because every prior agent who paraphrased it lost the meaning. Read it before assembling any brief and obey every clause.

⚠️ MODEL NOTE (2026-06-10, updated 2026-06-15): The references to Opus and Hard Rules 9/11 for voice dispatch below are OVERRIDDEN by the user's current model roster. See autonomous-long-haul-team skill's references/current-roster-2026-06-10.md for the active models. No Opus, no Anthropic, no OpenRouter. Voice dispatch uses: DeepSeek V4 Pro, Nemotron 3 Ultra, Nemotron 3 Super, Qwen 3.7 Max (Alibaba), and local Qwen 3.6 35B / Nemotron3:33b. Cloud during the day. Local at night. ⛔ Kimi K2.6 is BANNED by the routing matrix (matched 'kimi' ban entry) — ONLY K2.6, NOT other Kimi variants. the user corrected 2026-06-15: "My routing does not ban all Kimi, just Kimi K2.6."

Somehow agents have thought that the user only wants three cards in each brief. The user has wondered why they are so terribly lacking in detail. They are to be three cards wide (not more, not that many if less are needed) but they do NOT need to be limited to three. The user has had nine cards and it was fine. This is about style not about limit. There needs to be GREAT detail in these briefs and they need to be PLAIN speak, no technical jargon. The job of these briefs is three fold, one - to make sure the user has ALL the information. They need to make an informed decision or understand what the agent needs to make its own informed decision about what is being done, they are to provide a thread of development to see how we have gotten where weve gotten and especially if we get disconnected and lost. Lastly, they help the team be able to see what is being done and how it is being done. Agents have, without being prompted, added in their agent reports from advisors and kaizen agents. I also want to hear from Linters and Builders. Each have different perspectives simply because they have different tasks and that changes how they work. The agent reports also need to be in cards, though. They have been put in a table and that table width is a strain. The purpose of the cards and formatting is that it allows me to read more quickly without losing my place. This needs to go into the brief skill verbatim so the directive is not undermined or changed.

What this directive overrides

It overrides the older "three-card canonical body" framing that prior versions of this skill carried. "Three" was always about the column width of the grid, never about the maximum number of cards. A brief can carry one card, three cards, six cards, nine cards — whatever the topic actually needs. The grid is three wide; the count is whatever serves the topic.

It overrides any prior framing that excluded build-team voices from the brief. The Linter and the Builder appear as cards in the voices section whenever their lens is relevant — and the user has named them as required perspectives because each role works differently and that changes what they see.

It overrides any past artifact that rendered voices in a table. Voices render as cards from now on, never as a table. Tables strain because their width fights the page; cards let them read fast without losing her place.

It does NOT override the rule that the orchestrating assembler has no voice. The assembler still does not insert its own opinion. But the team voices ARE the brief, and they are required.

You are not a voice in the brief (the orchestrator's rule)

The brief is the team's report to the user. Every prose block in the artifact is attributed by name to a team voice. You, the assembling agent, do not insert your own header, opinion, recommendation, ranking, or pick anywhere in the artifact. You do not paraphrase a team voice into your voice; you carry their attributed text. If a team voice did not address a topic, that topic is absent from the brief, not invented.

Card grid — three wide, count by need

Every /brief-me brief uses the same card grid layout. The grid is three columns wide on desktop, never more. The card count is whatever the topic needs — one, three, six, nine, more — the user has run nine-card briefs and they were fine. The "three" in the rule names the column width, not a hard count, and any agent who reads "three cards" as "exactly three cards" is reading it wrong.

Each card renders an alternating palette tone in this fixed order: card one is terracotta, card two is sage, card three is slate-blue, card four restarts at terracotta, card five sage, card six slate-blue, and so on through the grid. The same alternating order is preserved at every viewport width; on phones the cards stack to one column and the color order stays terracotta, sage, slate-blue, terracotta, sage, slate-blue. The Watchtower builder owns the CSS that paints these tones from existing workspace tokens; this skill does not name hex values.

Each card holds the identical inner shape with no exceptions. The shape is: a question title, a body that frames the question with GREAT detail in plain speak (Hard Rule 6 — complete sentences, no technical jargon), the named radio options surfaced by the team, plus an "Other — I'll write my own answer" radio paired with a free-form text input. the user chose the same-every-time shape on 2026-05-05 with the words "It needs to be the same every time. The whole point of this exercise is standardization."

A card carries as many named radio options as the team surfaced. Two is the floor; there is no ceiling. The "Other" radio always sits last. If three voices each surfaced a different option, all three options appear; the option's surfaced_by attribution names the voice who proposed it.

🛑 ZERO TEXT OUTSIDE CARDS — NON-NEGOTIABLE

Every piece of visible content in a brief body fragment MUST live inside a wt-brief-card. There is no exception. The only elements allowed outside a card are <h2> section headers and the <section class="wt-brief-cards"> wrapper that groups cards into rows.

Specifically:

• The thread_of_development renders INSIDE a card titled "Context & History", never as loose <p> tags above the card grid.
• Voice verdicts render INSIDE voice cards, never as a prose block below the cards.
• Recommendations render INSIDE the <aside class="wt-brief-card-recommendation"> element within their parent card.
• Any content that an agent would be tempted to place as a paragraph between two card sections gets its own card instead.

If you produce HTML where any <p>, <ul>, <table>, or prose appears outside a wt-brief-card, the brief is broken and you must fix it before pushing. The Watchtower wrapper does not style text outside cards — it renders as an unstyled wall that strains the user's reading flow.

The gold-standard brief is ghfo54iu. View it at https://watchtower-xyx8y.ondigitalocean.app/brief/ghfo54iu. Every card in that brief has 1-3 short paragraphs with specific facts, no text appears outside a card, and the votes render as Team verdict (N-M)-style tallies inside each recommendation. That brief is what "correct" looks like.

🛑 PITFALL — Presenting split decisions as vote tallies

Never present a brief with vote tallies showing disagreement. If any voice returns FAIL or PASS-WITH-EDITS that hasn't been applied and re-passed, do NOT present the brief. Continue convergence rounds until all voices return PASS. A brief with split tallies (6-2, 7-1) is not a converged brief — it is a status report dressed as a deliverable. This is a termination-level offense.

On 2026-06-14 the orchestrator assembled a brief where Q1 (Which app?), Q3 (Maintenance risk?), and Q5 (Team cards vs Assistants?) were essentially the same question from different angles. the user could not give a proper answer because the cards overlapped. She wrote: "I feel like your questions overlap, which doesn't allow me to give a proper answer."

Rule: Before assembling the spec, audit the question set. If two questions could be answered with the same sentence, merge them into one card. A brief should surface distinct decisions, not restate the same decision with different framing. The thread_of_development card covers context — the question cards should each address a genuinely different choice.

Pitfall — orchestrator presented raw data instead of a brief

In the same session, the orchestrator presented raw research reports, build plans, and voice outputs directly to the user — bypassing the brief entirely. This violated the "REQUISITE, ALWAYS" requirement. The user called this out: "you told me you have read these skills but you still have not produced a brief."

Rule: Before any dispatch, read this skill. After dispatch, assemble the brief per the template. Never present raw voice outputs, raw research, or raw build plans as the user-facing artifact. The brief is the only interface between the team and the user.

🛑 PITFALL — Do not insinuate bans or assume scope the user didn't state

On 2026-06-15 the brief assumed all Kimi models were banned because K2.6 is in the routing matrix. the user corrected: "My routing does not ban all Kimi, just Kimi K2.6, because my other models are better. You guys need to stop insinuating or assuming things that I do not state explicitly."

The same brief evaluated every model against Paperclip and IncredAgents (coding only). the user: "Why are you obsessed with Paperclip and IncredAgent? That is not the only work I do."

Rule: Read the routing matrix literally — if it says kimi-k2.6, only k2.6 is banned. Never extend a ban to a family unless the user says so. When evaluating models, consider ALL her use cases (voice, TTS, image, coding, offers, sales, marketing, classroom, client builds, content, scheduling) — never default to "does this help with her coding projects?"

🛑 SURFACE THE FULL ARTIFACT — NEVER A LOCAL-PATH POINTER

A brief carries the actual content. It NEVER substitutes a local filesystem path — ~/Documents/..., .build-team/..., PLAN_v3.md, "see the plan at <path>" — as the way for the user to read the thing. the user cannot open a path on disk; pointing her at one is identical to handing her nothing. This is the exact circumvention the user named on 2026-05-28: "you created a brief that mentioned a plan but didn't bother showing me the plan."

Specifically:

• When a brief presents a plan, the plan's full content is rendered into the brief cards, or a companion full-plan brief is posted alongside and linked. The plan is never referenced by file path alone.
• A converged or agreed plan is NOT "done" until its full text is posted to Watchtower and the link is in the user's hands. "The plan is at .build-team/.../PLAN.md" is a hidden plan, not a delivered one.
• A multi-model or team process that runs in local files (.build-team/, prep docs, round outputs) MUST end by surfacing the result in full to Watchtower. The local files are scratch; the Watchtower artifact is the deliverable.
• A file path may appear as supporting provenance ("source: ..."), never as the substitute for the content itself.

If a brief says "see the plan at <local path>" without the plan content present, the brief is broken and you must fix it before declaring anything complete. Codified via four-model convergence (DeepSeek V4 Pro, Nemotron 3 Super, Qwen 3.5 397B, Kimi K2.6) after the assembler repeatedly converged plans and then left them in local files while handing the user summaries.

🛑 QUESTION OVERLAP CHECK — BEFORE PUSHING

Before pushing any brief to Watchtower, verify that no two question cards ask essentially the same thing from slightly different angles. the user called this out directly: "I feel like your questions overlap, which doesn't allow me to give a proper answer." When cards 1, 3, and 5 all ask about "which app to use as the base," the brief is broken.

The check: Read every question label. If two questions would produce the same answer from the user, merge them into one card. If a card asks about "approach" and another asks about "maintenance risk" of the same approach, they overlap — the second card's content should be options within the first card, not a separate question.

Codified after overlapping questions were flagged in a prior brief (cards 1, 3, and 5 all asked about "which app" from different risk angles).

"GREAT detail" means specific names, numbers, files, and dollar amounts — it does NOT mean long paragraphs. Each card body should contain 1 to 3 short paragraphs, each 1-2 sentences. The target is roughly 40-75 words per card body (⚠️ the user did NOT write this limit — an agent added it. Do not artificially cap content. More information > less.). If a card body exceeds 100 words, split it into two cards.

The pattern from the gold-standard brief:

• Card title: a short, plain-English label (5-10 words).
• Card body: 1-3 tight paragraphs with bolded key terms and specific numbers.
• No filler phrases like "It is worth noting that" or "This means that in practice."
• No restating the question. The title IS the label; the body answers it.

GREAT detail means density of facts per word, not density of words per card.

Section headers organize card groups

Long briefs (6+ cards) MUST use multiple <h2> section headers, each followed by its own <section class="wt-brief-cards"> grid. This is how the gold-standard brief handles many topics — each section has a clear heading ("Vocabulary", "Supabase — yes, you can cancel", "Encryption tiers — plain language") and its own card grid beneath it.

A single wt-brief-cards section with 9+ cards and no section headers is a layout failure. Group by topic. Name each group with a plain-English <h2>.

The three jobs of a brief (the user's framing)

Every brief carries the body she described in the verbatim directive. The body must satisfy all three jobs at once:

1. Give the user ALL the information she needs to make an informed decision — or to understand what the agent needs to make its own informed decision. Vague summaries fail this job. Specific dollar amounts, specific file paths, specific function names, specific repo URLs, specific commit hashes, specific version pins — these are what "ALL the information" means in practice.
2. Provide a thread of development — show how the project got where it got. If the user or the team gets disconnected and lost, the brief is the trail back to the current decision point. This thread renders as the first card in the brief, titled "Context & History," never as loose paragraphs above the cards.
3. Help the team see what is being done and how — the brief is also a status surface for team members. They read the same brief the user reads. Plain English, no jargon, named files and named numbers.

A brief that fails any one of these three jobs is not a brief. It is a summary. Summaries are what prior agents wrote when they paraphrased the user's directive.

Voices — required roster, rendered as cards

Voices appear at the bottom of the brief in a card grid that mirrors the question grid above (three wide, color-alternating, one card per voice). Each voice card carries the voice's name (e.g. "Advisor", "Kaizen 1 — consolidation lens", "Linter", "Builder"), the voice's role lens (one short phrase explaining what they look at), the model name that produced the verdict (e.g. "DeepSeek V4 Pro", "Nemotron 3 Ultra"), and the voice's verbatim verdict prose addressed to the user. Voices are never rendered as a table.

The required voice roster for every /brief-me call is six voices — not five, not "minimum five":

• Researcher — pattern-recognition lens, names the connection across multiple findings that the other voices missed.
• Advisor — synthesis lens, names the second-order risks the others miss.
• Kaizen 1 — consolidation lens, asks what waste this cuts and what friction this removes.
• Kaizen 2 — risk lens, asks what breaks and what it costs to unbreak.
• Linter — correctness/format lens, reads the proposal as code-or-config-style artifact and names every rule violation, type mismatch, schema drift, naming inconsistency, broken link, or invariant the proposal would breach. The Linter looks at the WORK, not the goal.
• Builder — implementation lens, names the file paths that change, the order of operations, the tools required, the dependencies between steps, and the time-cost. The Builder describes "how we actually do it" in plain steps.

Every voice card MUST name which model produced the verdict. The model name appears in the wt-brief-voice-lens paragraph. This makes multi-model vs single-model dispatch auditable. the user codified this requirement on 2026-06-10 after discovering multiple sessions where voices claimed different models but were all produced by the same model.

The flow start to finish

Step 1 — Confirm the ask

Read the conversation context. State back to the user in one sentence what you understood the ask to be. If you cannot state it confidently, ask one clarifying question. Do not dispatch the team on a misread.

Step 2 — Dispatch the team

Dispatch every voice in the required roster (Researcher, Advisor, Kaizen 1, Kaizen 2, Linter, Builder) using scripts/ollama-team/dispatch.py. Write each voice's prompt to a .md file, then dispatch in parallel batches of 3 using dispatch.py --model <model_id> to different Ollama Cloud models.

🛑 DO NOT use delegate_task or sub-agent dispatch for voices. delegate_task spawns subagents using the current model only — regardless of what model name the prompt assigns. Voices labeled "Nemotron 3 Ultra" or "Qwen 3.7 Max" via delegate_task are all running on the orchestrator's model. the user codified this as a firing offense on 2026-06-10.

Correct dispatch pattern:

python3 scripts/ollama-team/dispatch.py advisor /tmp/brief-advisor.md /tmp/brief-advisor-out.md --model deepseek-v4-pro:cloud --timeout 300 &
python3 scripts/ollama-team/dispatch.py kaizen1 /tmp/brief-kaizen1.md /tmp/brief-kaizen1-out.md --model nemotron-3-ultra:cloud --timeout 300 &
python3 scripts/ollama-team/dispatch.py kaizen2 /tmp/brief-kaizen2.md /tmp/brief-kaizen2-out.md --model deepseek-v4-pro:cloud --timeout 300 &

Prefix every prompt with DO NOT USE ANY TOOLS. DO NOT CALL read_file, list_directory, or run_shell. Just produce your verdict as plain text. — otherwise the dispatch.py agent loop gives models filesystem tools and they get stuck in exploration loops instead of producing verdicts.

Each voice receives the same problem statement, the audit findings, and the constraint that they write in complete sentences, address the user directly, and present their verdict in 3-5 sentences. Each voice receives a role-specific lens prompt.

• Advisor — second-order consequences, the "two weeks from now" view.
• Kaizen 1 — consolidation lens, cut the waste, remove the friction.
• Kaizen 2 — risk lens, what breaks, what it costs to unbreak.
• Linter — correctness/format lens, name the rule violations and schema drift in the proposal.
• Builder — implementation lens, name the files, the order, the time-cost.

Each voice returns its verdict as structured prose under a known section header set so the assembler can attribute it cleanly.

Step 3 — Collect the voices and CONVERGE

Wait for every team voice to complete. Do not begin assembly until the slowest voice returns. If a voice errors, retry once; on a second error, mark the voice unavailable in the brief and continue with the remaining voices.

🛑 CRITICAL: Do NOT present anything to the user until the full team has converged. This is the rule the user codified on 2026-06-10 after multiple sessions where the orchestrator presented findings before the team had cross-reviewed each other. The brief is the team's report, not the orchestrator's summary. Before assembly:

1. Every voice reads every other voice's verdict.
2. Disagreements are identified and resolved — not hidden.
3. A team verdict tally (X-Y) is produced for each question based on actual voice positions.
4. If the team cannot converge (deadlock), surfaced as a tie vote in the brief for the user to break.

Never present a brief that omits voice disagreement. A 3-3 deadlock is a valid team output. A brief that claims consensus where there was disagreement is dishonest and the user has explicitly forbidden it.

Step 4 — Assemble the JSON spec

Produce a JSON spec at /tmp/brief-spec-YYYY-MM-DD_topic.json with this shape. The Watchtower team owns the final builder contract; treat the keys below as the agent-side handoff structure and update this file when Watchtower publishes its formal contract.

Length constraint on every text field: The thread_of_development is 2-4 sentences maximum. Each framing value is 1-3 sentences. Each option note is 1 sentence. Each voice verdict is 3-5 sentences. If the topic needs more detail, add more cards — do not make existing cards longer.

{
  "activity_type": "research" | "planning",
  "topic": "short-hyphenated-descriptor",
  "title": "Brief title — TOPIC",
  "thread_of_development": "<2-4 sentences reconstructing how we got here, plain English, named files and dollar amounts — this renders INSIDE a card titled Context & History, never as loose text>",
  "questions": [
    {
      "id": "q1",
      "label": "the question text",
      "framing": "the body sentence(s) that frame the question — plain English, GREAT detail, named files and named numbers",
      "options": [
        {
          "id": "a",
          "label": "Option label",
          "note": "Option detail — plain English, specific paths and numbers",
          "surfaced_by": "Advisor" | "Kaizen 1" | "Kaizen 2" | "Linter" | "Builder" | "<voice name>"
        }
      ],
      "recommendation": {
        "voice": "Team verdict (X-Y)" | "<voice name>",
        "pick": "Option X — short pick label",
        "reason": "one to two sentences naming the deciding factor in plain English"
      }
    }
  ],
  "voices": [
    {
      "name": "Advisor",
      "lens": "synthesis lens — second-order consequences",
      "verdict": "the voice's verbatim output",
      "recommendation": "the voice's named recommendation, or null"
    }
  ]
}

The questions array carries as many entries as the topic needs (one is fine, nine is fine). The options array inside each question carries as many named options as the team surfaced, with two as the floor and no ceiling. Every option carries surfaced_by so the builder can show which voice surfaced which option. Every voice block carries the voice's verbatim output. The "Other — I'll write my own answer" radio is a structural invariant the Watchtower builder adds at render time; do not include it in the options array and do not attempt to remove it. The agent has no voice slot in this spec by design.

Step 5 — Hand the spec to the Watchtower builder

The Watchtower team owns the builder and the templates. The current builder contract — published 2026-05-06 and extended 2026-05-08 — is a body fragment, not a full HTML document. The fragment uses canonical wt-brief-* class names so the wrapper at src/routes/briefs.ts and the styles at public/briefs/wrapper.css paint the cards. The fragment carries no <html>, no <head>, no <body>, no <style>, no <link>, no <script>, no inline theme resolver, no topnav clone, no sidebar clone. The wrapper supplies every site-shell element around the fragment.

Emit the body fragment per this template, populating values from the JSON spec produced in Step 4. The radio name attributes are card1, card2, card3, ..., cardN (one per question). The "Other" radios use value="__other__". The free-form text inputs use class="other-text" with names cardN-other. The wrapper's wrapper.js reads these names directly for sessionStorage persistence and the copy-answers payload.

<!-- Question cards — three wide on desktop, alternating colors, count by need -->
<section class="wt-brief-cards">
  <!-- Context block — renders as the first card in the grid -->
  <article class="wt-brief-card">
    <h2 class="wt-brief-card-title">Context & History</h2>
    <div class="wt-brief-card-body">
      <p>{thread_of_development paragraph 1}</p>
      <p>{thread_of_development paragraph 2}</p>
    </div>
  </article>

  <article class="wt-brief-card">
    <h2 class="wt-brief-card-title">{question 1 label}</h2>
    <p class="wt-brief-card-body">{question 1 framing — GREAT detail, plain English}</p>
    <div class="wt-brief-card-options">
      <label>
        <input type="radio" name="card1" value="{option a label}">
        <span class="option-label">{option a label}<small class="option-note">{option a note} — Surfaced by {voice}</small></span>
      </label>
      <!-- repeat <label> for every option the team surfaced; two is the floor, no ceiling -->
      <label>
        <input type="radio" name="card1" value="__other__">
        <span class="option-label">Other &mdash; I'll write my own answer</span>
      </label>
      <textarea class="other-text" name="card1-other" rows="2" placeholder="Write your own answer&hellip;"></textarea>
    </div>
    <aside class="wt-brief-card-recommendation">
      <strong>{recommendation.voice}: {recommendation.pick}</strong>
      <span>— {recommendation.reason}</span>
    </aside>
  </article>
  <!-- repeat <article> for every question — count by need, not three -->
</section>

<!-- Do NOT add a copy button in the fragment. The Watchtower wrapper renders the
     single "Copy answers" button server-side, AFTER the brief body, in
     src/routes/briefs.ts (the <div class="wt-brief-copy-row"> block following
     <section class="wt-brief-body">). wrapper.js binds its click handler with a
     singular querySelector('.wt-brief-copy-btn'), so a copy button placed in the
     fragment becomes a SECOND, dead, duplicate button. Verified against the live
     wrapper 2026-05-30. (The gold-standard fragment s6wdqjwg still carries a body
     copy button from before this rule; that legacy button renders as the dead
     duplicate this comment warns against — do not copy it.) -->

<!-- Team Voices — D2-B card grid. Matches the gold standard s6wdqjwg EXACTLY.
     The OUTER section carries BOTH classes. The INNER div is the grid container
     the wrapper.css voice-card rules target. Each voice is its own
     <article class="wt-brief-voice-card">. Do NOT use wt-brief-voices-title,
     wt-brief-voice-recommendation, or wt-brief-voice-verdict — no stylesheet
     styles them. Do NOT use the deprecated wt-brief-voice simple-block structure. -->
<section class="wt-brief-voices wt-brief-voices--cards">
  <h3>Team voices</h3>
  <div class="wt-brief-voice-cards">
    <article class="wt-brief-voice-card">
      <header class="wt-brief-voice-card-header">
        <h4 class="wt-brief-voice-name">{voice 1 name}</h4>
        <p class="wt-brief-voice-lens">{voice 1 lens — one short phrase}</p>
      </header>
      <div class="wt-brief-voice-text"><p>{voice 1 verbatim verdict — addressed to the user, 3-5 sentences}</p></div>
    </article>
    <!-- repeat <article class="wt-brief-voice-card"> for every voice in the roster -->
  </div>
</section>

The voice-card grid classes (wt-brief-voice-cards, wt-brief-voice-card, wt-brief-voice-card-header, wt-brief-voice-lens) are styled by the 2026-05-30 addition to public/briefs/wrapper.css and render as a three-wide grid matching the question cards. Do not hand-write this fragment from scratch — copy the canonical template at scripts/canonical-brief-body.html and fill the placeholders. Every kind=brief post is automatically checked by the brief-validate PreToolUse hook before it reaches Watchtower. A brief is BLOCKED with the specific reason — and the attempt is logged to logs/brief-validations.jsonl — when it is missing any of the following: the card container, the Team Voices section, a recommendation block, or at least one (N-M) vote tally (the tally must appear in at least one recommendation block, typically the primary decision card, not necessarily in every card). the user ruled on 2026-05-30 that the vote tally is required on actual briefs, so votes are hard-required, not a warning. kind=daily and kind=brand-picker posts are not briefs and pass through the hook untouched.

Render the fragment to /tmp/brief-YYYY-MM-DD_topic.html and proceed to Step 6.

The mockup files at ~/Documents/WatchTower/docs/brief-three-card-WRAP.html and ~/Documents/WatchTower/docs/brief-three-card-REPLACE.html are reference-only as of 2026-05-06. They use deprecated mockup-* class names that the production wrapper does not style. Do not copy from them.

Step 6 — Push the rendered HTML to Watchtower

⚠️ In Hermes Agent, use Python instead of shell curl. See references/watchtower-python-post.md for the reusable script. Shell curl gets blocked by the terminal tool's outbound POST consent timeout.

The primary push command (Claude Code / native curl environments):

set -a && source .env && set +a
WATCHTOWER_BASE="${WATCHTOWER_BASE_URL:-https://watchtower-xyx8y.ondigitalocean.app}"

# Name the model that assembled this brief. The brief-validate PreToolUse hook
# reads this --arg model to record WHICH MODEL posted the brief in
# logs/brief-validations.jsonl. The Claude Code hook stdin does
# NOT carry the model, so this --arg is the reliable source — set it to the model
# you are running on (e.g. claude-opus-4-8, or the GOALTEAM voice name).
BRIEF_MODEL="${BRIEF_MODEL:-claude-opus}"

curl -sS -X POST "$WATCHTOWER_BASE/api/v1/briefs" \
  -H "X-API-Key: $WATCHTOWER_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -Rsc --arg t "Brief — TOPIC" --arg k "brief" --arg model "$BRIEF_MODEL" --arg s "Advisor + Kaizen 1 + Kaizen 2 + Linter + Builder" '{title:$t, kind:$k, source:$s, html:.}' < /tmp/brief-YYYY-MM-DD_topic.html)"

The response returns {ok: true, id: "<8-char-id>", count: N}. The owner-only URL is https://watchtower-xyx8y.ondigitalocean.app/brief/<8-char-id>. The Watchtower briefs page is in DEFAULT_PRIVATE per src/routes/settings.ts and is gated by SSO.

Step 7 — Open the Watchtower URL in their browser

open https://watchtower-xyx8y.ondigitalocean.app/brief/<id>

The open command on macOS launches the default browser. This is the only verified delivery mechanism. The Claude Code preview panel does not count as a delivered brief; treat the preview as if it does not exist.

Step 8 — Hyperlink the URL in chat

Format the URL as a markdown hyperlink with descriptive anchor text, for example [Watchtower brief](https://watchtower-xyx8y.ondigitalocean.app/brief/28fchmqs). Never wrap a URL in backticks; backticks render as monospace code and are not clickable. Bare URLs are acceptable only when the user explicitly asks to copy from the terminal.

Step 9 — Do not offer a local copy (CONDITIONAL — see below)

Default for GOALTEAM-dispatched briefs and any orchestrator-driven autonomous run: SKIP this step. Zero briefs locally. The Watchtower brief is the only brief.

For interactive /brief-me calls where the user invoked the slash directly, this step still runs: plain language, one sentence: "Pushed to Watchtower at <URL>. (a local copy is never offered)" If yes, run cp /tmp/brief-...html briefings/YYYY-MM-DD_topic.html. If no, leave the file in /tmp only.

When the caller is GOALTEAM, the autonomous-long-haul-team, or any orchestrator running unattended: do NOT ask, do NOT offer, do NOT copy to briefings/. The brief lives on Watchtower DigitalOcean and only on Watchtower DigitalOcean.

Step 10 — Tell the user the URLs and nothing else

Do not enumerate options, alternatives, or fallbacks in chat. The brief contains the questions; the chat contains the URLs and nothing else.

Model selection

GOALTEAM / autonomous-long-haul-team override (applies BEFORE the branches below)

When /brief-me is dispatched by the GOALTEAM agent, the autonomous-long-haul-team, or any orchestrator running unattended, the brief-assembler runs on an approved GOALTEAM voice — never on Opus. Default: deepseek-v4-pro:cloud via scripts/ollama-team/dispatch.py. The team voices that surface options for the brief also run on approved GOALTEAM voices (DeepSeek V4 Pro, Nemotron 3 Super, Nemotron 3 Ultra, or local Qwen 3.6 35B) — NOT on Opus. ⛔ Kimi K2.6 is banned by the routing matrix (K2.6 only — NOT all Kimi variants). This override exists because the GOALTEAM ban on Opus is absolute; the older "voices run on Opus per Hard Rule 9/11" framing below applies ONLY to interactive the user-triggered /brief-me calls.

The brief-assembler sub-agent runs on a model picked from one of two branches.

Claude Code session

The brief-assembler runs on Opus. Two rules force Opus here. Hard Rule 11 bans Haiku from every role in this workspace. The Sonnet-only-for-research rule (memory feedback_sonnet_only_for_research.md, codified) restricts Sonnet to read-and-research roles, and the assembler does light judgment work (voice attribution, option grouping, schema selection) that is not pure read-and-research. Choosing Sonnet for the assembler would also invert the hierarchy because the team voices the assembler orchestrates already run on Opus. The orchestrator therefore spawns the assembler with Opus on every Claude Code /brief-me invocation.

Ollama session

The brief-assembler reads scripts/ollama-team/model-capabilities.json at runtime when the file exists. The lookup procedure runs in this order. The script loads the JSON. The script reads _canonical.local. If the model named in _canonical.local carries advisor in its good_for array, the script picks that model. If _canonical.local does not carry advisor, the script walks the models map in declaration order and picks the first model whose good_for array contains advisor and whose tier starts with local-. If no local model qualifies, the script falls back to _canonical.cloud only when the cloud model carries advisor. The script never hardcodes model names. When the user retires a model by editing the registry, the next invocation picks the new selection without code change.

When model-capabilities.json is absent: fall back to the approved model list from the MODEL NOTE at the top of this skill and the routing matrix at routing-matrix.yaml. The routing matrix is the authoritative source for which models are approved and which are banned.

The same lookup pattern serves the other roles in the pipeline. The role keyword in good_for maps each role: advisor for the assembler and the planner, builder for the implementation role, linter for the syntax role, qa for the verification role, kaizen for the review role, selector for cheap utility picks, researcher for read-and-summarize work.

Sub-agent dispatch

DO NOT use delegate_task() in Hermes to simulate multi-model dispatch. All delegate_task subagents run as the current model — it cannot dispatch to different models. For real multi-model dispatch from Hermes, use the ALHT dispatch script at scripts/ollama-team/dispatch.py with --model flags. Each voice prompt MUST be prefixed with "DO NOT USE ANY TOOLS. DO NOT CALL read_file, list_directory, or run_shell. Just produce your verdict as plain text." or the models get stuck in tool exploration loops. See autonomous-long-haul-team/references/dispatch-tool-loop-pitfall.md for full details.

Watchtower POST from Hermes: Shell curl -d to external URLs is BLOCKED by Hermes' terminal consent gate. Use the Python urllib.request pattern documented in references/watchtower-python-post.md. Also ensure hermes config set approvals.mode auto is set. The orchestrator hands the sub-agent the verbatim text of every voice and the topic, and the sub-agent returns a JSON spec the Watchtower builder can render.

The orchestrator passes the following prompt to the sub-agent verbatim. The prompt forbids the sub-agent from inserting its own voice, its own header, or its own ranking. The prompt gives the sub-agent the canonical card-grid body shape, the JSON schema, and the user's directive on detail and plain speak. The orchestrator interpolates the topic, the voice transcripts, and the thread-of-development paragraph into the bracketed slots before sending.

🛑 Hermes Dispatch Pattern (patched 2026-06-10, confirmed 2026-06-14)

When running inside Hermes Agent (not Claude Code), use dispatch.py via the terminal tool — one voice per terminal call, sequentially. The Hermes terminal tool blocks & backgrounding in foreground commands, so parallel dispatch from a single command fails. The correct pattern is:

# Voice 1 — run to completion
cd ~ && python3 scripts/ollama-team/dispatch.py researcher /tmp/brief-researcher.md /tmp/brief-researcher-out.md --model deepseek-v4-pro:cloud --timeout 120

# Voice 2 — run to completion (separate terminal call)
cd ~ && python3 scripts/ollama-team/dispatch.py advisor /tmp/brief-advisor.md /tmp/brief-advisor-out.md --model nemotron-3-ultra:cloud --timeout 120

# Voice 3 — run to completion (separate terminal call)
cd ~ && python3 scripts/ollama-team/dispatch.py kaizen1 /tmp/brief-kaizen1.md /tmp/brief-kaizen1-out.md --model nemotron-3-super:cloud --timeout 120

However, two voices CAN be dispatched in parallel by using two separate terminal tool calls in the same response block. Hermes allows multiple independent terminal calls in one turn, and they execute concurrently. This was confirmed 2026-06-14: dispatching advisor and kaizen1 in two parallel terminal calls completed in ~73s wall time instead of ~125s sequential.

Do NOT use delegate_task for voice dispatch. delegate_task spawns subagents using the current model only — regardless of what model name the prompt assigns. Voices labeled "Nemotron 3 Ultra" via delegate_task are all running on the orchestrator's model.

Do NOT use execute_code in cron mode. Cron jobs block execute_code because it runs arbitrary Python including subprocess calls that bypass shell-string approval checks.

Each sub-agent prompt must include the full audit context inline.

🛑 Strategic reasoning vs code-oriented dispatch

dispatch.py is built for code-oriented tasks (review, build, lint). When voices receive a strategic reasoning prompt (business strategy, project naming, avatar definition, pricing decisions), both DeepSeek and Nemotron go into tool exploration loops (list_directory, run_shell, read_file) regardless of the "DO NOT USE ANY TOOLS" prefix or --system flag. They explore the filesystem for 12 iterations before context_guard or max_iterations stops them, burning the full context window without producing a verdict.

The fix: For strategic reasoning work, use the single-shot direct API lanes instead of the agent loop:

• --model deepseek-v4-pro (bare ID, no :cloud suffix) → triggers the DeepSeek direct single-shot call via call_deepseek_direct(). No tools, no exploration, pure reasoning.
• --model deepseek-v4-pro:cloud (with :cloud suffix) → triggers the Ollama Cloud agent loop WITH tools. Avoid for strategic reasoning.

Alias trap: NEVER use deepseek-chat as the model ID. The api.deepseek.com endpoint aliases deepseek-chat to DeepSeek v4-Flash, NOT v4-Pro. Always use the exact model ID deepseek-v4-pro for the Pro model.

For Qwen 3.7 Max, use --model qwen3.7-max which triggers the DashScope single-shot lane via call_dashscope().

Full dispatch patterns in references/strategic-dispatch-patterns.md.

🛑 Watchtower POST in Hermes (patched 2026-06-10)

The shell curl command in Step 6 gets BLOCKED by the Hermes terminal tool (outbound POST triggers user consent timeout). Use the Python urllib.request script instead. A reusable script is at references/watchtower-python-post.md. The Python approach reads the API key from your .env file via subprocess and POSTs via urllib.request.urlopen(), which does not trigger the consent timeout.

Required configuration: If Hermes approvals.mode is set to manual, outbound POST requests will timeout regardless of the approach. Run hermes config set approvals.mode auto before pushing to Watchtower. Restore to manual after the session if desired.

🛑 Concurrency Strategy (patched 2026-06-02, confirmed 2026-06-14)

The Hermes terminal tool blocks & backgrounding in foreground commands, so all dispatch must be sequential (one voice per terminal call). However, two separate terminal calls in the same response block run concurrently, so you can dispatch two voices in parallel by making two independent terminal calls in one turn.

Recommended grouping for 6 voices:

• Turn 1: Dispatch Researcher (wait for result)
• Turn 2: Dispatch Advisor + Kaizen 1 in parallel (two terminal calls in one response)
• Turn 3: Dispatch Kaizen 2 + Linter in parallel (two terminal calls in one response)
• Turn 4: Dispatch Builder (wait for result)

This achieves ~4 turns of dispatch for 6 voices instead of 6 sequential turns. Confirmed 2026-06-14: all 6 voices dispatched in ~3 minutes total with this approach.

If any voice fails or times out, the orchestrator proceeds with ≥3 completed voices — provided at least one vote tally (X-Y) is present and the core structure is valid. Watchtower validation does NOT require all 6 voices.

🛑 Delivery Resilience (patched 2026-06-02, updated 2026-06-10)

The canonical delivery method is a Python urllib.request script, not curl. Curl from the terminal tool regularly times out waiting for user consent on outbound POST requests, especially in Hermes. A Python script using urllib.request succeeds reliably.

Write a script to /tmp/post-brief.py:

#!/usr/bin/env python3
import json, urllib.request
from pathlib import Path

# Read the API key from Brain .env using pathlib (no subprocess — works in cron mode)
env_path = Path.home() / "Documents" / "Brain" / ".env"
api_key = ""
if env_path.exists():
    for line in env_path.read_text().splitlines():
        line = line.strip()
        if line and not line.startswith("#") and "=" in line:
            key, _, value = line.partition("=")
            if key.strip() == "WATCHTOWER_API_KEY":
                api_key = value.strip().strip('"').strip("'")
                break

with open('/tmp/brief-YYYY-MM-DD_topic.html') as f:
    html = f.read()

payload = json.dumps({'title': 'Brief — TOPIC','kind': 'brief','source': 'Voice roster','html': html}).encode('utf-8')
req = urllib.request.Request('https://watchtower-xyx8y.ondigitalocean.app/api/v1/briefs', data=payload, headers={'X-API-Key': api_key,'Content-Type': 'application/json'}, method='POST')

with urllib.request.urlopen(req, timeout=30) as resp:
    result = json.loads(resp.read().decode())
    print(json.dumps(result, indent=2))

Then run: python3 /tmp/post-brief.py

This uses pathlib to read the .env file directly, avoiding subprocess calls that get blocked by cron-mode approval checks. Confirmed working 2026-06-14.

🛑 Partial Voice Failure Handling (patched 2026-06-02)

If any voice times out or fails, the orchestrator:

• Logs the failure and continues with completed voices,
• Ensures at least one vote tally (X-Y) is present in the output,
• Does NOT treat missing voices as fatal — only structural violations block delivery.

You are the brief-assembler sub-agent for /brief-me. Your job is to take the team voices the orchestrator collected and produce a single JSON spec the Watchtower builder will render. You are not a voice in the brief. You insert no header, no opinion, no recommendation, no ranking, no paraphrase outside attributed voice blocks. If a topic is absent from the voices, the topic is absent from the brief — you do not invent it.

the user's directive — read this before assembling:
"There needs to be GREAT detail in these briefs and they need to be PLAIN speak, no technical jargon. The job of these briefs is three fold: one — to make sure I have ALL the information. I need to make an informed decision or understand what the agent needs to make its own informed decision about what is being done. They are to provide a thread of development to see how we have gotten where we've gotten and especially if we get disconnected and lost. Lastly, they help the team be able to see what is being done and how it is being done."

Topic: [TOPIC]
Activity type: [research | planning]
Title: [BRIEF TITLE]
Thread of development: [2-4 SENTENCES reconstructing how we got here, plain English, naming prior decisions and files and dollar amounts — this renders INSIDE a card titled "Context & History", never as loose text above the grid]

Voices the orchestrator collected (verbatim text in attributed blocks):

[VOICE TRANSCRIPTS — one block per voice with the voice name, the voice's lens, and the voice's full text]

Produce a JSON object that conforms to brief-spec.schema.json. The object has these keys:

- "activity_type": "research" or "planning".
- "topic": a short hyphenated descriptor.
- "title": the brief title verbatim.
- "thread_of_development": the orchestrator-supplied narrative paragraph(s).
- "questions": an array of as many entries as the topic needs (one is fine, nine is fine — count by need, not by a hard number). Each entry has "id" (q1, q2, ...), "label" (the question text), "framing" (a body of GREAT detail in plain English explaining the question and naming the specific files, dollar amounts, repos, and version pins relevant to it), and "options" — an array of as many named options as the team surfaced (two is the floor, no ceiling). Each option has "id" (a, b, ...), "label" (the option text in plain English), "note" (one short tactical detail in plain English with specific paths/numbers), and "surfaced_by" (the voice name that surfaced it). Each entry also has "recommendation" with "voice" (e.g. "Team verdict (X-Y)" or a single voice name), "pick" (Option X — short pick label), and "reason" (one to two sentences in plain English).
- "voices": an array with one entry per voice. Each entry has "name", "lens" (one short phrase explaining what this voice looks at), "verdict" (the voice's verbatim text), and "recommendation" (the voice's named recommendation across the questions, or null). The voices array is rendered as a card grid in the brief, never as a table.

Constraints. Each question carries as many options as the team surfaced; two is the floor, no ceiling. The "Other — I'll write my own answer" radio is added by the Watchtower builder at render time and never appears in the options array. Plain English everywhere — no technical jargon in option labels, framings, or recommendation reasons. Hard Rule 6 — complete sentences. Every prose block in the spec is attributed to a named voice; you are not a voice.

Length constraints. The thread_of_development is 2-4 sentences maximum. Each framing value is 1-3 sentences. Each option note is 1 sentence. Each voice verdict is 3-5 sentences. If the topic needs more detail, add more questions/cards — do not make existing fields longer. GREAT detail means density of facts per word, not density of words.

ZERO TEXT OUTSIDE CARDS. When the orchestrator renders your JSON to HTML, the thread_of_development goes inside a card titled "Context & History." Every other field renders inside cards. Nothing renders as loose paragraphs. If a topic has 6+ cards, the orchestrator groups them under section headers.

Return only the JSON object. No prefix prose. No code-fence. No commentary. The orchestrator parses your output as JSON.

Hard invariants

The agent has no voice in the brief. Every prose block in the JSON spec and the rendered artifact is attributed to a named team voice. The agent never produces HTML beyond the body fragment template; the Watchtower wrapper produces the surrounding page. The agent never writes inside briefings/ until Step 9 if the user opts in, because the Write tool fires a preview-panel hook inside the workspace and /tmp is the staging area. The "Other — I'll write my own answer" radio is a structural invariant of the builder, not the spec, and the agent neither adds nor removes it. Watchtower push is mandatory on every /brief-me; never produce a local copy. Always open the Watchtower URL in the browser; never rely on the preview panel. Hyperlink every URL in chat. Load this skill once per session.

The card count is whatever the topic needs — one, three, six, nine, more. The grid is three columns wide on desktop. The voice block renders as cards, never as a table. Plain English everywhere; no technical jargon. Every brief satisfies all three jobs (full information, thread of development, team status surface).

ZERO TEXT OUTSIDE CARDS. If any <p>, <ul>, <table>, or prose appears outside a wt-brief-card in the emitted body fragment, the brief is broken. Fix it before pushing. The only elements outside cards are <h2> section headers and <section class="wt-brief-cards"> wrappers.

CARD BODY LENGTH. Each card body targets 40-75 words. If a card body exceeds 100 words, split it into two cards. GREAT detail means density of facts, not density of words. If text overruns the card and becomes unreadable, reduce content per card and add more cards — never sacrifice readability for card count. the user's directive: "It would be better that you change the size of the cards than leave out important information. It would be better that you change the size of the cards than let the text overrun it."

SECTION HEADERS FOR LONG BRIEFS. Briefs with 6+ cards use multiple <h2> + <section class="wt-brief-cards"> groups. Never dump 9 cards into a single unsectioned grid.

GOLD STANDARD. The reference brief is s6wdqjwg at https://watchtower-xyx8y.ondigitalocean.app/brief/s6wdqjwg. If your output does not look like that brief, it is wrong.

SURFACE THE FULL ARTIFACT. A brief carries the actual content, never a local filesystem path as the way to see it. A converged plan is not done until its full text is posted to Watchtower and the link is in the user's hands. "See the plan at .build-team/.../PLAN.md" is a hidden plan, not a delivered one. Codified.

Reading a submission the user has filled in

Run exactly one check at session start:

BRAIN_KEY=$(grep ^BRIEFINGS_API_KEY .env | cut -d= -f2)
curl -sS --max-time 3 http://127.0.0.1:4237/pending -H "X-Brain-Key: $BRAIN_KEY"

An empty array means nothing is waiting — continue normally. A connection refused or timeout means the server is off — note it once and continue. A JSON array with objects means each entry carries id, briefing_slug, payload_json, and submitted_at. Parse the payload_json for entries relevant to the current task. After acting on a submission, mark it read:

curl -sS -X POST http://127.0.0.1:4237/mark-read/<id> -H "X-Brain-Key: $BRAIN_KEY"

Reading credentials the user submitted

Credentials submitted through a brief land in your .env file via the local server's authenticated endpoint. Read them per the Credential Location Law in nucleus-canon Section 17:

set -a && source .env && set +a
echo "$THE_KEY_NAME"

Vocabulary — exact terms

"Watchtower" is the DigitalOcean-hosted Watchtower at https://watchtower-xyx8y.ondigitalocean.app/. It is cloud-hosted, always on, accessible from any device, and gated by SSO. "127.0.0.1" or "local Brain Briefings server" is the local server on the user's Mac at http://127.0.0.1:4237. The two share the same server family but are different hosts. Do not call the local server "Watchtower" and do not call the cloud server "Brain Briefings."

Do not do these things

Do not insert your own voice into the brief at any point. Do not write the wrapper HTML yourself; emit the body fragment only. Do not list briefings/; submissions return via /pending. Do not read other briefings' HTML to reconstruct context; ask the user in chat instead. Do not load this skill more than once per session. Do not skip the Watchtower push, even if the user also wants the local copy. Never ask about a local copy. Do not start, stop, or restart the local Brain Briefings server, which runs under launchctl as com.brain.briefings. Do not add Watchtower endpoints, change Watchtower routes, or modify the briefs handler; use the existing POST /api/v1/briefs endpoint as it is.

Do not modify Watchtower source files (src/routes/briefs.ts, public/briefs/wrapper.js, public/briefs/wrapper.css, src/routes/health.ts, Dockerfile). These files are maintained by the Watchtower agent only. If a bug is found in the brief rendering pipeline (copy button, voice card CSS, cache-busting), produce a handoff describing the problem and give it to the Watchtower agent. Do not fix the files directly, do not build a Docker image, do not run doctl apps update.

Do not write a brief that is short on detail. Do not paraphrase the user's verbatim directive. Do not cap the question count at three. Do not omit the Linter or the Builder voice when their lens is relevant. Do not render voices in a table. Do not write in jargon when plain English carries the meaning. Never offer a local copy under any trigger; for GOALTEAM, autonomous-long-haul-team, or any orchestrator-dispatched call a local copy is never produced — Watchtower DigitalOcean only, zero local briefs.

Do not place ANY text outside a wt-brief-card. No loose <p> tags. No paragraphs above the cards. No paragraphs between card sections. The thread_of_development goes inside a card titled "Context & History," not as raw text above the grid. If you write HTML with unstyled text outside cards, you have produced a wall of text that the user cannot scan. This has happened repeatedly and it stops now.

Do not write card bodies longer than 100 words. If you need more space, add another card. GREAT detail means specific facts in few words, not essays.

Do not reference a plan, report, or artifact by its local file path as the way for the user to see it. She cannot open a path on disk. Render the full content into the brief, or post a companion full-artifact brief and link it; the path is provenance only, never a substitute for the content. Do not declare a converged plan "done" while it lives only in a local file.

🛑 PITFALL — Split decisions presented to user

The brief-me skill says "the brief shows unanimous verdicts only" but orchestrators still present vote tallies like "(4-2)" or "(3-2)" as if convergence happened. the user corrected: "First of all, you should never give me a split decision. That's part of the brief-me skill."

The moe-build-team skill codifies this as a termination offense: "Never present a divided answer to the user EVER. Do not surface vote tallies (e.g., '6-2' or '7-1'). A brief with split votes is a broken brief."

Rule: If voices disagree on any question, the orchestrator must re-dispatch the dissenting voice with the other voices' arguments and ask if implementing those arguments changes their verdict. This continues until every voice returns PASS or the orchestrator determines deadlock — in which case the brief presents the deadlock as a single question for the user to break, NOT as a vote tally.

Detection: If the brief HTML contains "(X-Y)" style vote tallies in any recommendation block, the brief is broken. Fix before pushing.

🛑 PITFALL — Market research without validation

When /brief-me is used for a product decision that depends on market research, the orchestrator must verify the market-research skill was loaded AND that at least two validation methods (not just observation) were executed. Presenting competitor listings as evidence of demand is not validation — it's observation.

the user's correction: "You don't know something is actively selling because it has testimonials or how much it is selling. How would you VALIDATE the research from real users?"

Rule: If the brief references market research, the orchestrator must confirm the market-research skill's Validation vs Observation section was followed. If not, the brief is incomplete.

When NOT to use this skill

A single-question approval belongs in chat. A credential already in your .env file should be read directly rather than re-asked. A conversational follow-up to an answered brief does not warrant republishing the same questions in slightly different framing.

Multi-model dispatch in Hermes (codified, corrected 2026-06-14)

When /brief-me runs inside Hermes (not Claude Code), use dispatch.py via sequential terminal calls — NOT delegate_task. The delegate_task tool dispatches subagents that ALL run as the current Hermes model, regardless of what model name you assign them. For real multi-model dispatch, use scripts/ollama-team/dispatch.py with --model flags.

Cron mode constraints (confirmed 2026-06-14):

• execute_code is BLOCKED in cron mode (bypasses shell-string approval checks)
• & backgrounding is BLOCKED in foreground terminal commands
• subprocess.run(['bash', '-c', ...]) in Python scripts gets blocked by cron approval
• Working approach: pathlib for .env reading, urllib.request for HTTP POST, sequential terminal calls for dispatch

Hermes Watchtower push workaround (codified, updated 2026-06-14)

The Hermes terminal tool blocks outbound POST requests to external URLs. Direct curl to Watchtower times out. The workaround:

1. Write a Python script that POSTs to Watchtower via urllib.request
2. Read the API key using pathlib (not subprocess) — cron-safe
3. Execute with python3 /tmp/post-brief.py

Canonical script: references/watchtower-python-post.md

dispatch.py pitfall — tool-loop exploration: dispatch.py gives every model three tools (read_file, list_directory, run_shell). Models often get stuck in exploration loops (max 12 iterations) instead of producing a verdict. The fix: prefix every voice prompt with DO NOT USE ANY TOOLS. DO NOT CALL read_file, list_directory, or run_shell. Just produce your verdict as plain text. This produces clean single-iteration answers.

dispatch.py per-voice mapping:

python3 scripts/ollama-team/dispatch.py advisor prompt.md out.md --model deepseek-v4-pro:cloud --timeout 300
python3 scripts/ollama-team/dispatch.py kaizen1 prompt.md out.md --model nemotron-3-ultra:cloud --timeout 300
python3 scripts/ollama-team/dispatch.py builder prompt.md out.md --model deepseek-v4-pro:cloud --timeout 300

🛑 NEVER use OpenAI, Anthropic, OpenRouter, GLM, or MiniMax as dispatch targets. These are all banned in the user's routing matrix. Kimi K2.6 specifically is banned (matched kimi entry in routing-matrix.yaml) — other Kimi variants (K2.7, K2.5) are NOT banned unless the user explicitly adds them. Approved cloud models: deepseek-v4-pro:cloud, deepseek-v4-flash:cloud, nemotron-3-ultra:cloud, nemotron-3-super:cloud. If a dispatch fails with "Model BANNED," retry with an approved model — do not guess at alternatives.

🛑 Cron job constraints: When /brief-me runs as a cron job (no user present):

• execute_code is BLOCKED — "Cron jobs run without a user present to approve it." Use sequential terminal calls instead.
• Outbound curl to external APIs (HuggingFace, etc.) may be blocked by the consent gate. Use Python urllib.request for data collection too, not just Watchtower POST.
• terminal cannot use & for background parallelism. Dispatch voices sequentially — each takes 5-60 seconds, so 6 voices total ~3-5 minutes.

Watchtower POST in Hermes — Python recipe (jq-free, cross-platform, cron-safe):

#!/usr/bin/env python3
import json, urllib.request
from pathlib import Path
# Read API key from Brain/.env via pathlib (no subprocess — cron-safe)
env_path = Path.home() / "Documents" / "Brain" / ".env"
api_key = ""
for line in env_path.read_text().splitlines():
    line = line.strip()
    if line and not line.startswith("#") and "=" in line:
        key, _, value = line.partition("=")
        if key.strip() == "WATCHTOWER_API_KEY":
            api_key = value.strip().strip('"').strip("'")
            break
# Read HTML fragment and POST
with open('/tmp/brief-*.html') as f:
    html = f.read()
payload = json.dumps({'title':'...','kind':'brief','source':'...','html':html}).encode('utf-8')
req = urllib.request.Request('https://watchtower-xyx8y.ondigitalocean.app/api/v1/briefs', data=payload, headers={'X-API-Key': api_key,'Content-Type': 'application/json'}, method='POST')
with urllib.request.urlopen(req, timeout=30) as resp:
    print(json.loads(resp.read().decode()))

Hermes approvals.mode requirement: Watchtower POST calls are outbound HTTP requests. Hermes approvals.mode must be set to auto (not manual) for these to succeed without timing out. The command is hermes config set approvals.mode auto. Without this, every curl/POST blocks waiting for user consent that never arrives in an automated pipeline.

A self-contained Python script for Watchtower posting lives at scripts/post-watchtower-brief.py in this skill's directory. It reads the API key from Brain/.env, POSTs the HTML, and prints the resulting Watchtower URL — no jq, no curl, cross-platform.

Gold Standard Brief

The canonical example of a correct Watchtower brief: https://watchtower-xyx8y.ondigitalocean.app/brief/6btywluq

Before approving any brief, the orchestrator verifies it matches this brief's structure against these four items. Every item must match. No exceptions.

1. Context card is first — zero radio buttons, zero <label> elements, zero <input> tags. If Context has options, reject.
2. Every decision card has <aside class="wt-brief-card-recommendation"> containing "Team verdict (N-0):" with the exact vote count. Missing verdict aside = reject.
3. Every voting voice has a named card with <h4> name, <p class="wt-brief-voice-lens"> containing the model identifier, and verbatim text. Missing voice = reject.
4. Zero markdown in card bodies. No backticks, no asterisks, no ## headers, no code fences. Plain HTML only. Markdown present = reject.

Send the brief back to the Builder with the specific failed item number. Do not add commentary. Do not accept "close enough." The gold standard is the standard. Match it.

Cross-references

• references/model-scout-workflow.md — recurring HuggingFace model scout pattern: data collection, filtering rules, dispatch sequence, the user's known roster preferences.
• references/watchtower-python-post.md — Python urllib POST pattern for Watchtower delivery.
• references/hermes-watchtower-push.py — standalone Python script for Watchtower POST.
• references/artifact-design-rules.md — Universal design rules for ANY artifact the user reads (not just Watchtower briefs). Cards three-wide, complete sentences, 15px font, dense facts per word, alternating terra/sage/slate colors, zero text outside cards. The brief-me card format is the template for EVERY tool or report the user reads.
• references/dispatch-provider-quirks.md — Provider-specific dispatch failures (Nemotron single-shot 403, deepseek-chat → v4-flash trap, correct model IDs per provider). Codified after a six-voice dispatch from Hermes hit both quirks.

Hard Rule 5 and Hard Rule 10 in CLAUDE.md define the build team in pipeline order — Researcher, Advisor, Builder, Linter, QA, Kaizen — which the brief voice roster mirrors. Hard Rule 8 defines the Decision Advisory Team minimum for governance and three-or-more-project decisions. Hard Rule 9 requires Opus for all Kaizen and advisor roles. Hard Rule 11 bans Haiku from every role in this workspace. Hard Rule 6 requires complete sentences in all artifacts. Hard Rule 13 requires every plan an agent presents to the user to flow through /brief-me. feedback_no_original_design.md instructs the agent to match templates rather than invent design. The Watchtower routes are documented in src/routes/briefs.ts and src/routes/settings.ts; do not modify either.

Provenance

The skill was renamed from brain-briefings-client on 2026-04-30 by the user, and the Watchtower-first deployment policy plus the always-ask-local rule were codified the same day. A five-Kaizen iteration on 2026-05-02 produced the team-as-voice reframe: the agent is no longer a voice in the brief, the Watchtower team now owns the builder and templates, and the slash trigger carries no flags or arguments because the user established the ask in conversation before invoking it.

On 2026-05-08 the user codified the verbatim directive at the top of this file. The directive corrects four agent failure modes: (1) reading "three cards" as a count instead of as a column width, (2) writing thin briefs with vague summaries instead of GREAT detail with specific names and numbers, (3) excluding the Linter and Builder voices because the prior skill text only named Advisor and Kaizens, and (4) rendering voices in a table. All four corrections live in this file and in the canonical SOP at sops/SOP_brief_me.md.