[ancelin-code]

What and why

A lane went straight from delivery-implement to a draft pull request. The
human at the merge gate was the first to review the change, and nothing
simplified it, although that human is the bottleneck the kit is built around.

A sixth skill, delivery-refine, runs as the lane's second session. It works
in one pass:

1. Review the change against the task's acceptance criteria and the edge-case
   and verification-gap lenses.
2. Fix the findings that name a concrete failure.
3. Simplify only the lines the change added, without altering their behaviour.
4. Re-run validation.
5. Add a Refinement section to the report that becomes the pull request
   body.

Design and evidence: ADR-011.

• A stronger reviewer:
  • By default the review runs one tier up: chore is reviewed as build,
    build as plan, plan as plan, on that tier's harness and model.
  • A tier can name its own reviewer in tiers.conf instead.
  • A cross-model review study found same-model fresh-context review no better
    than self-review, and a stronger reviewer best.
• The implementation is never lost: a failed refinement is logged as
  REFINE-FAILED, noted in the report, and the change is published as it
  was. --no-refine skips the session.
• Every harness: the launcher starts the session through harness.sh, so it
  works on every adapter, rather than on one harness's subagents.
  harness_prompt now takes the skill's name from its path.

How to review

• Start with delivery-refine/SKILL.md. The order is deliberate: fixing before
  simplifying means no effort goes into code about to change. The list of
  simplifications to make and to avoid draws on Anthropic's code-simplifier,
  Claude Code's /simplify, EveryInc's ce-simplify-code and
  addyosmani/agent-skills.
• Then launch-lanes.sh:
  • refine_for picks the review harness and model.
  • The lane's inner shell runs implement, refine when a change exists, then
    publish.
• Breaking: LAUNCHED and WOULD-LAUNCH gain two columns, the review
  harness and model, after the lane's model. The worktree and repository stay
  last. follow.sh reads only the id.
• Merge order: this branch and fix: a lane's branch pushes to itself, not to the default branch #21 both add to the top of CHANGELOG's
  Unreleased list. The code merges cleanly; whichever lands second needs a
  one-line rebase.
• Not validated on a real harness yet: the tests drive the launcher with a
  fake harness. The first real lanes, on tiroir, will be the first real runs.

How to try it

sh .agents/skills/delivery-orchestrator/scripts/launch-lanes.sh --dry-run a-001
# WOULD-LAUNCH  a-001  claude  sonnet  claude  opus  ../lanes/repo/a-001  repo

That output assumes build maps to sonnet and plan to opus. A real lane's
log shows REFINE claude opus between the implementation and PUBLISHED.

Does it earn its place?

It has not been measured yet, and the kit's rule says it must be. It is on by
default on the strength of the maintainer's practice and of the cross-model
review literature. The phase 6 evaluation adds a --no-refine arm and compares
four things: hidden tests passing, human review findings per pull request,
diff size, and cost per lane. If refinement does not reduce human findings or
raise the number of hidden tests passing, it gets turned off by default.