feat(workflow): add ELI5 review views at the plan and finish gates

Feature Description

Trellis planning artifacts are intentionally detailed because agents need requirements, design decisions, implementation steps, context, and acceptance criteria. The problem is not that the plan should contain less information. The problem is that the human has to scan the same agent-oriented material when approving the plan and reviewing the finished work.

I propose an ELI5 review layer at the two human-facing workflow gates:

1. Plan review — after planning artifacts converge and before the user approves task.py start.
2. Finish review — after implementation and verification, as part of finish-work before the task is fully handed off/archived.

At each gate, Trellis should generate a self-contained HTML artifact inspired by the ELI5 interaction pattern: big visual structure, plain language, and few words. The full PRD, design, implementation plan, checks, and evidence remain unchanged and authoritative.

Plan review view

The plan view should answer at a glance:

• What are we changing?
• Why does it matter?
• How will it work? — a small flow or picture when useful.
• What is in and out?
• How will we know it is done?
• Which decision or risk needs the user's attention?

It should link back to the full prd.md, design.md, and implement.md artifacts rather than copying all their detail.

Finish review view

The finish view should answer at a glance:

• Before → after — what changed for the user or system.
• What shipped?
• What proves it works? — the important checks/tests, not raw logs.
• Did the result match the approved plan?
• What remains, if anything? — known limitations, deferred work, or risks.
• Where is the full evidence? — task artifacts, commits, and verification details.

If implementation diverged from the approved plan, the finish view must show the difference clearly rather than smoothing it over.

Product boundaries

• This is a derived human review view, not a replacement source of truth.
• It does not shorten the PRD, remove planning questions, skip checks, or weaken approval gates.
• It does not change task classification, implementation, or verification behavior.
• It should not be injected into implementation/check agents as extra context.
• The upstream feature should be Trellis-owned and platform-neutral; it may be inspired by the Codex eli5 skill, but must not depend on a user's locally installed skill.
• The two artifacts should travel with the task into the archive so the approved picture and final picture remain easy to compare.

One possible implementation is a shared trellis-eli5-review skill with plan and finish modes, invoked by the existing planning-review and finish-work flows. Exact naming is open to maintainer preference.

Suggested acceptance criteria

• The final planning gate produces an ELI5-style HTML review derived from the converged planning artifacts.
• finish-work produces an ELI5-style HTML review derived from the approved plan, actual changes, commits, and verification results.
• Each view uses visual hierarchy, plain language, and a small number of scannable concepts.
• Each view links to the full authoritative evidence without duplicating it wholesale.
• The finish view explicitly reports plan/result differences and remaining work.
• Existing planning artifacts, safety gates, implementation behavior, and checks remain unchanged.
• The behavior comes from shared Trellis sources and is available consistently across supported platforms.

Motivation

Trellis currently serves two audiences with the same material:

• agents need complete, precise artifacts;
• humans need to understand and approve the big picture quickly.

The current brainstorm contract requires a final summary containing Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, Risks/Deferred Items, and artifact status. That is rigorous, but it is still a text-heavy presentation assembled in chat.

The current finish-work flow focuses on dirty-state checks, archiving, and recording the session journal. It does not require a durable, human-facing explanation of what changed, whether it matched the plan, and what evidence proves completion.

An ELI5 layer gives Trellis a deliberate dual representation:

Full fidelity for the agent; fast comprehension for the human.

This is inspired by the ELI5 skill's use of big pictures and few words. It is not asking Trellis to think less or plan less—only to explain the result better at the moments when the human must review it.

Alternatives Considered

1. Make PRDs and implementation plans shorter. This removes context that implementation and check agents may need, and does not address the finish stage.
2. Rely on ordinary chat summaries. They are inconsistent, easy to lose in long sessions, and do not provide a durable before/after pair.
3. Run a separate local ELI5 skill manually. This depends on the user's platform and installed skills, and is easy to forget at exactly the two workflow gates where it matters.
4. Add a separate simple workflow mode. The workflow itself does not need to become simpler. Only the human review representation needs to change.
5. Add only a finish report. Humans also need a scannable picture before approving implementation; paired plan/finish views make drift visible.

Related work (not duplicates)

• #320 removed redundant PRD material after brainstorming, but did not add a separate human review representation.
• #288 concerned preserving original requests and key confirmations for traceability, not visual plan/finish review views.
• #158 discussed general workflow and context mental load, mainly for long-running execution.
• #379 proposes a finish-stage artifact for frontend API changes, while this proposal is a generic human review layer for every task.