[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NW0KK5K22WXT1AF5X1FHTF":3,"skill-same:01M6NW0KK5K22WXT1AF5X1FHTF":61},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6NW0KK5K22WXT1AF5X1FHTF","premortem",null,"Identify failure modes before they occur using structured risk analysis","rubicanjr\u002FFinCognis","rubicanjr","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F234912519?v=4","01M6NT156NND8J474G34SB3923","Rubi","01M6NT15B70RWXE1N3YV0BZY8A",0,"MIT","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fpremortem\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26],"risk analysis","risk","analysis","grep","read","task","structured","modes","2026-11-10 10:12:30",false,"---\nname: premortem\ndescription: Identify failure modes before they occur using structured risk analysis\nallowed-tools: [Read, Grep, Glob, Task, AskUserQuestion, TodoWrite]\n---\n\n# Pre-Mortem\n\nIdentify failure modes before they occur by systematically questioning plans, designs, and implementations. Based on Gary Klein's technique, popularized by Shreyas Doshi (Stripe).\n\n## Usage\n\n```\n\u002Fpremortem              # Auto-detect context, choose depth\n\u002Fpremortem quick        # Force quick analysis (plans, PRs)\n\u002Fpremortem deep         # Force deep analysis (before implementation)\n\u002Fpremortem \u003Cfile>       # Analyze specific plan or code\n```\n\n## Core Concept\n\n> \"Imagine it's 3 months from now and this project has failed spectacularly. Why did it fail?\"\n\n## Risk Categories (Shreyas Framework)\n\n| Category | Symbol | Meaning |\n|----------|--------|---------|\n| **Tiger** | `[TIGER]` | Clear threat that will hurt us if not addressed |\n| **Paper Tiger** | `[PAPER]` | Looks threatening but probably fine |\n| **Elephant** | `[ELEPHANT]` | Thing nobody wants to talk about |\n\n## CRITICAL: Verify Before Flagging\n\n**Do NOT flag risks based on pattern-matching alone.** Every potential tiger MUST go through verification.\n\n### The False Positive Problem\n\nCommon mistakes that create false tigers:\n- Seeing a hardcoded path without checking for `if exists():` fallback\n- Finding missing feature X without asking \"is X in scope?\"\n- Flagging code at line N without reading lines N±20 for context\n- Assuming error case isn't handled without tracing the code\n\n### Verification Checklist (REQUIRED)\n\nBefore flagging ANY tiger, verify:\n\n```yaml\npotential_finding:\n  what: \"Hardcoded path at line 42\"\n\nverification:\n  context_read: true    # Did I read ±20 lines around the finding?\n  fallback_check: true  # Is there try\u002Fexcept, if exists(), or else branch?\n  scope_check: true     # Is this even in scope for this code?\n  dev_only_check: true  # Is this in __main__, tests\u002F, or dev-only code?\n\nresult: tiger | paper_tiger | false_alarm\n```\n\n**If ANY verification check is \"no\" or \"unknown\", DO NOT flag as tiger.**\n\n### Required Evidence Format\n\nEvery tiger MUST include:\n\n```yaml\ntiger:\n  risk: \"\u003Cdescription>\"\n  location: \"file.py:42\"\n  severity: high|medium\n  # REQUIRED - what mitigation was checked and NOT found:\n  mitigation_checked: \"No exists() check, no try\u002Fexcept, no fallback branch\"\n```\n\nIf you cannot fill in `mitigation_checked` with specific evidence, it's not a verified tiger.\n\n## Workflow\n\n### Step 1: Detect Context & Depth\n\n```python\n# Auto-detect based on context\nif in_plan_creation:\n    depth = \"quick\"   # Localized scope\nelif before_implementation:\n    depth = \"deep\"    # Global scope\nelif pr_review:\n    depth = \"quick\"   # Localized scope\nelse:\n    # Ask user\n    AskUserQuestion(\n        question=\"What depth of pre-mortem analysis?\",\n        header=\"Depth\",\n        options=[\n            {\"label\": \"Quick (2-3 min)\", \"description\": \"Plans, PRs, localized changes\"},\n            {\"label\": \"Deep (5-10 min)\", \"description\": \"Before implementation, global scope\"}\n        ]\n    )\n```\n\n### Step 2: Run Appropriate Checklist\n\n#### Quick Checklist (Plans, PRs)\n\nRun through these mentally, note any that apply:\n\n**Core Questions:**\n1. What's the single biggest thing that could go wrong?\n2. Any external dependencies that could fail?\n3. Is rollback possible if this breaks?\n4. Edge cases not covered in tests?\n5. Unclear requirements that could cause rework?\n\n**Output Format:**\n```yaml\npremortem:\n  mode: quick\n  context: \"\u003Cplan\u002FPR being analyzed>\"\n\n  # Two-pass process: first gather potential risks, then verify each one\n  potential_risks:  # Pass 1: Pattern-matching findings\n    - \"hardcoded path at line 42\"\n    - \"missing error handling for X\"\n\n  # Pass 2: After verification\n  tigers:\n    - risk: \"\u003Cdescription>\"\n      location: \"file.py:42\"\n      severity: high|medium\n      category: dependency|integration|requirements|testing\n      mitigation_checked: \"\u003Cwhat was NOT found>\"  # REQUIRED\n\n  elephants:\n    - risk: \"\u003Cunspoken concern>\"\n      severity: medium\n\n  paper_tigers:\n    - risk: \"\u003Clooks scary but ok>\"\n      reason: \"\u003Cwhy it's fine - what mitigation EXISTS>\"\n      location: \"file.py:42-48\"  # Show the mitigation location\n\n  false_alarms:  # Findings that turned out to be nothing\n    - finding: \"\u003Cwhat was initially flagged>\"\n      reason: \"\u003Cwhy it's not a risk>\"\n```\n\n#### Deep Checklist (Before Implementation)\n\nWork through each category systematically:\n\n**Technical Risks:**\n- [ ] Scalability: Works at 10x\u002F100x current load?\n- [ ] Dependencies: External services + fallbacks defined?\n- [ ] Data: Availability, consistency, migrations clear?\n- [ ] Latency: SLA requirements will be met?\n- [ ] Security: Auth, injection, OWASP considered?\n- [ ] Error handling: All failure modes covered?\n\n**Integration Risks:**\n- [ ] Breaking changes identified?\n- [ ] Migration path defined?\n- [ ] Rollback strategy exists?\n- [ ] Feature flags needed?\n\n**Process Risks:**\n- [ ] Requirements clear and complete?\n- [ ] All stakeholder input gathered?\n- [ ] Tech debt being tracked?\n- [ ] Maintenance burden understood?\n\n**Testing Risks:**\n- [ ] Coverage gaps identified?\n- [ ] Integration test plan exists?\n- [ ] Load testing needed?\n- [ ] Manual testing plan defined?\n\n**Output Format:**\n```yaml\npremortem:\n  mode: deep\n  context: \"\u003Cimplementation being analyzed>\"\n\n  # Two-pass process\n  potential_risks:  # Pass 1: Initial scan findings\n    - \"no circuit breaker for external API\"\n    - \"hardcoded timeout value\"\n\n  # Pass 2: After verification (read context, check for mitigations)\n  tigers:\n    - risk: \"\u003Cdescription>\"\n      location: \"file.py:42\"\n      severity: high|medium\n      category: scalability|dependency|data|security|integration|testing\n      mitigation_checked: \"\u003Cwhat mitigations were looked for and NOT found>\"\n      suggested_fix: \"\u003Chow to address>\"\n\n  elephants:\n    - risk: \"\u003Cunspoken concern>\"\n      severity: medium|high\n      suggested_fix: \"\u003Csuggested approach>\"\n\n  paper_tigers:\n    - risk: \"\u003Clooks scary>\"\n      reason: \"\u003Cwhy it's actually ok - cite the mitigation code>\"\n      location: \"file.py:45-52\"\n\n  false_alarms:\n    - finding: \"\u003Cinitial concern>\"\n      reason: \"\u003Cwhy verification showed it's not a risk>\"\n\n  checklist_gaps:\n    - category: \"\u003Cwhich checklist section>\"\n      items_failed: [\"\u003Citem1>\", \"\u003Citem2>\"]\n```\n\n### Step 3: Present Risks via AskUserQuestion\n\n**BLOCKING:** Present findings and require user decision.\n\n```python\n# Build risk summary\nrisk_summary = format_risks(tigers, elephants)\n\nAskUserQuestion(\n    question=f\"\"\"Pre-Mortem identified {len(tigers)} tigers, {len(elephants)} elephants:\n\n{risk_summary}\n\nHow would you like to proceed?\"\"\",\n    header=\"Risks\",\n    options=[\n        {\n            \"label\": \"Accept risks and proceed\",\n            \"description\": \"Acknowledged but not blocking\"\n        },\n        {\n            \"label\": \"Add mitigations to plan (Recommended)\",\n            \"description\": \"Update plan with risk mitigations before proceeding\"\n        },\n        {\n            \"label\": \"Research mitigation options\",\n            \"description\": \"I don't know how to mitigate - help me find solutions\"\n        },\n        {\n            \"label\": \"Discuss specific risks\",\n            \"description\": \"Talk through particular concerns\"\n        }\n    ]\n)\n```\n\n### Step 4: Handle User Response\n\n#### If \"Accept risks and proceed\"\n```python\n# Log acceptance for audit trail\nprint(\"Risks acknowledged. Proceeding with implementation.\")\n# Continue to next workflow step\n```\n\n#### If \"Add mitigations to plan\"\n```python\n# User provides mitigation approach\n# Update plan file with mitigations section\n# Re-run quick premortem to verify mitigations address risks\n```\n\n#### If \"Research mitigation options\"\n```python\n# Spawn parallel research for each HIGH severity tiger\nfor tiger in high_severity_tigers:\n    # Internal: How has codebase handled this before?\n    Task(\n        subagent_type=\"scout\",\n        prompt=f\"\"\"\n        Find how this codebase has previously handled: {tiger.category}\n\n        Specifically looking for patterns related to: {tiger.risk}\n\n        Return:\n        - File:line references to similar solutions\n        - Patterns used\n        - Libraries\u002Futilities available\n        \"\"\"\n    )\n\n    # External: What are best practices?\n    Task(\n        subagent_type=\"oracle\",\n        prompt=f\"\"\"\n        Research best practices for: {tiger.risk}\n\n        Context: {tiger.category} in a {tech_stack} codebase\n\n        Return:\n        - Recommended approaches (ranked)\n        - Library options\n        - Common pitfalls to avoid\n        \"\"\"\n    )\n\n# Wait for research to complete\n# Synthesize options\n# Present via AskUserQuestion with 2-4 mitigation options\n```\n\n#### If \"Discuss specific risks\"\n```python\n# Ask which risk to discuss\nAskUserQuestion(\n    question=\"Which risk would you like to discuss?\",\n    header=\"Risk\",\n    options=[format_risk_option(r) for r in all_risks[:4]]\n)\n# Then have conversation about that specific risk\n```\n\n### Step 5: Update Plan (if mitigations added)\n\nIf user added mitigations, append to the plan:\n\n```markdown\n## Risk Mitigations (Pre-Mortem)\n\n### Tigers Addressed:\n1. **{risk}** (severity: {severity})\n   - Mitigation: {user_or_researched_mitigation}\n   - Added to phase: {phase_number}\n\n### Accepted Risks:\n1. **{risk}** - Accepted because: {reason}\n\n### Pre-Mortem Run:\n- Date: {timestamp}\n- Mode: {quick|deep}\n- Tigers: {count}\n- Elephants: {count}\n```\n\n## Integration Points\n\n### In create_plan \u002F plan-agent\n\nAfter plan structure is approved, before ExitPlanMode:\n\n```python\n# Run quick premortem\n\u002Fpremortem quick\n\n# If HIGH risks found, block until addressed\n# If only MEDIUM\u002FLOW, inform and proceed\n```\n\n### After plan approval, before implementation\n\n```python\n# Run deep premortem on full plan\n\u002Fpremortem deep thoughts\u002Fshared\u002Fplans\u002FYYYY-MM-DD-feature.md\n\n# Block until all HIGH tigers addressed\n```\n\n### In PR review workflows\n\n```python\n# Run quick premortem on diff scope\n\u002Fpremortem quick\n\n# Inform of any risks found\n```\n\n## Severity Thresholds\n\n| Severity | Blocking? | Action Required |\n|----------|-----------|-----------------|\n| HIGH | Yes | Must address or explicitly accept |\n| MEDIUM | No | Inform user, recommend addressing |\n| LOW | No | Note for awareness |\n\n## Example Session\n\n```\nUser: \u002Fpremortem deep thoughts\u002Fshared\u002Fplans\u002F2026-01-08-api-rate-limiting.md\n\nClaude: Running deep pre-mortem on API rate limiting plan...\n\n[Reviews plan against deep checklist]\n\nPre-mortem complete. Found 2 tigers, 1 elephant:\n\n**TIGERS:**\n1. [HIGH] No circuit breaker for external payment API\n   - Category: dependency\n   - If payment API is slow\u002Fdown, requests will pile up\n\n2. [HIGH] No rollback strategy defined\n   - Category: integration\n   - If rate limiting breaks auth flow, no quick fix path\n\n**ELEPHANTS:**\n1. [MEDIUM] Team hasn't used Redis before\n   - We're introducing Redis for rate limit counters\n   - Learning curve could slow implementation\n\n**PAPER TIGERS:**\n1. Database migration size - Only adds one index, \u003C1s migration\n\n[AskUserQuestion presented]\n\nUser: Research mitigation options\n\nClaude: Researching mitigations...\n\n[Spawns scout + oracle in parallel]\n\nFound 3 options for circuit breaker:\n\n1. **Use existing retry util** (Recommended)\n   - Found at src\u002Futils\u002Fretry.ts:45\n   - Already handles exponential backoff\n   - Just need to add circuit breaker state\n\n2. **Add resilience4j-lite**\n   - Popular library for this pattern\n   - More features but new dependency\n\n3. **Custom implementation**\n   - Full control but more code to maintain\n\nWhich approach for the circuit breaker?\n\nUser: Option 1 - use existing retry util\n\nClaude: Added to plan:\n\n## Risk Mitigations (Pre-Mortem)\n\n### Tigers Addressed:\n1. **No circuit breaker** (HIGH)\n   - Mitigation: Extend src\u002Futils\u002Fretry.ts with circuit breaker state\n   - Added to Phase 1\n\nShall I also address the rollback strategy tiger?\n```\n\n## References\n\n- [Pre-Mortems by Shreyas Doshi](https:\u002F\u002Fcoda.io\u002F@shreyas\u002Fpre-mortems)\n- [Gary Klein's Original Research](https:\u002F\u002Fhbr.org\u002F2007\u002F09\u002Fperforming-a-project-premortem)\n- [Project Pre-Mortem Guide - Mountain Goat Software](https:\u002F\u002Fwww.mountaingoatsoftware.com\u002Fblog\u002Fuse-a-pre-mortem-to-identify-project-risks-before-they-occur)\n","# Pre-Mortem\n\nIdentify failure modes before they occur by systematically questioning plans, designs, and implementations. Based on Gary Klein's technique, popularized by Shreyas Doshi (Stripe).\n\n## Usage\n\n```\n\u002Fpremortem              # Auto-detect context, choose depth\n\u002Fpremortem quick        # Force quick analysis (plans, PRs)\n\u002Fpremortem deep         # Force deep analysis (before implementation)\n\u002Fpremortem \u003Cfile>       # Analyze specific plan or code\n```\n\n## Core Concept\n\n> \"Imagine it's 3 months from now and this project has failed spectacularly. Why did it fail?\"\n\n## Risk Categories (Shreyas Framework)\n\n| Category | Symbol | Meaning |\n|----------|--------|---------|\n| **Tiger** | `[TIGER]` | Clear threat that will hurt us if not addressed |\n| **Paper Tiger** | `[PAPER]` | Looks threatening but probably fine |\n| **Elephant** | `[ELEPHANT]` | Thing nobody wants to talk about |\n\n## CRITICAL: Verify Before Flagging\n\n**Do NOT flag risks based on pattern-matching alone.** Every potential tiger MUST go through verification.\n\n### The False Positive Problem\n\nCommon mistakes that create false tigers:\n- Seeing a hardcoded path without checking for `if exists():` fallback\n- Finding missing feature X without asking \"is X in scope?\"\n- Flagging code at line N without reading lines N±20 for context\n- Assuming error case isn't handled without tracing the code\n\n### Verification Checklist (REQUIRED)\n\nBefore flagging ANY tiger, verify:\n\n```yaml\npotential_finding:\n  what: \"Hardcoded path at line 42\"\n\nverification:\n  context_read: true    # Did I read ±20 lines around the finding?\n  fallback_check: true  # Is there try\u002Fexcept, if exists(), or else branch?\n  scope_check: true     # Is this even in scope for this code?\n  dev_only_check: true  # Is this in __main__, tests\u002F, or dev-only code?\n\nresult: tiger | paper_tiger | false_alarm\n```\n\n**If ANY verification check is \"no\" or \"unknown\", DO NOT flag as tiger.**\n\n### Required Evidence Format\n\nEvery tiger MUST include:\n\n```yaml\ntiger:\n  risk: \"\u003Cdescription>\"\n  location: \"file.py:42\"\n  severity: high|medium\n  # REQUIRED - what mitigation was checked and NOT found:\n  mitigation_checked: \"No exists() check, no try\u002Fexcept, no fallback branch\"\n```\n\nIf you cannot fill in `mitigation_checked` with specific evidence, it's not a verified tiger.\n\n## Workflow\n\n### Step 1: Detect Context & Depth\n\n```python\n# Auto-detect based on context\nif in_plan_creation:\n    depth = \"quick\"   # Localized scope\nelif before_implementation:\n    depth = \"deep\"    # Global scope\nelif pr_review:\n    depth = \"quick\"   # Localized scope\nelse:\n    # Ask user\n    AskUserQuestion(\n        question=\"What depth of pre-mortem analysis?\",\n        header=\"Depth\",\n        options=[\n            {\"label\": \"Quick (2-3 min)\", \"description\": \"Plans, PRs, localized changes\"},\n            {\"label\": \"Deep (5-10 min)\", \"description\": \"Before implementation, global scope\"}\n        ]\n    )\n```\n\n### Step 2: Run Appropriate Checklist\n\n#### Quick Checklist (Plans, PRs)\n\nRun through these mentally, note any that apply:\n\n**Core Questions:**\n1. What's the single biggest thing that could go wrong?\n2. Any external dependencies that could fail?\n3. Is rollback possible if this breaks?\n4. Edge cases not covered in tests?\n5. Unclear requirements that could cause rework?\n\n**Output Format:**\n```yaml\npremortem:\n  mode: quick\n  context: \"\u003Cplan\u002FPR being analyzed>\"\n\n  # Two-pass process: first gather potential risks, then verify each one\n  potential_risks:  # Pass 1: Pattern-matching findings\n    - \"hardcoded path at line 42\"\n    - \"missing error handling for X\"\n\n  # Pass 2: After verification\n  tigers:\n    - risk: \"\u003Cdescription>\"\n      location: \"file.py:42\"\n      severity: high|medium\n      category: dependency|integration|requirements|testing\n      mitigation_checked: \"\u003Cwhat was NOT found>\"  # REQUIRED\n\n  elephants:\n    - risk: \"\u003Cunspoken concern>\"\n      severity: medium\n\n  paper_tigers:\n    - risk: \"\u003Clooks scary but ok>\"\n      reason: \"\u003Cwhy it's fine - what mitigation EXISTS>\"\n      location: \"file.py:42-48\"  # Show the mitigation location\n\n  false_alarms:  # Findings that turned out to be nothing\n    - finding: \"\u003Cwhat was initially flagged>\"\n      reason: \"\u003Cwhy it's not a risk>\"\n```\n\n#### Deep Checklist (Before Implementation)\n\nWork through each category systematically:\n\n**Technical Risks:**\n- [ ] Scalability: Works at 10x\u002F100x current load?\n- [ ] Dependencies: External services + fallbacks defined?\n- [ ] Data: Availability, consistency, migrations clear?\n- [ ] Latency: SLA requirements will be met?\n- [ ] Security: Auth, injection, OWASP considered?\n- [ ] Error handling: All failure modes covered?\n\n**Integration Risks:**\n- [ ] Breaking changes identified?\n- [ ] Migration path defined?\n- [ ] Rollback strategy exists?\n- [ ] Feature flags needed?\n\n**Process Risks:**\n- [ ] Requirements clear and complete?\n- [ ] All stakeholder input gathered?\n- [ ] Tech debt being tracked?\n- [ ] Maintenance burden understood?\n\n**Testing Risks:**\n- [ ] Coverage gaps identified?\n- [ ] Integration test plan exists?\n- [ ] Load testing needed?\n- [ ] Manual testing plan defined?\n\n**Output Format:**\n```yaml\npremortem:\n  mode: deep\n  context: \"\u003Cimplementation being analyzed>\"\n\n  # Two-pass process\n  potential_risks:  # Pass 1: Initial scan findings\n    - \"no circuit breaker for external API\"\n    - \"hardcoded timeout value\"\n\n  # Pass 2: After verification (read context, check for mitigations)\n  tigers:\n    - risk: \"\u003Cdescription>\"\n      location: \"file.py:42\"\n      severity: high|medium\n      category: scalability|dependency|data|security|integration|testing\n      mitigation_checked: \"\u003Cwhat mitigations were looked for and NOT found>\"\n      suggested_fix: \"\u003Chow to address>\"\n\n  elephants:\n    - risk: \"\u003Cunspoken concern>\"\n      severity: medium|high\n      suggested_fix: \"\u003Csuggested approach>\"\n\n  paper_tigers:\n    - risk: \"\u003Clooks scary>\"\n      reason: \"\u003Cwhy it's actually ok - cite the mitigation code>\"\n      location: \"file.py:45-52\"\n\n  false_alarms:\n    - finding: \"\u003Cinitial concern>\"\n      reason: \"\u003Cwhy verification showed it's not a risk>\"\n\n  checklist_gaps:\n    - category: \"\u003Cwhich checklist section>\"\n      items_failed: [\"\u003Citem1>\", \"\u003Citem2>\"]\n```\n\n### Step 3: Present Risks via AskUserQuestion\n\n**BLOCKING:** Present findings and require user decision.\n\n```python\n# Build risk summary\nrisk_summary = format_risks(tigers, elephants)\n\nAskUserQuestion(\n    question=f\"\"\"Pre-Mortem identified {len(tigers)} tigers, {len(elephants)} elephants:\n\n{risk_summary}\n\nHow would you like to proceed?\"\"\",\n    header=\"Risks\",\n    options=[\n        {\n            \"label\": \"Accept risks and proceed\",\n            \"description\": \"Acknowledged but not blocking\"\n        },\n        {\n            \"label\": \"Add mitigations to plan (Recommended)\",\n            \"description\": \"Update plan with risk mitigations before proceeding\"\n        },\n        {\n            \"label\": \"Research mitigation options\",\n            \"description\": \"I don't know how to mitigate - help me find solutions\"\n        },\n        {\n            \"label\": \"Discuss specific risks\",\n            \"description\": \"Talk through particular concerns\"\n        }\n    ]\n)\n```\n\n### Step 4: Handle User Response\n\n#### If \"Accept risks and proceed\"\n```python\n# Log acceptance for audit trail\nprint(\"Risks acknowledged. Proceeding with implementation.\")\n# Continue to next workflow step\n```\n\n#### If \"Add mitigations to plan\"\n```python\n# User provides mitigation approach\n# Update plan file with mitigations section\n# Re-run quick premortem to verify mitigations address risks\n```\n\n#### If \"Research mitigation options\"\n```python\n# Spawn parallel research for each HIGH severity tiger\nfor tiger in high_severity_tigers:\n    # Internal: How has codebase handled this before?\n    Task(\n        subagent_type=\"scout\",\n        prompt=f\"\"\"\n        Find how this codebase has previously handled: {tiger.category}\n\n        Specifically looking for patterns related to: {tiger.risk}\n\n        Return:\n        - File:line references to similar solutions\n        - Patterns used\n        - Libraries\u002Futilities available\n        \"\"\"\n    )\n\n    # External: What are best practices?\n    Task(\n        subagent_type=\"oracle\",\n        prompt=f\"\"\"\n        Research best practices for: {tiger.risk}\n\n        Context: {tiger.category} in a {tech_stack} codebase\n\n        Return:\n        - Recommended approaches (ranked)\n        - Library options\n        - Common pitfalls to avoid\n        \"\"\"\n    )\n\n# Wait for research to complete\n# Synthesize options\n# Present via AskUserQuestion with 2-4 mitigation options\n```\n\n#### If \"Discuss specific risks\"\n```python\n# Ask which risk to discuss\nAskUserQuestion(\n    question=\"Which risk would you like to discuss?\",\n    header=\"Risk\",\n    options=[format_risk_option(r) for r in all_risks[:4]]\n)\n# Then have conversation about that specific risk\n```\n\n### Step 5: Update Plan (if mitigations added)\n\nIf user added mitigations, append to the plan:\n\n```markdown\n## Risk Mitigations (Pre-Mortem)\n\n### Tigers Addressed:\n1. **{risk}** (severity: {severity})\n   - Mitigation: {user_or_researched_mitigation}\n   - Added to phase: {phase_number}\n\n### Accepted Risks:\n1. **{risk}** - Accepted because: {reason}\n\n### Pre-Mortem Run:\n- Date: {timestamp}\n- Mode: {quick|deep}\n- Tigers: {count}\n- Elephants: {count}\n```\n\n## Integration Points\n\n### In create_plan \u002F plan-agent\n\nAfter plan structure is approved, before ExitPlanMode:\n\n```python\n# Run quick premortem\n\u002Fpremortem quick\n\n# If HIGH risks found, block until addressed\n# If only MEDIUM\u002FLOW, inform and proceed\n```\n\n### After plan approval, before implementation\n\n```python\n# Run deep premortem on full plan\n\u002Fpremortem deep thoughts\u002Fshared\u002Fplans\u002FYYYY-MM-DD-feature.md\n\n# Block until all HIGH tigers addressed\n```\n\n### In PR review workflows\n\n```python\n# Run quick premortem on diff scope\n\u002Fpremortem quick\n\n# Inform of any risks found\n```\n\n## Severity Thresholds\n\n| Severity | Blocking? | Action Required |\n|----------|-----------|-----------------|\n| HIGH | Yes | Must address or explicitly accept |\n| MEDIUM | No | Inform user, recommend addressing |\n| LOW | No | Note for awareness |\n\n## Example Session\n\n```\nUser: \u002Fpremortem deep thoughts\u002Fshared\u002Fplans\u002F2026-01-08-api-rate-limiting.md\n\nClaude: Running deep pre-mortem on API rate limiting plan...\n\n[Reviews plan against deep checklist]\n\nPre-mortem complete. Found 2 tigers, 1 elephant:\n\n**TIGERS:**\n1. [HIGH] No circuit breaker for external payment API\n   - Category: dependency\n   - If payment API is slow\u002Fdown, requests will pile up\n\n2. [HIGH] No rollback strategy defined\n   - Category: integration\n   - If rate limiting breaks auth flow, no quick fix path\n\n**ELEPHANTS:**\n1. [MEDIUM] Team hasn't used Redis before\n   - We're introducing Redis for rate limit counters\n   - Learning curve could slow implementation\n\n**PAPER TIGERS:**\n1. Database migration size - Only adds one index, \u003C1s migration\n\n[AskUserQuestion presented]\n\nUser: Research mitigation options\n\nClaude: Researching mitigations...\n\n[Spawns scout + oracle in parallel]\n\nFound 3 options for circuit breaker:\n\n1. **Use existing retry util** (Recommended)\n   - Found at src\u002Futils\u002Fretry.ts:45\n   - Already handles exponential backoff\n   - Just need to add circuit breaker state\n\n2. **Add resilience4j-lite**\n   - Popular library for this pattern\n   - More features but new dependency\n\n3. **Custom implementation**\n   - Full control but more code to maintain\n\nWhich approach for the circuit breaker?\n\nUser: Option 1 - use existing retry util\n\nClaude: Added to plan:\n\n## Risk Mitigations (Pre-Mortem)\n\n### Tigers Addressed:\n1. **No circuit breaker** (HIGH)\n   - Mitigation: Extend src\u002Futils\u002Fretry.ts with circuit breaker state\n   - Added to Phase 1\n\nShall I also address the rollback strategy tiger?\n```\n\n## References\n\n- [Pre-Mortems by Shreyas Doshi](https:\u002F\u002Fcoda.io\u002F@shreyas\u002Fpre-mortems)\n- [Gary Klein's Original Research](https:\u002F\u002Fhbr.org\u002F2007\u002F09\u002Fperforming-a-project-premortem)\n- [Project Pre-Mortem Guide - Mountain Goat Software](https:\u002F\u002Fwww.mountaingoatsoftware.com\u002Fblog\u002Fuse-a-pre-mortem-to-identify-project-risks-before-they-occur)\n",{"name":5,"description":7,"allowed-tools":32},[33,34,35,36,37,38],"Read","Grep","Glob","Task","AskUserQuestion","TodoWrite","main","70e1c350500ee750987420bbae48837afa906b7e","skills\u002Fpremortem","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis","https:\u002F\u002Fgithub.com\u002Frubicanjr","linktr.ee\u002Ffinanskodu","Industrial Engineer & CIO @FinansKodu. Architecting AI-driven financial agents and autonomous workflows. 🏗️ Building systems, not just prompts.","2026-06-09 13:50:15",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add rubicanjr\u002FFinCognis --skill premortem",{"tool":53,"command":54},"bunx","bunx skills add rubicanjr\u002FFinCognis --skill premortem",{"tool":56,"command":57},"pnpm","pnpm dlx skills add rubicanjr\u002FFinCognis --skill premortem","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fpremortem\u002FSKILL.md",true,[],[62,83,92,112,142,161],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":73,"publishedAt":27},"01M6NWS9DAXJTADT4T5MB49X8W","workflow-router","Goal-based workflow orchestration - routes tasks to specialist agents based on user goals","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[74,75,76,77,78,79,80,81,82],"workflow router","workflow","router","orchestration","goals","goal","user","workflow orchestration","tasks",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":27},"01M6NWS3RETSC0SHP16HP66E14","wiring","Wiring Verification","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fwiring\u002FSKILL.md",[],[85,90,91],"verification","false",{"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":101,"publishedAt":27},"01M6NWS0XW9CVQZBDA1EGW0TWC","websocket-patterns","Connection management, room patterns, reconnection strategies, message buffering, and binary protocol design.","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fwebsocket-patterns\u002Fskill.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000015","视觉设计",[102,103,104,105,106,107,108,109,110,111],"websocket","patterns","websocket patterns","design","protocol","management","message","strategies","binary","connection",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":122,"publishedAt":27},"01M6NWRDQDX9ZNETAWRRMQWV52","visual-verdict","Screenshot comparison QA for frontend development. Takes a screenshot of the current implementation, scores it across multiple visual dimensions, and returns a structured PASS\u002FREVISE\u002FFAIL verdict with concrete fixes. Use when implementing UI from a design reference or verifying visual correctness.","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-verdict\u002FSKILL.md",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[123,124,125,126,127,128,129,130,131,132,133,134,135,105,136,137,138,139,140,141],"visual","verdict","visual verdict","ui","across","revise","comparison","correctness","implementing","for","fixes","dimensions","frontend","development","qa","screenshot","returns","use","frontend development",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":27},"01M6NWR8HSNRS7MNDK2J02QYMN","verification-loop","Comprehensive verification system covering build, types, lint, tests, security, and diff review before a PR.","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fverification-loop\u002FSKILL.md",[],[149,150,90,151,152,153,154,155,156,157,158,159,160],"verification loop","loop","lint","review","security","pr","system","diff","build","tests","diff review","types",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":27},"01M6NWR4HHSFR0VR5EXFRWA747","vector-db-patterns","Embedding strategies, ANN algorithms, hybrid search, RAG chunking strategies, and reranking for semantic search and retrieval.","https:\u002F\u002Fgithub.com\u002Frubicanjr\u002FFinCognis\u002Fblob\u002Fmain\u002Fskills\u002Fvector-db-patterns\u002Fskill.md",[],[168,169,170,171,103,172,173,174,175,109,176,177,178,179,180,132,181,182],"vector db patterns","vector db","db","vector","semantic search","search","embedding strategies","algorithms","chunking","semantic","retrieval","embedding","Hybrid Search","hybrid","rag"]