review-past-performance

name	review-past-performance
description	Self-improvement loop for coding sessions. Pulls the last 24h of ICM memories, git history, and available transcripts; detects patterns like repeated mistakes, slow workflows, untested changes, or missing skills; then proposes 1-3 concrete improvements (new skills, prompt tweaks, eval criteria). Nothing is written until you approve. Use when asked to "review my performance", "self-improve", "what am I repeating", "review past performance", or "what should I fix in my workflow".
license	MIT
allowed-tools	Bash, Read, Write, Grep, Glob, AskUserQuestion
compatibility	Claude Code, Codex, Cursor, and other Agent Skills compatible tools. Requires ICM (https://github.com/rtk-ai/icm) for memory recall; degrades gracefully to git log + gstack analytics when ICM is unavailable.
metadata	{"targets":["cursor"],"author":"Oleg Koval","tags":["self-improvement","performance-review","icm","skills","workflow","ai-tools"]}

/review-past-performance

Self-improvement loop. Analyze recent sessions, find durable patterns, propose fixes.

Step 1 — Gather raw signals (run in parallel)

# A: ICM memories from last 24h
icm recall "mistakes errors repeated workflow" --limit 10 2>/dev/null || echo "ICM_UNAVAILABLE"
icm recall "completed task feature fix" --limit 10 2>/dev/null || echo "ICM_UNAVAILABLE"

# B: Git activity last 24h across all repos the user works in
git log --all --since="24 hours ago" --oneline --author="$(git config user.email 2>/dev/null)" 2>/dev/null | head -30 || echo "NO_GIT"

# C: ICM transcripts (last 3 sessions)
icm transcript search "" --limit 3 2>/dev/null || echo "TRANSCRIPTS_UNAVAILABLE"

# D: Skill usage from gstack analytics (what skills were run, outcomes)
tail -50 ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null | jq -c 'select(.ts > (now - 86400 | todate))' 2>/dev/null || \
  tail -50 ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null | head -20 || echo "NO_ANALYTICS"

# E: ICM errors-resolved topic (what broke and was fixed)
icm recall "error" -t "errors-resolved" --limit 5 2>/dev/null || echo "NO_ERROR_MEMORIES"

# F: Recent learnings (gstack)
_GSTACK_HOME="${GSTACK_HOME:-$HOME/.gstack}"
eval "$($HOME/.slate/skills/gstack/bin/gstack-slug 2>/dev/null)" 2>/dev/null || true
_LEARN_FILE="$_GSTACK_HOME/projects/${SLUG:-unknown}/learnings.jsonl"
[ -f "$_LEARN_FILE" ] && tail -20 "$_LEARN_FILE" || echo "NO_LEARNINGS"

Step 2 — Synthesize patterns

Read all signals. Classify findings into these categories:

Repeated mistakes — same error, same fix, same confusion appearing more than once in the signals. E.g., always forgetting to handle null on a specific field, always hitting the same linting error.

Slow workflows — multi-step sequences that took many tool calls but could be a single skill. E.g., always doing manual git log + grep + read 3 files before every PR review.

Missing coverage — areas where work was done but no test was written or no memory was stored.

Underused skills — skills that would have applied but were not invoked (check skill-usage.jsonl gaps vs. git activity).

Knowledge gaps — concepts that came up repeatedly as questions or confusion.

Score each finding:

• Frequency: how many times it appeared (1 = once, 3 = three or more)
• Time cost: rough estimate per occurrence (minutes)
• Fixability: easy (a new skill/memory fixes it), medium (needs a process change), hard (structural)

Pick the top 1-3 findings by frequency × time_cost × fixability_inverse.

Step 3 — Formulate proposals

For each finding, produce exactly one proposal. Proposal types:

Type A — New skill: The repeated sequence can be codified. Provide:

• Proposed skill name (lowercase, dashes, ≤32 chars)
• Trigger phrases (3-5)
• 5-8 line SKILL.md workflow skeleton
• Estimated time savings per occurrence

Type B — Skill tweak: An existing skill is close but missing a step or check. Provide:

• Which skill (/skill-name)
• What specific text to add/change (before/after diff)
• Why this covers the gap

Type C — ICM memory / eval criteria: A pattern should be captured as a durable memory or eval rule. Provide:

• icm store command (with topic, content, importance)
• Or: a yes/no eval question to add to an existing skill

Step 4 — Present findings (D1)

Use AskUserQuestion:

D1 — Performance review: N patterns found, N proposals
Project/branch/task: 24h session review — git, ICM memories, skill analytics.
ELI10: I looked at your last 24 hours of work: git commits, ICM memories,
skill runs, and resolved errors. Here's what I found repeating and what
I'd do about it. Approve proposals individually or skip any.
Stakes if we pick wrong: skipping a proposal leaves the pattern unfixed;
approving a bad proposal adds noise. You can always /skillify or rm a skill later.
Recommendation: A — review each proposal and approve what resonates.
Note: options differ in kind, not coverage — no completeness score.
A) Walk me through each proposal (recommended)
B) Show summary only, I'll decide what to dig into
C) Abort — nothing to act on today

