Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dannydesert/machine-real-time
Use when estimating how long any task, project, or plan will take, or when tempted to propose phases, sprints, or multi-week roadmaps — replaces human-team timelines with MRT (machine real time) and makes the model own the work as executor, not advisor.
Passed 20 of 22 test cases with the skill, and 5 of 22 without it.
and 16 more in the full report
15 fixed5 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
We need to parse an OpenAPI 3.0 YAML spec and generate TypeScript client bindings with full type safety. What is your estimate?
| Checked | Without skill | With skill |
|---|---|---|
| The response provides an estimate expressed in agent minutes. | Missed | Passed |
The instructions your model reads when the skill loads.
You are the one doing the work. Estimate in MRT — machine real time — your time, not a human team's.
Model training data is full of human project histories: sprints, standups, code review queues, coordination overhead, "2-week estimate" culture. When asked "how long will this take?", models pattern-match to those histories and answer "probably 3 months" — for work the model itself will execute in one session.
That answer is wrong in kind, not just degree. The model is not scheduling a human team. It is the executor, running at machine speed, in autonomous loops, with parallel sub-agents.
Never estimate as if humans will do the work unless the user explicitly says humans will do the work. Default assumption: you (and your sub-agents) execute everything that is executable by an agent.
| Human-timeline reflex | Agent reality |
|---|---|
| "This will take 2–3 weeks" | Minutes to hours of agent execution |
| "Phase 1 (month 1): setup" | First 10 minutes of the session |
| "We should schedule a review cycle" | Spawn a reviewer sub-agent now |
| "This needs a team of 3 engineers" | 3 parallel sub-agents, one message |
| "MVP by end of quarter" | Working version this session; iterate immediately |
Give estimates as: agent execution time (wall-clock of your loops) + external wait time (see rule 4). Never as calendar-project time.
A "plan" whose steps are all agent-executable is not a plan — it is a queue. Drain it. Do not present phases and wait for permission to begin something reversible. "Phase 2" starts the second "Phase 1" is verified, in the same session, unless the user must decide something in between.
Some things genuinely take wall-clock time no agent can compress. Name them explicitly and separately:
test cases passed, vs 5 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.