CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/post-mortem-author

Use after any user-visible incident to write a blameless post-mortem: a sourced timeline, root cause (what and why, not who), impact on users, revenue and SLOs, action items with owners, dates and success criteria, and what went well.

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

75%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-structured skill body: the section skeleton, blame-language rewrites, action-item discipline, and fully worked SEV-2 example leave no ambiguity about execution. The main cost is token efficiency — repeated SRE quotations and citations could be cut — and the duplicated skeleton blurs the split between body and reference.

Suggestions

Collapse the three Overview block quotes from Google SRE into one short quote plus a single citation; cite the source once and drop the repeated "Per [google-sre-postmortem]" markers throughout (conciseness).

In Step 1, list only the section names and point to the template for the per-section guidance, removing the duplication between the body and references/post-mortem-document-template.md (progressive_disclosure).

Add an explicit feedback loop in Step 2/4 — e.g., "if reviewers reject blame language or withhold sign-off, revise and re-submit" — and move the 5-business-day authoring deadline into the Step 1 workflow (workflow_clarity).

DimensionReasoningScore

Conciseness

The body is mostly operational but repeats itself: the Google SRE source is block-quoted three times in the Overview, "Per [google-sre-postmortem]" is cited roughly eight times, and "Postmortems are not punishment" appears in both the Overview and Step 2. This is more than the "minor instances" of the 4 anchor.

3 / 5

Actionability

Fully actionable for an instruction-only skill: an exact 9-section skeleton, concrete before/after blame-language rewrites ("Bob deployed without testing" → "The pre-deploy testing didn't cover the null-metadata case"), four required action-item fields, a storage layout with a naming convention, and a completely filled worked example with tables.

5 / 5

Workflow Clarity

Steps 1–5 are clearly sequenced with checkpoints (reviewer rejection criteria in Step 2, sign-off and closure conditions in Step 4), but there is no explicit fix-and-re-review feedback loop, and the "author within 5 business days" rule lives only in the anti-patterns table rather than in the workflow itself.

4 / 5

Progressive Disclosure

One clearly signaled, one-level-deep reference (references/post-mortem-document-template.md, verified to exist) with well-organized sections. Minor gaps: the full section skeleton is duplicated between Step 1 and the reference template, and the ~70-line worked example keeps the overview body long.

4 / 5

Total

16

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: specific, comprehensive on capabilities, explicitly triggered, and clearly distinct. The only weakness is trigger coverage — a single "user-visible incident" phrasing where synonyms and concrete incident types would improve recall.

DimensionReasoningScore

Specificity

The description enumerates the full deliverable set concretely — "a sourced timeline, root cause (what and why, not who), impact on users, revenue and SLOs, action items with owners, dates and success criteria, and what went well" — comprehensive coverage with no vague filler.

5 / 5

Completeness

Both "what" (write a blameless post-mortem with the listed components) and "when" ("Use after any user-visible incident") are explicitly present, but the "when" clause is a single generic trigger rather than the concrete enumerated trigger phrases of the top anchor.

4 / 5

Trigger Term Quality

Natural terms like "post-mortem", "incident", "blameless", and "user-visible incident" are present, but common variations users would actually say ("postmortem", "incident report", "retro", "outage", "SEV") are missing, matching the good-but-incomplete anchor rather than the comprehensive one.

4 / 5

Distinctiveness Conflict Risk

Blameless post-mortem authorship after incidents is a clear niche with distinct triggers; the description would not plausibly fire for unrelated document or writing skills.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page