llp-super-refine

name	llp-super-refine
description	Repeatedly review and revise one LLP with fresh Claude Fable 5 Max and OpenAI gpt-5.6-sol Ultra reviewers until both independently find it ready, recording every real review with LLP 0005 provenance, then move a Draft document to Review. Use when the user invokes /llp-super-refine or asks for an LLP to undergo the automatic dual-model refine-until-ready loop.

llp-super-refine

Run an opinionated, author-authorized specialization of llp-review: two fresh reviews per round, revisions by the orchestrating Claude session, and convergence on Review rather than Accepted.

Invoke as /llp-super-refine <number | slug | filename>. If the target is omitted or ambiguous, list the Draft/Review candidates and ask the user to select one.

Runtime contract

• Run the orchestration from Claude Fable 5 with Max effort. If the current runtime is not Claude Fable 5 Max, stop and tell the user to invoke the skill there.
• Use a fresh Claude Fable 5 Max context as one reviewer in every round. The orchestrating session edits the LLP and therefore never counts as this independent review.
• Use a fresh OpenAI gpt-5.6-sol Codex CLI session at ultra reasoning effort as the other reviewer in every round.
• Give both reviewers the same LLP revision and prevent either from reading the current round's other review. Do not resume reviewer sessions between rounds.

LLP 0005 invariants

• Never fabricate, reconstruct, or record a review that was not actually received.
• Record one artifact per reviewer family under llp/reviews/NNNN-slug.<family>.md. Use .fable.md and .codex.md; append a dated, numbered section for later rounds and never overwrite earlier reviews.
• Open every artifact or round section with provenance: family, exact provider/runtime and effort, date, redaction status, and method. Preserve the received review body verbatim; put orchestrator verification or disposition notes outside that verbatim body.
• Do not send the document to an external provider unless this skill was explicitly invoked by a human. Redact secrets by default.
• Never move a document to Accepted, Implemented, or another terminal state. /llp-super-refine authorizes only the Draft to Review transition described below.

Review brief

Ask each reviewer to read the entire current revision and the governing/referenced LLPs and code needed to verify load-bearing claims. Use the LLP 0005 standard questions:

What do you think of this proposal? Is it a good idea? Do we have a good plan here? How would you change it to make it better? What would you add or take away or change? Is anything definitely or possibly wrongheaded here? Do you have any novel ideas that you think might make this way better even if they are a bit non-standard? What are the key open questions we need to answer to refine this?

Require this structure: overall assessment; strengths with section citations; concerns with severity, evidence, and resolution criteria; suggestions; open questions; explicit readiness verdict. Define ready as having no unresolved material correctness, coherence, feasibility, safety, or decision-quality concern. Optional polish may remain if clearly labeled non-blocking.

For Codex, use a non-interactive read-only run equivalent to:

codex exec -m gpt-5.6-sol -c 'model_reasoning_effort="ultra"' -s read-only --output-last-message <output-file> -C <repo> <prompt>

Capture the actual CLI version, model, effort, and session ID from the run in provenance. If ultra or gpt-5.6-sol is unavailable, stop rather than silently substituting.

Loop

1. Locate and read the LLP fully. Read llp/0005-rfc-process.guide.md, relevant authorities, existing review artifacts, and the working-tree diff. Preserve unrelated user changes.
2. Identify the exact revision under review so later artifacts can distinguish rounds. Do not expose prior review findings to the fresh reviewers; the document's own revision history is allowed.
3. Launch the fresh Fable and Codex reviews independently, preferably concurrently. Wait for both actual results.
4. Save both reviews with honest provenance. Spot-check every decisive factual claim against the repository and note the result without altering the verbatim review.
5. Reconcile the two verdicts yourself:
   • If either review has a material concern, revise the LLP to address it. Use judgment rather than mechanically accepting feedback; explain rejected material feedback in the next round's context only through the revised document or an explicit disposition note in the artifact.
   • Update **Revised:** and any revision summary the document convention requires. Keep Draft or Review unchanged during revision.
   • Start a wholly fresh round at step 2. Every revised version must receive both new reviews.
6. Stop only when both reviewers independently mark the same revision ready and your factual checks reveal no material defect.
7. If that converged revision has **Status:** Draft, change it to **Status:** Review. If it is already Review, leave it there. Do not advance it further.
8. Report the rounds completed, revisions made, artifact paths, final status, and any explicitly non-blocking residue.

Failure and scope boundaries

• If a reviewer fails, times out, or returns an unusable review, retry with a fresh session; do not count the failed attempt or invent its artifact.
• If feedback requires a fundamentally different design or a new LLP, stop and ask the author before expanding scope; use llp-create after authorization.
• If convergence cannot be reached because the reviewers expose a human product decision, stop with the document at its current status and ask the user for that decision.