feat(optimize): share the efficiency objective

autotune, autoskill and confidence each carried their own idea of what an
improvement is, and autotune's two efficiency rules were the same sentence
twice. They now route to one skill that names three axes to move at once —
fewer tokens, less time, higher quality — and the rules that decide when a
proposal counts: at least one axis better, none damaged, quality never the
currency, observed friction instead of a guessed percentage.

Applying its own rule, autotune gets shorter rather than longer. The test
holds the coupling, so a later rewrite cannot silently drop a route.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/autoskill/SKILL.md

@@ -7,6 +7,10 @@ description: >
   and the pattern is general enough to reuse. Portable across projects.
 ---
 
+Its objective is the `optimize` skill's: a skill is worth creating only when it
+cuts tokens or time and raises quality — judge every candidate against that
+skill's three axes and rules.
+
 When you notice the operator repeating the same kind of instruction,
 correction, or prompt pattern (about three occurrences, exact wording may
 vary), do the following:

skills/autotune/SKILL.md

@@ -13,6 +13,10 @@ Autotune turns observed friction into durable skills. It runs on demand only,
 it changes nothing without an explicit answer from the operator, and every
 skill it writes or rewrites lands in the operator's skills repository.
 
+Its objective is the `optimize` skill's: every proposal must cut tokens or time
+and raise quality — follow that skill's three axes and rules, and drop any
+candidate that moves none of them.
+
 ## Trigger discipline
 
 - Run **only** when the operator asks: `/autotune`, "autotune", "tune the
@@ -111,7 +115,6 @@ reverse — remove the mirrors too, or the old name keeps firing.
   whole collection is not what autotune is for.
 - Never write a skill for one-off work, for secrets, or for behaviour an
   existing skill already covers - propose extending that skill instead.
-- A skill that saves tokens but loses correctness is a regression; validation,
-  error handling, and security steps are never the thing that gets trimmed.
-- Efficiency claims stay honest: name the observed friction the skill removes,
-  never a guessed percentage.
+- The `optimize` skill's rules decide what counts as an improvement: at least
+  one axis better, none damaged, and the claim named as observed friction rather
+  than a guessed percentage.

skills/confidence/SKILL.md

@@ -27,3 +27,9 @@ Calibration rules:
   hidden layers may follow, and give both numbers.
 - Static analysis alone caps at the low nineties; only executed evidence
   (test, reproduction, live probe) justifies more.
+
+Objective: the `optimize` skill's. The number exists to save the operator a
+verification round trip (time), to stop a rework cycle before it starts
+(quality), and to replace a long hedging paragraph with two figures and their
+residuals (tokens). A confidence block that costs more than it saves — padding,
+repeated caveats, a number without residuals — misses its own objective.

skills/optimize/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: optimize
+description: >
+  The shared objective of the self-improving skills: raise efficiency — fewer
+  tokens, less time — and raise quality at the same time. Trigger from autotune,
+  autoskill and confidence, which route their objective here, and on /optimize
+  when the operator asks how to make the agent's own work cheaper, faster or
+  better. Portable across projects.
+---
+
+Every skill, rule, or report the agent produces about its own working is judged
+on three axes at once. A proposal that cannot name the axis it moves is not an
+optimization, it is a preference.
+
+## The three axes
+
+- **Tokens** — fewer input and output tokens for the same result: read the range
+  instead of the whole file, grep the saved log instead of re-running the
+  command, route to an authoritative doc instead of duplicating it, report in
+  lines instead of paragraphs.
+- **Time** — fewer round trips and less waiting: independent calls in parallel,
+  one command that answers the question instead of three that circle it, no
+  polling for work the harness will report on its own.
+- **Quality** — fewer errors and less rework: verification instead of
+  assumption, and learnings that persist so the same mistake is not paid for
+  twice.
+
+## Rules
+
+- A change must improve at least one axis and damage none. Output that got
+  cheaper but lost correctness is a regression, not an optimization.
+- Quality is never the currency: validation, error handling, tests, and security
+  steps are not what gets cut to save tokens or time.
+- Measure, do not guess: name the observed friction — the re-read, the retry,
+  the correction the operator had to give twice — and what it cost. A guessed
+  percentage is not a measurement.
+- The cheapest step is the one that does not run: drop work before optimizing
+  it.
+- Persist it or pay again: an optimization that lives only in this session is
+  re-derived in the next one, so it belongs in a skill or a memory entry.

tests/test_optimize.py

@@ -0,0 +1,27 @@
+"""The self-improving skills must share the optimize objective."""
+
+from __future__ import annotations
+
+import unittest
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+SKILLS = REPO_ROOT / "skills"
+ROUTERS = ("autotune", "autoskill", "confidence")
+
+
+class TestOptimizeObjective(unittest.TestCase):
+    def test_skill_names_the_three_axes(self):
+        text = (SKILLS / "optimize" / "SKILL.md").read_text(encoding="utf-8")
+        self.assertIn("name: optimize", text)
+        for axis in ("**Tokens**", "**Time**", "**Quality**"):
+            self.assertIn(axis, text)
+
+    def test_routers_point_at_it(self):
+        for skill in ROUTERS:
+            text = (SKILLS / skill / "SKILL.md").read_text(encoding="utf-8")
+            self.assertIn("`optimize` skill", text, f"{skill} does not route to optimize")
+
+
+if __name__ == "__main__":
+    unittest.main()