early-experience-data

Early Experience Data Generation

This skill governs how data generation for the early-experience paradigm is done. Read this entire file before starting work on a new env.

What this skill is for

This skill produces SFT-ready training data for the two methods defined in the paper (https://arxiv.org/abs/2510.08558) and recapped in METHOD.md:

• Implicit World Modeling (IWM) — train the policy to predict the next state given the current state and an action.
• Self-Reflection (SR) — train the policy to produce a chain-of-thought reasoning over expert vs alternative actions, then the expert action.

The output of the workflow is JSONL files in three categories: expert, IWM, reflection. Where you put them and how you organize the surrounding pipeline scripts is up to your project — the skill is agnostic about layout. Training itself is out of scope. If a task requires running SFT, evaluating checkpoints, or tuning training hyperparameters, that belongs elsewhere — surface it to the user rather than acting on it inside this skill.

Required reading order

Before starting a new env, read in this order:

1. METHOD.md — what IWM and SR actually are, and the reflection prompt template. This is the source of truth for the method.
2. method_recap.md — short list of decisions where the right answer is non-obvious. Use as a runbook, not as a tutorial.
3. pitfalls.md — accumulated gotchas from previous envs. Skim before each new env in case something carries over.
4. This env's own NOTES.md (if you or a previous agent already started one) — env-specific decisions already recorded. NOTES_TEMPLATE.md is the skeleton to copy when you're starting fresh.

If any of these files is missing or empty (aside from NOTES.md on a fresh env), surface it as a question rather than guessing.

On conflicts between layers. For skill-wide mechanics (gates, output shape), this skill wins. For env-specific content (state representation, K, sampling strategy, prompt extensions, filtering rationale, anything tied to one env's interface or paper section), the env's NOTES.md is closer to truth than the generic guidance here. But never silently resolve a conflict. If NOTES.md says one thing and SKILL.md / METHOD.md says another, stop and surface the conflict to the user before proceeding — the usual outcome is that NOTES.md needs a correction, and the user will edit it.