[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JJS1RY9FBZK663RY05GJ8T":3,"skill-same:01M6JJS1RY9FBZK663RY05GJ8T":68},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6JJS1RY9FBZK663RY05GJ8T","cpostmortem",null,"Post-merge bug analysis. Use when a bug escapes to production. Traces which phase missed it and strengthens the workflow.","joshft\u002Fcorrectless","joshft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2847920?v=4","01M6JJGJ1WCYFH1BKGPZJ0Z4YD","josh","01M6JJGJ69XYFA6MTDXSH5BG42",66,"MIT","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcpostmortem\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"use","which","invariants","antipatterns","token","missed","bug analysis","bug","log","workflow","edit","write","read","Bash","analysis","Meta","git","architecture","merge","2026-11-10 10:12:30",false,"---\nname: cpostmortem\ndescription: Post-merge bug analysis. Use when a bug escapes to production. Traces which phase missed it and strengthens the workflow.\nallowed-tools: Read, Grep, Glob, Bash(git*), Edit, Write(.correctless\u002Fmeta\u002F*), Write(.correctless\u002Fantipatterns.md), Write(.claude\u002Ftemplates\u002Finvariants\u002F*), Write(.correctless\u002Fartifacts\u002Ftoken-log-*), Write(CLAUDE.md), Write(.correctless\u002FARCHITECTURE.md)\ncontext: fork\ninteraction_mode: hybrid\n---\n\n# \u002Fcpostmortem — Post-Merge Bug Analysis\n\n> **Shared constraints apply.** Before executing, read `_shared\u002Fconstraints.md` from the parent of this skill's base directory. All constraints there apply to this skill.\n\n## Intensity Gate\n\nThis skill requires effective intensity `standard` or above (available to all projects). Compute effective intensity using the procedure in the shared constraints (`_shared\u002Fconstraints.md`).\n\n**Intensity threshold**: \u002Fcpostmortem activates at standard minimum intensity (available to all).\n\n- If the effective intensity is below the required intensity, print an informational message:\n  - Skill name: \u002Fcpostmortem\n  - Required intensity: standard\n  - Effective intensity: (computed above)\n  - Override: pass `--force` to override the intensity gate, or set `workflow.intensity` to `standard` or above in `.correctless\u002Fconfig\u002Fworkflow-config.json`\n  - Then **do not proceed** with the skill body. Stop here.\n- If the effective intensity is at or above the threshold, or if the user passed `--force`, proceed normally — skip the gate entirely, no gate output.\n\nYou are the postmortem agent. A bug was found in merged code. Your job is to analyze why the workflow missed it and strengthen the workflow so it doesn't miss similar bugs in the future.\n\n**You do NOT fix the bug.** Fixing is a separate `\u002Fctdd` cycle. You analyze and improve the process.\n\n## Progress Visibility (MANDATORY)\n\nPostmortem analysis takes 5-10 minutes. The user must see progress throughout.\n\n**Before starting**, create a task list:\n1. Read bug report and gather facts\n2. Trace to spec\u002Freview\u002FQA gap\n3. Determine class fix (antipattern, template update, structural test)\n4. Write PMB entry\n5. Update phase effectiveness\n6. Present corrective actions to human\n\n**Between each step**, print a 1-line status: \"Facts gathered — {severity} bug in {feature}. Tracing which phase missed it...\" and \"Gap identified — {phase} should have caught this. Determining class fix...\"\n\nMark each task complete as it finishes.\n\n## Before You Start\n\n1. Read `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` for existing bug history.\n2. Read `.correctless\u002Fantipatterns.md` to check if this bug class is already tracked.\n3. Identify the spec artifact for the feature. If the feature has an active workflow, read the path from `workflow-advance.sh status`. If no active workflow exists (post-merge postmortem), search `.correctless\u002Fspecs\u002F` by slug.\n4. Read the verification report at `.correctless\u002Fverification\u002F{task-slug}-verification.md` (if it exists).\n5. Read `.correctless\u002Fartifacts\u002Fdebug-investigation-*.md` if any exist — prior `\u002Fcdebug` investigations provide root cause context for understanding how the bug was missed.\n\n## Behavior\n\n### Step 1: Gather the Facts\n\nAsk the human (batch where appropriate):\n- What broke? (description, how discovered)\n- What's the severity? (critical \u002F high \u002F medium \u002F low)\n- Which feature introduced it? (spec slug, if known)\n- Was the workflow run? Which phases were executed?\n\n### Step 2: Analyze the Miss\n\nRead the spec (path from step 3) and verification report at `.correctless\u002Fverification\u002F{task-slug}-verification.md` (if they exist):\n- Did a spec invariant cover this bug class? If yes, why didn't the test catch it?\n- If no invariant covered it, should one have existed? Which category?\n- Which workflow phase should have caught this? (spec, review\u002Freview-spec, tdd-qa, tdd-verify\u002Fcverify, audit)\n- Was that phase skipped? If so, would running it have caught the bug?\n- If the phase ran and still missed it, why?\n\n### Step 3: Determine Corrective Action\n\n**Every corrective action must be a class fix, not an instance fix.** The question is never \"how do we fix this bug?\" — the implementation team handles that. The question is \"how do we make this class of bug structurally impossible to recur?\"\n\n> **Design Contract Checker lens convention:** if this PMB's corrective action documents a new `\u002Fcreview-spec` Design Contract Checker lens, it must also add a registry row to `agents\u002Fdesign-contract-lenses.tsv` (the single source of truth) and a matching bullet in `agents\u002Freview-spec-design-contract.md` — otherwise the documented lens never reaches the enforcer (the AP-036 gap). Do not leave the lens as prose only.\n\nIf a QA round found and fixed a specific instance of this bug but the bug recurred in a later feature, the original QA corrective action was too narrow. The postmortem must identify what the class fix should have been and implement it now.\n\nFor each miss, propose one or more of:\n\n**New antipattern**: draft an AP-xxx entry. Present to human for approval. The antipattern must describe the *class* of bug, not the specific instance (e.g., \"config struct parsed but not wired to handler\" not \"SignalFusionConfig missing SetSignalFusionConfig call\").\n\n**Structural test**: a test that catches ALL current and future instances of this bug class automatically. For example: a reflection-based test that enumerates all config sub-structs and verifies each has wiring. This is the highest-value corrective action — it turns a process problem into an automated check.\n\n**Invariant template update**: if a template should catch this bug class (e.g., config-lifecycle template should require wiring verification tests), draft the addition. This ensures all future specs that touch this domain include the right rules.\n\n**Spec update**: if the original spec should have had an invariant for this, draft it as a reference for future specs.\n\n**Drift debt**: if the bug reveals untracked architectural drift, create a DRIFT-xxx entry.\n\n#### Antipattern Promotion Check\n\nAfter creating or updating an AP-xxx entry, check whether the antipattern's Frequency field now indicates 3 or more features (parsed from \"N findings across M features\" format). If an entry has a missing Frequency field or malformed Frequency value, skip the promotion check — no error.\n\nPrefer entries that have just crossed the threshold (frequency newly meets the 3-feature mark due to this postmortem) over entries that already met the threshold before this postmortem. This cross-threshold preference ensures promotion fires at the most relevant moment.\n\nIf the frequency meets the threshold and the AP-xxx is NOT already referenced in `.correctless\u002FARCHITECTURE.md` (promotion deduplication — search for the literal `AP-xxx` string in `.correctless\u002FARCHITECTURE.md`; if found, skip), draft a promotion suggestion:\n\n- Draft a PAT-xxx or ABS-xxx skeleton (PAT-xxx for process patterns, ABS-xxx for code invariants)\n- Use \"How to catch it\" from the antipattern to pre-populate the Rule\u002FInvariant field\n- Use \"What went wrong\" from the antipattern to inform the Violated-when field\n- Include a `Guards against: AP-xxx` field referencing the antipattern ID\n- Include a Test field describing how the architectural entry would be verified\n\nPresent the promotion suggestion as a structured decision:\n1. Add to `.correctless\u002FARCHITECTURE.md` (recommended) — write the drafted PAT-xxx or ABS-xxx entry\n2. Skip — this antipattern doesn't warrant an architecture entry\n3. Modify the draft before adding\n4. Defer to a future feature\n\nOr type your own: ___ (promotion decisions require explicit human input)\n\nThe human must approve before writing to `.correctless\u002FARCHITECTURE.md` — never auto-write.\n\n### Step 4: Write the PMB Entry\n\nRead `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` first. Append the new PMB entry to the `post_merge_bugs` array. Use `Edit` to add the entry — do NOT overwrite the file. Use the next sequential PMB-NNN ID.\n\nEntry format:\n\n```json\n{\n  \"id\": \"PMB-{NNN}\",  \u002F\u002F Use next sequential number from existing entries\n  \"date\": \"ISO date\",\n  \"description\": \"what broke\",\n  \"severity\": \"high\",\n  \"found_by\": \"how discovered\",\n  \"root_cause\": \"technical root cause\",\n  \"spec_existed\": true,\n  \"spec_id\": \"feature-slug\",\n  \"invariant_existed\": false,\n  \"invariant_id\": null,\n  \"phase_that_should_have_caught\": \"tdd-qa\",\n  \"phase_was_skipped\": false,\n  \"why_missed\": \"explanation\",\n  \"corrective_action\": {\n    \"antipattern_added\": true,\n    \"antipattern_id\": \"AP-xxx\",\n    \"invariant_template_updated\": false,\n    \"template\": null,\n    \"addition\": null,\n    \"drift_debt_created\": false\n  }\n}\n```\n\n### Step 5: Update Phase Effectiveness\n\nIncrement counters in `phase_effectiveness` for the relevant phase. Note patterns (e.g., \"tdd-qa has missed 5 goroutine lifecycle bugs\").\n\n### Step 6: Append Learning to CLAUDE.md\n\nAfter writing the PMB entry and antipattern, append a learning to the `## Correctless Learnings` section of `CLAUDE.md`:\n\n```markdown\n### {date} — Postmortem: {1-line bug description}\n- {key learning — what future agents should do differently}\n- Source: PMB-{N}\n```\n\nBefore appending, read the existing Correctless Learnings section. If an entry with the same PMB-N already exists, skip (deduplication). If the `## Correctless Learnings` section doesn't exist in CLAUDE.md, create it with the header before appending.\n\nThis learning is loaded into every future session. The spec agent, review agent, and QA agent will all benefit from knowing what escaped testing in the past.\n\n## Claude Code Feature Integration\n\n### Task Lists\nSee \"Progress Visibility\" section above — task creation and narration are mandatory.\n\n### Token Tracking\n\nLog token usage following the shared constraints (`_shared\u002Fconstraints.md`). Skill-specific values:\n- `skill`: \"cpostmortem\"\n- `phase`: \"analysis\"\n- `agent_role`: \"analysis-agent\"\n\n### \u002Fexport\nAfter postmortem completes: \"Export this postmortem conversation: `\u002Fexport .correctless\u002Fdecisions\u002F{task-slug}-postmortem.md` — captures the full analysis of why the workflow missed this bug.\"\n\n## Autonomous Defaults\n\nWhen running in autonomous mode (`mode: autonomous` in prompt context), use these defaults instead of pausing for human input.\nWhen dispatched by `\u002Fcauto`, return autonomous decisions in the `AUTONOMOUS_DECISIONS_START`\u002F`AUTONOMOUS_DECISIONS_END` format provided in the task prompt.\n\n**Deferred escalation (R-011)**: This skill has `context: fork` and cannot receive human follow-up input. When an `escalate: always` decision point is reached in autonomous mode, the default is applied and the decision is returned with `escalation_deferred: true` and `original_escalation_reason` for human review at pipeline conclusion.\n\n- **AD-001**: Investigation scope — full root cause analysis (default). Rationale: partial investigation risks missing the class of bug behind the instance.\n- **AD-002**: Corrective action classification — apply standard AP\u002FPMB taxonomy (default). Rationale: consistent taxonomy enables cross-postmortem pattern detection.\n- **AD-003**: Corrective action approval — `escalate: always`. Default if deferred: propose but do not apply. Rationale: corrective actions create new antipattern entries and architectural constraints.\n\n## If Something Goes Wrong\n\n- **Skill interrupted**: Re-run `\u002Fcpostmortem`. It reads the bug report and workflow artifacts each time — no state to corrupt.\n- **Rate limit hit**: Wait 2-3 minutes and re-run.\n- **Wrong analysis**: The postmortem writes to antipatterns.md and workflow-effectiveness.json via Edit (append). If the analysis was wrong, edit those files to remove the incorrect entries.\n\n## Constraints\n\n- Every postmortem MUST produce at least one corrective action.\n- **Every corrective action must be a class fix.** \"Add the missing wiring call\" is an instance fix, not a corrective action. \"Add a structural test that fails when any sub-struct lacks wiring\" is a class fix. If you can only identify an instance fix, that means the analysis isn't done — dig deeper.\n- If the analysis concludes \"this was unpreventable,\" push back — ask whether a structural test, a template update, or a different test approach would have caught it. The human must explicitly confirm.\n- If a bug recurred after a previous QA round found and fixed a single instance, the postmortem MUST flag that the original QA corrective action was too narrow and specify what the class fix should have been.\n- Do NOT fix the bug. Analysis and process improvement only.\n","# \u002Fcpostmortem — Post-Merge Bug Analysis\n\n> **Shared constraints apply.** Before executing, read `_shared\u002Fconstraints.md` from the parent of this skill's base directory. All constraints there apply to this skill.\n\n## Intensity Gate\n\nThis skill requires effective intensity `standard` or above (available to all projects). Compute effective intensity using the procedure in the shared constraints (`_shared\u002Fconstraints.md`).\n\n**Intensity threshold**: \u002Fcpostmortem activates at standard minimum intensity (available to all).\n\n- If the effective intensity is below the required intensity, print an informational message:\n  - Skill name: \u002Fcpostmortem\n  - Required intensity: standard\n  - Effective intensity: (computed above)\n  - Override: pass `--force` to override the intensity gate, or set `workflow.intensity` to `standard` or above in `.correctless\u002Fconfig\u002Fworkflow-config.json`\n  - Then **do not proceed** with the skill body. Stop here.\n- If the effective intensity is at or above the threshold, or if the user passed `--force`, proceed normally — skip the gate entirely, no gate output.\n\nYou are the postmortem agent. A bug was found in merged code. Your job is to analyze why the workflow missed it and strengthen the workflow so it doesn't miss similar bugs in the future.\n\n**You do NOT fix the bug.** Fixing is a separate `\u002Fctdd` cycle. You analyze and improve the process.\n\n## Progress Visibility (MANDATORY)\n\nPostmortem analysis takes 5-10 minutes. The user must see progress throughout.\n\n**Before starting**, create a task list:\n1. Read bug report and gather facts\n2. Trace to spec\u002Freview\u002FQA gap\n3. Determine class fix (antipattern, template update, structural test)\n4. Write PMB entry\n5. Update phase effectiveness\n6. Present corrective actions to human\n\n**Between each step**, print a 1-line status: \"Facts gathered — {severity} bug in {feature}. Tracing which phase missed it...\" and \"Gap identified — {phase} should have caught this. Determining class fix...\"\n\nMark each task complete as it finishes.\n\n## Before You Start\n\n1. Read `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` for existing bug history.\n2. Read `.correctless\u002Fantipatterns.md` to check if this bug class is already tracked.\n3. Identify the spec artifact for the feature. If the feature has an active workflow, read the path from `workflow-advance.sh status`. If no active workflow exists (post-merge postmortem), search `.correctless\u002Fspecs\u002F` by slug.\n4. Read the verification report at `.correctless\u002Fverification\u002F{task-slug}-verification.md` (if it exists).\n5. Read `.correctless\u002Fartifacts\u002Fdebug-investigation-*.md` if any exist — prior `\u002Fcdebug` investigations provide root cause context for understanding how the bug was missed.\n\n## Behavior\n\n### Step 1: Gather the Facts\n\nAsk the human (batch where appropriate):\n- What broke? (description, how discovered)\n- What's the severity? (critical \u002F high \u002F medium \u002F low)\n- Which feature introduced it? (spec slug, if known)\n- Was the workflow run? Which phases were executed?\n\n### Step 2: Analyze the Miss\n\nRead the spec (path from step 3) and verification report at `.correctless\u002Fverification\u002F{task-slug}-verification.md` (if they exist):\n- Did a spec invariant cover this bug class? If yes, why didn't the test catch it?\n- If no invariant covered it, should one have existed? Which category?\n- Which workflow phase should have caught this? (spec, review\u002Freview-spec, tdd-qa, tdd-verify\u002Fcverify, audit)\n- Was that phase skipped? If so, would running it have caught the bug?\n- If the phase ran and still missed it, why?\n\n### Step 3: Determine Corrective Action\n\n**Every corrective action must be a class fix, not an instance fix.** The question is never \"how do we fix this bug?\" — the implementation team handles that. The question is \"how do we make this class of bug structurally impossible to recur?\"\n\n> **Design Contract Checker lens convention:** if this PMB's corrective action documents a new `\u002Fcreview-spec` Design Contract Checker lens, it must also add a registry row to `agents\u002Fdesign-contract-lenses.tsv` (the single source of truth) and a matching bullet in `agents\u002Freview-spec-design-contract.md` — otherwise the documented lens never reaches the enforcer (the AP-036 gap). Do not leave the lens as prose only.\n\nIf a QA round found and fixed a specific instance of this bug but the bug recurred in a later feature, the original QA corrective action was too narrow. The postmortem must identify what the class fix should have been and implement it now.\n\nFor each miss, propose one or more of:\n\n**New antipattern**: draft an AP-xxx entry. Present to human for approval. The antipattern must describe the *class* of bug, not the specific instance (e.g., \"config struct parsed but not wired to handler\" not \"SignalFusionConfig missing SetSignalFusionConfig call\").\n\n**Structural test**: a test that catches ALL current and future instances of this bug class automatically. For example: a reflection-based test that enumerates all config sub-structs and verifies each has wiring. This is the highest-value corrective action — it turns a process problem into an automated check.\n\n**Invariant template update**: if a template should catch this bug class (e.g., config-lifecycle template should require wiring verification tests), draft the addition. This ensures all future specs that touch this domain include the right rules.\n\n**Spec update**: if the original spec should have had an invariant for this, draft it as a reference for future specs.\n\n**Drift debt**: if the bug reveals untracked architectural drift, create a DRIFT-xxx entry.\n\n#### Antipattern Promotion Check\n\nAfter creating or updating an AP-xxx entry, check whether the antipattern's Frequency field now indicates 3 or more features (parsed from \"N findings across M features\" format). If an entry has a missing Frequency field or malformed Frequency value, skip the promotion check — no error.\n\nPrefer entries that have just crossed the threshold (frequency newly meets the 3-feature mark due to this postmortem) over entries that already met the threshold before this postmortem. This cross-threshold preference ensures promotion fires at the most relevant moment.\n\nIf the frequency meets the threshold and the AP-xxx is NOT already referenced in `.correctless\u002FARCHITECTURE.md` (promotion deduplication — search for the literal `AP-xxx` string in `.correctless\u002FARCHITECTURE.md`; if found, skip), draft a promotion suggestion:\n\n- Draft a PAT-xxx or ABS-xxx skeleton (PAT-xxx for process patterns, ABS-xxx for code invariants)\n- Use \"How to catch it\" from the antipattern to pre-populate the Rule\u002FInvariant field\n- Use \"What went wrong\" from the antipattern to inform the Violated-when field\n- Include a `Guards against: AP-xxx` field referencing the antipattern ID\n- Include a Test field describing how the architectural entry would be verified\n\nPresent the promotion suggestion as a structured decision:\n1. Add to `.correctless\u002FARCHITECTURE.md` (recommended) — write the drafted PAT-xxx or ABS-xxx entry\n2. Skip — this antipattern doesn't warrant an architecture entry\n3. Modify the draft before adding\n4. Defer to a future feature\n\nOr type your own: ___ (promotion decisions require explicit human input)\n\nThe human must approve before writing to `.correctless\u002FARCHITECTURE.md` — never auto-write.\n\n### Step 4: Write the PMB Entry\n\nRead `.correctless\u002Fmeta\u002Fworkflow-effectiveness.json` first. Append the new PMB entry to the `post_merge_bugs` array. Use `Edit` to add the entry — do NOT overwrite the file. Use the next sequential PMB-NNN ID.\n\nEntry format:\n\n```json\n{\n  \"id\": \"PMB-{NNN}\",  \u002F\u002F Use next sequential number from existing entries\n  \"date\": \"ISO date\",\n  \"description\": \"what broke\",\n  \"severity\": \"high\",\n  \"found_by\": \"how discovered\",\n  \"root_cause\": \"technical root cause\",\n  \"spec_existed\": true,\n  \"spec_id\": \"feature-slug\",\n  \"invariant_existed\": false,\n  \"invariant_id\": null,\n  \"phase_that_should_have_caught\": \"tdd-qa\",\n  \"phase_was_skipped\": false,\n  \"why_missed\": \"explanation\",\n  \"corrective_action\": {\n    \"antipattern_added\": true,\n    \"antipattern_id\": \"AP-xxx\",\n    \"invariant_template_updated\": false,\n    \"template\": null,\n    \"addition\": null,\n    \"drift_debt_created\": false\n  }\n}\n```\n\n### Step 5: Update Phase Effectiveness\n\nIncrement counters in `phase_effectiveness` for the relevant phase. Note patterns (e.g., \"tdd-qa has missed 5 goroutine lifecycle bugs\").\n\n### Step 6: Append Learning to CLAUDE.md\n\nAfter writing the PMB entry and antipattern, append a learning to the `## Correctless Learnings` section of `CLAUDE.md`:\n\n```markdown\n### {date} — Postmortem: {1-line bug description}\n- {key learning — what future agents should do differently}\n- Source: PMB-{N}\n```\n\nBefore appending, read the existing Correctless Learnings section. If an entry with the same PMB-N already exists, skip (deduplication). If the `## Correctless Learnings` section doesn't exist in CLAUDE.md, create it with the header before appending.\n\nThis learning is loaded into every future session. The spec agent, review agent, and QA agent will all benefit from knowing what escaped testing in the past.\n\n## Claude Code Feature Integration\n\n### Task Lists\nSee \"Progress Visibility\" section above — task creation and narration are mandatory.\n\n### Token Tracking\n\nLog token usage following the shared constraints (`_shared\u002Fconstraints.md`). Skill-specific values:\n- `skill`: \"cpostmortem\"\n- `phase`: \"analysis\"\n- `agent_role`: \"analysis-agent\"\n\n### \u002Fexport\nAfter postmortem completes: \"Export this postmortem conversation: `\u002Fexport .correctless\u002Fdecisions\u002F{task-slug}-postmortem.md` — captures the full analysis of why the workflow missed this bug.\"\n\n## Autonomous Defaults\n\nWhen running in autonomous mode (`mode: autonomous` in prompt context), use these defaults instead of pausing for human input.\nWhen dispatched by `\u002Fcauto`, return autonomous decisions in the `AUTONOMOUS_DECISIONS_START`\u002F`AUTONOMOUS_DECISIONS_END` format provided in the task prompt.\n\n**Deferred escalation (R-011)**: This skill has `context: fork` and cannot receive human follow-up input. When an `escalate: always` decision point is reached in autonomous mode, the default is applied and the decision is returned with `escalation_deferred: true` and `original_escalation_reason` for human review at pipeline conclusion.\n\n- **AD-001**: Investigation scope — full root cause analysis (default). Rationale: partial investigation risks missing the class of bug behind the instance.\n- **AD-002**: Corrective action classification — apply standard AP\u002FPMB taxonomy (default). Rationale: consistent taxonomy enables cross-postmortem pattern detection.\n- **AD-003**: Corrective action approval — `escalate: always`. Default if deferred: propose but do not apply. Rationale: corrective actions create new antipattern entries and architectural constraints.\n\n## If Something Goes Wrong\n\n- **Skill interrupted**: Re-run `\u002Fcpostmortem`. It reads the bug report and workflow artifacts each time — no state to corrupt.\n- **Rate limit hit**: Wait 2-3 minutes and re-run.\n- **Wrong analysis**: The postmortem writes to antipatterns.md and workflow-effectiveness.json via Edit (append). If the analysis was wrong, edit those files to remove the incorrect entries.\n\n## Constraints\n\n- Every postmortem MUST produce at least one corrective action.\n- **Every corrective action must be a class fix.** \"Add the missing wiring call\" is an instance fix, not a corrective action. \"Add a structural test that fails when any sub-struct lacks wiring\" is a class fix. If you can only identify an instance fix, that means the analysis isn't done — dig deeper.\n- If the analysis concludes \"this was unpreventable,\" push back — ask whether a structural test, a template update, or a different test approach would have caught it. The human must explicitly confirm.\n- If a bug recurred after a previous QA round found and fixed a single instance, the postmortem MUST flag that the original QA corrective action was too narrow and specify what the class fix should have been.\n- Do NOT fix the bug. Analysis and process improvement only.\n",{"name":5,"context":43,"description":7,"allowed-tools":44,"interaction_mode":45},"fork","Read, Grep, Glob, Bash(git*), Edit, Write(.correctless\u002Fmeta\u002F*), Write(.correctless\u002Fantipatterns.md), Write(.claude\u002Ftemplates\u002Finvariants\u002F*), Write(.correctless\u002Fartifacts\u002Ftoken-log-*), Write(CLAUDE.md), Write(.correctless\u002FARCHITECTURE.md)","hybrid","main","74f9ef3f5acae9c857f6be6dd86cdc3b10830c90","skills\u002Fcpostmortem",4,"https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless","https:\u002F\u002Fjoshft.github.io\u002Fcorrectless\u002F","https:\u002F\u002Fgithub.com\u002Fjoshft","2026-11-07 02:53:35",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add joshft\u002Fcorrectless --skill cpostmortem",{"tool":60,"command":61},"bunx","bunx skills add joshft\u002Fcorrectless --skill cpostmortem",{"tool":63,"command":64},"pnpm","pnpm dlx skills add joshft\u002Fcorrectless --skill cpostmortem","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcpostmortem\u002FSKILL.md",true,[],[69,92,115,133,150,164],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":38},"01M6JJW224Q40TCVMTKRZPDHDY","cwtf","Audit the workflow itself. Use when you suspect agents shortcut or after a bug escapes despite the workflow running. Checks phase execution, rule coverage, and agent thoroughness.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcwtf\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[71,28,35,81,82,83,32,84,85,86,31,30,29,87,88,19,89,26,90,91],"artifacts","audit","execution","grep","find","jq","coverage","autonomous","wtf","you","shortcut",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":104,"publishedAt":38},"01M6JJVT9M4KGWQ99V0CSF6WZ5","cverify","Verify implementation matches spec. Check rule coverage, undocumented dependencies, architecture compliance. Writes verification report and drift debt. Run after \u002Fctdd completes.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcverify\u002FSKILL.md",[98,99],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[94,105,28,36,106,35,107,34,32,31,30,29,87,108,109,110,111,112,113,114],"go","run","verification","diff","ruff","drift","verify implementation","cargo","stryker","ctdd",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":38},"01M6JJVP2E6BHHKF3SCMDXG0S2","cupdate-arch","Update .correctless\u002FARCHITECTURE.md after features land. Use after \u002Fcdocs or when the codebase structure has changed.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcupdate-arch\u002FSKILL.md",[],[122,123,124,36,125,35,126,32,127,84,31,30,29,19,128,129,130,131,132],"arch","cupdate arch","docs","update","land","Rules","structure","codebase","features","codebase structure","cdocs",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":38},"01M6JJVJVZ72KVWN1K3RWQK0YJ","ctriage","Bulk triage deferred findings backlog. Presents findings one at a time with disposition options.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fctriage\u002FSKILL.md",[],[135,140,34,32,141,84,86,142,31,30,29,143,144,145,146,147,148,149],"triage","json","one at a time","interactive","options","backlog","time","bulk","with","at",{"skillNo":151,"name":114,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":38},"01M6JJVCYCNYD4GHK33DZE9DXA","Enforced TDD workflow. Write failing tests from spec rules, then implement. Use after \u002Fcreview approves a spec.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fctdd\u002FSKILL.md",[155],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[114,157,158,159,28,81,160,32,127,84,31,30,29,19,161,162,163],"spec","implement","tdd","tdd workflow","task","tests","creview",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":38},"01M6JJV7S3EQG3GHQ56DD8P1SA","csummary","Feature summary. Use after \u002Fcdocs to see what the workflow caught, or mid-feature to check progress.","https:\u002F\u002Fgithub.com\u002Fjoshft\u002Fcorrectless\u002Fblob\u002Fmain\u002Fskills\u002Fcsummary\u002FSKILL.md",[],[166,28,35,81,32,84,171,31,30,29,88,19,172,173,174,175,132],"check","what the","summary","feature","progress"]