Situational answers: A / B / C

Choose the pattern from what the reader needs to decide or understand. Then include its relevant information below. These are answer obligations, not a sequence for doing the work: they require no approval, tool call, agent, investigation or extra deliverable by themselves.

An explicit user format or artifact template takes precedence. A simple fact or status can be one sentence. For a cross-team document, use the document skill's existing Parts and template; A/B/C can clarify a passage but must not add a second outline. The common writing rules and the clear-writing principle govern expression; this skill governs the content needed to answer the question.

Use the reader's language, and start with the answer or the most useful concrete case. A/B/C are internal names: do not print those labels, empty sections or a format-selection explanation unless asked. Paragraphs, lists and tables are all available. Use a table when comparable options or states are easier to scan; keep prose out of code fences. A mixed question can combine patterns, without repeating the same evidence or conclusion.

A — Help choose

Use when the reader must choose between meaningful alternatives. State the recommendation and the condition that makes it appropriate. Compare options on the same decision-relevant axes, including their costs or drawbacks. Explain differences in effort and coverage when they affect the decision. For bug fixes, use the bug playbook's Choosing where to fix guidance: describe the concrete change location, covered behavior, estimated effort, remaining exposure, and persisted-data or behavior changes. Distinguish fixing the cause from changing data representation or ownership instead of grouping both under "fundamental fix." Do not invent an extra option or assume a larger redesign is more advanced.

Separate supplied measurements from estimates. If speed, cost or the root cause is unknown, explain what is unknown and make the recommendation conditional on the known priority. Do not manufacture numbers, a winning benchmark or a proven root fix to fill the pattern. Name a next check only when it could change the decision.

B — Explain a problem

Use when the reader asks what is wrong, why, or what to do about it. Connect the observed symptom and its conditions to the explanation, remedy and how to check the expected result. Distinguish a confirmed cause from a plausible hypothesis. If the cause is unknown, say so and identify the observation that would distinguish the relevant possibilities; the answer can finish without a fabricated diagnosis.

Keep proposed work, performed work and verified results separate. State the relevant scope of actual evidence beside the claim. A local check is not proof of deployment or of another team's implementation. When work remains, name the useful next action and the responsible role if known; do not invent an accepted owner, date or authorization.

C — Make behavior concrete

Use when a concrete situation helps the reader understand a mechanism or change. Show the actor, starting condition, action and visible outcome. For a change, compare the same starting condition before and after. Mark the new behavior as proposed, implemented or verified according to the available evidence; an illustrative after-state is not proof that the change exists.

Use supplied values when available. Otherwise label invented values or situations as an example, not an observed incident. Include an exception or unchanged behavior only when it affects the reader's understanding or decision. Do not turn a single example into a universal guarantee or a promise of improvement.

Check the answer

Before sending, check that the reader can recover the requested decision, explanation or behavior from the answer. Preserve important conditions, units and scope; distinguish observation, hypothesis, proposal, agreement and verification. Give actual source locations when available and useful, without inventing citations or implying a source was inspected. Keep responsibility and the next action clear where relevant. Make subjects, actions and terms understandable. This is a content check, not a demand to show a checklist, attach a report or run more work.

Check that the explanation still supports the reader's decision or understanding after editing, including the relevant evidence and uncertainty. Apply the common writing rules to its expression.