post-mortem
Review a completed session to extract actionable improvements. Identifies DX friction, documentation gaps, architectural confusion, anti-patterns, process failures, and skill/config improvements. Uses progressive disclosure for targeted investigation types.
What this skill does
# Post-Mortem Review a completed session or task to assess how it went and extract improvements. This covers both "how did we do" evaluation and "what can we learn" investigation. ## When to Use After completing any non-trivial task or session. The goal is continuous improvement: - **Routine review**: How smooth was execution? Where did friction occur? - **Problem sessions**: Things took longer than expected, multiple corrections needed - **Bug fixes**: What caused it and what would prevent it next time? - **New patterns**: Something worked well that should be codified ## Investigation Types Load the relevant reference based on what you're investigating: | Situation | Load | File | |-----------|------|------| | Agent hit friction during execution (wrong files, bad assumptions, unclear conventions) | **DX Friction** | `references/dx-friction.md` | | Documentation (READMEs, comments, API docs) was wrong, incomplete, or misleading | **Documentation Gaps** | `references/documentation-gaps.md` | | Code was hard to understand or things were in unexpected places | **Architecture Clarity** | `references/architecture-clarity.md` | | A bug was fixed but the root cause suggests a process gap | **Bug Prevention** | `references/bug-prevention.md` | | Code works but diverges from best practices, idioms, or established conventions | **Anti-Patterns** | `references/anti-patterns.md` | | Skills, hooks, commands, agents, or `.claude/` configs need updating | **Tooling Improvements** | `references/tooling-improvements.md` | Load multiple references when the session spans investigation types. ## Core Process Every post-mortem follows four steps regardless of investigation type. ### 1. Reconstruct What Happened Walk through the session timeline. For each significant step, note: - What was attempted - What actually happened - Where corrections were needed and why - What went smoothly (worth noting what worked, not just what didn't) Don't editorialize yet. Just document the sequence. ### 2. Assess Execution Quality Evaluate how the session went overall: - **Efficiency**: Did we take a direct path or wander? Where were the detours? - **Accuracy**: Were initial approaches correct, or did we need multiple corrections? - **Tooling fit**: Did skills, commands, and configs help or get in the way? - **Communication**: Was intent clear between user and agent throughout? - **Outcome**: Did we deliver what was asked for? Is it solid or just "works for now"? Flag anything that felt harder than it should have been, even if it ultimately succeeded. ### 3. Identify Systemic Causes For each friction point, ask: **"What would have prevented this?"** Push past the first answer. "I should have read the file more carefully" is a symptom. "The file's name doesn't indicate what it contains" or "there's no convention documented for where this type of code lives" is a systemic cause. **Good root causes** point to something fixable: - A missing or misleading piece of documentation - An architectural pattern that's inconsistent or undiscoverable - A skill/config that gives wrong guidance - A convention that exists but isn't written down - A test gap that allowed a regression - A workflow that worked well but isn't codified **Bad root causes** are just descriptions of what went wrong: - "I made a mistake" - "The code was complex" - "It took a while to figure out" ### 4. Propose Concrete Actions Every finding should produce one of these: - **Documentation update** - Fix incorrect docs, add missing docs, clarify ambiguous docs - **Skill/config update** - Modify an existing skill or CLAUDE.md instruction - **New skill/hook** - Create a new skill or hook to codify a pattern - **Architecture improvement** - Refactor to make the system more discoverable - **Test addition** - Add tests that would catch this class of issue - **Codify a win** - Something that worked well should be made repeatable Each action should have a specific file path and description of the change. Vague actions like "improve documentation" are not useful. ## Output Format ```markdown ## Session Post-Mortem ### What Happened [Timeline of the session with key decision points] ### Execution Assessment - **Outcome:** [What was delivered vs what was asked] - **Efficiency:** [Direct path or detours? Where and why?] - **What worked well:** [Patterns, skills, or approaches worth repeating] ### Findings #### Finding 1: [Title] **What happened:** [The friction or issue, stated factually] **Root cause:** [The systemic issue underneath] **Action:** [Specific change with file path] **Priority:** [High/Medium/Low based on how often this would recur] #### Finding 2: [Title] ... ### Summary [1-2 sentences: biggest takeaway and what should change first] ```
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.