From grimoire
Designs and audits organizational documentation practices to establish institutional norms for recording events, failures, and decisions accurately without euphemism.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:design-honest-record-keepingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Establish institutional norms for recording events, decisions, and failures accurately and without euphemism — because organizations that record reality honestly develop better learning loops, earlier warning signals, and stronger accountability than those that soften unflattering facts.
Establish institutional norms for recording events, decisions, and failures accurately and without euphemism — because organizations that record reality honestly develop better learning loops, earlier warning signals, and stronger accountability than those that soften unflattering facts.
谷梁传 (Guliang Chi, ~5th–4th century BC) — Book of Commentary on the Spring and Autumn Annals:
Why best: The 谷梁传 is built around a single interpretive principle: the 春秋's value as a historical and moral record comes entirely from its accuracy. Each entry — how an event is named, what details are included, what is omitted — constitutes a permanent moral judgment. The text repeatedly analyzes cases where the 春秋 used a particular word or form to convey a moral assessment: calling a ruler's death "killed" rather than "died peacefully," recording a defeat accurately rather than calling it a "withdrawal." The 谷梁传's teaching: institutional records that use euphemism or omit unflattering facts corrupt not just the record but the institution's capacity for moral and operational judgment.
Google Site Reliability Engineering — Blameless Post-Mortems (Beyer et al., 2016): Google's SRE handbook establishes the blameless post-mortem as a foundational engineering practice. The key design requirement: "A postmortem that blames individuals is not a useful postmortem." The actual requirement is: record exactly what happened — what systems failed, what decisions were made, what the timeline was — without assigning individual blame, without softening technical failures, and without omitting decisions that contributed to the incident. Google's rationale: accurate records produce actionable learning; blame-focused or euphemized records produce self-protection. This practice is adopted at Netflix, Etsy, Atlassian, PagerDuty, and throughout the SRE community globally. The "blameless post-mortem" is now standard vocabulary in software reliability engineering.
Amazon "Correction of Errors" (COE) process: Amazon's internal process for significant operational failures requires a formal COE document that names the root causes, the contributing decisions, and the corrective actions without euphemism. Bezos's specific instruction (documented in Brad Stone "The Everything Store" and internal memos): failure to write an honest COE is treated as a more serious failure than the original incident. The COE is reviewed by leadership and the accuracy of the account — not just the corrective action — is evaluated. This practice forces accurate recording as a discipline, not an option.
NASA Aviation Safety Reporting System (ASRS, established 1975): After the 1972 Eastern Airlines crash (where crew errors went unreported in prior incidents because pilots feared career consequences), NASA established ASRS as an anonymous, confidential system for reporting safety concerns and near-misses in aviation. The design principle: accurate reporting requires protection from consequences of honest disclosure. Since 1975, ASRS has received 2M+ reports. Analysis of these reports has driven most major aviation safety improvements in the past 50 years. The system is based on a specific design insight: honest records require institutional protection, not just encouragement. Standard reference in safety engineering globally.
James Reason — "Managing the Risks of Organizational Accidents" (1997): Reason's Swiss cheese model of accident causation requires accurate records of near-misses and minor failures to identify the alignment of holes before catastrophic accidents occur. His finding: organizations with cultures of honest reporting of small failures have dramatically lower rates of catastrophic accidents. Organizations that suppress or soften reporting of small failures lose the early warning signals that would have prevented the large ones. Standard in nuclear, aerospace, healthcare, and chemical process safety.
Bridgewater Associates: Ray Dalio's explicit institutional practice of recording meeting discussions accurately and making them available to participants — including critical feedback about decisions and people — is designed to prevent the softening of institutional memory. Dalio's principle ("Principles", 2017): "Don't let people off the hook." An organizational culture that routinely softens its records of what was said and decided loses the ability to learn and hold people accountable.
Why distinct from apply-transparent-rules: apply-transparent-rules is pre-event — publish the rules before situations arise so enforcement is predictable. design-honest-record-keeping is post-event — record what actually happened after events occur. Both are necessary; neither substitutes for the other.
Why distinct from apply-institutional-integrity: apply-institutional-integrity addresses the consistent, impartial application of rules regardless of rank. It does not address documentation practice or how events are recorded. An organization can apply rules consistently and still produce dishonest records of those applications.
Why distinct from design-incident-response: design-incident-response designs the operational process for responding to production incidents. design-honest-record-keeping addresses the documentation principle that applies across all types of events — incidents, failures, decisions, risk assessments, performance reviews — not just production incidents.
Adopted by: Google SRE blameless post-mortems are standard practice at Netflix, Etsy, Atlassian, and PagerDuty; Amazon's COE process is reviewed at the leadership level with accuracy explicitly evaluated; NASA ASRS has operated since 1975 and is the standard reference for safety reporting in nuclear, aerospace, healthcare, and chemical process industries; James Reason's honest near-miss reporting model is required curriculum in nuclear, aerospace, and healthcare safety programs globally.
Impact: NASA ASRS has received 2M+ reports since 1975, and analysis of those honest disclosures has driven most major aviation safety improvements over the past 50 years; James Reason's research shows organizations with cultures of honest reporting of small failures have dramatically lower rates of catastrophic accidents than those that suppress or soften small-failure reporting.
Audit current documentation for euphemism and omission patterns. Review a sample of recent post-mortems, incident reports, meeting notes, and project retrospectives. Look for: passive voice that obscures agency ("the system went down" vs. "the deployment caused an outage"); softened descriptions of failures ("suboptimal outcome" vs. "we missed the deadline by 3 weeks because the estimate was wrong"); omitted decisions ("we deployed the fix" vs. "we deployed the fix over objections from two engineers who flagged the risk"); attribution to external factors when internal decisions contributed ("the incident was caused by the vendor" when internal decisions amplified the impact). Document the patterns — they reveal the institutional pressure points.
Establish explicit documentation standards. Create written standards for how different types of records must be structured:
Separate accuracy from blame. The most common reason honest records are suppressed is that accurate recording feels equivalent to assigning blame. Design this distinction explicitly: "This record is for learning, not discipline. Accurate description of what happened is required; personal judgment about individuals is not." The blameless post-mortem design: name what happened, name what decisions were made, do not name individuals as culpable — attribute to systems and processes. This separation makes accurate recording psychologically safer without sacrificing informational accuracy.
Protect honest disclosure from retaliation. Accurate records require that contributors believe disclosure is safe. Design explicit protections: records of near-misses and small failures should not be used in performance reviews; anonymous reporting channels should exist for situations where reporters fear consequences; leadership must demonstrate that honest bad news is valued over comfortable false positives. The NASA ASRS model: confidential, anonymous, consequence-free reporting produces more accurate safety data than any other mechanism.
Make honest record keeping a leadership behavior, not just a policy. Leaders who model honest records — who write post-mortems that acknowledge their own decisions as contributing factors, who record meeting decisions accurately including dissenting views, who do not soften their own performance assessments — establish the norm more effectively than any written policy. The inverse is also true: a single leader who visibly softens an unflattering record teaches the entire organization that honesty is optional.
Review records for accuracy, not just completion. Most documentation compliance checks verify that records exist, not that they're accurate. Add an accuracy review to significant post-mortems and incident reports: have someone not involved in the event review the record and identify any known facts that were omitted or softened. This functions as a quality check on the record itself, not just the event response.
Software incident: An outage affects 20% of users for 4 hours. First draft post-mortem: "A configuration issue caused service degradation. The team worked quickly to restore service." Honest record keeping version: "A configuration change deployed by [team] at 14:32 without completing the change management checklist caused a cascade failure. Two engineers flagged the missing checklist before deployment; the flag was overridden by the deployment lead to meet a business deadline. The outage lasted 4 hours, affecting 20% of users and causing $X in SLA breaches. Root cause: decision to skip checklist. Contributing factor: business deadline pressure overriding safety process." The second version enables the institution to fix the actual cause.
Financial performance: Board report on missed quarter: "Revenue came in below expectations due to macroeconomic headwinds and delayed customer decision-making." Honest record: "Revenue missed target by 18%. Primary contributing factors: (1) sales forecast was based on optimistic assumptions not validated by historical close rates; (2) two major deals that were included in committed pipeline slipped because buyer organizations encountered budget freezes that our sales process should have identified earlier; (3) headcount additions in Q3 were approved based on the original forecast rather than updated actuals. The macroeconomic environment contributed but was not the primary cause." The honest version enables the board to evaluate whether the forecast process is the problem.
Project retrospective: Project delivered 6 weeks late. Retrospective: "We encountered some challenges with scope and coordination, but the team worked hard and the outcome is strong." Honest version: "The project delivered 6 weeks late against the original commitment. Contributing factors: (1) initial scope was underestimated by 40% — the estimate was made without technical review; (2) three key dependencies on the infrastructure team were not confirmed before the project start date; (3) two scope additions in week 4 were accepted without extending the timeline. Learning: technical review of estimates and confirmed dependencies are required before committing to delivery dates." The honest version drives process change.
npx claudepluginhub jeffreytse/grimoire --plugin grimoireGuides writing blameless postmortems for incident reviews, root cause analysis, and organizational learning.
Turns incidents, near misses, and escaped bugs into lasting fixes to safeguards by strengthening controls. Use after something goes wrong.
Documents incidents, outages, or production failures with blameless post-mortems. Includes timeline, root cause analysis, and action items.