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: 82/100
Skill Content
Details
- Author
- tangxiangru
- Repository
- tangxiangru/AutoR
- Created
- 6 months ago
- Last Updated
- 2 weeks ago
- 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
Decide what to build and how, and stop at whatever maturity you actually need. `--stage ideas` for an idea board, `--stage shortlist` for a ranked set with the weak ones killed, `--stage spec` for pinned requirements via one question per round; with no stage it runs the planning tournament and returns a plan. Add `--deep` for post-tournament Planner→Architect→Critic validation on vague or expensive work. Use for planning a change, exploring options, deciding between ideas, pinning down what is actually being asked, or on 'plan das', 'wie gehen wir das an', 'welche Optionen haben wir', 'was genau soll das können'.
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