If B: print a one-line summary table (proposal number, type, finding, estimated savings). Stop.

If C: print "No changes made. Run /review-past-performance again anytime." Stop.

If A: proceed to Step 5.

Step 5 — Proposal gate (one per proposal)

For each proposal (D2, D3, D4 ...):

Print:

--- Proposal N of N ---
Finding: <one sentence>
Pattern evidence: <which signals showed this>
Proposal type: <A/B/C>
<full proposal detail from Step 3>
Estimated savings: ~X min/occurrence

Then AskUserQuestion:

D<N> — Apply proposal N: <short title>?
Project/branch/task: <finding in one sentence>
ELI10: <plain English: what this proposes, what changes, what you gain>
Stakes if we pick wrong: <what happens if you apply a bad one, or skip a good one>
Recommendation: A — apply it — the evidence is clear enough to try it.
Note: options differ in kind, not coverage — no completeness score.
A) Apply this proposal (recommended)
B) Skip this one
C) Modify before applying (describe what to change)

If C: ask what to change, update the proposal in-memory, re-show, re-ask A/B only.

Step 6 — Execute approved proposals

For each approved proposal:

Type A (new skill):

mkdir -p ~/.claude/skills/<name>

Write ~/.claude/skills/<name>/SKILL.md with the skeleton from Step 3. Print: "Skill / created at ~/.claude/skills//SKILL.md — invoke it with /."

Type B (skill tweak): Read the target skill file. Apply the diff. Print the before/after. Do NOT commit.

Type C (ICM memory):

icm store -t "<topic>" -c "<content>" -i <importance> -k "<keywords>"

Print the stored memory ID.

Step 7 — Summary

After all proposals are processed, print a compact summary:

/review-past-performance complete
Applied: N proposals
Skipped: N proposals

What changed:
- [list each applied change with one line]

Run again tomorrow: /review-past-performance

Then:

# Store this review run as an ICM memory so future reviews have continuity
icm store -t "context-workflow" \
  -c "Performance review $(date +%Y-%m-%d): found [N] patterns, applied [N] proposals. Key findings: [one-line summary]" \
  -i medium \
  -k "performance-review,self-improvement" 2>/dev/null || true

# Log to gstack timeline if available
~/.slate/skills/gstack/bin/gstack-timeline-log \
  '{"skill":"review-past-performance","event":"completed","outcome":"success"}' 2>/dev/null || true

---

Notes

• This skill reads only — no git mutations, no PR actions, no Notion/Linear writes.
• Type A skills created here are skeletons. Run them once and tune before relying on them.
• If ICM is unavailable (ICM_UNAVAILABLE), fall back to git log + gstack analytics only; note the limitation in findings.
• If there are fewer than 3 signals available, say so and offer to run again after more sessions.