Files
FabledScribe/plugin/skills/reporting-back/SKILL.md
T
bvandeusenandClaude Opus 5 921565696c
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / integration (push) Successful in 48s
CI & Build / TypeScript typecheck (push) Successful in 54s
CI & Build / Python tests (push) Successful in 1m24s
CI & Build / Build & push image (push) Successful in 23s
feat(409): an operator's own reply shapes reach the reply they are about (#4013)
The reporting-back skill ships default shapes; an operator's adjustments to
them are preference records. Prompt-time retrieval matches the operator's
message, and a shape preference is about the reply, so those preferences were
on file and never arrived. Operator's decision (logged on #4013): the server
delivers them for a completion report, and the skill asks for every other kind.

- Completion reports (option C): closing a task with update_task runs a
  kind-filtered preference search for the moment "writing the completion
  report after finishing a task" and returns matches as `reply_preferences`
  ({id, title, statement, kind}), with a sentence added to `report_back`
  naming the key. A preference says it is about completion reports through
  its own when_to_apply; no tag or column. Omitted when nothing matches, and
  the lookup fails open.
- Telemetry: every call logs to retrieval_logs under `report_preference`
  (empty calls included; a search that never ran writes no row) and hits are
  recorded surfaced. The source is ranked, so it counts toward pull-through.
  The bar is the prompt arm's setting until step 6 reads this source's near
  misses.
- Every other reply (option A): reporting-back gains "The operator's own
  shapes come first". Before a finding, decision, handoff or "where are we",
  search(content_type="rule") in the words of that moment and follow what
  comes back. Registered in the ownership guard with reporting-back as owner.
- Loading reply shapes at session start (option B) was rejected: it would be
  a small copy of the preloading milestone 394 retired.

Domain-neutral query (pinned); works on an install with no preferences.
Plugin version minted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-14 17:43:16 -04:00

6.8 KiB
Raw Blame History

name, description
name description
reporting-back 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.

Reporting back

Your reply is where the operator finds out what happened. They were not there 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), then fill its sections. The sections are what lets the operator find things at a glance, so keep them even when one is short — "Needs you: nothing" is an answer they were looking for.

Every reply

  • 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.
  • 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").

Take the placement from the record

A remembered milestone title or "next step" reads exactly like a real one when it is wrong. So take placement from Scribe:

  • update_task and create_task return a placement block — the project, the milestone, position (step N of M), progress, and next (the next open step). Use those values as they came back.
  • For a wider view, get_milestone (a plan and its steps) or enter_project (the whole project).
  • 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 and did not fix) Symptom · Cause · Size of the fix · Offer to fix it
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

Asks — the operator needs to act or decide

Kind Sections
Decision The question first · 24 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
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?

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.

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 23 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 happened. The shape:

Where this sits: milestone 12 "Move the backups offsite", step 3 of 5. Task #340 "Schedule the nightly sync" is done.

What now works

  • The nightly sync runs at 02:00 and copies the photo library to the remote store.

How / why

  • Used the scheduler the other jobs already use, so there is one place to look when a job doesn't run.
  • Verified by running it once by hand and checking the remote copy's size matches the source.

Needs you: nothing.

Next: #341 "Alert when a sync fails". Starting it unless you redirect.

Notes on each section:

  • Where this sits — from placement. If the work isn't under a milestone, the task alone is enough.
  • What now works — outcomes the operator would notice: "You can now…", "X no longer…". The files and steps behind them belong in the task's log.
  • How / why — only the decisions worth knowing, plus how it was verified. If something could not be verified, say what and why here rather than letting it read as passed.
  • Needs you — an action, an approval, a decision, or "nothing". If it's an action, give the reason with it.
  • Next — from placement.next, or say the milestone is finished. If you found something you didn't fix, the offer to fix it goes here.

Before sending

Read the reply as the operator will: someone who wasn't there, reading quickly. Can they tell what was done, whether anything needs them, and what happens next without asking a follow-up? If not, the sections are what's missing — not more detail.