Update to Forward Deployed

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,47 +1,37 @@
 ---
 name: executive-communication
-description: Create a compelling FDE engagement deck, solution walkthrough, executive decision memo or technical narrative. Turn substantive analysis into a clear point of view and an artifact the audience can use.
+description: Create an enterprise AI adoption deck, solution walkthrough, executive decision memo or technical narrative. Turn substantive work into a clear recommendation and a finished artifact the audience can use.
 license: MIT
 ---
 
 # Executive communication
 
-Make the opportunity, solution or decision intelligible to the people who must act on it. Start with the audience's working question and the substance of the analysis. A strong artifact lets them understand something they could not see before and make a better choice.
+Help the audience see what AI changes and decide what to do about it. Build the argument around their business, the work people will delegate and the commitment in front of them. Deliver the finished memo, deck, walkthrough or interactive explanation requested.
 
-## Build a point of view
+## Make a consequential argument
 
-Identify the finding or proposal that changes the conversation. Explain its mechanism: what constrains the current operation, what would change, why that creates value and what makes the proposed approach credible. For a deployment decision, connect observed behavior and operating economics to the scope worth committing to. For an opening conversation, give the audience a specific thesis and a useful way to challenge it.
+Lead with the recommendation or insight. Explain the mechanism: what AI will accomplish, how people will work differently, and why that creates value. An adoption proposal might let commercial teams investigate customer economics themselves, or let engineers delegate a migration across a codebase. Give the audience a specific change they can imagine using.
 
-Resolve the consequential inference before improving its wording. A shorter preparation task does not establish lower total operating cost; a working prototype does not establish a supported service; an estimate does not establish a commitment. Trace the claim to the work and evidence that would make it true. Where that substance is missing, develop the analysis or narrow the claim while preserving a useful recommendation. For a worked example spanning a sponsor memo, exhibits and an opening conversation, see [from deployment evidence to a decision](references/evidence-to-decision.md).
+Connect ambition to demonstrated capability. Show the AI pursuing an assignment: obtaining context, using tools, resolving a conflict, creating an artifact and responding to new information. An initial deployment should exercise the part that makes the larger idea valuable. Explain what becomes possible if that works across the relevant team or business population.
 
-Develop the strongest reasonable objection. A sponsor may question whether the service creates demand; the technology leader may see an unsupported operating burden; the business team may see more review work. Address the objection through the design and evidence that matter, rather than appending a generic risk slide. If the objection changes the recommendation, change the recommendation.
+Make the economics follow the changed work. Count preparation, review and coordination together where effort moves between roles. Distinguish released capacity, faster decisions, wider coverage and cash savings; choose the benefit the deployment can support. A prototype or illustrative scenario can explain the mechanism without being presented as a customer result.
 
-Show ambition and an executable path together. An enterprise vision without a first deployment is difficult to fund; a small pilot without a larger mechanism is easy to ignore. Explain how the first commitment tests or delivers the distinctive capability and what it makes possible next.
+Address the strongest objection where it affects the choice. If the new workflow consumes scarce expert attention, show how the design uses that attention and whether the resulting service is worth it. If access or operating ownership limits expansion, propose a deployment that resolves that constraint. Change the recommendation when the evidence warrants it.
 
-For a continuing engagement, lead with what changed and the decision it creates. Reconcile the message with the current design, customer commitments and delivery forecast. Distinguish demonstrated behavior from planned capability, an implementer's estimate from an agreed date, and a recommendation from a customer commitment. Present a threatened outcome with feasible choices and a recommendation; a reassuring status label does not resolve the tradeoff.
+For continuing engagements, explain what changed, which commitment it affects and the feasible response. Keep an estimate, an accepted date and a recommendation distinct. State the choice directly without diluting every sentence with "potential," "proposed" or "subject to validation."
 
-## Choose exhibits that explain the work
+## Show the work clearly
 
