post-mortem
Skill0 starsChanged 3 months agoMITView on GitHub
เขียน engineering post-mortem หรือ RCA ของ bug ที่แก้และ validate แล้ว โดยบันทึก symptom, root cause, กลไกของปัญหา, fix, validation และเหตุที่หลุดรอด ใช้เมื่อผู้ใช้ขอ post-mortem, root cause analysis, RCA, สรุปสาเหตุหลังแก้บั๊ก หรือทำเอกสารปิดงาน ห้ามใช้แทน incident report และห้ามเขียนจากสมมติฐานที่ยังไม่ยืนยัน
12 other projects use a version of this.
Adopted by
Most recently taken up by
- op3616windows/skillstheir own version, first seen Nov 8, 2026
- nseney1/Soma-Governancetheir own version, first seen Nov 1, 2026
- nseney1/Aegis-Guardrailstheir own version, first seen Oct 25, 2026
- neronain/ClaudeSkills-Neronaintheir own version, first seen Aug 9, 2026
- augments-labs/sdlc-skillstheir own version, first seen Aug 8, 2026
- Hassaan146/claude-skillstheir own version, first seen Jul 25, 2026
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- thananon/9arm-skills★ 3.2ksame name
- Hassaan146/claude-skills★ 18same name
- carlkibler/agent-skills★ 6same name
- MarcoZorn/agencykit★ 6same name
- andreluizweb/my-claude-skills★ 4same name
- nseney1/Aegis-Guardrails★ 4same name
- nseney1/Soma-Governance★ 4same name
- neronain/ClaudeSkills-Neronain★ 3same name
- Hussain-Elfalah/Agentic-Skills★ 2same name
- augments-labs/sdlc-skills★ 1same name
2 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- audit-product-experienceSkill
- commit-messageSkill
- git-deliver-workSkill
- git-flow-releaseSkill
- management-talkSkill
- repo-next-taskSkill
- scrutinizeSkill
The file
Files
Post-mortem
สร้างบันทึกทางวิศวกรรมที่ช่วยให้ผู้อ่านในอนาคตเข้าใจว่าอะไรพัง ทำไมจึงพัง แก้อย่างไร และรู้ได้อย่างไรว่าแก้แล้ว
ตรวจ prerequisites ก่อนเขียน
ยืนยันข้อมูลสี่ข้อก่อนร่างเอกสาร:
- มีวิธี reproduce symptom ที่แน่นอนหรือมีอัตราเกิดสูงพอให้ตรวจซ้ำได้
- root cause ได้รับการยืนยันเป็นกลไก ไม่ใช่เพียง hypothesis
- ระบุ fix ด้วย PR, commit, branch หรือรายการ change ที่ชัดเจน
- validation แสดงว่า original failure หายไปและไม่ได้ผ่านเพราะหลบ path เดิม
ถ้าขาดข้อใด ให้แสดงรายการข้อมูลที่ขาดแล้วหยุด อย่าเติมช่องว่างด้วยรายละเอียดที่ฟังดูน่าเชื่อ
อย่าใช้ workflow นี้กับ customer-visible outage ที่ต้องมี timeline, blast radius, detection และ communication history ให้เสนอ incident report แทน หากเป็น typo หรือ change เล็กที่ PR description เพียงพอ อย่าสร้างเอกสารเกินความจำเป็น
รวบรวมหลักฐาน
อ่าน repro, logs, tests, diff, PR หรือ commit ที่เกี่ยวข้อง แล้วแยกข้อมูลต่อไปนี้:
- สิ่งที่ผู้ใช้หรือระบบสังเกตเห็น
- cause chain ตั้งแต่ defect ถึง symptom
- หลักฐานที่ยืนยัน cause และ hypotheses ที่ถูกตัดออก
- เหตุผลที่ fix แก้ cause แทนการซ่อน symptom
- ขอบเขตของ validation ทั้งที่ทดสอบแล้วและยังไม่ได้ทดสอบ
- gap ใน test, review, workload หรือ process ที่ทำให้ปัญหาหลุดรอด
ใช้ code identifiers, file paths, function names และ commit references เมื่อช่วยให้วิศวกรตามกลับไปยังต้นเหตุได้
โครงสร้างเอกสาร
เรียงหัวข้อตามลำดับนี้:
- Summary — symptom, ผลกระทบ, fix และสถานะปัจจุบันในย่อหน้าเดียว
- Symptom — error, log, test หรือ behavior ที่สังเกตจริง
- Root cause — กลไกและ cause chain แบบ end-to-end
- Why it produced the symptom — เชื่อม defect ภายในกับผลที่มองเห็น
- Fix — สิ่งที่เปลี่ยนและเหตุผลที่แก้ root cause
- How it was found — repro, เครื่องมือ, hypotheses ที่ตัดออก และ experiment ที่ยืนยัน
- Why it slipped through — coverage หรือ process gap โดยไม่โทษบุคคล
- Validation — tests, workloads, metrics หรือ soak run พร้อมขอบเขตจริง
- Follow-ups — งานที่มี owner และ tracking reference หรือระบุว่าไม่มีงานต่อ
Summary, Root cause, Fix และ Validation เป็นหัวข้อบังคับ หัวข้ออื่นตัดออกได้เมื่อไม่มีสาระและต้องไม่ทำให้ข้อเท็จจริงขาดตอน
กฎการเขียนและการส่งออก
- ใช้ active voice และถ้อยคำที่ตรวจสอบย้อนกลับได้
- รักษาหลัก blameless โดยอธิบาย defect และ system gap ไม่กล่าวโทษคน
- อย่าใช้คำว่า “น่าจะ” หรือ “เชื่อว่า” แทนหลักฐาน ถ้ายังไม่รู้ให้ระบุว่ายังไม่ยืนยัน
- ระบุ validation coverage ตามจริง และอย่าเหมารวมไปยัง configuration ที่ไม่ได้ทดสอบ
- สร้าง draft ในแชตเป็น default หากผู้ใช้ไม่ได้ระบุปลายทาง
- อย่า post, comment, ส่ง email หรือแก้เอกสารภายนอกโดยไม่มีคำสั่งและการยืนยันที่ชัดเจน
- เมื่อต้องการฉบับสำหรับ leadership ให้ส่งต่อเนื้อหาที่เสร็จแล้วไปยัง
$management-talkโดยไม่ลดทอน engineering record ต้นฉบับ
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.