/experiment-design

name: experiment-design
description: 'Turn a refined GIScience / remote sensing / spatial data science proposal into a detailed, claim-driven experiment roadmap. Use after `refine-research`, or when the user asks for a detailed experiment plan, ablation matrix, spatial evaluation protocol, run order, compute budget, or paper-ready validation that supports the core problem, novelty, simplicity, and contribution.'
argument-hint: [topic-or-scope]
allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Agent

Experiment Design: Claim-Driven, Paper-Oriented Validation

Refine and concretize: **$ARGUMENTS**

Overview

Use this skill after the method is stable enough that the next question becomes: **what exact experiments should we run, in what order, to defend the paper?** If the user wants the full chain in one request, prefer `/experiment-design-pipeline`.

The skill is domain-general (AI / deep learning / ML research is fully supported) **and** must handle GIScience, remote sensing, and spatial data science research as a first-class case. **The spatial-specific validation layer (MAUP sensitivity, alternative spatial weights, GWR/MGWR, residual Moran's I, spatial CV) is conditional, not automatic** — add only the pieces the research question and chosen claims actually require, and document any spatial check that was considered and skipped (with a one-line reason). When uncertain whether to include a spatial check, **honor `HUMAN_CHECKPOINT` and ask the user** before either adding it (extra cost) or omitting it (review risk). See `spatial-analysis/SKILL.md` §5.3 for the same gating rule applied at execution time.

The goal is not to generate a giant benchmark wishlist. The goal is to turn a proposal into a **claim -> evidence -> run order** roadmap that supports four things:

1. the method actually solves the anchored problem 2. the dominant contribution is real and focused (not a confound of scale, data source, or setup choice) 3. the method is elegant enough that extra complexity is unnecessary 4. any frontier-model-era component (foundation model, VLM, diffusion, RL, geo/graph transformer, etc.) is genuinely useful, not decorative

Constants

• **OUTPUT_DIR = `output/`** — Default destination for experiment planning artifacts.
• **MAX_PRIMARY_CLAIMS = 2** — Prefer one dominant claim plus one supporting claim.
• **MAX_CORE_BLOCKS = 5** — Keep the must-run experimental story compact.
• **MAX_BASELINE_FAMILIES = 3** — Prefer a few strong baselines over many weak ones.
• **DEFAULT_SEEDS = 3** — Use 3 seeds when stochastic variance matters and budget allows.

Workflow

Phase 0: Load the Proposal Context

Read the most relevant existing files first if they exist (use `Read`; skip silently if missing):

• `output/LIT_REVIEW_REPORT.md` — consolidated literature review, thematic synthesis, ranked gaps
• `output/IDEA_REPORT.md` — ranked idea candidates with pilot scores
• `output/refine-logs/FINAL_PROPOSAL.md` — refined proposal the experiments must defend
• `output/refine-logs/REFINE_REPORT.md` — round-by-round resolution log and drift record

Extract:

• **Problem Anchor** (and, if spatial, the geographic / sensor / scale scope)
• **Dominant contribution**
• **Optional supporting contribution**
• **Critical reviewer concerns** (including any spatial-validity concerns: autocorrelation, MAUP, transferability, geographic bias)
• **Data / compute / timeline constraints** (including geospatial data licensing, AOI coverage, revisit cadence, compute for large rasters / graphs)
• **Which frontier primitive is central, if any** (e.g., geo-foundation model, SAM-style segmenter, VLM, diffusion, GNN, transformer)

**If none of these files exist, focus on `$ARGUMENTS`** and derive the same information directly from the user's prompt. Do not block on missing files; do not fabricate content from files that are not present.

Phase 1: Freeze the Paper Claims

Before proposing experiments, write down the claims that must be defended.

Use this structure:

• **Primary claim**: the main mechanism-level contribution
• **Supporting claim**: optional, only if it directly strengthens the main paper story
• **Anti-claim to rule out**: e.g. "the gain only comes from more parameters," "the gain only comes from a larger search space," or "the modern component is just decoration"
• **Minimum convincing evidence**: what would make each claim believable to a strong reviewer?

Do not exceed `MAX_PRIMARY_CLAIMS` unless the paper truly has multiple inseparable claims.

Phase 2: Build the Experimental Storyline

Design the paper around a compact set of experiment blocks. Default to the following blocks and delete any that are not needed:

1. **Main anchor result** — does the method solve the actual bottleneck? 2. **Novelty isolation** — does the dominant contribution itself matter? 3. **Simplicity / elegance check** — can a bigger or more fragmented version be avoided? 4. **Frontier necessity check** — if an LLM / VLM / Diffusion / RL-era component is central, is it actually the right tool? 5. **Failure analysis or qualitative diagnosis** — what does the method still miss?

For each block, decide whether it belongs in:

• **Main paper** — essential to defend the core claims
• **Appendix** — useful but non-blocking
• **Cut** — interesting, but not worth the paper budget

Prefer one strong baseline family over many weak baselines. If a stronger modern baseline exists, use it instead of padding the list.

Phase 3: Specify Each Experiment Block

For every kept block, fully specify:

• **Claim tested**
• **Why this block exists**
• **Dataset / split / task**
• **Compared systems**: strongest baselines, ablations, and variants only
• **Metrics**: decisive metrics first, secondary metrics second
• **Setup details**: backbone, frozen vs trainable parts, key hyperparameters, training budget, seeds
• **Success criterion**: what outcome would count as convincing evidence?
• **Failure int