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

plugins/pm-engineering/skills/system-design-interview/SKILL.md

@@ -14,6 +14,8 @@ Ask for these if not provided:
 - **Scope** (interview prep / real architecture decision / practice run)
 - **Scale target** (rough numbers: DAU, requests/sec, data volume — or "assume typical web scale")
 - **Constraints or priorities** (e.g. prioritise availability over consistency, minimise cost, low-latency reads)
+- **Time available** (interview context only: 30 / 45 / 60 minutes — skip for real architecture sessions)
+- **Emphasis** (optional — any area to go deeper on, e.g. "focus on the DB design" or "spend more time on scaling")
 
 ## Output Format
 
@@ -62,12 +64,7 @@ Then proceed with stated assumptions if answering an interview question.
 
 ### 5. High-Level Architecture
 
-```
-[Client] → [CDN/Edge] → [Load Balancer] → [API Servers] → [Cache] → [DB]
-                                                         → [Message Queue] → [Workers]
-```
-
-Describe each layer in 1–2 sentences explaining its role and technology choice.
+Draw an ASCII diagram specific to this system. Do not default to the client→CDN→LB→API→Cache→DB template unless it genuinely applies. Label each component with the specific technology chosen (e.g. "Kafka" not "Message Queue", "PostgreSQL" not "DB"). Describe each component in 1–2 sentences explaining its role and why that technology was chosen.
 
 ### 6. Component Deep-Dive
 
@@ -122,7 +119,8 @@ Things to tackle in production but out of scope for this design session:
 
 ## Quality Checks
 - [ ] Clarifying questions are design-changing (not generic filler)
-- [ ] Capacity estimates use real numbers (not just "it scales")
+- [ ] Capacity estimates show the arithmetic: DAU → requests/day → requests/sec → storage per record → total storage, so the numbers can be sanity-checked
+- [ ] Every row in the Trade-offs table has a non-empty Trade-off column (no rows where the trade-off is blank or says "none")
 - [ ] At least 2 component deep-dives with technology choices justified
 - [ ] Trade-offs section is honest (not just benefits of chosen approach)
 - [ ] Data flow is described end-to-end for the critical path