Menu
Fold one lesson into one existing skill, behind a confirmation gate.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Audit and improve AGENTS.md files in repositories, keeping CLAUDE.md as a one-line @AGENTS.md reference so the same project memory works across tools (Claude Code, Codex, Gemini CLI, …). Use when user asks to check, audit, update, improve, or fix AGENTS.md (or CLAUDE.md) files. Scans for all such files, evaluates quality against templates, outputs quality report, then makes targeted updates. Also use when the user mentions "AGENTS.md maintenance" or cross-tool "project memory optimization".
Graph a skill's flow — steps, artifacts, invocations — render it with draw-graphology, and report checkable weak links — each verified by two independent subagents — as a handoff file of lessons for improve-skills.
Summarize the CURRENT Claude session's work into a very concise 3P (Progress/Plans/Problems) Slack status report, draft it to the user for review, then place it as a native Slack draft for a final look before they send. User-invoked mid-session (`/slack-comm`) when you need to report what you just did in a tight, matter-of-fact format. Not for org-scale newsletters or pulling other people's updates.
Unattended cleanup loop — scan the codebase for readability debt and run up to N targets (default 5) through a cleaner/reviewer/tester trio; verified cleanups land as per-target refactor commits on a clean-loop/<date> branch. Not a performance tool (pair-ratchet) and not for polishing just-written code (simplify-python).
Create data-driven network graph visualizations with graphology + sigma.js. Use when the user wants to visualize a network, dependency graph, knowledge graph, call graph, org/relationship map, communities/clusters, or any node-edge dataset too large to place by hand.
Use AFTER writing or editing Python to make it read better without changing behavior — idiomatic rewrites (comprehensions, enumerate/zip, f-strings, pathlib, dataclasses), flattened control flow (guard clauses, de-nesting, boolean logic), and removed cruft (dead code, redundant conditionals, pointless intermediates). High-confidence, behavior-preserving rules only; each carries an anti-rule for when NOT to apply it. Trigger when the user asks to "simplify", "clean up", "tidy", "de-nest", or make recently written Python more idiomatic/Pythonic. Not a performance tool (use pair-optimize) and not a behavior-changing refactor.
Based on SOC occupation classification
| name | improve-skills |
| version | 1.0.0 |
| description | Fold one lesson into one existing skill, behind a confirmation gate. |
| disable-model-invocation | true |
A skill should absorb what you learn while using it. Mid-session you hit friction, get corrected, or find a better way — each is a lesson the skill should have known and didn't. This turns one lesson into one skill edit, behind a gate: nothing is written until you approve the proposal.
One skill per run. The single highest-value change, made well and confirmed, beats a batch of half-considered edits — and it keeps the confirmation honest. Targets are the skills under ~/personal/skills; this skill edits existing skills, it does not create new ones.
Gather candidate improvements from two sources:
For each lesson capture three things: (a) what was learned, (b) which repo skill it belongs in, (c) why that skill is currently silent or wrong about it. A lesson with no home skill is out of scope — note it as "no target, maybe a new skill" and set it aside.
Completion: a list of candidate lessons, each tied to exactly one existing skill in the repo with a one-line rationale — or an explicit "no actionable lesson found" when the session surfaced none.
If the lessons cluster on a single skill, that is the target. If they span several, present the shortlist (skill · the lesson · why it matters) and ask the user to pick one, recommending the highest-value. Then read the whole target SKILL.md, plus any reference file the change would touch, so the edit fits its structure and voice.
Completion: exactly one target skill chosen and its SKILL.md (and any affected reference file) fully read.
Read ~/.agents/skills/writing-great-skills/SKILL.md (and its GLOSSARY.md for any term you're unsure of), then design the concrete edit. In particular:
Completion: a written proposal a reader could approve or amend without seeing the file — naming the target skill, the exact change (before→after or added/removed lines) and where it goes, and the lesson driving it.
Show the proposal. Ask the user to approve, amend, or reject. Fold feedback back into the Step 3 proposal and re-present until they approve. Write nothing before approval. On outright rejection, stop and report.
Completion: explicit user approval of a specific proposal, or a clean stop on rejection.
Make exactly the approved edit — no scope creep to other files or to other improvements you happen to notice. Bump the skill's version if it carries one and the change is substantive.
Completion: the approved change is written to the one target skill; nothing else is modified.
Re-read the edited region: confirm it reads cleanly, added no duplication or sprawl, and left the skill internally consistent — description matches body, links resolve. Report which skill changed, what changed, the lesson behind it, and any leftover lessons parked for a future run.
Completion: edited region verified consistent; report delivered, listing the change and any deferred lessons.
