skills:retrospective

Name: skills:retrospective
Author: kagenti

Engineering Community

Repo stars 216
Author updated Live
Author repo kagenti

Fluxly profile Facts only: domain, agents, trust score, runtime, permissions and network

Domain: Engineering
Compatible agents: Claude Code
Cursor
Cline
Codex
Windsurf
Gemini CLI

+20
Trust score: 88 / 100 · community maintained
Author / version / license: @kagenti · no license declared
Token usage: Moderate
Setup complexity: Guided setup
External API key: Not required
Operating systems: Unspecified (assume cross-platform)
Runtime requirements: No special requirements
Permissions: Read-only
Write / modify
Shell exec
Network behavior: Local-only
Install commands: 26 variants

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview skills-retrospective.preview

---
name: skills:retrospective
description: End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(…
category: engineering
runtime: no special runtime
---

# skills:retrospective output preview

## PART A: Task fit
- Use case: End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(["/skills:retrospective"]) --> P1["Phase 1: Session Analysis"]:::skills P1 --> P1B["Phase 1b: Commit History"]:::skills P1B --> P2["Phase 2: Skill Inventory"]:::skills P2 --> P3["Phase 3: Create Plan"]:::skills P3 --> APPROVE{"User approves?"} runs entirely loc….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Table of Contents / When to Use / Phase 1: Session Analysis” and do not present inference as author intent.

## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(["/skills:retrospective"]) --> P1["Phase 1: Session Analysis"]:::skills P1 --> P1B["Phase 1b: Commit History"]:::skills P1B --> P2["Phase 2: Skill Inventory"]:::skills P2 --> P3["Phase 3: Create Plan"]:::skills P3 --> APPROVE{"User approves?"} runs entirely loc…”.
- **02** When the source has headings, the agent prioritizes “Table of Contents / When to Use / Phase 1: Session Analysis” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.

## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.

SKILL.md SKILL.md

---
name: skills:retrospective
description: End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(…
category: engineering
source: kagenti/kagenti
---

# skills:retrospective

## When to use
- End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(["/skills:retrospectiv…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.

## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.

## Execution rules
- Organize steps around “Table of Contents / When to Use / Phase 1: Session Analysis” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.

## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.

Evidence boundary and execution chain

The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.

skill "skills:retrospective" {
  input      -> user goal + target files + boundaries + acceptance criteria
  context    -> Table of Contents / When to Use / Phase 1: Session Analysis
  rules      -> SKILL.md triggers / order / output contract
  runtime    -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
  guardrails -> usually needs no extra API key + small-sample validation + diff/log review
  output     -> copyable result + checklist + next iteration
}

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: End-of-session review to identify improvements, skill gaps, and refactoring opportunities START(["/skills:retrospective"]) --> P…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Table of Contents”, “When to Use”, “Phase 1: Session Analysis”, “1.1 Repeated Commands”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name skills:retrospective directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Table of Contents / When to Use / Phase 1: Session Analysis” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Session Retrospective

flowchart TD
    START(["/skills:retrospective"]) --> P1["Phase 1: Session Analysis"]:::skills
    P1 --> P1B["Phase 1b: Commit History"]:::skills
    P1B --> P2["Phase 2: Skill Inventory"]:::skills
    P2 --> P3["Phase 3: Create Plan"]:::skills
    P3 --> APPROVE{"User approves?"}
    APPROVE -->|Yes| P4["Phase 4: Execute"]:::skills
    APPROVE -->|Changes| P3
    P4 --> DONE([Commit changes])

    classDef skills fill:#607D8B,stroke:#333,color:white

Follow this diagram as the workflow.

When to Use
Phase 1: Analysis
Phase 2: Skill Inventory Review
Phase 3: Create Plan
Phase 4: Execute with Approval
Skill Gap Patterns
Refactoring Patterns

When to Use

Run at the end of significant sessions:

After debugging a complex issue
After implementing a new feature
After onboarding to a new area of the codebase
When you notice repeated patterns
Periodically (weekly/monthly) for skill hygiene

Phase 1: Session Analysis

Review the current session for patterns. Do NOT make changes yet.

1.1 Repeated Commands

What commands did you run more than 3 times?

# Check bash history for patterns
history | grep -E "kubectl|helm|git" | sort | uniq -c | sort -rn | head -20

1.2 Long Debugging Cycles

What took longest to figure out?

Did I try multiple approaches before finding the right one?
Was there a "trick" that finally worked?
Would a checklist have helped?

1.3 Repeated Lookups

What information did you search for repeatedly?

API endpoints, configuration keys, command flags
Error message meanings
"How do I..." questions

1.4 Missing Workflows

Signs of missing workflow:

"I wish I had known to do X first"
"The order matters: A before B before C"
"This only works if Y is configured"

Phase 1b: Commit History Analysis

Analyze recent commit history to identify blind paths and wasted iterations.

1b.1 Review Recent Commits

git log --oneline -30

1b.2 Identify Revert/Fix Chains

Look for patterns that indicate wrong paths were taken:

git log --oneline -50 | grep -iE "revert|fix:|fixup|undo|retry|attempt"

For each revert/fix chain, classify the root cause:

Pattern	Root Cause	Skill Fix
Fix → Fix → Fix same thing	Wrong initial approach	Add decision tree to skill
Revert then different approach	First approach was wrong	Add "don't do X" anti-pattern
Multiple commits changing same file	Incremental guessing	Add diagnostic steps before fix
Commit then immediately fix	Didn't verify before commit	Strengthen verification step
Applied fix that broke other tests	Didn't check impact	Add "check related tests" step

1b.4 Count Wasted Iterations

# Count fix/revert commits vs feature commits in last 30
echo "Feature commits:"
git log --oneline -30 | grep -cvE "fix:|revert|fixup|undo"
echo "Fix/revert commits:"
git log --oneline -30 | grep -ciE "fix:|revert|fixup|undo"

A healthy ratio is 3:1 (feature:fix). Below 2:1 means the agent is taking too many blind paths.

1b.5 Analyze What the Agent Explored

Review the session conversation for:

Hypotheses tested: How many guesses before finding the right fix?
Commands that returned nothing useful: Ran a command, got no insight, tried another
Repeated "let me try another approach": Sign of missing decision guidance
Correct exploration: Some unknown paths are expected — the agent should explore options when the situation is genuinely ambiguous

1b.6 Build Skills from Bad Paths

For each blind path identified, determine if a skill can prevent it:

Blind Path	Preventable?	Action
Tried approach A, failed, tried B, B worked	YES — add "use B when [condition]"	Update skill with decision tree
Explored 3 approaches, all reasonable, #3 worked	PARTIALLY — ambiguous situation	Add "try in this order" guidance
Guessed at fix without diagnosing first	YES — skipped diagnostic step	Add "diagnose before fixing" rule
Tried approach that can't work in this env	YES — env-specific constraint	Add environment check to skill
Novel problem, had to explore	NO — genuinely unknown	Document solution for next time

Phase 2: Skill Inventory Review

Review existing skills for refactoring opportunities. Do NOT make changes yet.

2.1 List All Skills

find .claude/skills -name "SKILL.md" | sort

2.2 Check for Duplicates

Look for skills that cover similar ground:

Pattern	Action
Two skills with overlapping commands	Consider merging
One skill doing too many things	Consider splitting
Similar skills in different categories	Consider consolidating
Skill references outdated patterns	Update to best practices

2.3 Best Practices Check

For each skill, verify:

Frontmatter has name and description
TOC included if over 50 lines
Commands are copy-pasteable and tested
Troubleshooting section exists
Links to related skills are valid
No outdated information

2.4 Identify Refactoring Candidates

Common refactoring needs:

Merge: k8s:pods and k8s:health have overlapping pod checks
Split: A skill covers both Kind and OpenShift but patterns differ
Rename: Skill name doesn't match what it actually does
Restructure: Category no longer makes sense

Phase 3: Create Plan

Write a plan document for approval. Include all proposed changes.

Plan Template

Create docs/SKILL_RETROSPECTIVE_<date>.md:

# Skill Retrospective Plan - [Date]

## Session Context
[What was the session about?]

## Proposed Changes

### New Skills to Create
| Skill | Reason | Priority |
|-------|--------|----------|
| `category/name` | Gap identified when... | High/Medium/Low |

### Skills to Update
| Skill | Change | Reason |
|-------|--------|--------|
| `category/name` | Add X | Missing from workflow |

### Skills to Refactor
| Action | Skills | Reason |
|--------|--------|--------|
| Merge | `a`, `b` → `c` | Overlapping content |
| Split | `x` → `y`, `z` | Too broad |
| Rename | `old` → `new` | Clarity |

### Skills to Delete
| Skill | Reason |
|-------|--------|
| `category/name` | Superseded by X |

## Questions for Review
- Should X and Y be merged?
- Is category Z still relevant?

## Estimated Effort
- New skills: N
- Updates: M
- Refactors: K

Present Plan

Show the plan to the user and ask:

Here's my retrospective plan. Before I make any changes:

Do these proposed changes make sense?

Should I prioritize any specific items?

Are there changes you'd skip or modify?

Phase 4: Execute with Approval

Only after user approves the plan, execute changes.

4.1 Execute in Order

Refactors first - Prevents creating skills that will be immediately restructured
Updates second - Improve existing before adding new
New skills last - Build on clean foundation

4.2 Checkpoint After Each Major Change

After significant changes, pause and confirm:

Completed: [description]. Continue with next item?

4.3 Final Commit

Commit all changes with comprehensive message:

docs: Session retrospective skill updates

- Created: auth/new-skill
- Updated: k8s:health with pod debugging
- Merged: testing/a + testing/b → testing/combined
- Deleted: obsolete/skill

Based on [session context].

Skill Gap Patterns

Session Pattern	Likely Gap
"I had to google..."	Missing reference skill
"After trying X, Y, Z, W worked"	Missing debugging decision tree
"The pattern for this is..."	Missing pattern skill
"You need A before B"	Missing prerequisite skill
"Different on OpenShift vs Kind"	Missing env-specific skill
401/403 errors	Missing auth skill
Connection/routing issues	Missing networking skill
Commit → revert → different approach	Missing anti-pattern in skill
3+ fix commits for same issue	Missing diagnostic step in skill
Agent explored multiple approaches	Add "try in this order" to skill

Refactoring Patterns

When to Merge Skills

Two skills share >50% of commands
Users always use them together
Distinction is confusing

When to Split Skills

Skill has multiple "modes" or use cases
Different audiences need different parts
Skill is over 200 lines

When to Rename/Move

Name doesn't match actual purpose
Category has changed
Consistency with other skills

When to Delete

Superseded by better skill
No longer applicable (deprecated tool/pattern)
Never actually used

skills:write - Template for new skills
skills:scan - Full repo audit and gap analysis

Install command

One-click installPick a runner, click Copy, paste into your terminal, press enter

npx skills add kagenti/kagenti/.claude/skills/skills:retrospective -y

Open general install guide

View skill source

Works with

Claude Code
Cursor
Cline
Codex
Windsurf
Gemini
OpenCode
Roo Code
AAide
+Augment
GitHub Copilot
OpenClaw
KKiro
Junie
WWarp
Goose
Trae
Kilo Code
OpenHands
Amp
Zencoder
CContinue
AIAider
CodeBuddy
CodeGeeX
Replit Agent

Security audit

88 / 100

Community

未声明 license/许可。
未声明 version。
未限定 allowed-tools，默认拥有全部工具权限。

Metadata

Source: github
kagenti/kagenti
中文

More by @kagenti

Category & tags

Category Engineering

skills:retrospective

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Session Retrospective

Table of Contents

When to Use

Phase 1: Session Analysis

1.1 Repeated Commands

1.2 Long Debugging Cycles

1.3 Repeated Lookups

1.4 Missing Workflows

Phase 1b: Commit History Analysis

1b.1 Review Recent Commits

1b.2 Identify Revert/Fix Chains

1b.3 Classify Blind Paths

1b.4 Count Wasted Iterations

1b.5 Analyze What the Agent Explored

1b.6 Build Skills from Bad Paths

Phase 2: Skill Inventory Review

2.1 List All Skills

2.2 Check for Duplicates

2.3 Best Practices Check

2.4 Identify Refactoring Candidates

Phase 3: Create Plan

Plan Template

Present Plan

Phase 4: Execute with Approval

4.1 Execute in Order

4.2 Checkpoint After Each Major Change

4.3 Final Commit

Skill Gap Patterns

Refactoring Patterns

When to Merge Skills

When to Split Skills

When to Rename/Move

When to Delete

Discussion

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Session Retrospective

Table of Contents

When to Use

Phase 1: Session Analysis

1.1 Repeated Commands

1.2 Long Debugging Cycles

1.3 Repeated Lookups

1.4 Missing Workflows

Phase 1b: Commit History Analysis

1b.1 Review Recent Commits

1b.2 Identify Revert/Fix Chains

1b.3 Classify Blind Paths

1b.4 Count Wasted Iterations

1b.5 Analyze What the Agent Explored

1b.6 Build Skills from Bad Paths

Phase 2: Skill Inventory Review

2.1 List All Skills

2.2 Check for Duplicates

2.3 Best Practices Check

2.4 Identify Refactoring Candidates

Phase 3: Create Plan

Plan Template

Present Plan

Phase 4: Execute with Approval

4.1 Execute in Order

4.2 Checkpoint After Each Major Change

4.3 Final Commit

Skill Gap Patterns

Refactoring Patterns

When to Merge Skills

When to Split Skills

When to Rename/Move

When to Delete

Related Skills

Discussion