Plan-optimizer skill

---
name: plan-optimizer
description: >-
  Iteratively optimize a plan by scoring it against a rubric, critiquing it, and
  rewriting it until the score plateaus. Use this skill whenever the user wants
  to refine, improve, harden, stress-test, or "make the best possible" version
  of a plan of any kind — project plans, execution/rollout plans, code
  implementation plans, research plans, strategy memos, study plans, training
  plans, go-to-market plans, or proposals. Trigger it when the user says things
  like "improve this plan", "iterate on this until it can't get better", "score
  and refine my approach", "find the holes in this plan", "make this plan
  bulletproof", or describes wanting an automatic improve-and-score loop. Also
  use it proactively when the user shares a draft plan and asks "is this good?"
  or "what would make this better?" — the loop produces a measurably stronger
  plan than a single critique pass.
---

# Plan Optimizer

This skill turns plan-writing into a search problem. Instead of producing one
plan and hoping it's good, you generate a plan, **score it numerically against
an explicit rubric**, **critique it**, **rewrite it to fix the weaknesses**, and
repeat — keeping the best version seen so far — until the score stops improving.
That plateau is your signal that further iteration is just noise, and you stop.

The reason this works is that scoring and rewriting are *separate* acts.
Generating a plan and judging a plan use different cognitive muscles; forcing an
explicit critique between revisions converts blind rewriting into directed
search that climbs toward a target rather than drifting sideways.

## When to use this

Use it whenever there's a plan that should be as good as it can reasonably get
and the cost of a weak plan is real. If the user just wants a quick first draft,
don't impose the whole loop — offer it. If they want the *best* plan, run the
loop.

## The loop at a glance

```
plan        = generate the initial plan from the task
best        = plan
best_score  = score(plan)            # 0-100, against the rubric
history     = [best_score]

repeat:
    candidate = improve(best)        # critique -> targeted rewrite
    s         = score(candidate)
    if s > best_score + MARGIN:      # require a real margin, not noise
        best, best_score = candidate, s
    history.append(best_score)
until plateau(history)               # no real gain over the last K rounds
return best, history
```

Run this in your head / in the conversation, not as code — the "functions" are
reasoning steps you perform. Keep all intermediate plans and scores so you can
show the trajectory at the end.

## Step 1 — Build the rubric first

Before writing any plan, write the rubric. **The rubric is the ceiling**: the
loop can only climb as high as the rubric lets it perceive quality, so a vague
rubric gives you a low, noisy ceiling. Spend real effort here.

A good rubric is domain-adapted, weighted, and as objective as possible. Derive
the criteria from what would actually make *this* plan succeed or fail, not from
a generic checklist. Most strong plans, whatever the domain, are graded on some
mix of:

- **Goal clarity** — is the objective and definition of "done" unambiguous and measurable?
- **Completeness** — are the necessary steps/workstreams present, with nothing load-bearing missing?
- **Sequencing & dependencies** — is the order right; are prerequisites identified?
- **Feasibility & resourcing** — is it realistic given time, people, budget, constraints?
- **Risks & mitigations** — are the real failure modes named, with contingencies?
- **Success metrics** — are there concrete signals that tell you it's working?
- **Specificity** — is it actionable (owners, dates, concrete first step) rather than vague aspiration?

Assign each criterion a weight that reflects its importance for this task, and
state, briefly, what a low/medium/high score looks like for each. Prefer
criteria you can check against something objective (does the plan name a first
action? does every phase have an exit condition?) over purely subjective taste —
objective criteria resist gaming.

Show the rubric to the user before you start iterating if there's any ambiguity
about what "good" means for them; their priorities (speed vs. thoroughness,
risk-aversion vs. ambition) should shape the weights.

## Step 2 — Generate the initial plan

Write a genuine first attempt at the plan that addresses the task. Don't
sandbag it to make the loop look impressive — a strong starting point reaches a
higher final ceiling. Then score it against the rubric (Step 3).

## Step 3 — Score

