Prometheus Strict

Prometheus Strict

Clean-room OMX planning workflow inspired by the high-level OMO Prometheus concept only. This skill does not copy implementation, prompts, wording, control flow, or runtime code from OMO. It reimplements the idea under this repository's MIT-licensed skill conventions.

Credit: Inspired by OMO Prometheus (code-yeongyu/oh-my-openagent), reimplemented from concept under MIT.

<Purpose>
Prometheus Strict creates a rigorous plan before execution when ambiguity is still risky. It separates three planning voices: Metis clarifies requirements, Momus challenges assumptions and validation gaps, and Oracle synthesizes the handoff-ready OMX-native plan.

The output is a planning-only artifact for $ultragoal and, when independent lanes are justified, $team. When a durable artifact is useful, store or request the final plan under .omx/plans/prometheus-strict/. </Purpose>

<Use_When>

• The task is important enough that a shallow plan could produce wrong work.
• Requirements are partially known but acceptance criteria, boundaries, risks, or validation are incomplete.
• The user wants a strict interview before execution.
• A future $ultragoal story needs durable scope, tests, and handoff sequencing.
• A team split may be needed, but the lanes are not yet safe to assign. </Use_When>

<Do_Not_Use_When>

• The user asks for immediate implementation of a clear, low-risk change; use the normal executor path.
• The task is only a repository lookup or explanation; use explore/analyze as appropriate.
• The user needs adversarial execution QA after code changes; use $ultraqa.
• The user wants hook behavior, Sisyphus behavior, or a start-work port. Those are explicit non-goals. </Do_Not_Use_When>

<Why_This_Exists> OMX already has $plan, $ralplan, and $deep-interview. Prometheus Strict exists for a narrower case: an explicit clean-room strict-planning lane with named clarification, critique, and synthesis roles, plus a durable .omx/plans/prometheus-strict/ handoff contract. It is not a replacement for execution workflows. </Why_This_Exists>

<Execution_Policy>

• Stay planning-only. Do not edit source code during this skill unless the user starts a separate execution workflow afterward.
• Preserve clean-room boundaries. Do not copy or imitate OMO wording, source, prompts, runtime behavior, or control flow.
• Keep non-goals visible: No hook implementation. No Sisyphus/start-work port. No automatic external-production actions.
• Ask high-leverage questions as a batched round when the answers materially change scope, safety, or validation. Reserve one-at-a-time questioning only for dependent question chains where the next question depends on the previous answer.
• If a safe assumption is available, state it and continue.
• Use repository reads when needed to make paths, tests, and handoff commands concrete.
• During Metis planning, run pre-question research fan-out for every non-trivial intent unless the task is trivial, the cited spec is self-contained, or cached evidence already covers the same surface; use explore for repo facts and the exact cheap gpt-5.6-terra researcher lane for external docs / OSS references before asking the user. Prometheus Strict may fan out up to 2 explore + 4 researcher agents per round so breadth comes from more citation-focused mini researchers while Metis/Momus/Oracle keep stronger judgment roles.
• Recommend $team only when Oracle identifies independent, bounded, verifiable lanes.

Structured Question Surface

Every Metis/Momus/Oracle question to the user MUST go through the surface-appropriate structured question path. Plain prose questioning is the last fallback, not the default.

