assume-this-stage-is-the-last-one-you-get

Solid

Use at the first three stages of a run under a hard wall clock, when the plan defers the modelling to a later stage. Covers the measured probability that the later stages never execute, why deferring to the stage designed for the work is the most expensive available choice, and what each early stage should leave behind if it turns out to be the last one to run.

AI & Automation 804 stars 25 forks Updated today NOASSERTION

Install

View on GitHub

Quality Score: 85/100

Stars 20%
97
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Plan as if the experimentation stage will not happen, because usually it does not The pipeline has a stage for running experiments and a stage for analysing them. On a wall-clocked run they are frequently theoretical. Measured over a nineteen-task scored arm, with a four-hour cap per task: | final stage the run reached | runs | |---|---| | 01 literature survey | 6 | | 02 hypothesis generation | 3 | | 03 study design | 5 | | 04 implementation | 4 | | 06 analysis | 1 | **Nineteen of nineteen hit the cap. None finished the walk.** Six never left the first stage; four of those six spent between 13 and 22 attempts on it. So the predictions file that got scored was, on most tasks, whatever an early stage happened to produce on the way past. That is the environment. Planning as though stage five will arrive is planning for a stage that arrives about one time in twenty. ## What follows **Do the modelling in the stage you are in.** Not because the stage boundaries are wrong, but because a plan whose payoff is two stages away has a low probability of being executed, and a marginally worse model built now has a probability of one. Concretely, at each early stage: - **01, literature survey.** Alongside the sources, run the data loader, print the shapes, and write the trivial baseline submission. The survey is better for it — you now know what the columns actually contain — and if the run ends here, it ends with a valid file. - **02, hypotheses.** Every hypothesis you reg...

Details

Author
tangxiangru
Repository
tangxiangru/AutoR
Created
5 months ago
Last Updated
today
Language
Python
License
NOASSERTION

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

decide-the-input-or-the-deadline-decides-it

Use at study design, and again at every stage boundary after it, when the run's own notes still carry an open question about which file or which system one of the named experiments will run on - the shipped stand-in, the authors' release, or one you generate from the Methods. Covers writing the default outcome beside every open question, ranking the list by that default rather than by difficulty, and the three-route ladder for a system the task did not ship.

804 Updated today
tangxiangru
AI & Automation Listed

plan-executor

Execute a staged plan document end to end — compile its recommendation into an acceptance contract, implement each stage, verify every one in a fresh git clone, and on failure freeze the evidence, diagnose it from three independent angles, apply the best admissible fix and re-verify from a clean state, looping until the plan is green or the budget runs out. Use this whenever the user points at a plan, review, report, ADR, design doc or issue and asks to "execute it", "run this plan", "make this happen", "carry out the recommendation", "do §6", "make the acceptance tests pass", or "keep fixing and re-running until it's green" — including when they just paste a path to a document with a staged recommendation and say go. Also use for long unattended runs that must survive usage limits and resume, and for any request to auto-fix failures found while executing a plan rather than stopping at the first red. If no plan document exists yet, produce one first with the architecture-research-report skill, then execute it

2 Updated today
nguyenvanphituoc
AI & Automation Listed

assumption-inventory

Surface and confirm the load-bearing assumptions behind a task before a long or expensive run — goal, root, what may be edited, what is off-limits, what done means, and open questions — separating what can be cited from what is being guessed, so bad direction is caught before time is burned. Also pressure-tests the plan's acceptance criteria, flagging any that are weak or built on unproven assumptions, and asks the blocking uncertainties (scope boundaries, interpretations, soft "done" bars) as structured questions. Use at the start of a multi-step or high-cost task, when resuming ambiguous or handed-off work, or whenever the target is not crisply stated and you are about to commit to a long run.

3 Updated 2 days ago
adamlinscott