optimize
Skill9 starsChanged 3 months agoMITView on GitHub
Use when the user wants to autonomously improve a measurable metric through iterative experimentation with git-based checkpointing and automatic rollback.
- Deletes or force-pushes
76 other projects use a version of this.
Adopted by
Most recently taken up by
- ansvisor/ansvisortheir own version, first seen Nov 8, 2026
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tooltheir own version, first seen Nov 8, 2026
- Mrbaeksang/skillstheir own version, first seen Nov 8, 2026
- cihantopac/searvextheir own version, first seen Nov 8, 2026
- daintreehq/daintreetheir own version, first seen Nov 5, 2026
- theexperiencecompany/gaiatheir own version, first seen Nov 3, 2026
Used with
Projects with it also use arrange, teach-impeccable and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
HK-hubSkillarrange
Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
Also in 14 projects that use this
HK-hubSkillteach-impeccable
One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
Also in 17 projects that use this
zwy123zwySkillnormalize
将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。
Also in 19 projects that use this
open-coder-aiSkillpolicy-init
Create conformant Chock policy from request. args(request, target_path,
Also in 3 projects that use this
- +8 more from HK-hub
Other versions76 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 76
- Z3Prover/z3★ 13ksame name
- highcharts/highcharts★ 13ksame name
- whitecircle/halo★ 851same name
- hacan359/tonkatsu_box★ 597same name
- talesofai/cohub★ 585same name
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool★ 432same name
- nexmoe/DayBee★ 424same name
- nexmoe/eve★ 424same name
- Southclaws/storyden★ 348same name
- 10xChengTu/Mux0★ 337same name
66 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository56 other files it gives its agents.
- .claude/agents/CLAUDE.mdCLAUDE.md
- .claude/hooks/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .claude/prompts/CLAUDE.mdCLAUDE.md
- .claude/rules/CLAUDE.mdCLAUDE.md
- .claude/skills/CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- vision/CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- scaffold/llms.txtllms.txt
- architecture-checkSkill
- backlog-reviewSkill
- bootstrapSkill
- brainstormSkill
- buildSkill
- claude-sense-checkSkill
- code-qualitySkill
- commitSkill
- continueSkill
- custom-hooksSkill
- dashboardSkill
- debug-sessionSkill
- deploySkill
- discoverSkill
- doctorSkill
- fix-issueSkill
- framework-upgradeSkill
- handoffSkill
- help-meSkill
- ideateSkill
- lanesSkill
- manual-testSkill
- merge-downSkill
- merge-upSkill
- parallel-workSkill
- performance-checkSkill
- phase-reviewSkill
- pr-statusSkill
- quality-checkSkill
- quickstartSkill
- refine-loopSkill
- researchSkill
- retrospectiveSkill
- security-auditSkill
- skill-createSkill
- skill-evalSkill
- sprint-endSkill
- sprint-startSkill
- story-cycleSkill
- testing-cycleSkill
- test-validatorSkill
- UAT-cycleSkill
- undo-workSkill
- uninstallSkill
- weekly-maintenanceSkill
- wrap-upSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 11 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 73 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 66
Update at each experiment iteration.
- Very specific: line 72
Run verify-clean-git-state micro-component.
- Distinctive: line 78
Do NOT proceed with uncommitted changes.
- Distinctive: line 83
Run the metric command and parse the current value:
- Distinctive: line 130
Simplicity preference: If two approaches could achieve similar metric improvement, prefer the one that removes code over the one that adds …
- Distinctive: line 154
Run the metric command again.
- Distinctive: line 156
Crash handling: If the metric command fails (non-zero exit, no parseable output):
- Distinctive: line 158
Read the last 50 lines of output for error diagnosis
- Distinctive: line 160
If fix works: re-measure
- Very specific: line 161
If fix fails: mark as crash, rollback, continue to next experiment
- Distinctive: line 206
Consider a different approach category — if you've been tuning parameters, try restructuring.
- Distinctive: line 207
If the next experiment also fails: stop the loop early
- Very specific: line 243
Git safety: Every experiment is a commit.
- Distinctive: line 248
Max cap: Default 20 experiments, configurable up to any limit.
“Common” is measured: kept by at least 6 in 10 of the 73 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
optimize
Optimizing: $ARGUMENTS
Argument Parsing
| Argument | Required | Default | Description |
<goal> | Yes | - | What to optimize (e.g., "increase test coverage", "reduce bundle size") |
--metric "<command>" | Yes | - | Shell command that outputs the metric value. Pipe through grep if needed to isolate the number |
--target <N> | Yes | - | Target value to reach |
--direction min|max | No | max | Whether to minimize or maximize the metric |
--max <N> | No | 20 | Maximum experiments before stopping |
Examples:
/optimize "increase test coverage" --metric "npm test -- --coverage 2>&1 | grep 'All files' | awk '{print $10}'" --target 90 --direction max
/optimize "reduce bundle size" --metric "npm run build 2>&1 | grep 'gzipped' | awk '{print $3}'" --target 150 --direction min --max 30
/optimize "eliminate lint warnings" --metric "npm run lint 2>&1 | tail -1 | grep -oE '[0-9]+ problems'" --target 0 --direction minFailure State Persistence
At loop entry, write docs/sessions/.failure-state.md:
---
status: active
skill: optimize
phase: "baseline"
phase_name: "Baseline Measurement"
started_at: "[ISO-8601 timestamp]"
story: "[goal from $ARGUMENTS]"
branch: "[from git branch --show-current]"
next_action: "Measure baseline metric"
files_modified: []
---
## Context
Goal: [goal]
Metric command: [command]
Target: [target] (direction: [min|max])
Max experiments: [max]
Current experiment: 0
Best value: [pending]Update at each experiment iteration. Delete when optimization completes or max experiments reached.
Process
1. Pre-Flight
Run verify-clean-git-state micro-component. Confirm:
- Working tree is clean (no uncommitted changes)
- On a feature branch (not main/master)
- Git is available
<HARD-GATE>
Do NOT proceed with uncommitted changes. The experiment loop rolls back failed experiments by resetting commits — uncommitted work WILL be lost. Stash or commit first.
</HARD-GATE>2. Baseline Measurement
Run the metric command and parse the current value:
# Run the user's metric command
RESULT=$(<metric-command>)Parse a numeric value from the output. If parsing fails, show the raw output and ask the user to refine the --metric command.
Record baseline:
docs/sessions/.optimization-log.tsv:
commit metric_value delta status description lines_added lines_removed
<hash> <value> 0 baseline Starting point 0 0Print:
Baseline: <value>
Target: <target> (direction: <min|max>)
Gap: <difference>
Max experiments: <max>3. Experiment Loop
LOOP (experiment = 1 to max):
3a. Analyze → 3b. Implement → 3c. Commit → 3d. Measure → 3e. Decide → 3f. Log
EXIT when:
- Target reached
- Max experiments exhausted
- 3 consecutive experiments with no improvement (diminishing returns)
- No more improvement ideas identified3a. Analyze & Propose
Study the codebase for the next improvement opportunity. Use grep-first-explore to find relevant code.
Consider:
- What specific change could move the metric toward the target?
- Can this be achieved by removing or simplifying code? (Prefer this)
- What's the expected impact on the metric?
- What's the risk of regression?
Simplicity preference: If two approaches could achieve similar metric improvement, prefer the one that removes code over the one that adds code. Simpler solutions are more maintainable and less likely to introduce bugs.
Print a one-line proposal before implementing:
Experiment <N>: <brief description of the change>3b. Implement
Make the code change. Keep changes focused — one idea per experiment. Do NOT combine multiple unrelated changes in a single experiment (makes it impossible to attribute metric movement).
3c. Commit (Checkpoint)
Stage and commit the change as an experiment checkpoint:
git add -A
git commit -m "experiment: <brief description>"This commit exists so we can cleanly rollback if the metric regresses.
3d. Measure
Run the metric command again. Parse the new value.
Crash handling: If the metric command fails (non-zero exit, no parseable output):
- Read the last 50 lines of output for error diagnosis
- Attempt ONE fix (typo, missing import, syntax error)
- If fix works: re-measure
- If fix fails: mark as
crash, rollback, continue to next experiment
# If command fails or output isn't parseable:
git reset --soft HEAD~1 # Undo the experiment commit
git restore . # Discard the experiment's changes
# Log as crash, continue loop3e. Decide: Keep or Discard
Compare new metric value against the best value so far:
IF (direction == max AND new_value > best_value) OR
(direction == min AND new_value < best_value):
→ KEEP: Branch advances. Update best_value.
ELSE:
→ DISCARD: git reset --soft HEAD~1 && git restore .Important: Compare against best value, not baseline. The frontier only advances.
Print decision:
Experiment <N>: <description>
Result: <new_value> (was: <best_value>, delta: <change>)
Decision: KEEP ✓ / DISCARD ✗
[If KEEP: New best: <new_value>, gap to target: <remaining>]3f. Log
Append to docs/sessions/.optimization-log.tsv:
<commit-hash> <metric_value> <delta_from_best> <keep|discard|crash> <description> <lines_added> <lines_removed>Lines added/removed from git diff --stat HEAD~1 (for kept experiments) or from the discarded diff.
4. Diminishing Returns Detection
Track consecutive non-improvements. If 3 experiments in a row are discarded (no metric improvement):
- Print: "3 consecutive experiments without improvement."
- Consider a different approach category — if you've been tuning parameters, try restructuring; if restructuring, try a different algorithm
- If the next experiment also fails: stop the loop early
- Report: "Stopped early: diminishing returns after
<N>experiments"
5. Completion Report
### Optimization Complete
**Goal:** [description]
**Metric:** [command]
**Direction:** [min|max]
**Results:**
- Baseline: [initial value]
- Final: [best value]
- Target: [target value]
- Improvement: [delta] ([percentage]%)
- Target reached: [Yes/No]
**Experiments:** [total] run, [kept] kept, [discarded] discarded, [crashed] crashed
**Experiment Log:**
| # | Description | Value | Delta | Status |
|---|-------------|-------|-------|--------|
| 0 | Baseline | ... | — | baseline |
| 1 | ... | ... | ... | keep/discard |
**Simplicity:** Net code change: +[added] / -[removed] lines ([net] net)
**Remaining gap (if target not reached):**
- [What else could be tried]
- [Why further improvement may be difficult]Safety
- Git safety: Every experiment is a commit. Discards use
git reset --soft HEAD~1 && git restore .(safe alternatives to blockedgit reset --hard). Only the latest uncommitted experiment can be lost on crash — all previous kept experiments are safe in git history. - Working tree guard: Hard gate prevents starting with uncommitted changes.
- Crash isolation: Failed metric commands trigger at most one fix attempt before rollback.
- Diminishing returns: Auto-stop after 3+ consecutive failures prevents infinite loops.
- Branch protection: Pre-flight checks refuse to run on main/master.
- Max cap: Default 20 experiments, configurable up to any limit.
When to Use
- Improving test coverage toward a target percentage
- Reducing bundle size, build time, or binary size
- Eliminating lint warnings or type errors
- Optimizing benchmark scores (latency, throughput)
- Any task with a clear numeric metric and a target value
When NOT to Use
- Tasks without a measurable, command-line-accessible metric
- Subjective quality improvements (use
/refine-loopinstead) - During story-cycle execution (use story-cycle's own phases)
- On main/master branch (create a feature branch first)
Relationship to Other Skills
/refine-loop— Criteria-based iteration (subjective). Use/optimizewhen you have a measurable metric; use/refine-loopwhen quality is assessed by inspection./story-cycle— Story delivery workflow./optimizeis a standalone tool for metric improvement, not part of the sprint workflow./undo-work— Manual rollback./optimizehandles its own rollback automatically via git checkpoint/reset.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