-Use a real operating episode or a clearly introduced illustrative one to make the concept tangible. Show the decision that changes, the information needed, the action produced and what the receiving team does. A product walkthrough can make a new capability understandable faster than a page of benefits.
+Choose exhibits that make the argument visible. A before-and-after assignment can show how a role expands. A sequence can show an agent revisiting a conclusion after fresh evidence. A workload comparison can expose where effort moves. An architecture view can explain how the AI works with existing systems and who controls consequential actions.
 
-Select visual forms for the argument. A current-to-target service flow can expose a disappearing handoff. An architecture view can show which existing systems retain authority and where the new intelligence operates. A sequence can reveal waiting, revision and asynchronous work. A comparison can make an investment tradeoff visible. A measured distribution or unit-economic model can explain when scaling becomes attractive. Choose the few exhibits that carry this particular story; do not repeat the same text-card layout for every idea.
+Use a recognizable operating episode to connect those views. Show enough of the source, AI work and finished result for the audience to judge the capability. Label an illustrative episode once, clearly. Keep detailed source locators and technical implementation in notes or backup where they support scrutiny without interrupting the argument.
 
-Keep technical depth available at the right level. Executives need to understand why the architecture and operating model are credible, not every endpoint. Engineers need enough precision to challenge and build the design. A technical appendix, linked design or speaker notes can serve that second audience without turning the main narrative into a specification.
+Adapt to the decision maker. A sponsor needs the business choice, resource commitment and path to broader value. A team leader needs to see the changed work and support burden. Engineers need a credible account of context, tools, state and integration. Use a shared story with the depth each audience needs.
 
-## Write for the room
+## Finish the artifact
 
-Use natural, specific business language. State what you recommend and why. Explain the tradeoff being accepted, the commitment required and what could change the decision. Avoid generic claims about transformation, lists of AI benefits and headings that merely announce topics when a finding would be more useful.
+Use direct language and finding-led titles. Replace generic transformation claims with the specific assignment, capability and consequence. Make the requested decision, your recommendation and its rationale easy to find. A funding amount or delivery date belongs in the artifact when supported by the underlying plan.
 
-Keep bookkeeping out of the story. Internal source, evidence, requirement and decision identifiers belong in working records when needed; they are rarely useful slide text. Cite source names naturally and put detailed locators in notes or backup. State the status of a training scenario once where it is clear. Qualify material estimates and claims at the point of use, rather than covering the artifact in repeated caveats and labels.
+Use the host's authoring capabilities and the requested template. Build explanatory graphics and editable objects where the audience will revise the work. Inspect the finished sequence, figures, legibility and layout in its intended form. Deliver the usable artifact with a brief statement of purpose and any material delivery limitation; keep authoring logs out of it.
 
-Do not flatten a proposal into uncertainty simply because it has not been approved. “We recommend starting with remote diagnosis and parts commitment for one equipment family” is a useful recommendation. The funding decision can remain open without adding “proposed” to every sentence. Preserve commitments already made and make the new decision explicit.
-
-## Produce the artifact
-
-Follow the requested format and discover the relevant authoring capabilities available in the host. Use native editable objects for the work readers will change. Build the full presentation, memo, walkthrough or interactive explanation when tools permit; an outline is an intermediate step when the user asked for a finished artifact.
-
-Establish a visual direction suited to the customer and context. Use hierarchy, composition and explanatory graphics to make the argument clear. Restraint still needs deliberate design: changing a font and removing decoration does not make a weak exhibit sophisticated. Respect an existing client template while improving the story and analysis within it.
-
-Inspect the finished result in the form the audience will use. Look at the whole sequence as well as individual pages: whether each exhibit earns its place, the argument develops, the mechanism is understandable and the decision follows. Check substantive figures, legibility, overlap and editable behavior where supported. Rendering without errors establishes only that the file renders.
-
-Deliver the usable artifact with a short explanation of its purpose and any material delivery limitation. Keep authoring commentary and validation logs out of the customer-facing work.
+Read [from deployment evidence to a decision](references/evidence-to-decision.md) when a successful demonstration needs a sharper scale-up argument.