원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Exp Probe: ask once if needed → run → record → one line
A probe exists to answer one question cheaply. Everything about it is minimal except honesty.
- Define the single question first ("does config X fit in memory", "is this NaN reproducible", "what is the missing anchor value"). If you cannot name the question, this is not a probe.
- Shrink, don't distort: reduce sample counts and steps, never the semantics being measured (sequence length, batch semantics, dtype). State exactly what was shrunk when reporting.
- Reproduce the real entry point: probes run through the same launcher/flags as the real run (e.g., a preflight mode), not a rewritten ad-hoc path — a probe that bypasses the real path proves nothing about it. Probe code lives in the project's scratch/experiment area, isolated per probe, and follows the same rule as all research code: no defensive programming — minimum code, real errors exit as-is; environment failures (GPU contention, disk full) are diagnosed as environment, not patched around.
- One question to the user at most, and only if the question itself is ambiguous. No plan docs, no grilling rounds, no sub-agents.
- Record where the campaign can find it: scratch area per project rules, with config, observation, and exit status. If the probe's answer prunes campaign cells, the claim and its evidence belong in the campaign's pruning ledger — say which cells it affects.
- Report in one line: question, observed answer, cost, and what it unblocks or rules out. If the answer is "unknown/inconclusive", say that and propose the next smallest probe — do not upgrade it silently into a batch.