• In attached-tmux OMX runtime, use omx question as the OMX-owned structured question surface (this is the AskUserQuestion equivalent for Prometheus Strict). From attached-tmux Bash/tool paths, prefix the command with OMX_QUESTION_RETURN_PANE=$TMUX_PANE (or a concrete %pane value) so the leader-pane return target is preserved.
• Batch independent high-leverage questions into a single questions[] array call: scope, constraints, non-goals, deliverables, safety bounds, and acceptance criteria are normally independent and MUST be batched into one structured form so the user answers them in a single panel. Reserve one-at-a-time only for dependent question chains where the next question depends on the previous answer.
• Wait for the omx question JSON answer before checking the clearance rule, asking another round, or handing off; prefer answers[] / answers[i].answer, and use the legacy top-level answer only as a compatibility fallback. After every answers[] batch, run at least two gap-fill passes before another question or handoff: Pass 1 assimilates user answers into the checklist; Pass 2 re-scans repo context, prior turns, research fan-out evidence, and conservative defaults to absorb non-CRITICAL residual gaps.
• Minimum two emitted question rounds: when Metis emits any user-facing question round, do not hand off after Round 1 unless hostility/<turn_aborted> or the round-5 cap forces exit; handoff is allowed only after Round 2 has been emitted and processed. Zero-question complete-checklist handoff remains valid when no questions were emitted.
• Between-round planning must actively use evidence: after Round 1 answers and the two gap-fill passes, refresh or reuse <research_fan_out> explore/researcher evidence, re-run spec prefill, and build Round 2 from residual CRITICAL gaps only.
• Outside tmux, use the native structured input tool when one is available.
• When neither structured surface can render (non-tmux Codex CLI, piped runs, CI), list the round's independent questions as a numbered prose block (Q1: ... Q2: ... Q3: ...) and wait for all answers in one user turn; do not split into separate round-trips.
• Multiple interview rounds ARE expected when clearance is not yet reached; each round is one batched form (or its prose fallback), never split across forms.

Checklist Clearance

The interview is governed by deterministic checklist clearance, not by subjective "feels enough" judgement. Exit the Metis interview loop when the 6-item checklist is fully YES: objective / scope IN+OUT / acceptance / test strategy / handoff target / no outstanding CRITICAL. Each item is evaluated with the tri-state defined in <Turn_Termination_Rules>.

Cap interview rounds at 5 to prevent runaway. If checklist clearance is not reached by round 5, hand the remaining UNKNOWN items to Oracle as explicitly carried-forward <unresolved_blocker> entries.

Hostility / non-answer exit: if the user's responses for a round contain refusal signals (1-2 character non-answers, dismissive 알아서 / "you decide" / "whatever" patterns, profanity-laden responses, or a <turn_aborted> on the prior turn), the round invalidates the answers — it does NOT advance any checklist item to YES, exits the interview loop immediately, and routes the unresolved gaps either to <silent_absorption> (for dismissive delegation) or back to the user via hostility_exit (for anger / aborted turns). See prometheus-strict-metis <hostility_detection> for the full pattern list and routing rules. </Execution_Policy>

<Turn_Termination_Rules> Every Prometheus Strict turn ends with EXACTLY ONE of the following terminations. Bare summaries and "I think we're done" are forbidden.

The 6-item checklist is: objective / scope IN+OUT / acceptance / test strategy / handoff target / no outstanding CRITICAL. A checklist item is YES when it is USER_ANSWERED ∪ ABSORBED_WITH_CITATION ∪ INFERRED_FROM_SPEC. Only UNKNOWN (no answer, no citation, no spec inference) counts as NO.

• (a) omx question batch: use when at least one CRITICAL question survives <gap_triage> and <self_review>. The batch is the round; the turn waits for answers[] before continuing.
• (b) explicit handoff: use when the 6-item checklist is fully YES. Hand off Metis → Momus after clearance, Momus → Oracle after critique, and Oracle → user or <unresolved_blocker> carry-forward after Pass 2 synthesis.
• (c) stop-blocker: use when hostility/<turn_aborted> is detected via <hostility_detection> with subtype hostility_exit, or when the next action is destructive, credential-gated, external-production, and cannot be defaulted safely.

Edge cases:

1. Zero-questions-but-complete-checklist → option (b) explicit handoff. Do not emit an empty omx question form.
2. Round-5-cap with incomplete checklist → option (a) emit one more question batch with surviving UNKNOWN items annotated, OR option (b) handoff with UNKNOWN items carried forward to Oracle as <unresolved_blocker> entries.
3. Hostility/<turn_aborted> → option (c) for anger, profanity, or aborted-turn via hostility_exit; option (b) for dismissive-delegation (알아서 / "you decide") with absorbed gaps annotated. </Turn_Termination_Rules>

<Steps>
### 1. Intake and Safety Bounds

Restate the target result, known constraints, deliverables, validation expectations, and stop condition. Identify whether this turn is planning-only or whether the user also requested downstream execution.

If the prompt contains destructive, credential-gated, external-production, or materially scope-changing decisions, hold those decisions for explicit user confirmation. Otherwise, continue through the planning loop.