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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user