agentsclimarketplace

Review past performance

Skill oleg-koval/agent-skills/packages/software-development/review-past-performance/adapters/claude/skills/review-past-performance

Opinionated agent skill catalog for Codex, Claude, Cursor, Copilot, and launch workflows.

Install
npx -y skills add oleg-koval/agent-skills --skill review-past-performance

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

8.0 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

/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 /<name> created at ~/.claude/skills/<name>/SKILL.md — invoke it with /<name>."

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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most review quality skills give in ~1.9k tokens

Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-07

  • Ask questions one at a timein 81 of 1048, across 64 files
  • Provide a recommended answer for each questionin 73 of 1048, across 50 files
  • Explore the codebase instead of asking answerable questionsin 66 of 1048, across 42 files
  • Resolve dependencies between decisions one-by-onein 42 of 1048, across 17 files
  • Interview the user relentlessly about the planin 38 of 1048, across 13 files
  • Order findings by severityin 31 of 1048
  • Resolve each branch of the decision treein 27 of 1048, across 5 files
  • Run a grilling sessionin 26 of 1048, across 5 files
  • Update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 11 files
  • Propose precise canonical terms for vague languagein 25 of 1048, across 7 files
  • Create documentation files lazilyin 24 of 1048, across 5 files
  • Assign severity to every findingin 24 of 1048

Said here and by no other author read

  • gather signals from the last 24 hours
  • run signal gathering commands in parallel
  • score findings by frequency, time cost, and fixability
  • select the top three findings
  • create one proposal per finding
  • execute only approved proposals

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.