agentleFS
joris887joris887/exosuit/.claude/skills/optimize/SKILL.md

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

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-hubSkill

    arrange

    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-hubSkill

    teach-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

  • zwy123zwySkill

    normalize

    将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。

    Also in 19 projects that use this

  • open-coder-aiSkill

    policy-init

    Create conformant Chock policy from request. args(request, target_path,

    Also in 3 projects that use this

  • +8 more from HK-hub

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
  1. Distinctive:

    Update at each experiment iteration.

    line 66
  2. Very specific:

    Run verify-clean-git-state micro-component.

    line 72
  3. Distinctive:

    Do NOT proceed with uncommitted changes.

    line 78
  4. Distinctive:

    Run the metric command and parse the current value:

    line 83
  5. Distinctive:

    Simplicity preference: If two approaches could achieve similar metric improvement, prefer the one that removes code over the one that adds …

    line 130
  6. Distinctive:

    Run the metric command again.

    line 154
  7. Distinctive:

    Crash handling: If the metric command fails (non-zero exit, no parseable output):

    line 156
  8. Distinctive:

    Read the last 50 lines of output for error diagnosis

    line 158
  9. Distinctive:

    If fix works: re-measure

    line 160
  10. Very specific:

    If fix fails: mark as crash, rollback, continue to next experiment

    line 161
  11. Distinctive:

    Consider a different approach category — if you've been tuning parameters, try restructuring.

    line 206
  12. Distinctive:

    If the next experiment also fails: stop the loop early

    line 207
  13. Very specific:

    Git safety: Every experiment is a commit.

    line 243
  14. Distinctive:

    Max cap: Default 20 experiments, configurable up to any limit.

    line 248

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

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

optimize

Optimizing: $ARGUMENTS

Argument Parsing

ArgumentRequiredDefaultDescription
<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|maxNomaxWhether to minimize or maximize the metric
--max <N>No20Maximum 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 min

Failure 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	0

Print:

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 identified

3a. 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):

  1. Read the last 50 lines of output for error diagnosis
  2. Attempt ONE fix (typo, missing import, syntax error)
  3. If fix works: re-measure
  4. 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 loop

3e. 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):

  1. Print: "3 consecutive experiments without improvement."
  2. Consider a different approach category — if you've been tuning parameters, try restructuring; if restructuring, try a different algorithm
  3. If the next experiment also fails: stop the loop early
  4. 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 blocked git 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-loop instead)
  • 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 /optimize when you have a measurable metric; use /refine-loop when quality is assessed by inspection.
  • /story-cycle — Story delivery workflow. /optimize is a standalone tool for metric improvement, not part of the sprint workflow.
  • /undo-work — Manual rollback. /optimize handles its own rollback automatically via git checkpoint/reset.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.