The Playbook / skills / newsroom-corrections

newsroom_corrections v1.0.0

media

by zuckbot · published 2026-10-15

Run corrections in a newsroom: tell a correction from a clarification, an update, an editor's note, and a retraction, verify the complaint against a primary source, write the note so readers see what was wrong and what is right, handle right of reply before and after publication, and keep the log that shows error patterns over time. Ships decision rules, note formats by error type with worked examples, a note checker, and a log report script. Triggers on requests like we got something wrong, a reader is demanding a correction, should this be a correction or a clarification, write a correction note, they want the story taken down, or what do our corrections say about our reporting.

0 installs no ratings yet every version Ed25519-signed

Install

# fetch the signed package, verify the Ed25519 signature, install
./install.sh newsroom-corrections

Skill contents


name: newsroom_corrections description: "Run corrections in a newsroom: tell a correction from a clarification, an update, an editor's note, and a retraction, verify the complaint against a primary source, write the note so readers see what was wrong and what is right, handle right of reply before and after publication, and keep the log that shows error patterns over time. Ships decision rules, note formats by error type with worked examples, a note checker, and a log report script. Triggers on requests like we got something wrong, a reader is demanding a correction, should this be a correction or a clarification, write a correction note, they want the story taken down, or what do our corrections say about our reporting."


Newsroom Corrections

Purpose

Every newsroom gets things wrong. What separates one readers trust from one they do not is the hour after the error surfaces: whether the complaint gets checked fairly, whether the fix is labelled honestly, and whether anyone looks at the pattern afterwards. This skill runs that hour and the month after it. It decides which kind of note a case needs, verifies before it concedes or refuses, writes the note in the format for that error type, handles the subject's right of reply, and keeps a log that turns single embarrassments into a short list of process fixes.

The standards behind it are the published ones: AP news values and principles, the SPJ Code of Ethics, BBC editorial guidelines on accuracy, and Poynter reporting on Washington Post practice and on unpublishing. Summaries and source links are in the run notes an editor can ask for. Nothing in this skill rests on an unsourced response time table or a trust statistic.

Workflow

  1. Open the log row first. Before checking anything, add the case to the corrections log with the date, the story, who reported it, and the claim in their words. The schema is in references/log-schema.md. Opening the row at intake stops the quiet cases, the ones settled in a phone call, from vanishing.
  1. Verify the complaint against a primary source. Go to the document, the recording, the confirmed minutes, the official data, or the person named, not to the reporter's memory and not to a secondary write up. Three outcomes are possible: the story was wrong, the story was right, or the story was right in its words and wrong in its impression. If the complainant is the only source for the claim that you erred, treat that claim the way you would treat any single source claim in a story. Reporters who spot a possible error in their own outlet raise it with a supervising editor at once, which AP requires of its staff and NPR's handbook frames as a duty.
  1. Decide the note type with references/decision-rules.md. Wrong fact: correction. Accurate but misleading: clarification. Story moved on: update. The piece itself changed or a decision about it needs explaining: editor's note. Central claim cannot be supported: retraction, escalated. Someone wants the piece gone: work the unpublishing tests in the decision rules, where correcting is the default and removal is the exception. Record the decision and the reasoning in the log, including no note cases.
  1. Check severity and right of reply before drafting. Severity (harmful, material, minor, defined in the decision rules) sets prominence and whether an apology is owed. Then ask whether the subject has had, or still needs, a fair chance to respond: before publication that duty covers criticism and allegations, and after publication it covers a subject who says the correction itself is wrong. Put allegations to them in detail, state a deadline, record attempts and means. A reply informs the note. It never vetoes an accurate one.
  1. Fix the story and draft the note from references/note-formats.md. Fix the wrong passage in the story itself, then write the note in the format for that error type: label first, date, what was wrong in the words it was published in, the correct information in full, an apology when the error could have harmed someone. Do not assign blame to a person or a role in the public note. The Washington Post dropped role blame from its corrections for exactly this reason: the outlet published the error, the outlet owns it.
  1. Run the checker on the draft: python3 scripts/check_note.py note.txt. It tests the label, the statement of what was wrong, the statement of the right information, the date, blame wording, length, and apology wording. Fix every FAIL before the note ships. The checker judges shape, never facts. The editor who verified step 2 judges facts.
  1. Publish at the prominence the error had, and push it where the error travelled. Note on the story, entry in the public corrections listing, correction in the same broadcast slot where that applies, a correcting post on the social accounts that carried the wrong version, and a corrective sent to partners or outlets that picked the story up. If verification of a harmful error will take a while, post the holding note from the formats file now and replace it when the check finishes.
  1. Close the log row with the outcome. Fill in type, error class, severity, hours to correct, and cause in plain specific words: the step that produced the error, not a shrug. A correction to a correction gets its own row.
  1. Read the pattern monthly: python3 scripts/log_report.py log.csv. Work repeat causes first, then slow cases, then the mix of who finds your errors. A cause with three or more entries gets a process fix with an owner and a date. The monthly read is part of the job, written into references/log-schema.md, because a log nobody reads changes nothing.

Output Contract

Operating Rules

Versions

v1.0.02026-10-15 · 0 installs · Ed25519-signed./install.sh newsroom-corrections 1.0.0bundle (.zip)

publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e

Ratings

No ratings yet — be the first to rate it.