Score the current plan from 0 to 100. Do this as a deliberate, separate pass:
go criterion by criterion, assign each a sub-score, note *why*, then combine by
the weights. Always write a one-line rationale per criterion — the rationale is
what feeds the next critique, and it's what keeps scoring honest rather than a
gut number.

Two guards against noisy scoring:

- **Require a margin to accept.** Only replace the current best if the new score
  beats it by a meaningful margin (e.g. +2 on a 100 scale), not by a fraction.
  Scoring has noise; without a margin you'll "improve" into a worse plan.
- **Re-anchor occasionally.** Every few rounds, re-read the *original* rubric
  fresh rather than drifting toward whatever the latest plan happens to do well.
  This catches reward-hacking, where revisions start optimizing for a score the
  rubric didn't really intend.

## Step 4 — Improve (critique, then rewrite)

This is the engine. Do **not** just say "make it better" and rewrite — that
produces lateral drift. Instead, in two explicit moves:

1. **Critique.** Against the rubric, list the specific weaknesses of the current
   best plan, ordered by how much they cost in score. Be concrete: "no rollback
   step for the migration", not "could be more robust". Name the lowest-scoring
   criteria and why they're low.
2. **Rewrite.** Produce a new full version of the plan that directly fixes the
   critique's top items, while preserving what already scored well. Don't
   regress strengths to chase a weakness.

### Two search strategies — pick one, switch when stuck

- **Hill-climb (default).** One critique→rewrite candidate per round. Fast and
  cheap. Use this unless told otherwise. Its weakness is local optima — small
  fixes that can't reach a fundamentally better structure.
- **Best-of-N.** When hill-climbing stalls (see plateau, Step 5) but you suspect
  the plan needs a structural rethink, generate **N** genuinely different
  candidates in one round — not minor variants, but different framings or
  architectures of the plan — score all N, and keep the best. This widens the
  search and is how you break through a ceiling that incremental edits can't.
  N=3 is a sensible default; more candidates cost more.

A good automatic policy: hill-climb until you hit a plateau, then do **one
best-of-N round** to try to escape the local optimum. If best-of-N also fails to
beat the ceiling by the margin, you've genuinely converged — stop.

If the user has access to a stronger model than the one running the loop, note
that running the *improve* and *score* steps on a stronger model is the single
biggest lever: a stronger model proposes structurally better rewrites and also
perceives flaws a weaker scorer misses, which raises the ceiling itself.

## Step 5 — Stop on plateau

Track the best score over a sliding window of the last K rounds (K=3 is
reasonable). Stop when **the best score has not improved by more than the margin
over the last K rounds** — that's the "iterations have become noise" point.
Also stop if you hit a sensible max rounds (e.g. 6–8) regardless, so the loop
always terminates. Before declaring convergence on a hill-climb plateau, try the
one best-of-N escape round described above.

## Step 6 — Output

Return:

1. **The best plan**, clean and ready to use — this is the deliverable, lead with it.
2. **Its final score** with the per-criterion breakdown.
3. **The score trajectory** (e.g. `62 → 74 → 81 → 83 → 83`) so the user sees the
   climb and the plateau.
4. **A short note on what the loop changed** — the 2–3 biggest improvements made
   from first draft to final, so the user understands *why* it's better.

Keep the process visible but concise. The user cares most about the final plan;
the trajectory and rationale are evidence that it's been genuinely hardened, not
just reformatted.

## Pitfalls to watch

- **Reward hacking the rubric.** If scores climb but the plan doesn't feel
  better, the rewrites are gaming the metric. Re-anchor on the original intent,
  and prefer objective criteria.
- **A weak rubric capping everything.** If you plateau low, suspect the rubric
  before the plan. A ceiling that feels too low often means the rubric can't see
  the dimension that matters — add or reweight a criterion.
- **Reformatting masquerading as improvement.** Bigger/prettier ≠ better.
  Improvements should change substance (a missing risk, a fixed dependency), not
  just structure. The margin guard helps; so does an honest critique.
- **Never stopping.** Respect the plateau and the max-rounds cap. Past the
  plateau you're spending effort to move noise around.