Design Panel

Design Panel

Get independent multi-lane generation of candidate designs on one pinned problem BEFORE a single design exists, then converge them through one mandatory synthesis into the sole planner-eligible artifact.

This is the Codex-line binding of the provider-neutral design-panel methodology. The design trunk (shared/references/design-panel-methodology.md) is NOT installed; this skill carries the operative rules for the Codex runtime.

Codex execution model (sealed external candidate lanes)

DP3-NATIVE-ROUTE-UNVERIFIED: native subagent sealing depends on runtime configuration this skill does not inspect, so it is not an eligible candidate route. Every candidate uses the existing direct $external-worker boundary with file-based prompt delivery. An absent CLI, died lane, or empty output is caught visibly by DP7 as UNVERIFIED or BLOCKED:dependency; no internal fallback may replace an unavailable external candidate.

Candidate launch arguments MUST NOT select or resume an existing provider session: Claude --continue/-c, --resume/-r, --session-id, --fork-session, --from-pr, and --teleport, plus the Codex exec resume route, are forbidden. Inspect the resolved provider argv before launch; a session-reuse route makes that candidate UNVERIFIED and it is never counted toward quorum.

• Each candidate lane is dispatched as a design-capable worker run (per $external-worker and external-dispatch.md), carrying the identical pinned input; only the framing overlay differs.
• Where the host runtime cannot launch a lane concurrently, run the lanes sequentially in fresh external contexts and synthesize their outputs afterward; sequential execution does not change the panel's logic, only its concurrency — each lane still needs a fresh context that has not seen a sibling lane's output.
• Count an external lane only after the approved thin wrapper owner in lead/external-dispatch.md accepts its terminal result through the strict V2 parser, full external-nonauthorizing tuple, and untrusted/potentially-sensitive resultText contract; a launch is not a candidate.

The design-panel invariants (DP1–DP8)

Steps

1. Read the routing surface. Read and normalize .agents/.agents-mode.yaml first; honor parallelMode, externalProvider, externalPriorityProfile, and the other structured routing keys. Shipped auto stays on the Codex/Claude pair; Kimi is explicit-only Windows-enrolled read-only no-tools bundle review, independently verified and nonauthorizing; Grok remains unavailable in 1.x.
2. Pinned-input gate. Confirm one admitted objective, scope, and evidence/constraint package exist. A panel multiplies an unverified premise across every lane — verify it first.
3. Choose N and framings. Default N=2. Pick a distinct, bounded framing per lane and pre-register them (lane id, framing, resolved role) before dispatch.
4. Dispatch the candidate lanes through the external surface, each carrying the identical pinned input and its own framing, with file-based prompt delivery (write the prompt body to a temporary file; argv stays for launcher flags and file paths). Inspect the resolved provider argv and fail closed on every session-reuse route listed by DP3-NATIVE-ROUTE-UNVERIFIED. Run concurrently when the runtime supports it, else sequentially in fresh contexts. Each lane writes its candidate to design-<lane>.md, never design.md.
5. Collect. Count each lane only after the approved thin wrapper owner returns its terminal result through the strict V2 parser, full external-nonauthorizing tuple, and untrusted/potentially-sensitive resultText contract. A died, timed-out, or empty lane is UNVERIFIED — re-run it with the same framing; never silently reduce quorum below N=2.
6. Synthesize. The orchestrating session performs the synthesis directly (never a spawned "synthesizer" run acting as a stand-in lead, and never a candidate author). Produce the comparison/disposition matrix and write the sole canonical design.md, citing every candidate as evidence.
7. Return exactly one public result: the synthesized design and its gate (PASS | REVISE | BLOCKED:dependency | BLOCKED:prerequisite). Never present one candidate as "the design." Candidate artifacts stay as work-item inputs and are never handed to the planner.

Skip-guards (defense in depth — both apply)

1. Canonical-filename reservation — candidate lanes write design-<lane>.md; only synthesis writes design.md. The existing plan-stage gate already requires design.md, so a skipped synthesis leaves no artifact the pipeline can consume. This is the STRUCTURAL skip-prevention mechanism.
2. Ledger convention (RECOMMENDED, AUDITABLE — not a validator-enforced gate) — when task memory is active, a candidate run is recorded in the work-item's agent-runs.jsonl as status: completed, gate: RETURN(lead) — never design-stage PASS; only the synthesis run should use PASS, citing every candidate as evidence. A smoke probe confirmed the source helper scripts/validate-work-item-state.py (installed at .agents/skills/lead/scripts/validate-work-item-state.py for repo-local installs, $HOME/.agents/skills/lead/scripts/validate-work-item-state.py for global installs) does NOT mechanically reject a candidate run marked PASS, nor a RETURN(lead) run missing a cited artifact — this convention is an auditable review trail, not a fail-closed gate. The actual structural skip-prevention is skip-guard #1 above plus the INPUT_ONLY candidate label. No new ledger schema is introduced.

Synthesis artifact contract

The synthesis owner is the orchestrating session, performing synthesis directly (never a spawned "synthesizer" run, never a candidate author). The synthesis artifact (design.md) must contain:

1. the pinned input and a one-line scope-conformance check;
2. the panel roster: lane, framing, resolved execution path/model, candidate path;
3. an independence check (fresh context, no sibling-output exposure);
4. the SET-level comparison/disposition matrix (columns: claim/surface, lane source, agreement-or-unique, conflict, evidence checked, final disposition + rationale);
5. unresolved conflicts, or a specific "none" rationale;
6. one coherent final design package, including the Change-Surface Contract;
7. final numbered {guarantee, single-owner, enforcement-probe} claims;
8. canonical proposed decision-registry IDs for any cross-cutting/long-lived decision;
9. final PASS | REVISE | BLOCKED:<class>.

PASS is valid only when the run is completed, points to the synthesis artifact (design.md), and cites one evidence entry per candidate plus the comparison itself. Candidate artifacts carry none of items 6-8 (DP6).

Rules

• This is a utility skill, not a new specialist role, and not a replacement for $lead.
• Only the synthesis step may write design.md; candidate lanes never see each other's output.
• Do not silently downgrade an external lane to internal execution.
• Do NOT commit, push, or install from this skill. Implementation stops at the human commit gate.

Non-goals

• Not an ordinary single-architect design chain (that is $design).
• Not a review loop that verifies one already-existing artifact (that is $review-loop).
• Not a single advisory opinion (that is $second-opinion / $consultant).
• Not disjoint parallel helper lanes that each own a different artifact (that is $external-brigade).
• Not for a single-module additive design, and not for a problem statement that is still unverified.

Terms and Abbreviations

• candidate: one independently-framed lane's design output; complete enough to compare but not eligible for downstream use by itself (Panel disposition: INPUT_ONLY).
• framing: the distinct scope, angle, or problem decomposition assigned to one lane; the source of independence, not the vendor.
• fresh context: an execution context that has not seen a sibling lane's prompt or output.
• synthesis: the required comparison/merge step that produces the only planner-eligible design.
• RETURN(lead): the ledger gate shape used to return a completed candidate run without declaring design-stage PASS.
• PASS / REVISE / BLOCKED: gate verdicts — accept, return for bounded correction, or stop on a real external blocker.