菜单
Use to turn a crewborg behavior pattern into a falsifiable, pre-registered improvement hypothesis with a predicted metric move, for the optimizer loop. Trigger on 'generate a hypothesis', 'why is this happening', 'what change should I try', or 'turn this pattern into an experiment'.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | hypothesis-generation |
| description | Use to turn a crewborg behavior pattern into a falsifiable, pre-registered improvement hypothesis with a predicted metric move, for the optimizer loop. Trigger on 'generate a hypothesis', 'why is this happening', 'what change should I try', or 'turn this pattern into an experiment'. |
Convert a pattern candidate (from pattern-toolkit) into a single
falsifiable hypothesis that drives the next policy change and the next eval. The
loop is hypothesis-first: you need a pre-game hypothesis, then you modify the
policy to collect data matching it. A hypothesis without a predicted, measurable
move is just an opinion.
Announce at start: "Framing this pattern as a falsifiable hypothesis with a mechanism, a predicted metric move on the goal, and the data needed to validate it."
design.md §7/§10/§12).
("Deadline-held plurality-join vote forfeits free-parity ejections" →
vote_policy.py.)data-collection-design). If the current artifacts can't
distinguish the hypothesis from the null, the hypothesis isn't testable yet.design.md §12: thresholds, lead/evade ticks, isolation bars, vote bars; env
flags BE_DUMB, DICK_MODE, LLM_MEETINGS). Prefer hypotheses that map to one
knob — they're cheap to test and cheap to revert.SEARCH_LEAD_TICKS/EVADE_TICKS are inert under BE_DUMB=1). A hypothesis
about an inert param will show no effect for the wrong reason — check the
shipped variant first.Write the five parts down before changing code or running the eval — in the
findings doc or a hypothesis stub. The prediction and the regression tripwire are
the contract eval-aggregation checks against. Use tr.research-partner's shape:
Question → Result(predicted) → Interpretation(mechanism) → Caveats(confounds) → Next Experiment(the change).
docs/designs/suspicion.md §6 (offline LR fitting) is a concrete hypothesis loop:
each evidence weight is a pre-registered claim ("venting raises P(imposter) by
LR≈8"), validated by re-fitting from replays, with every change logged in a
provenance table. Mirror that discipline for behavioral hypotheses.
A pre-registered hypothesis block (the five parts) + the regression tripwire. Hand
the change to data-collection-design (instrument first) and the
prediction to eval-aggregation (the bar to test against).
pattern-toolkit.data-collection-design, then eval-aggregation.tr.research-partner.design.md §7/§10/§12, docs/designs/suspicion.md §6,
episode_data/FINDINGS_v4.md.Use to identify and download Coworld episode artifacts — replays, results, and per-agent logs — for completed episodes, or STREAMED live from a still-running experience request (--watch: each episode downloads as it finishes, no waiting for the batch). Triggers: 'download the replay/logs for episode X', 'pull the last N episodes <player> played', 'fetch artifacts for this experience request / pool / round', 'stream artifacts while the request runs', 'get the episode data for post-mortem'. Game-agnostic (Crewrift, amongthem, etc.).
Use to create and monitor Coworld experience requests — hosted batches of episodes you define (target, roster, roles, count) for evaluating a policy against a live field. Triggers: 'run crewborg vs the top opponents', 'make an experience request', 'request N hosted games', 'A/B a policy against the league', 'measure the imposter', 'set up an evaluation battery'. DEFAULT FLOW after create: launch the STREAMING pipeline in the background (step 4) — artifacts download and analysis prep overlap the still-running episodes; don't wait for the batch to drain.
Use to run your own built player policy in a LOCAL Coworld episode and watch it — the Gate-1 smoke test ('did my change take, does it connect → play → exit cleanly?'). Triggers: 'smoke test the player locally', 'run a local game', 'run my policy locally and watch it', 'does the build still work', 'open the replay locally'. Game-agnostic; this is correctness only, NOT a competitive matchup (you can't run other users' policies locally).
Use to submit an ALREADY-UPLOADED policy version to a Coworld league and monitor whether it QUALIFIES, then competes (and becomes champion). Triggers: 'submit crewborg to the league', 'did it qualify', 'is it disqualified / champion', 'watch the qualifier', 'monitor standings after submitting'. SUBMIT is the public, effectively-irreversible, champion-making action — explicit human go-ahead only. (Building + uploading a version is the separate `build & upload` skill.)
Use to decide whether a crewborg change ACTUALLY helped — A/B the candidate against the baseline head-to-head, fresh, right now, against the same field. Triggers: 'did my change help', 'compare v71 vs v70', 'A/B test crewborg', 'is the candidate better', 'did fixing the imposter regress the crew'. Runs two MATCHED fresh experience requests, diffs role-split metrics with significance (compare.py), renders a comparison report, and guides a qualitative side-by-side. It's also the 'designed run' that crewrift-experiment hands off to.
Use to build and query the Crewrift event warehouse — a policy-indexed DuckDB/Parquet dataset of per-tick gameplay events (kills, follows, proximity, votes, tasks, chat) over many episodes — for deep, mechanistic, cross-episode questions about a policy's behaviour. Triggers: 'how often is crewborg near a crewmate without killing', 'who trails crewborg', 'where does it abandon tasks', 'does it vote real imposters', 'build the warehouse for this round', 'query the events', 'stream an experience request into a warehouse'. For a FRESH experience request, stream_eval.py builds the warehouse WHILE the episodes run (the default; builds are incremental). This is the deep-dig mainstay after crewrift-survey flags something.