Maestro Improve

<!-- maestro-skill-version: dev -->

maestro-improve

Use when a Lead assigns improvement work on one target to a Peer. The target is the only parameter; a separate Peer challenges the returned candidate before acceptance.

A correction that stays in a transcript is spent when that session ends. The lesson record is what survives, and doctrine is the only thing a future session actually reads. This skill is the one place the two are joined: it turns filed corrections into the smallest edit that would have prevented them.

The parameter

The target names the doctrine a lesson corrects: a recipe section, the SLP Workspace Pack in src/plugins/resources/SLP.md, a Hub template, a skills/maestro-* file, or a repository's Workspace Protocol. Where each one lives, and what an edit to it costs, is in references/targets.md.

The loop

maestro lesson list --project <project>     # pending only, by design
maestro lesson show <id>                    # the gap, the expectation, the why

• Group the pending lessons by target. Two lessons on one rule are one edit, not two, and the second one is usually what tells you which reading of the rule was ambiguous.
• Per group, propose the smallest edit that would have prevented what happened. Doctrine is read under load, so a sentence that removes an ambiguity beats a paragraph that adds a procedure. If the existing text already says it, the lesson is a rejection, not an edit.
• The smallest edit may be a deletion. A mechanism - a seat, a review pass, a push, a sentence - earns its place by the outcomes it changed, not by how often it ran: where the lessons show one that added traffic and changed no result, remove it rather than add a counterweight. A repeating failure is first answered by moving the responsibility to the seat that owns it, not by another role, checklist or approval round, and three times a mechanism helped is not a reason to run it more often.
• One commit per target group, on a branch, with the evidence ids of every lesson in the group in the message. The ids are how a later reader gets from the rule back to the incident that shaped it.
• Mark each lesson processed by pointing at that commit:

maestro lesson process <id> --commit <sha>

The improver never deletes a lesson and never edits one. Processing is a pointer, so the record of what was corrected stays readable after the doctrine it corrected has changed again.

A lesson whose hazard is mechanical is not answered by a sentence. Where the hazard has a mechanical form available - a helper that removes the unsafe shape, a refusal, a check that fails - the edit is that mechanism, and the return names which mechanism now makes the recurrence impossible rather than which sentence now warns about it. Where none is possible, say so in the return. A described remedy fails invisibly until it recurs, and its recurrence reads as carelessness, which tends to produce a second warning rather than a mechanism (l26, the recurrence of l8).

Rejecting a lesson

A lesson can be wrong: the rule already covers it, the correction misread it, or two lessons disagree and only one survives. Answer it where it lives and mark it processed in the same command:

maestro lesson process <id> --answer "<why this produced no edit>"

The answer is for whoever filed it. "Out of scope" is not an answer; name the text that already covers it, or the reading that was wrong.