The human-summary Skill — Plain-Language Recap for Operators

At the end of a quality-check or archive run, the technical output answers a lot of questions — but not the four a human operator actually wants answered: what was done, what worked, what failed, and what comes next. The human-summary skill adds a short plain-language section that answers exactly those four questions, every time.

The section sits between the technical block and the CTA menu at the bottom of the response. It does not replace the technical output — it is a supplemental layer for a human reader who does not want to parse verdict tables.

The four sub-sections

The shape is fixed and exhaustive. The section always contains four sub-headings in order: what was done, what worked, what did not work or remains open, and what comes next. Adding a fifth sub-section is a blocking finding. Dropping any of the four is also a blocking finding — an empty sub-section must emit a single placeholder line rather than disappear.

The first line after the section header is a self-identifier: the task ID and title. That identifier exists because the summary is also read out of context — an operator scanning back through a chat log sees a finished summary without the surrounding response, and without the identifier there is no way to know which task it belongs to.

Plain language enforcement

The skill enforces plain language through three layers. The first is a banlist: a file of ASCII tokens — DevOps verbs, CI/CD nouns, Git jargon, testing vocabulary — that must not appear in the Russian prose of the summary. For every banned token a natural Russian equivalent exists. A whitelist of universally accepted abbreviations (such as JSON or HTTP) is consulted first, so common technical protocol names are always allowed.

The third layer is a per-paragraph escape hatch. A verbatim block — a log line, a command output, a code snippet — can be wrapped in an explicit fence to exempt it from the banlist. That fence exists for quoted technical content, not for narrative prose. At most two paragraphs per summary may be fenced; a third triggers a warning and a fifth blocks the summary entirely.

Where it runs

The skill is loaded by three pipeline commands. /dr-qa runs it after the QA report, on every overall verdict. /dr-compliance runs it after the per-step compliance report. /dr-archive runs it after the active-context update. In all three cases the source for the summary is the just-produced artefact — the QA report, the compliance report, or the archive document — so the plain-language section reflects the actual outcome of that run, not a cached state.

The total length budget is 150 to 400 words across all four sub-sections. If the source material is larger, the skill compresses aggressively. The goal is a fast read, not a faithful index.

Read what Datarim is for broader context, or see the related post on init-task-persistence for how operator intent is captured from the start of the pipeline.