Brief Me

/brief-me

A single trigger the user types to receive a structured, converged team advisory report. The conversation that established the ask happens before the slash call. The brief is the team's report, not the agent's. The agent assembles the report from team voices, renders it locally from the shipped template, and opens it on the user's screen. There is no server, no upload, and no external posting step — the brief is a single self-contained HTML file opened in the user's browser.

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 standing directive (verbatim, codified 2026-05-08)

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.

Somehow agents have thought that I only want three cards in each brief. I have 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. I have 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 I have ALL the information. Ineed to make an informed decision or understand what YOU need to make your own informed decision about what we are doing, 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 we are doing and how we are doing it. 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 you do not undermine or change what I have said.

What this directive establishes

• "Three" is the column width of the grid, never the card count. 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.
• All six team voices appear in the brief, including the Linter and the Builder. Each role works differently, and that changes what they see. All six are required perspectives.
• Voices render as cards, never as a table. Tables strain because their width fights the page; cards let the user read fast without losing their place.
• GREAT detail in plain speak. Specific names, numbers, files, and dollar amounts — in complete sentences, with no technical jargon.

The directive does NOT change the rule that the orchestrating assembler has no voice. The assembler inserts no opinion of its own. 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.

The six required voices

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 a 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.

Each voice runs on a real, named model from the user's active approved roster, and each voice card MUST name the model that produced its verdict. This makes multi-model dispatch auditable. Never simulate the roster by spawning sub-agents that all run on the orchestrator's own model while labeling them with other models' names — that is a firing offense. If the runtime cannot genuinely dispatch to distinct models, say so and use the strongest available real dispatch path rather than fabricating model attributions.

Convergence — unanimous PASS only, no split decisions

Do NOT present anything to the user until the full team has converged. Before assembly:

1. Every voice reads every other voice's verdict.
2. Disagreements are identified and resolved — not hidden. If any voice returns FAIL or PASS-WITH-EDITS, apply the edits and re-dispatch that same voice until it returns a clean PASS.
3. A unanimous team verdict is produced for each question based on actual voice positions.

Never present a brief with vote tallies showing disagreement. A brief showing a split tally (6-2, 7-1, 4-2) is not a converged brief — it is a status report dressed as a deliverable, and presenting one is a termination-level offense. Every recommendation in a delivered brief reads Team verdict (N-0) — unanimous, with N equal to the number of voices that actually voted.

If the team genuinely cannot converge after re-dispatch rounds, that is a deadlock. Surface the deadlock as a single question in the brief for the user to break — never as a split vote tally. A brief that claims consensus where there was disagreement is dishonest and is forbidden.

Report nothing to the user during convergence rounds. The brief is the first and only thing they see.

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 six voices

Dispatch every voice in the required roster (Researcher, Advisor, Kaizen 1, Kaizen 2, Linter, Builder) to real named models per the user's active roster. Each voice receives the same problem statement, the findings, and the constraint that it write in complete sentences, address the user directly, and present its verdict in 3-5 sentences. Each voice also receives its role-specific lens prompt:

• Researcher — the cross-finding pattern the others missed.
• Advisor — second-order consequences, the "two weeks from now" view.
• Kaizen 1 — cut the waste, remove the friction.
• Kaizen 2 — what breaks, what it costs to unbreak.
• Linter — the rule violations and schema drift in the proposal.
• Builder — the files, the order, the time-cost.

If a voice errors, retry once. On a second error, mark the voice unavailable in the brief and continue with the remaining voices. Partial voice failure is not fatal; fabricated voice output is.

Step 3 — Converge

Run the convergence loop described above. Every voice reads every other voice's verdict. Resolve disagreement by re-dispatching the dissenting voice with the other voices' arguments and asking whether those arguments change its verdict. Continue until every voice returns a clean PASS on the same final text, or declare a deadlock and surface it as a single user-decision question.

Step 4 — Assemble the spec

Assemble the brief content as a structured spec before rendering. A working shape:

