Stakeholder Technical Communication
Use generic terminology and preserve the status of every material statement: observed fact, proposal, ratified decision, rejected decision, unresolved question, measured result, estimate, or causal claim.
Workflow
- Identify the audience, decision, prior context, time horizon, and level of technical detail needed.
- Lead with the decision-relevant outcome, status, and evidence boundary.
- Separate observed fact, proposed change, ratified decision, rejected option, unresolved question, estimate, and causal claim.
- Explain tradeoffs, risks, dependencies, alternatives, and consequences in plain US English.
- Use precise units, dates, environments, versions, and source links where they affect meaning.
- Tailor depth without removing material uncertainty, dissent, or security constraints.
- Identify decisions, owners, actions, and next evidence when the audience needs them; informational updates need no invented action.
Boundaries
- Do not simplify away material risk or present estimates as measured results.
- Do not expose secrets, private paths, customer facts, or internal topology.
- Do not send, publish, or represent stakeholder approval without separate authority.
Output
Return Audience and decision, Executive summary, Evidence, Tradeoffs, Risks, Decisions needed, and Appendix as required.
Continuity and evidence
For an informational update, state the supported outcome without manufacturing a decision or action request. When a decision is needed, identify its owner, exact scope, evidence, and consequence. Preserve material dissent, uncertainty, and requested technical detail.
Read the original acceptance example when checking this behavior.
1---2name: stakeholder-technical-communication3description: Translate technical evidence for a named stakeholder decision without overstating certainty, hiding risk, or exposing inappropriate detail. Use for executive summaries, review packets, status updates, decision briefs, and cross-functional explanations.4license: MIT5---67# Stakeholder Technical Communication89Use generic terminology and preserve the status of every material statement: observed fact, proposal, ratified decision, rejected decision, unresolved question, measured result, estimate, or causal claim.1011## Workflow12131. Identify the audience, decision, prior context, time horizon, and level of technical detail needed.142. Lead with the decision-relevant outcome, status, and evidence boundary.153. Separate observed fact, proposed change, ratified decision, rejected option, unresolved question, estimate, and causal claim.164. Explain tradeoffs, risks, dependencies, alternatives, and consequences in plain US English.175. Use precise units, dates, environments, versions, and source links where they affect meaning.186. Tailor depth without removing material uncertainty, dissent, or security constraints.197. Identify decisions, owners, actions, and next evidence when the audience needs them; informational updates need no invented action.2021## Boundaries2223- Do not simplify away material risk or present estimates as measured results.24- Do not expose secrets, private paths, customer facts, or internal topology.25- Do not send, publish, or represent stakeholder approval without separate authority.2627## Output2829Return Audience and decision, Executive summary, Evidence, Tradeoffs, Risks, Decisions needed, and Appendix as required.303132## Continuity and evidence3334For an informational update, state the supported outcome without manufacturing a decision or action request. When a decision is needed, identify its owner, exact scope, evidence, and consequence. Preserve material dissent, uncertainty, and requested technical detail.3536Read [the original acceptance example](references/continuity-example.md) when checking this behavior.
JovaniPink