self-improvelisted

Improve **this repository** (the task-pipeline skills repo itself) — not by fixing rule violations (that is [`/self-audit`](../self-audit/SKILL.md)), but by raising quality where nothing is broken yet. Four lenses run in parallel as named read-only subagents: **Clarity**, **Leanness**, **Coverage**, **Ergonomics**. ## improve vs audit — the split that defines this skill `/self-audit` asks *"does the repo obey its own declared rules?"* — it has an oracle (CLAUDE.md invariants, the artifact contract in `docs/contract.md`, the real `skills/` tree), the fix direction is determined, and every gated finding is applied. `/self-improve` asks *"nothing is violated — but where is the repo weaker than it could be?"* — there is **no oracle**. An "improvement" is a judgement call, and its direction is a design decision, not a mechanical correction. That is the literal difference between fixes (audit) and improvements (improve), and it drives the whole apply model: - **Audit applies everything that passes its gate** — the source of truth says which way to go. - **Improve applies only a narrow, mechanical, behavior-preserving subset automatically**, at a higher confidence bar, and **proposes** everything that changes the design for the user to greenlight. Improvements that reshape a flow, merge sections, or add a guardrail are decisions a human must nod at. **Boundary rule (hard):** if a lens finds an actual violation of a declared rule (an invariant, a producer↔consumer mismatch, READ