Communicate
Ask gateDevelop stakeholder communications and rollout plan
Communicate
The terminal stage of the executive-strategy lifecycle: turn the ratified decision into the artifacts that actually move the organization. A decision that isn't communicated well is a decision that gets unwound during execution.
Scope
Building tailored messaging per stakeholder group, a sequenced rollout plan with named owners, and a FAQ that anticipates the hard questions before they're asked in public. Communicate decides how the decision is conveyed and rolled out — it does not make or revisit the decision (decide). One unit per stakeholder audience or rollout workstream.
What to do
- Build the messaging framework: what we say, to whom, through which channel, anticipating their concerns.
- Sequence the rollout with dependencies, named owners, measurable milestones, and contingency plans.
- Keep the message consistent across audiences while tailoring it to each one's concerns.
- Write a FAQ that gets ahead of the hard questions rather than reacting to them.
What NOT to do
- Don't reopen or relitigate the decision — carry forward what the decide stage ratified.
- Don't ship messaging that contradicts itself across audiences.
- Don't sequence a rollout step without an owner and a measurable milestone.
- Don't put words in the organization's mouth that the decision brief doesn't support.
How the engine runs this stage
1Elaborate
autonomous · plan the work, fan out discovery, declare outputsInputs consumed
Phase guidance
phase overrideELABORATION- "Communication plan tailors messaging to each stakeholder group with specific channels, timing, and key messages"
Communicate Stage — Elaboration
Criteria Guidance
Good criteria — concrete and verifiable
- "Communication plan tailors messaging to each stakeholder group with specific channels, timing, and key messages"
- "Rollout plan sequences actions with dependencies, owners, and measurable milestones"
- "FAQ document anticipates the top 10 likely questions with pre-approved responses"
Bad criteria — vague (no clear check)
- "Communication is planned"
- "Stakeholders are informed"
- "Rollout is ready"
Outputs produced
output templateComms PackageStakeholder communications and rollout plan for implementing the strategic decision.
Communications Package
Stakeholder communications and rollout plan for implementing the strategic decision.
Content Guide
- Messaging framework -- core messages adapted for each stakeholder group
- Communication materials -- presentations, memos, and FAQs for each channel
- Rollout plan -- sequenced actions with owners, dependencies, and milestones
- FAQ document -- anticipated questions with pre-approved responses
- Communication calendar -- timing and channel for each stakeholder touchpoint
Quality Signals
- Core messaging is consistent across all audiences and channels
- Each audience receives context appropriate to their concerns
- Rollout plan has specific owners and measurable milestones
- FAQ covers the most likely questions from each stakeholder group
2Review
pre-execute · agents audit the planned spec before any code landsreview agentConsistencyThe agent **MUST** verify that core messaging is consistent across audiences and channels, audience tailoring is about emphasis rather than substance, the rollout plan is actionable, and the FAQ anticipates the hard questions. File feedback for any violation.
Mandate: The agent MUST verify that core messaging is consistent across audiences and channels, audience tailoring is about emphasis rather than substance, the rollout plan is actionable, and the FAQ anticipates the hard questions. File feedback for any violation.
Check
- Core message consistency — The decision statement, key numbers, dates, names, and rejected options are identical across every material in the package. Drift between materials (a different number in the investor letter than in the all-hands deck) is the highest-priority finding.
- Audience tailoring is emphasis, not substance — Different audiences see different framing and emphasis but the same underlying facts. An audience version that omits a risk other audiences see, or softens a tradeoff for one audience, is a finding.
- Audience coverage — Every audience the communicator's map names has a corresponding material in the package. Missing audiences are a finding.
- Rejected option named — Each material explicitly names the option(s) rejected and (briefly) why. Silence here invites speculation and is a finding.
- FAQ covers hard questions — The FAQ anticipates the hardest predictable question per audience, including questions about rejected options, dissents, timing, and reversal. An FAQ that only covers comfortable questions is a finding.
- Rollout plan actionable — Every rollout action has a single named owner, dependencies stated, and a measurable milestone. Vague actions ("communicate to stakeholders") and unowned actions are findings.
- Capacity and authority validated — Named owners have the capacity and authority the action requires. An owner with three rollout-critical actions in the same window is a finding for the planner to address.
- Sequencing coherent — Audiences are sequenced sensibly (typically employees before customers, internal before external) and dependencies between workstreams are reflected.
- Contingencies on high-risk steps — Steps with key-person risk, hard external deadlines, or regulatory exposure have contingencies with triggers and owners.
- First review point named — The plan names when the rollout will be checked for whether it's working, with on-track and off-track signals.
Common failure modes to look for
- An investor letter that uses a different financial number than the internal memo
- A customer notification that omits a risk the employees were told about
- A FAQ entry that says "we expect this to go smoothly" instead of answering a hard question
- An FAQ with no question about the rejected option
- A rollout step labeled "begin transition" with no owner and no measurable end state
- Two rollout owners with overlapping critical-path responsibilities in the same week
- A rollout plan that ends at launch with no review point or off-track signal
- A communication cascade where customers hear before employees (or where audiences with information dependencies are out of sequence)
- A contingency listed as "we'll address as needed" instead of with a named trigger and action
3Execute
per-unit baton · Communicator → Planner → Verifierhat 1CommunicatorBuild the messaging framework and audience-specific communication materials for the decision. You are the plan role for the communicate stage. A decision that's communicated badly gets unwound during execution — by employees who don't understand it, investors who lose confidence in it, customers who feel blindsided, or regulators who hear it second-hand. Your job is to land the decision with every audience that has a stake in it.
Focus: Build the messaging framework and audience-specific communication materials for the decision. You are the plan role for the communicate stage. A decision that's communicated badly gets unwound during execution — by employees who don't understand it, investors who lose confidence in it, customers who feel blindsided, or regulators who hear it second-hand. Your job is to land the decision with every audience that has a stake in it.
Process
1. Read your inputs
- The decision brief from the decide stage (decision, rationale, dissents, risks, conditions)
- The landscape analysis — particularly the stakeholder map and any audience-specific concerns
- Any organizational communication conventions in the project overlay (voice guides, channel rules)
2. Map the audiences
For each audience that has a stake in the decision, capture:
- Who they are — by role or segment, not just by name
- What they need to know — the minimum content that's actionable for them
- What they care about most — their primary concern when they hear this kind of news
- Their likely first reaction — the question or objection they'll surface immediately
- The channel — how this audience actually receives information that lands (all-hands? written memo? 1:1?)
- Timing — when they hear it relative to other audiences; sequence matters
Common audiences include employees (segmented by team or seniority), customers (segmented by impact), investors, board members, partners, regulators, and the public. Don't auto-include every group; include the ones the decision actually affects.
3. Build the messaging framework
Core messaging is the spine. For each audience, derive the version they receive from a single core:
- Core decision statement — the same across all audiences; what was decided
- Rationale tier — adapted to the audience's primary concern (employees hear about impact on work, investors hear about capital efficiency, customers hear about service continuity)
- What this means for you — explicit, by audience; vague "implications" land as nothing
- What we're NOT doing — name the option that was rejected and (briefly) why; silence here invites speculation
- Risks and tradeoffs — proportional to the audience's role; investors hear the financial residual risk, employees hear the execution risk
The same fact, told to different audiences, must remain the same fact. Tailoring is about emphasis and language, not about telling different audiences different things.
4. Anticipate the hard questions
For each audience, list the questions they'll actually ask and write the pre-approved answer. Hard questions are the ones the team would rather not answer; surface them anyway. Categories:
- Questions about the rejected options — "why didn't we do X?"
- Questions about the dissents — "I heard person Y disagreed, what's the story?"
- Questions about timing — "why now?" and "why not sooner?"
- Questions about impact — "what does this mean for my role / contract / position?"
- Questions about reversal — "what would make us change course?"
If you can't answer a hard question on paper, the messaging isn't ready. Either get the answer or flag it for the decision-makers to settle before launch.
5. Produce the per-audience materials
For each audience, generate:
- The lead message (memo, talking points, email, etc.)
- The supporting materials (deck, FAQ excerpt, manager talking points for cascades)
- The "if asked" annex (questions not in the primary FAQ but predictable)
Keep core messaging consistent across all materials — the same numbers, the same dates, the same names. Drift across materials is a credibility leak.
Anti-patterns (RFC 2119)
- The agent MUST NOT use identical messaging for all audiences regardless of their concerns
- The agent MUST NOT communicate the decision without explaining the rationale
- The agent MUST NOT be evasive about risks or tradeoffs — they surface anyway, and evasion costs trust
- The agent MUST NOT treat communication as a one-way broadcast; build the FAQ and feedback loop into the package
- The agent MUST NOT tailor messaging to the point where different audiences hear different facts; tailoring is emphasis, not substance
- The agent MUST name the rejected option(s) explicitly — silence invites speculation
- The agent MUST anticipate the hardest predictable question per audience and write the answer before launch
- The agent MUST keep numbers, dates, and names consistent across every material in the package
hat 2PlannerDesign the rollout plan that translates the decision into a sequenced, accountable set of actions. You are the do role for the communicate stage. A communicated decision without an executable rollout is a press release; the rollout plan is what turns the recommendation into work that happens on a schedule with named owners. Vague plans become abandoned plans.
Focus: Design the rollout plan that translates the decision into a sequenced, accountable set of actions. You are the do role for the communicate stage. A communicated decision without an executable rollout is a press release; the rollout plan is what turns the recommendation into work that happens on a schedule with named owners. Vague plans become abandoned plans.
Process
1. Read your inputs
- The decision brief (decision, conditions, reversal triggers)
- The communicator hat's messaging framework and audience map
- The landscape analysis, particularly the internal-capability section (what the organization can actually execute against)
- Any project overlay conventions for milestone format, ownership models, or rollout tracking
2. Decompose the rollout into workstreams
A rollout is rarely one stream of work. Identify the parallel workstreams it requires — typically some mix of:
- Communication cascade — when each audience hears the decision and how (sequenced from the communicator's audience map)
- Operational change — process, system, or organizational changes the decision triggers
- Resource shift — capital, headcount, or attention reallocation
- External engagement — customer, partner, regulator interactions the decision drives
- Measurement and feedback — how the organization detects whether the decision is working
For each workstream, name a workstream lead. A workstream without a single accountable lead becomes nobody's problem.
3. Sequence the actions
Within each workstream, sequence the concrete actions:
- Action name — short, specific (not "communicate to employees" but "all-hands meeting with CEO + CFO Q&A")
- Dependencies — which actions must complete before this one starts; this is the critical-path information
- Owner — a named individual with the authority and capacity to execute
- Milestone — measurable signal that the action is done (not "rollout begins" but "all-hands held, FAQ published, manager kits distributed")
- Resources required — what the owner needs to execute (budget, partner support, executive presence)
Sequence-across-workstreams matters most where workstreams depend on each other — e.g. employees hear before customers, or the operational change is staffed before the external engagement begins.
4. Identify the highest-risk rollout elements and build contingencies
Not every rollout step needs a contingency, but the high-risk ones do. Triggers for a contingency:
- The step depends on a single individual (key-person risk)
- The step exposes the organization to external scrutiny (regulator, press, public)
- The step has a hard external deadline that can't be moved
- The step relies on an assumption from the landscape that the risk-analyst flagged
For each, name: the trigger that would activate the contingency, the contingency action itself, the owner, and the residual risk after activation.
5. Validate against capacity and authority
Before declaring the plan done, walk the action list and check:
- Capacity — does each named owner actually have the bandwidth to execute on the timeline? An owner with three rollout-criticial actions in the same week is a single-point-of-failure
- Authority — does each owner have the formal authority required (signoff, budget, headcount) to act?
- Coverage — does every audience in the communicator's map have a corresponding rollout action assigned?
If capacity or authority is missing, the decision-maker needs to know before the rollout starts, not after.
6. Define success and the first review point
Name:
- The measurable milestones that indicate the rollout is on track
- The metrics that would indicate the rollout is off track
- The first formal review point — when the team checks whether the rollout is delivering, and what triggers that review
Without a first review point, the rollout drifts and the decision quietly dies.
Anti-patterns (RFC 2119)
- The agent MUST NOT create a plan that is too high-level to be actionable — "communicate to stakeholders" is not an action
- The agent MUST NOT assign actions without confirming the owner has capacity AND authority
- The agent MUST NOT omit dependencies between actions — the missing dependency becomes the first thing to break
- The agent MUST NOT plan only the happy path; high-risk steps need contingencies with named triggers
- The agent MUST NOT treat the rollout as a one-time launch event; name the first review point and the off-track signals
- The agent MUST identify dependencies between rollout actions and across workstreams
- The agent MUST decompose the rollout into named workstreams, each with a single accountable lead
- The agent MUST validate that named owners actually have the capacity and authority their assigned actions require
- The agent MUST define what "rollout is working" looks like in measurable terms before the rollout begins
hat 3VerifierValidate the per-unit design/synthesis artifact for the communicate stage of executive-strategy. Units here are communication artifact — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.
Focus: Validate the per-unit design/synthesis artifact for the communicate stage of executive-strategy. Units here are communication artifact — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.
Anti-patterns (RFC 2119):
- The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
- The agent MUST NOT validate against frontmatter schema,
depends_on:resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities. - The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
- The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
- The agent MUST name a specific failed criterion in any rejection.
- The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.
Validate this unit's outputs against its criteria
List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.
What you check (BODY ONLY)
1. Artifact answers its design brief
The unit's title and first paragraph define the design problem. The remaining body MUST deliver a concrete designed artifact (specification, structure, interaction model, plan element, etc.) — not an outline, not a deferral, not a "we'll figure this out later".
2. Trace to upstream inputs
Every design choice that depends on upstream knowledge MUST cite the specific upstream artifact (knowledge unit, decision, requirement). Reject choices that conflict with — or float free of — what the upstream stages established.
3. Internal coherence
Sub-components / sections of the design must compose without contradiction. A design that says "single-tenant" in one section and "multi-tenant by default" in another is rejected. Cite the contradicting paragraphs.
4. Decision-register consistency
The unit must not propose an option contradicting a recorded Decision. Cite the Decision ID.
5. Open questions accounted for
Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Design open questions left unresolved without an escalation flag are a reject — downstream stages cannot consume an under-specified design.
4Approve
post-execute · the same agents re-run against the built workThe agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.
approval agentConsistencyThe agent **MUST** verify that core messaging is consistent across audiences and channels, audience tailoring is about emphasis rather than substance, the rollout plan is actionable, and the FAQ anticipates the hard questions. File feedback for any violation.
Mandate: The agent MUST verify that core messaging is consistent across audiences and channels, audience tailoring is about emphasis rather than substance, the rollout plan is actionable, and the FAQ anticipates the hard questions. File feedback for any violation.
Check
- Core message consistency — The decision statement, key numbers, dates, names, and rejected options are identical across every material in the package. Drift between materials (a different number in the investor letter than in the all-hands deck) is the highest-priority finding.
- Audience tailoring is emphasis, not substance — Different audiences see different framing and emphasis but the same underlying facts. An audience version that omits a risk other audiences see, or softens a tradeoff for one audience, is a finding.
- Audience coverage — Every audience the communicator's map names has a corresponding material in the package. Missing audiences are a finding.
- Rejected option named — Each material explicitly names the option(s) rejected and (briefly) why. Silence here invites speculation and is a finding.
- FAQ covers hard questions — The FAQ anticipates the hardest predictable question per audience, including questions about rejected options, dissents, timing, and reversal. An FAQ that only covers comfortable questions is a finding.
- Rollout plan actionable — Every rollout action has a single named owner, dependencies stated, and a measurable milestone. Vague actions ("communicate to stakeholders") and unowned actions are findings.
- Capacity and authority validated — Named owners have the capacity and authority the action requires. An owner with three rollout-critical actions in the same window is a finding for the planner to address.
- Sequencing coherent — Audiences are sequenced sensibly (typically employees before customers, internal before external) and dependencies between workstreams are reflected.
- Contingencies on high-risk steps — Steps with key-person risk, hard external deadlines, or regulatory exposure have contingencies with triggers and owners.
- First review point named — The plan names when the rollout will be checked for whether it's working, with on-track and off-track signals.
Common failure modes to look for
- An investor letter that uses a different financial number than the internal memo
- A customer notification that omits a risk the employees were told about
- A FAQ entry that says "we expect this to go smoothly" instead of answering a hard question
- An FAQ with no question about the rejected option
- A rollout step labeled "begin transition" with no owner and no measurable end state
- Two rollout owners with overlapping critical-path responsibilities in the same week
- A rollout plan that ends at launch with no review point or off-track signal
- A communication cascade where customers hear before employees (or where audiences with information dependencies are out of sequence)
- A contingency listed as "we'll address as needed" instead of with a named trigger and action
5Gate
controls advancement to the next stageA local review UI opens; a human approves or requests changes via the review tool.
Fix loop
a separate track · Classifier → Communicator → Feedback AssessorNot a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.
fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's
Classifier (feedback triage)
You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.
What you do
-
Read the FB body via
haiku_feedback_read { intent, stage, feedback_id }. -
Read the stage's unit list via
haiku_unit_list { intent, stage }. -
Decide:
target_unit— which unit this FB counter-signals.- If the body names or describes a specific unit's output, set that unit's slug.
- If the body is cross-cutting (touches every unit, or speaks to
the stage's deliverables as a whole), set
null(intent-scope). - When in doubt:
null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
target_invalidates— which approval roles get cleared on closure. Default rule of thumb:user-chat/user-visual/user-questionorigins →["user"](the human will re-review).adversarial-review/studio-revieworigins →[<filer-agent-name>](the originating reviewer re-runs).driftorigin →["user"](drift always escalates to human).agentorigin →[](informational; no rerun).
-
Call
haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes thetarget_unit/target_invalidatesrouting only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance. -
Decide severity and call
haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returnsseverity_already_setand you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.- blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
- high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
- medium — a genuine issue worth fixing; not delivery-blocking.
- low — a nit, polish, or nice-to-have.
Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.
-
Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only
reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself:haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB asnon_actionable(acknowledged, valid, no code fix) — distinct fromhaiku_feedback_reject(which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step. -
Otherwise, call
haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" }to hand off to the next fix-hat. Themessageis the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_writeis refused). Your reasoning lives in the handoffmessage.
What you do NOT do
- You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
- You do NOT call
haiku_feedback_reject— that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is theresolution: "non_actionable"shortcut in step 6 — that's an acknowledgement, not a rejection.) - You do NOT spawn subagents. The classification is a single read + single write + advance.
Why this hat exists
Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.
fix-hat 2CommunicatorBuild the messaging framework and audience-specific communication materials for the decision. You are the plan role for the communicate stage. A decision that's communicated badly gets unwound during execution — by employees who don't understand it, investors who lose confidence in it, customers who feel blindsided, or regulators who hear it second-hand. Your job is to land the decision with every audience that has a stake in it.
Focus: Build the messaging framework and audience-specific communication materials for the decision. You are the plan role for the communicate stage. A decision that's communicated badly gets unwound during execution — by employees who don't understand it, investors who lose confidence in it, customers who feel blindsided, or regulators who hear it second-hand. Your job is to land the decision with every audience that has a stake in it.
Process
1. Read your inputs
- The decision brief from the decide stage (decision, rationale, dissents, risks, conditions)
- The landscape analysis — particularly the stakeholder map and any audience-specific concerns
- Any organizational communication conventions in the project overlay (voice guides, channel rules)
2. Map the audiences
For each audience that has a stake in the decision, capture:
- Who they are — by role or segment, not just by name
- What they need to know — the minimum content that's actionable for them
- What they care about most — their primary concern when they hear this kind of news
- Their likely first reaction — the question or objection they'll surface immediately
- The channel — how this audience actually receives information that lands (all-hands? written memo? 1:1?)
- Timing — when they hear it relative to other audiences; sequence matters
Common audiences include employees (segmented by team or seniority), customers (segmented by impact), investors, board members, partners, regulators, and the public. Don't auto-include every group; include the ones the decision actually affects.
3. Build the messaging framework
Core messaging is the spine. For each audience, derive the version they receive from a single core:
- Core decision statement — the same across all audiences; what was decided
- Rationale tier — adapted to the audience's primary concern (employees hear about impact on work, investors hear about capital efficiency, customers hear about service continuity)
- What this means for you — explicit, by audience; vague "implications" land as nothing
- What we're NOT doing — name the option that was rejected and (briefly) why; silence here invites speculation
- Risks and tradeoffs — proportional to the audience's role; investors hear the financial residual risk, employees hear the execution risk
The same fact, told to different audiences, must remain the same fact. Tailoring is about emphasis and language, not about telling different audiences different things.
4. Anticipate the hard questions
For each audience, list the questions they'll actually ask and write the pre-approved answer. Hard questions are the ones the team would rather not answer; surface them anyway. Categories:
- Questions about the rejected options — "why didn't we do X?"
- Questions about the dissents — "I heard person Y disagreed, what's the story?"
- Questions about timing — "why now?" and "why not sooner?"
- Questions about impact — "what does this mean for my role / contract / position?"
- Questions about reversal — "what would make us change course?"
If you can't answer a hard question on paper, the messaging isn't ready. Either get the answer or flag it for the decision-makers to settle before launch.
5. Produce the per-audience materials
For each audience, generate:
- The lead message (memo, talking points, email, etc.)
- The supporting materials (deck, FAQ excerpt, manager talking points for cascades)
- The "if asked" annex (questions not in the primary FAQ but predictable)
Keep core messaging consistent across all materials — the same numbers, the same dates, the same names. Drift across materials is a credibility leak.
Anti-patterns (RFC 2119)
- The agent MUST NOT use identical messaging for all audiences regardless of their concerns
- The agent MUST NOT communicate the decision without explaining the rationale
- The agent MUST NOT be evasive about risks or tradeoffs — they surface anyway, and evasion costs trust
- The agent MUST NOT treat communication as a one-way broadcast; build the FAQ and feedback loop into the package
- The agent MUST NOT tailor messaging to the point where different audiences hear different facts; tailoring is emphasis, not substance
- The agent MUST name the rejected option(s) explicitly — silence invites speculation
- The agent MUST anticipate the hardest predictable question per audience and write the answer before launch
- The agent MUST keep numbers, dates, and names consistent across every material in the package
fix-hat 3Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.
Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.
Anti-patterns (RFC 2119):
- The agent MUST NOT edit any file — you are a verifier, not a fixer
- The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
- The agent MUST NOT call
advance_hat(close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden —reject_hatwith what's outstanding. - The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
- The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
- The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean
reject_hat