Content quality improvements to remaining 5 engineering skills

Completes the quality pass across all 10 skills:
- incident-postmortem: fix opening paragraph (blameless framing emphasis),
  add root cause circular check + action item specificity quality checks
- pr-description-writer: add title format quality check, fix
  risk-appropriate reviewer guidance quality check
- system-design-interview: rewrite architecture diagram instruction
  (system-specific not generic template), fix capacity estimates to show
  arithmetic, add trade-offs non-empty check
- api-docs-writer: add API Version + Rate Limits inputs, clarify output
  format options, add error codes completeness check, fix code examples check
- architecture-decision-record: add ADR Number + Team Context inputs,
  fix Implementation Notes + Review Date guidance, fix quality checks for
  context specificity and rejected option reasoning

Both skills/ and plugins/pm-engineering/skills/ copies updated.

https://claude.ai/code/session_01C3HwChrccJd145vJ6Z7ajF
This commit is contained in:
mohitagw15856
2026-05-20 08:02:16 +00:00
committed by Claude
parent 49137bd1b6
commit 01c10eb625
10 changed files with 42 additions and 28 deletions
@@ -5,7 +5,7 @@ description: "Write a structured incident postmortem or post-incident review. Us
# Incident Postmortem Skill
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output is ready to share with engineering teams, leadership, and affected stakeholders.
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output enforces blameless framing throughout — system gaps over individual failures — and drives toward specific, closeable action items rather than vague process commitments.
## Required Inputs
@@ -133,9 +133,11 @@ Rules for action items:
- [ ] Timeline has no blame-focused language
- [ ] Root cause is specific (not "human error")
- [ ] Root cause answers "why did this happen?" not just "what happened?" — it names a system or process gap, not a symptom
- [ ] Contributing factors explain the systemic gaps
- [ ] Every action item has an owner and due date
- [ ] "What went well" section is genuine, not token
- [ ] No action item contains vague language like "improve monitoring", "increase resilience", or "better testing" — each must name a specific change
- [ ] Executive summary is readable by non-technical leadership
## Usage Examples