assume-this-stage-is-the-last-one-you-get
SolidUse 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.
Install
Quality Score: 85/100
Skill Content
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
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.
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
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.