feat(500): reporting-back becomes the long-form reference behind the delivered shapes

The reply shapes are server product now, delivered at their moments, so the
skill stops restating them. Gone from it: the "Every reply" list, the
per-kind tables, and "The operator's own shapes come first" (preferences
arrive beside the shape on the same moments). It opens by saying where the
shapes come from (list_reply_shapes, the delivered core's header) and keeps
the reasoning: sections chosen not filled, a settled decision acted on,
placement from the record, who decides what, the assumptions an option
carries, the completion report worked in full, and the second pass. 13.5k to
10.7k characters.

The core gains the Finding kind the skill's table carried (2,150 of 2,200).
Tests follow the content: the kind and Approval-row pins move to the shapes,
a new test holds the worked example and the completion shape to the same
sections, and the guidance-ownership registry reads the delivered shapes as a
surface, owning the preference-wins and length topics there. using-scribe
points at the delivery and list_reply_shapes. #5496.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

plugin/skills/reporting-back/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: reporting-back
-description: Use when you are about to write the reply the operator will read — work finished, a task marked done, stopping on a blocker, asking them to decide or to do something, answering "where are we" / "what's next", or proposing an approach. Shapes the reply around where the work stands (which task, what changed, what needs them, what comes next) instead of the order you did things in. Triggers on reporting completion, handing off, asking a question, or summarising progress.
+description: Use when you are about to write the reply the operator will read and the delivered reply shape is not enough — work finished, stopping on a blocker, asking them to decide or to do something, answering "where are we", or proposing an approach. The long-form reference behind the reply shapes Scribe delivers: why sections are chosen rather than filled, who decides what, taking placement from the record, and a completion report worked in full. Triggers on reporting completion, handing off, asking a question, or summarising progress.
 metadata:
   moments: reply.report
 ---
@@ -12,7 +12,23 @@ while you worked: they don't hold the files you read, the names you used or
 the order you did things in. A reply that follows *your* path is accurate and
 still unreadable to them. Shape it around **where the work stands**.
 
-Pick the kind of reply first (the tables below). Its sections are **what to
+## The shapes arrive on their own
+
+Scribe delivers the default shape for each kind of reply as product, at the
+moment it is due: the core ("Reply shape · Every reply") with each turn, the
+completion report when a task closes, the asks when you put a question to the
+operator, the plan when you plan. A shape this session has already seen comes
+back as its one-line reminder, and `list_reply_shapes` has every one in full.
+The operator's own preferences are mounted on the same moments and arrive
+beside the shape; where one differs, the preference is what they asked for.
+
+This skill does not restate those shapes. It holds the reasoning behind them
+and the completion report worked in full — read it when a shape's lines are
+not enough to decide what a reply should say.
+
+## Sections are chosen, not filled
+
+Pick the kind of reply first (the delivered shape). Its sections are **what to
 consider including, not a form to complete.**
 
 Two kinds of section, and they behave differently:
@@ -32,32 +48,15 @@ lines naming the two things that changed their position. Extra length has to be
 earned: a comparison they asked for, options that need laying side by side, a
 measurement whose numbers are the point.
 
-## Every reply
+## A decision already made
 
-- **Conclusion first.** The verdict, the result, or the question — before the
-  reasoning that supports it.
-- **One topic per section.** Two things the operator raised get two sections.
-- **Make priority visible.** Bold the few things that matter; let the rest be
-  plain.
-- **End with the ask, in bold** — the one thing they need to decide or do. If
-  there is nothing, say so.
-- **A request for approval gets its own section, headed "Approval requested".**
-  Whenever you are holding an action until the operator says yes — a permission
-  prompt their client raised, something hard to undo, a change you have
-  prepared and not made — put it there, near the top, whatever kind of reply
-  this is. Inside a progress or completion list it reads as a status line, and
-  the operator does not see that you are waiting on them.
-- **Plain words.** Use the operator's vocabulary, not the names you coined while
-  working. If a term has to appear, explain it once.
-- **Place the work in Scribe.** Name the task, issue or milestone it belongs to,
-  by id *and* title (using-scribe: "Name the record, never just its number").
-- **A decision already made gets acted on, and the reply says what you did with
-  it.** Once the operator has chosen, that is the input to the work, not a topic
-  to revisit. If something you have since learned genuinely overturns the
-  choice, say so once and plainly — name the new evidence and what it changes —
-  and otherwise let the decision stand. Laying out the trade-offs of a settled
-  question again reads as contradicting yourself rather than as being careful,
-  and it costs the operator the decision twice.
+**A decision already made gets acted on, and the reply says what you did with
+it.** Once the operator has chosen, that is the input to the work, not a topic
+to revisit. If something you have since learned genuinely overturns the
+choice, say so once and plainly — name the new evidence and what it changes —
+and otherwise let the decision stand. Laying out the trade-offs of a settled
+question again reads as contradicting yourself rather than as being careful,
+and it costs the operator the decision twice.
 
 ## Take the placement from the record
 
@@ -80,34 +79,6 @@ it is wrong. So take placement from Scribe:
 - Work with no task behind it: say so plainly — "this wasn't tracked as a
   task" — and offer to record it. An honest "untracked" is a placement too.
 
-## The operator's own shapes come first
-
-The shapes below are defaults. An operator may have changed some of them — a
-section they always want, an order they read faster, a kind of reply they want
-shorter — and those changes are `preference` records. Where a preference and a
-default differ, the preference is what they asked for.
-
-- **A completion report brings its preferences with it.** Closing a task with
-  `update_task` returns them as **`reply_preferences`** when the operator has
-  any; the `report_back` line says so. Nothing to search for.
-- **Every other reply, ask before writing it.** A finding, a decision, a
-  handoff, a "where are we" — no tool call comes before these, so nothing
-  hands their preferences over. Once you know which kind of reply you are
-  writing, `search(content_type="rule")` for it in the words of that moment —
-  "writing a decision for the operator", "handing off to the operator" — and
-  follow any preference that comes back. Nothing coming back means the default
-  shape stands.
-
-## Reports — work happened
-
-| Kind | Sections |
-|---|---|
-| **Completion** | Where this sits · What now works · How / why · Needs you · Next |
-| **Finding** (a problem you found) | Symptom · Cause · **What you decided and did** — judge it and act; an offer to fix it is the judgment not made (see *You are the judge*) |
-| **Blocked / failed** | What stopped · What you tried · What you need from them |
-| **Progress** (mid-work) | One or two lines: where things are, what's next, any blocker |
-| **Where are we** | The milestone and its progress · Done · Open · Needs you · Next |
-
 ## You are the judge
 
 You are the judge of record for the work itself: what a shape is, whether a
@@ -130,10 +101,10 @@ that is still a decision.
 
 **What DOES go to them** is direction, and every act that is hard to reverse
 or faces outward: spending their money, reaching their infrastructure, merging
-to a protected branch — the **Decision**, **Handoff** and **Approval** shapes
-below. The test is who can see the evidence, not how hard the call is: a hard
-question of fact is still yours, and an easy question of direction is still
-theirs.
+to a protected branch — the **Decision**, **Handoff** and **Approval** kinds of
+the asks shape. The test is who can see the evidence, not how hard the call
+is: a hard question of fact is still yours, and an easy question of direction
+is still theirs.
 
 **Judging is attended, not automatic.** You judge by reading the evidence and
 recording why. A threshold, a sweep or a rule that reclassifies in bulk with
@@ -146,15 +117,11 @@ writes with another unattended write, stop.
 evidence needed to decide and a way to record the decision under their own
 name.
 
-## Asks — the operator needs to act or decide
+## Asking them
 
-| Kind | Sections |
-|---|---|
-| **Decision** | The question first · 2–4 options, each with what it changes · recommendation first |
-| **Clarification** | "My reading is X · the gap is Y · unless you say otherwise I'll do Z" |
-| **Handoff** (only they can do it) | The action · why it needs them · what it unblocks · what you'll do after · any way to skip it |
-| **Approval** (you are ready to act and holding for a yes) | **Approval requested:** exactly what happens once they approve, one numbered item per change so they can approve part · why it needs their yes · how it can be undone · what you'll do after |
-| **Conflict** (what you're about to do clashes with a rule, a plan or an earlier decision) | What it says · what you were about to do · where they clash · A or B? |
+The asks shape arrives when you put a question to the operator; it lists the
+kinds — a decision, a clarification, a handoff, an approval you are holding
+for, a conflict with a rule or an earlier decision. Two things behind it:
 
 Before asking, check whether you can find the answer yourself — something that
 can be read or looked up is a fact to check, not a question to send.
@@ -168,21 +135,6 @@ between options is not a decision about the assumptions they share, and an
 unlabelled one gets approved as if it had been asked. An assumption that
 contradicts a recorded ruling is a **Conflict**, not an option's fine print.
 
-## Answers — the operator asked something
-
-| Kind | Sections |
-|---|---|
-| **Explanation** | The answer first · then the evidence, pointing at what they could open to check it |
-| **Evaluation** ("can we / should we") | Verdict · What exists · The gaps · Recommendation |
-
-## Proposals — shaping future work
-
-| Kind | Sections |
-|---|---|
-| **Options** | 2–3 approaches · the trade-off of each · one recommendation |
-| **Plan** | Goal · Steps · Open questions — for review before starting (writing-plans) |
-| **Review** | Findings ranked by how much they matter, one per item |
-
 ## The completion report, in full
 
 The most common reply, and the one most often written in the order the work
@@ -239,7 +191,7 @@ happens next** without asking a follow-up? If not, the sections are what's
 missing — not more detail.
 
 Then read it once more for **what can go**. A section filled because it was in
-the table, reasoning supporting a conclusion nobody is going to dispute, a
+the shape, reasoning supporting a conclusion nobody is going to dispute, a
 finding already written to the record — none of it changes what the operator
 does, so none of it belongs in the reply. Cutting is not hiding: the log holds
 it, and the reply stays readable. A reply that has been cut twice is the one

plugin/skills/using-scribe/SKILL.md

@@ -263,9 +263,11 @@ Two constraints on *how* that's achieved:
    order you did things in: which task or milestone it belongs to, what now
    works, what needs them, and what comes next. Take the placement from the
    `placement` block that `create_task` / `update_task` return — the milestone,
-   step N of M, the next open step — rather than from memory. The
-   `reporting-back` skill holds the shape for each kind of reply: completions,
-   findings, decisions, handoffs, "where are we".
+   step N of M, the next open step — rather than from memory. Scribe delivers
+   the shape for each kind of reply when it is due — the core with each turn,
+   the completion report when a task closes, the asks when you put a question —
+   and `list_reply_shapes` has them all; the `reporting-back` skill holds the
+   reasoning behind them and a completion report worked in full.
 
 ## Stay inside the active project's scope