[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SAPBW598XTRMB3YRKQXNG":3,"skill-same:01M71SAPBW598XTRMB3YRKQXNG":85},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M71SAPBW598XTRMB3YRKQXNG","postmortem-writing",null,"Author blameless incident postmortems — timeline, root cause(s), contributing factors, action items","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fpostmortem-writing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"postmortem","postmortem writing","writing","root","data loss","timeline","Production","production incident","author","use","root cause","event","security","data","action","action items","contributing","incident","regression","near","2026-11-10 13:02:02",false,"---\nname: postmortem-writing\ndescription: Author blameless incident postmortems — timeline, root cause(s), contributing factors, action items\nwhen_to_use: Use after a production incident (outage, data loss, security event, regression) or a near-miss.\n---\n\n# Postmortem\n\n> **Defer to `orc-doc-writing`** for the shared scaffolding: the doc-type map (postmortem vs PRD\u002FTRD\u002FRFC\u002FADR, and how it differs from `systematic-debugging`), the shared section outline, the publication & numbering convention, and the review gates. This skill carries only the postmortem-specific template, blameless rules, and tone. Note: postmortems are date-keyed, not monotonically numbered (see the publication note in `orc-doc-writing`).\n\nA postmortem is the artifact that turns an incident into organizational learning. The fix lands in code; the postmortem lands in the team's collective memory.\n\n## When to write one\n\nWrite one for:\n\n- Any **customer-visible** incident (degraded service, errors, data loss, security event).\n- Any incident that triggered an **on-call page**, regardless of customer impact.\n- **Near-misses** caught before customer impact but caused by a real defect (a manual override, last-minute deploy revert, etc.).\n- **Recurring incidents** of the same kind — even if individually minor, the recurrence itself is the incident.\n\nDon't write a full postmortem for:\n- Bugs caught in QA or by a pre-deploy CI signal\n- Performance regressions that were rolled back within the same deploy window with no production impact\n- Single-engineer \"oops\" caught by a teammate's review — the review was the safety net working\n\n## Blameless framing (non-negotiable)\n\nA postmortem is **blameless**: it documents what *the system* (people + tools + processes) allowed to happen, not what an individual did wrong. This rule has three concrete consequences:\n\n1. **Use roles, not names** in the timeline and root-cause sections. \"The deploying engineer\" — not \"Alice.\" Names are fine in the *Contributors* header (people who took action during\u002Fafter) but not in causal language.\n2. **Replace \"human error\" with the system question.** \"The engineer ran the wrong command\" → \"The deploy tool accepts a one-letter flag that's easily confused with another.\" The action item is on the tool, not on the engineer.\n3. **No hindsight bias.** What was knowable to the responder *at the moment*? \"They should have noticed X\" is bias unless X was actually visible on a dashboard they were looking at.\n\nIf you find yourself writing \"should have\", stop and reframe.\n\n## Where they live\n\n`docs\u002Fpostmortems\u002FYYYY-MM-DD-\u003Cshort-slug>.md`. Good for engineering-team-only postmortems; mirror to a shared doc tool (Notion, Confluence, Google Doc) when leadership, support, or non-engineering stakeholders need read access. For orc projects, default to in-repo (see the publication note in `orc-doc-writing`).\n\n## Template\n\nRead [TEMPLATE.md](references\u002FTEMPLATE.md) when drafting (step 4): header block (severity, status, start\u002Fend, duration, impact, contributors), Summary, Timeline table with sources, What happened, Root cause(s) with why-chains, Contributing factors, What went well \u002F poorly, Action items checklist (owner, P0–P2, tracking, done-when), Lessons.\n\n## Severity definitions (project-dependent)\n\nIf the project doesn't have these defined, propose a minimal three-tier scheme during the postmortem and note that the definitions need an ADR\u002Fpolicy doc:\n\n- **SEV-1** — Total outage or material customer harm (data loss, security breach). Pages everyone.\n- **SEV-2** — Partial outage or significant degradation. Pages the on-call.\n- **SEV-3** — Edge-case impact, recoverable by user, or near-miss. Doesn't page; still gets a postmortem if it's a real defect.\n\n## Process discipline\n\n1. **Write within 48 hours.** Memory fades fast and so do the relevant chat\u002Flog transcripts.\n2. **Draft alone, then circulate.** Same as RFC — opinionated draft sharpens the discussion.\n3. **Action items are the deliverable.** A postmortem with a great narrative and no action items has failed. A postmortem with three concrete action items and a sloppy narrative is succeeding.\n4. **Track action items in the same tracker as feature work.** They die in a separate \"tech debt\" board.\n5. **Status: Final ≠ done.** Mark \"Action items in flight\" while items are open. Move to Final only when all P0 items are closed (or explicitly punted with rationale).\n\n## What to do as the model\n\n1. Confirm there was a real incident worth documenting. If borderline (caught in CI, no production impact), suggest a shorter \"near-miss note\" instead.\n2. Establish severity with the user (or propose a tier and confirm).\n3. Build the timeline first — go to the chat transcript \u002F pager \u002F logs and lift events with timestamps. Don't paraphrase from memory.\n4. Draft with the template. Fill each section. Use roles not names in causal language.\n5. Surface the draft for the user to fill in any organizational context the model can't see (who decided what, what tools were used).\n6. After acceptance, file the action items as tracker issues — don't leave them in the document only.\n\n## Anti-patterns to refuse\n\n- A postmortem that names a single individual as the cause.\n- \"We were on a tight deadline\" without action items on the deadline-setting process.\n- Action items of the form \"everyone be more careful.\"\n- Postmortems written by the implicated engineer alone.\n- Treating the postmortem as published when it's still missing the tracker links for action items.\n","# Postmortem\n\n> **Defer to `orc-doc-writing`** for the shared scaffolding: the doc-type map (postmortem vs PRD\u002FTRD\u002FRFC\u002FADR, and how it differs from `systematic-debugging`), the shared section outline, the publication & numbering convention, and the review gates. This skill carries only the postmortem-specific template, blameless rules, and tone. Note: postmortems are date-keyed, not monotonically numbered (see the publication note in `orc-doc-writing`).\n\nA postmortem is the artifact that turns an incident into organizational learning. The fix lands in code; the postmortem lands in the team's collective memory.\n\n## When to write one\n\nWrite one for:\n\n- Any **customer-visible** incident (degraded service, errors, data loss, security event).\n- Any incident that triggered an **on-call page**, regardless of customer impact.\n- **Near-misses** caught before customer impact but caused by a real defect (a manual override, last-minute deploy revert, etc.).\n- **Recurring incidents** of the same kind — even if individually minor, the recurrence itself is the incident.\n\nDon't write a full postmortem for:\n- Bugs caught in QA or by a pre-deploy CI signal\n- Performance regressions that were rolled back within the same deploy window with no production impact\n- Single-engineer \"oops\" caught by a teammate's review — the review was the safety net working\n\n## Blameless framing (non-negotiable)\n\nA postmortem is **blameless**: it documents what *the system* (people + tools + processes) allowed to happen, not what an individual did wrong. This rule has three concrete consequences:\n\n1. **Use roles, not names** in the timeline and root-cause sections. \"The deploying engineer\" — not \"Alice.\" Names are fine in the *Contributors* header (people who took action during\u002Fafter) but not in causal language.\n2. **Replace \"human error\" with the system question.** \"The engineer ran the wrong command\" → \"The deploy tool accepts a one-letter flag that's easily confused with another.\" The action item is on the tool, not on the engineer.\n3. **No hindsight bias.** What was knowable to the responder *at the moment*? \"They should have noticed X\" is bias unless X was actually visible on a dashboard they were looking at.\n\nIf you find yourself writing \"should have\", stop and reframe.\n\n## Where they live\n\n`docs\u002Fpostmortems\u002FYYYY-MM-DD-\u003Cshort-slug>.md`. Good for engineering-team-only postmortems; mirror to a shared doc tool (Notion, Confluence, Google Doc) when leadership, support, or non-engineering stakeholders need read access. For orc projects, default to in-repo (see the publication note in `orc-doc-writing`).\n\n## Template\n\nRead [TEMPLATE.md](references\u002FTEMPLATE.md) when drafting (step 4): header block (severity, status, start\u002Fend, duration, impact, contributors), Summary, Timeline table with sources, What happened, Root cause(s) with why-chains, Contributing factors, What went well \u002F poorly, Action items checklist (owner, P0–P2, tracking, done-when), Lessons.\n\n## Severity definitions (project-dependent)\n\nIf the project doesn't have these defined, propose a minimal three-tier scheme during the postmortem and note that the definitions need an ADR\u002Fpolicy doc:\n\n- **SEV-1** — Total outage or material customer harm (data loss, security breach). Pages everyone.\n- **SEV-2** — Partial outage or significant degradation. Pages the on-call.\n- **SEV-3** — Edge-case impact, recoverable by user, or near-miss. Doesn't page; still gets a postmortem if it's a real defect.\n\n## Process discipline\n\n1. **Write within 48 hours.** Memory fades fast and so do the relevant chat\u002Flog transcripts.\n2. **Draft alone, then circulate.** Same as RFC — opinionated draft sharpens the discussion.\n3. **Action items are the deliverable.** A postmortem with a great narrative and no action items has failed. A postmortem with three concrete action items and a sloppy narrative is succeeding.\n4. **Track action items in the same tracker as feature work.** They die in a separate \"tech debt\" board.\n5. **Status: Final ≠ done.** Mark \"Action items in flight\" while items are open. Move to Final only when all P0 items are closed (or explicitly punted with rationale).\n\n## What to do as the model\n\n1. Confirm there was a real incident worth documenting. If borderline (caught in CI, no production impact), suggest a shorter \"near-miss note\" instead.\n2. Establish severity with the user (or propose a tier and confirm).\n3. Build the timeline first — go to the chat transcript \u002F pager \u002F logs and lift events with timestamps. Don't paraphrase from memory.\n4. Draft with the template. Fill each section. Use roles not names in causal language.\n5. Surface the draft for the user to fill in any organizational context the model can't see (who decided what, what tools were used).\n6. After acceptance, file the action items as tracker issues — don't leave them in the document only.\n\n## Anti-patterns to refuse\n\n- A postmortem that names a single individual as the cause.\n- \"We were on a tight deadline\" without action items on the deadline-setting process.\n- Action items of the form \"everyone be more careful.\"\n- Postmortems written by the implicated engineer alone.\n- Treating the postmortem as published when it's still missing the tracker links for action items.\n",{"name":5,"description":7,"when_to_use":54},"Use after a production incident (outage, data loss, security event, regression) or a near-miss.","main","7522fd7266944e30052204c2f6df287d8b5516be","codex\u002Forc\u002Fcontent\u002Fskills\u002Fpostmortem-writing",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-14 07:24:14",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add HigorAlves\u002Forc --skill postmortem-writing",{"tool":71,"command":72},"bunx","bunx skills add HigorAlves\u002Forc --skill postmortem-writing",{"tool":74,"command":75},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill postmortem-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fpostmortem-writing\u002FSKILL.md",true,[79],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002FTEMPLATE.md","REFERENCE","参考文档",3674,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fpostmortem-writing\u002Freferences\u002FTEMPLATE.md",[86,94,124,150,171,193],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":93},"01M73VYZ3XY4HAVS3WS73CW9J7","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":105,"publishedAt":49},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[100,101,104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[31,106,107,38,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123],"writing plans","plans","code","tests","for","ZeRO","context","steps","write","plan","verification","tasks","you","when","files","implementation plan","superpowers","engineer",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":135,"publishedAt":49},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[130,131,134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[31,136,110,137,138,38,139,140,141,142,143,144,119,145,146,147,148,149],"writing for agents","a skill","document","editing","push","doctrine","layer","tuning","inline","matt pocock","github","docs","reference","https",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":157,"publishedAt":49},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[156],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[158,159,160,161,162,163,38,164,165,166,167,119,168,169,170],"workspace mode","mode","workspace","auto-detection","detection","parent","repo","pr","git","repos","auto","mechanics","dispatch",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":49},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[177],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[173,119,145,179,180,181,182,183,38,184,185,110,186,187,113,188,189,190,191,192],"only","provisioning infrastructure","never","condition","Bash","interactive","one","do","infrastructure","secrets","human","generate","credentials","work",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":49},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[200,201,149,202,203,204,205,146,206,207,208,209,145,210,211,212],"wait","wait what","vocabulary","stop","it","land","message","say","last","pitch","true","re","project"]