sumo-experiment-problem-solvinglisted

Use when turning a confusing simulation or controller experiment result into a precise prompt, plan, or next diagnostic step. Especially relevant when comparing variants, questioning why performance changed, inferring mechanisms from logs, building fair baselines, or preserving evidence boundaries around completion, backlog, action timing, trigger logic, and metrics.
Tarard/Torii-SUMO · ★ 3 · AI & Automation · score 61

Install: claude install-skill Tarard/Torii-SUMO

# Simulation Experiment Prompting ## Overview Use this skill to preserve the reasoning behind good experiment prompts. The goal is not to ask for a bigger run; the goal is to convert confusion into one bounded diagnostic question. ```text observation -> uncertainty -> fixed variables -> smallest contrast -> feedback -> next prompt ``` Simulators, scripts, controllers, harnesses, and plugins are actuators. The prompt should decide what uncertainty they are allowed to reduce. ## Prompt Skeleton Every nontrivial experiment prompt should contain: - `phenomenon`: what was observed, without interpretation. - `desired_claim`: what the user wants to be able to say if the evidence supports it. - `blocking_uncertainty`: the one unknown that currently prevents that claim. - `fixed_variables`: scenario, inputs, seed, horizon, activation time, controller schedule, constraints, and output schema that must stay paired. - `allowed_change`: the smallest mechanism, code path, or parameter that may change. - `feedback_signal`: the metric, log, trace, or diff that will decide whether the idea survives. - `claim_boundary`: what must not be claimed from this run. If these fields cannot be filled, the next prompt should ask for observation, not execution. ## Mental Moves Use these moves when shaping the user's next request: 1. Separate observation from explanation. 2. Compare against the strongest previous result under the same scenario before inventing new logic. 3. Treat negative resul