{
  "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 — renders INSIDE the Context & History card",
  "questions": [
    {
      "id": "q1",
      "label": "the question text",
      "framing": "1-3 sentences framing the question — plain English, GREAT detail, named files and named numbers",
      "options": [
        {
          "id": "a",
          "label": "Option label",
          "note": "one short tactical detail in plain English with specific paths/numbers",
          "surfaced_by": "<voice name>"
        }
      ],
      "recommendation": {
        "voice": "Team verdict (N-0)",
        "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",
      "model": "<model name that produced this verdict>",
      "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 — two is the floor, there is no ceiling. Every option carries surfaced_by so the rendered card shows which voice proposed it. The "Other — I'll write my own answer" radio is a structural invariant added at render time on every decision card; it never appears in the options array. The assembling agent has no voice slot in this spec by design.

Length discipline. The thread of development is 2-4 sentences. Each framing 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. GREAT detail means density of facts per word, not density of words per card.

Step 5 — Render the brief from the shipped template

Copy the shipped brief-template.html and replace only the words — the structure, styles, and scripts stay exactly as they are. Produce ONE single self-contained HTML file. Self-contained means: all CSS inlined in the file (it already is, in the template), the logo embedded as a base64 data URI in the masthead (read the shipped assets/freedomaios-logo.png and inline it — the template shows the pattern), and no external fetches of any kind except the https://incredagents.com hyperlink on the logo and in the footer.

Fill, in order:

1. <title> and masthead — the brief title, the kicker line, and a purpose paragraph telling the user what this brief decides.
2. The decision card grid — the Context & History card first (prose only, no radios), then one card per question.
3. The team voices grid — one card per voice.
4. The copy-answers card — leave its text, button, and script untouched unless the topic requires wording changes.

Radio input name attributes are card1, card2, ..., cardN — one shared name per decision card so the radios are mutually exclusive within a card. The "Other" radio uses value="__other__" and its free-form textarea uses name="cardN-other". The template's copy-answers script depends on this structure; do not rename classes or restructure the cards.

Name the rendered file descriptively, for example brief-YYYY-MM-DD_<topic>.html, in a working directory.

Step 6 — Open the brief on the user's screen

open /path/to/brief-YYYY-MM-DD_<topic>.html

The open command on macOS launches the file in the user's default browser. This is the delivery mechanism. A file path printed in chat is NOT delivery — the brief must be open on the user's screen. (On Linux use xdg-open; on Windows use start.)

Step 7 — The user answers and replies

Tell the user, in one or two plain sentences: the brief is open on their screen; pick one option on every decision card (or choose "Other" and write their own answer in the white box); click the Copy my answers button; paste the copied text back into the chat. Nothing leaves their machine — the button copies to their clipboard locally, and there is no server.

When the pasted answers arrive, treat them as decisions and execute. Do not re-ask anything the answers already settled.

Branding — logo and link

The skill ships with assets/freedomaios-logo.png. The logo appears in the brief masthead (embedded as base64 so the file stays self-contained) and is wrapped in a link to https://incredagents.com opening in a new tab. The footer also credits IncredAgents with the same link. Do not remove, replace, or restyle the logo, and do not point the link anywhere else.

Card grid — three wide, count by need

Every brief uses the same card grid. The grid is three columns wide on desktop, never more, and stacks to one column on mobile. The card count is whatever the topic needs — one, three, six, nine, more. Any agent who reads "three cards" as "exactly three cards" is reading it wrong.

Cards rotate accent colors in the template's fixed order: the Context & History card is navy, then terracotta, sage, navy, terracotta, sage, and so on through the grid. Use the template's accent-navy, accent-terracotta, accent-sage classes in that rotation. The copy-answers card at the bottom is accent-amber.

Decision-card anatomy — the same shape every time

Every decision card holds the identical inner shape with no exceptions:

1. A question title — a short, plain-English label (5-10 words).
2. A body — 1-3 short paragraphs framing the question with GREAT detail in plain speak: specific names, numbers, files, dollar amounts. Complete sentences. No jargon. No filler phrases like "It is worth noting that." No restating the question — the title is the label, the body answers it.
3. Named radio options — as many as the team surfaced. Two is the floor; there is no ceiling. Each option carries its label plus a one-sentence note ending with "— Surfaced by <voice>". If three voices each surfaced a different option, all three appear.
4. The "Other — I'll write my own answer" radio, always last, paired with the white free-form text box that appears when "Other" is selected.
5. A recommendation block pinned to the bottom of the card: Team verdict (N-0): <pick> plus one or two plain-English sentences naming the deciding factor.

The user chose the same-every-time shape with the words: "It needs to be the same every time. The whole point of this exercise is standardization."

If a card body exceeds roughly 100 words, split it into two cards. It is better to change the number of cards than to leave out important information or let text overrun a card.

Context & History — always the first card

The thread of development renders as the FIRST card in the grid, titled Context & History, as prose only — no radio buttons, no options, no inputs. It reconstructs in 2-4 plain-English sentences how the work got to this decision point: prior decisions, named files, named numbers, dollar amounts. If the user or the team gets disconnected and lost, this card is the trail back.

No standing flow diagram

There is NO "How It Flows" or workflow-diagram section in the brief. A workflow or diagram appears only INSIDE a decision card, and only when a specific decision genuinely needs one to be understood. Never add a standing process section to the brief.

Team voices — cards, never a table

The six voice verdicts render at the bottom of the brief under a "Team voices" heading, in a card grid mirroring the decision grid (three wide, one per voice). Each voice card carries:

• the voice's name (e.g. "Kaizen 2"),
• its lens in one short phrase,
• the model name that produced the verdict,
• the voice's verbatim verdict addressed to the user, 3-5 sentences.

Voices are NEVER rendered as a table. Voice verdicts never appear as a loose prose block below the cards.

Zero text outside cards — non-negotiable

Every piece of visible content in the brief body lives inside a card. The only elements allowed outside cards are <h2> section headers and the card-grid wrapper sections. Specifically:

• The thread of development renders INSIDE the Context & History card, never as loose paragraphs above the grid.
• Voice verdicts render INSIDE voice cards.
• Recommendations render INSIDE the recommendation block of their parent card.
• Any content an agent would be tempted to place as a paragraph between two card sections gets its own card instead.

If the rendered HTML has any <p>, <ul>, <table>, or prose floating outside a card, the brief is broken. Fix it before opening it for the user.

Section headers organize long briefs

Briefs with 6+ cards use multiple <h2> section headers, each followed by its own card grid, grouping cards by topic with plain-English headings. A single unsectioned grid of 9+ cards is a layout failure.

Question overlap check — before delivery

Before rendering, read every question label. If two questions could be answered with the same sentence, merge them into one card. If one card asks about an approach and another asks about the same approach's maintenance risk, they overlap — the second card's content belongs as options within the first card. A brief surfaces distinct decisions, never the same decision restated with different framing. The user flagged this directly: "I feel like your questions overlap, which doesn't allow me to give a proper answer."

Surface the full artifact — never a pointer

A brief carries the actual content. When a brief presents a plan, the plan's full content renders into the brief cards, or a companion full-plan brief is delivered alongside and linked. A file path may appear as supporting provenance ("source: ..."), never as the substitute for the content itself. The user's words: "you created a brief that mentioned a plan but didn't bother showing me the plan."

The three jobs of a brief

Every brief must satisfy all three jobs at once:

1. Give the user ALL the information needed 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, file paths, function names, repo URLs, and version pins are what "ALL the information" means in practice.
2. Provide a thread of development — show how the work got where it got, so the brief is the trail back to the current decision point after any disconnection.
3. Help the team see what is being done and how — the brief is also a status surface for the wider team. Plain English, no jargon, named files and named numbers.

A brief that fails any one of these three jobs is a summary, and summaries are what agents wrote when they paraphrased the directive.

Hard invariants

• The assembling agent has no voice in the brief. Every prose block is attributed to a named team voice.
• Six voices required: Researcher, Advisor, Kaizen 1, Kaizen 2, Linter, Builder. Each voice card names its model.
• Unanimous convergence only. Every recommendation reads Team verdict (N-0). Split tallies are never presented. Deadlock becomes a single user-decision question, not a tally.
• Silence during convergence rounds — the user hears nothing until the team has converged.
• Card grid three wide on desktop; card count by need, never capped at three.
• Context & History is the first card — prose only, no inputs.
• Every decision card: title, GREAT-detail body, named radio options (floor of two, no ceiling) with "Surfaced by" notes, the "Other" radio last with its white free-form box, and a Team verdict (N-0) recommendation block.
• Voice cards render as cards, never a table.
• Zero text outside cards. Only <h2> section headers and grid wrappers live outside cards.
• No standing flow-diagram section. Workflows appear inside a decision card only when a specific decision needs one.
• One single self-contained HTML file rendered from the shipped template. Logo base64-embedded in the masthead, linking to https://incredagents.com.
• Delivery is open on the user's screen — never a bare path in chat, never an external upload.
• Plain English, complete sentences, everywhere.
• Load this skill once per session.

Do not do these things

• Do not insert your own voice, header, ranking, or pick anywhere in the brief.
• Do not present the brief before the full team has converged, and never present split vote tallies.
• Do not cap the card count at three, and do not write thin cards — GREAT detail means specific facts in few words.
• Do not render voices in a table, or omit the Linter or the Builder.
• Do not place any text outside a card.
• Do not add a "How It Flows" or any standing workflow section.
• Do not modify the template's structure, styles, or copy-answers script — replace only the words.
• Do not remove or re-link the logo; it always points to https://incredagents.com.
• Do not upload the brief anywhere or POST it to any server. Delivery is local: render, open, copy-answers, reply.
• Do not reference a plan or artifact by file path as the way to see it — render the content into the brief.
• Do not fabricate a voice verdict or a model attribution. If a voice fails twice, mark it unavailable.
• Do not write in jargon when plain English carries the meaning.

When NOT to use this skill

A single-question approval belongs in chat. A conversational follow-up to an answered brief does not warrant republishing the same questions in slightly different framing. A brief exists for decisions and research conclusions that need the full team's converged weight — nothing smaller.

Files this skill ships with

• SKILL.md — this file.
• brief-template.html — the canonical local brief template. Copy it and replace only the words.
• assets/freedomaios-logo.png — the masthead branding asset, base64-embedded at render time, linking to https://incredagents.com.
• ONBOARDING.md — the standalone onboarding guide for agents picking up this skill cold.