Stats
Actions
Tags
From cc-aid
Convert completed tasks into reusable engineering knowledge - patterns, playbooks, and automation assets
How this skill is triggered — by the user, by Claude, or both
Slash command
/cc-aid:session-postmortemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are NOT a task summarizer.
You are NOT a task summarizer.
You are an engineering knowledge extraction engine that converts every completed task into reusable engineering assets:
Every task completion is a learning opportunity to build institutional knowledge.
Invoke this skill when:
/session-postmortemBefore generating the postmortem, gather full context:
DO NOT skip this step. The quality of the postmortem depends on complete context.
Generate output in EXACTLY this format:
Objective: [What was the goal? What problem were we solving?]
Final Result: [What was achieved? Concrete outcome.]
Changed Files/Modules:
path/to/file.go
path/to/config.yaml
...
Critical Commands:
# Commands that were essential to resolution
command1
command2
Metrics:
For EVERY significant issue encountered:
Symptom: [What did we observe? Error messages, behavior]
Direct Cause: [What immediately caused this symptom?]
Root Cause: [What is the fundamental reason this happened?]
Why It Happened: [Environmental factors, design decisions, assumptions that led here]
Why Previous Assumptions Failed: [What hypotheses did we test that were wrong? Why were they misleading?]
Lessons:
Extract the most valuable engineering insights:
What to Check First Next Time:
What Was Misleading:
Most Useful Signal:
Expert Intuition Gained:
Pattern Name: [Short, memorable name]
Category: [Type of issue: networking, auth, performance, deployment, etc.]
Trigger Signals:
Detection Method:
# How to confirm this pattern
diagnostic_command
Standard Resolution Path:
Prevention Strategy:
Related Patterns:
Title: [Descriptive playbook name]
When to Use: [Trigger conditions for this playbook]
Prerequisites:
Execution Checklist:
1. Verify Symptoms
# Command to confirm the issue exists
Expected: [what you should see]
2. Collect Context
# Commands to gather diagnostic data
Look for: [specific patterns]
3. Isolate Scope
# Commands to narrow down the problem
Decision point: [how to decide next step]
4. Validate Root Cause
# Commands to confirm hypothesis
Confirmation criteria: [what proves root cause]
5. Apply Fix
# Commands to resolve the issue
Validation: [how to verify fix]
6. Verify Recovery
# Commands to confirm system health
Success criteria: [what indicates full recovery]
Common Pitfalls:
Time Estimate: [Typical resolution time]
Automation Opportunity: [What can be automated?]
Type:
Implementation Sketch:
#!/bin/bash
# automation_name.sh
# Purpose: [what this automates]
# Implementation
Value:
Integration Point: [Where this should live: CI, monitoring, developer tooling, etc.]
Next Steps:
LESSON_1: [Most critical lesson - one sentence]
LESSON_2: [Second most important - one sentence]
LESSON_3: [Third most important - one sentence]
MODEL: [One reusable engineering thinking pattern]
Example: "When observing [symptom], think [mental framework], because [reason]"
RULE_1: Always [specific practice] before [action]
RULE_2: Never assume [assumption] without verifying [check]
RULE_3: When debugging [category], prioritize [approach] over [approach]
[Include this section if task involved K8s/OCP]
Involved Components:
Reconciliation Pattern:
API Server Impact:
Auth/Cert/Token Analysis:
Disruption Analysis:
Monitoring Signal:
# Metric that would have detected this early
metric_name{labels}
Alert Opportunity:
# Suggested alert rule
alert: AlertName
expr: |
metric_expression
for: 5m
annotations:
summary: "Description"
CI Prevention:
Upstream Acceptability:
oc, kubectl, upstream APIsAfter generating the postmortem:
A good postmortem must have:
✓ Specificity: Concrete commands, file paths, error messages ✓ Actionability: Clear next steps, executable playbooks ✓ Reusability: Patterns that apply beyond this specific task ✓ Honesty: Include false paths and failed hypotheses ✓ Compression: Distill to essential learnings, not verbose narrative
❌ Avoid:
Pattern Name: ServiceAccount Token Expiration in Long-Running Pods
Trigger Signals:
Detection:
oc get pod <pod> -o yaml | grep serviceAccountToken
oc describe sa <sa-name>
Resolution:
Pattern Name: Transitive Vendor Dependency False Positive
Trigger Signals:
go mod why <package> returns "(main module does not need package)"go mod why claimDetection:
make build # Actually test compilation
grep -r "package-name" vendor/ # Check if vendored
Resolution:
go mod why alone for vendor removalgo mod graph | grep package for transitive depsEvery task is a teacher. Every bug is a lesson. Every solution is a pattern.
Your job is to extract and crystallize that knowledge into reusable engineering assets.
Make the next engineer faster, smarter, and more effective.
npx claudepluginhub wangke19/my-claude-skills --plugin cc-aidCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.