Menu
Pre-push workflow — communicate with ScavieFae, capture notes in RESEARCH-LOG.md, check hygiene, then commit and push. Use when the user says "push", "ship it", "send it", or asks to commit and push changes.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | push |
| description | Pre-push workflow — communicate with ScavieFae, capture notes in RESEARCH-LOG.md, check hygiene, then commit and push. Use when the user says "push", "ship it", "send it", or asks to commit and push changes. |
| disable-model-invocation | true |
| user-invocable | true |
Pre-push workflow for the Autonomous World Model. Every push is a communication touchpoint — with ScavieFae, with future sessions, with the running record.
Do NOT skip steps or treat this as a formality. Each step exists because we got burned without it. But DO skip steps that genuinely don't apply (marked with trigger conditions).
Read the current state. Understand what's going out.
git diff --stat origin/main..HEAD (committed but not pushed)
git diff --stat (unstaged changes to potentially include)
git status (untracked files)
git log --oneline origin/main..HEAD (commits to push)
Categorize the changes:
Report the category and scope to the user before proceeding.
Trigger: Changes touch any of: scripts/, models/, training/, data/, crank/, solana/, or interface contracts (encoding.py, state_convert.py, solana_bridge.py, solana/client/src/, JSON frame format). Skip for docs-only changes that don't affect the offchain/onchain interface.
Update docs/HANDOFF.md with a new entry at the top (below the header, above the first ---).
Entry format (match the existing style in HANDOFF.md):
## Verb: Description (Author, Date)
**Author → ScavieFae**: [What changed and why, written for someone who wasn't here]
### What changed
[Substantive description. Not just file names — what the change DOES and WHY it matters for the recipient.]
### Cross-boundary implications
[How this affects ScavieFae's work. Interface contracts, deployment, onchain behavior, SDK changes. If none, say "None — offchain only" or similar.]
### Files changed
| File | Change |
|------|--------|
| ... | ... |
### Next steps
[What happens next. Action items for either side.]
---
Write for someone who wasn't here. They don't have your context. Include the "why" not just the "what."
Trigger: The session involved research reasoning, design decisions, implementation findings, dead ends, or anything worth preserving for future agents and sessions. Skip only for truly mechanical changes (typo fixes, dependency bumps).
Update docs/RESEARCH-LOG.md with a new entry at the top. If the file doesn't exist, create it with a header:
# Running Log — Autonomous World Model
Running notes from work sessions. Newest entries at top. Append-only.
---
Entry format:
## [Date] [Time] — [What you were doing]
[What you encountered. Decisions made and why. Dead ends hit. Surprises found. The texture of the work — not just outcomes, but the process.]
[If you changed approach mid-task, explain the pivot.]
Rules:
Trigger: Changes to docs/run-cards/, new experiment infrastructure, or experiment status changes.
Check that run card YAML frontmatter status fields match reality:
proposed → running if implementation startedrunning → kept or discarded if results are inrollout_coherence and prior_best_rc filled in if eval has been runAlso check: does any new run card need to be created for work done in this session?
Trigger: Changes to models/encoding.py, crank/state_convert.py, crank/solana_bridge.py, solana/client/src/, or the JSON frame format consumed by viz/ and site/.
These are review-gated per CLAUDE.md:
| What changed | Who reviews | Why |
|---|---|---|
| Onchain programs, syscall, ECS | Model side reviews math/format | Hardest to undo |
| Weight format / encoding changes | Codex reviews | Must match onchain structs |
| Binary wire format (PlayerState) | All sides | Shared boundary |
If any of these changed: flag it explicitly in the HANDOFF entry and note the review requirement. Do NOT push without acknowledging the review gate — ask the user.
Trigger: New baseline numbers, new findings that change research direction, experiment status changes, new dead ends discovered.
NEVER modify program.md autonomously. This is Mattie's document — it shapes how agents operate. It is the human's lever on the autoresearch loop.
If the session produced findings that should update program.md:
Examples of things to propose:
git add -A or git add .. Name each file. Don't sweep in unrelated changes, secrets (.env), or large binaries.git log --oneline -10). End with the co-author line.git status after push.Report what was pushed (commit hash, files, branch) so the user has a record.
Close out an experiment — update run card with results, update frontmatter, rebuild docs index, close PR, log to research log, propose program.md updates. Use when an experiment has finished training and eval.
Pre-flight checklist for launching a training experiment on Modal — verifies run card, config, data contract, local smoke test, budget, observability, and stop conditions before burning GPU time. Use when kicking off any new experiment, Mamba2 or JEPA. Counterpart to /experiment-complete.
Get Mamba2 and training architecture guidance for experiment design. Use when a proposed experiment touches model structure, training regime, or loss design and you need to understand how the architecture constrains or enables the approach.
Search the world model research literature for prior art, alternative approaches, or techniques from adjacent fields. Use when evaluating whether a proposed technique has precedent, when seeking inspiration from different paradigms, or when a paper is referenced and you need context on it.
Review project experiment history to answer questions about what's been tried, what worked, hit rates, and empirical patterns. Use when proposing a new experiment direction and you need to check whether it's been explored, or when evaluating results against prior findings.
Run one conductor heartbeat — check experiment state, evaluate completed runs, dispatch new research cycles. Supports parallel experiments. Use with `/loop 60m /conductor` for autonomous operation.