---

name: reimagine-work description: >- Use when someone asks to find the "stupid human steps" in how work gets done, where a person is the bottleneck for a team of agents, how to redesign a process from zero, or to run the weekly "Elon algorithm" pass (question, delete, simplify, speed up, automate) over an agent fleet. Also use as a routine: weekly full pass with an outside reviewer, plus weekday incremental runs that propose at most one new change or stay silent. Also use when work arrives "one drop at a time" (batch waits, daily-only runs, per-item human review) and should become a continuous stream, or when deciding how much autonomy an ask type has earned, what threshold makes an input worth acting on, or which lanes cost too much per real outcome. It proposes and builds only internal, reversible checks. It never sends, posts, spends, enrolls, deletes, merges or changes a routine.

Reimagine work (v3.3 template: weekly Elon loop + continuous stream + escalation ladder + earned autonomy)

Template. Replace every <PLACEHOLDER> with your own values. Nothing in this skill sends, posts, spends or approves anything; it only proposes. The judge it refers to ships in shadow mode (log only) with hard gates on.

Find every place a human is what work waits on, remove that wait, and do it again next week. The deliverable is a short ranked list and exact yes lines, not a long report.

Asks that are already answered (never re-ask)

Before any yes line reaches the human, check these in order. If any one is true, the work proceeds with no new ask, and it gets logged with what authorized it:

1. The human already said it. If the owner's own words in this conversation asked for this exact action ("send these follow-ups, by email and chat"), that is the yes. A copy tweak they asked for ("keep it simple like the outbound") is still inside that yes. Do not send a confirm line for the same batch.
2. A lane owner approved it. If the person who owns the lane (for example, the content lead for publishing) approved, proceed under their conditions. Don't ask the top owner for a second yes.
3. A standing approval with a cap covers it. Check the approval ledger. A matching row with owner_bots, a cap and a scope is the yes.
4. It's reversible or read-only. No yes at all.

The human gets a yes line only for a new send, spend, publish, delete or gate change that none of the four covers. Each yes line that does reach them gets counted. If any lane sends more than 2 a day, flag it in the next pass as a defect to fix.

Where the idea comes from

These principles come from a public write-up by a ten-person company that runs a fleet of permanent agents. Its founder says they "found what work was waiting on and removed it, over and over." Use these principles to judge each redesign:

1. Own an area. Each agent is permanent and owns one part of the company. Two agents doing the same job is a SIMPLIFY finding.
2. Coordinate through the world, not through messages. Agents stop "telling each other what they were about to do." They read and change a shared record (queue, ledger, state file). A human relaying a message between agents is a finding.
3. Fix forward. A small reversible change goes in, a later check catches problems, and any break is fixed with a new change on top. Asking before a reversible internal fix is a finding.
4. Test on a clock, not per change. Run the full check on a schedule against the latest state. "It broke since the last run" is enough to find the cause.
5. Review by someone who didn't write it. Helper agents try to break a change before it lands.
6. Agents read production themselves. Errors, receipts and metrics go straight to the owning agent, and no human relays them.
7. A stall is an incident. A lane that ships nothing for a full working period pages its owner agent.
8. AI judges from recorded decisions. A judge either decides and cites where the owner already answered, sends back a wrong question, or holds the question for a human. "When a judge gets one wrong we say so, and the judges read that next time."
9. Nothing waits on the queue. Open asks that sit for days are the loop's main measure of failure.
10. Hard gates stay small and dumb. Anything that touches the outside world and can't be undone goes through "a small set of dumb, hard-coded gates."
11. Humans keep taste. That means saying no, deleting what the last model needed, and asking for 10x or 100x, which models do not ask for on their own.

A second source adds the stream layer: a public post on agent-written code ("code used to arrive one drop at a time. soon, if not already, code will be written as if it were a continuous stream") and the engineering manifesto it quotes. Principles 12 to 16 come from those two texts:

12. Work is a stream, not drops. Design for constant small changes, not batches that wait for a person. "AI needs to be able to work autonomously and continuously with less and less human babysitting."
13. Make the easy thing the right thing. Guardrails do the steering, so that even agents "with little context about the right way of doing things" land work inside them. A rule an agent must remember is weaker than a check it cannot skip.
14. Bottlenecks move. "what happens when you eliminate a bottleneck? Another takes it is place", including "approvals, specifications, and code reviews". Re-measure after every fix. Don't assume the old bottleneck is still the one.
15. Rework, don't only speed up. Phase 1 is speeding up existing steps. Phase 2 is "reworking and rethinking them altogether". When the pace breaks a workflow, rewrite it instead of adding another patch.
16. Fix the class, for everyone. Build the "habit of ensuring that repeated failures trigger an investigation and a fix", and put the fix in a shared skill, prompt or context file so every agent gets it next time.

A third source is a follow-up thread by the same founder on how the fleet got there ("we started with a simple thing that worked", "it earned autonomy over months", "we audit every token against our goals hourly / we double down on what works / and cut things that don't fast"). Principles 17 to 21 come from it:

17. Start narrow, earn autonomy. Start with one small job that works, check its output closely, and widen scope one ask type at a time as the record proves it. Autonomy is granted per ask type, never per agent.
18. One dial for how much to take on. Spend is set by a threshold for what counts as an actionable signal ("how bad does a bug have to be? are we fixing every P5 or only P3+"). Saying no to more is how cost goes down, and it can be turned back up the next day. The owner moves the dial; nobody decides item by item whether a low-value item is worth doing.
19. Audit cost against outcomes on a clock. Tokens are checked against the goal often (cost per outcome that actually changed something). Double down on what works, and cut what doesn't, fast.
20. Rate the work where it lands. Ask the people the work is for to rate it on a fixed cadence ("every 15 messages") and track the trend, instead of the owner reviewing items.
21. Watch a newcomer try it. A regular cold-start test ("watching newbies try [the product] weekly", borrowed from playtesting culture) finds what only the owner knows.

Rules

• Write only your own report, your own state file, and internal checks that are reversible, tested and logged, with a backup next to each changed file.
• Never send, post, publish, spend, enroll, delete, merge, change a routine, or edit a skill. You recommend these, and the owner decides.
• Never edit a script marked FROZEN. Report what it needs instead.
• Every count comes from a file opened this run, cited by path and date range. Label time estimates "estimate" and show the math.
• Never print secrets, tokens or cookies. Never put personal data about candidates or leads, money amounts, or deal names in the output. Use counts and lane names.
• Hard gates always stay human (see "Classify"). A redesign can make a gate faster or batch it, but never remove it.
• Run the existing tests before and after any build. If tests were already failing, find out why before you build. A broken shared reader is a finding in its own right.

Evidence: the ledger is the source of truth

Use what exists, in this order:

1. Approval ledger. Every owner yes and no, with scope, caps and date. Count asks against answers: asks per answer, and re-asks of things already answered.
2. Outcome record. For each yes: baseline, target, check dates, verdicts, and what_changed (changed / no_change / unknown / pending / overdue). A yes that changed nothing is evidence against that kind of ask.
3. Judge logs. Backtest and shadow rows: match rate by ask type, misses, decide / send-back / hold counts.
4. Queues. Yes-queue files, kickoff queue, open-asks list. Measure age (median, max, item-days) and asks per bot per day against the cap.
5. Gate and receipt logs. Send and publish gate rows by sender, routine receipts, browser and lock logs, missed-run reports.
6. Correction log. Every "no, wrong, redo" from the owner.
7. Chats, Slack, email and calendar (read only). Relays, pastes and access requests.

The loop (five steps, in this order)

1. QUESTION: where did agents wait on a human?

One row per kind of wait, not per instance: step, lane, who (a role, not a name), evidence (path, count, window), frequency, wait time, and touch time (estimate). Also look for yes lines, per-item picks, pastes, relayed approvals, logins and seats, reviews of work that already passed a check, chase messages, stale asks, and the same correction made twice.

2. DELETE: what protects nothing?

Delete candidates include bots, routines and yes lines with no output or receipt in 14 days, asks the bot itself would answer no to, re-asks already in the ledger, and scaffolding the current model no longer needs. Rank delete candidates by cost per changed outcome (tokens, plus dollars labeled estimate, divided by outcomes with what_changed = changed in the window). Rank "double down" candidates the same way from the cheap end. Never propose cutting a lane younger than 14 days, or one whose latest outcomes are still pending, so slow work is not cut just before it lands. Proposals only. Expired asks are recorded as "unanswered", never as "no", so a judge never learns to refuse from silence.

3. SIMPLIFY: one owner per job

List duplicate agents and loops. Name one owner per job, using the evidence: receipts, gate rows by sender, open asks. When the owner has already picked the owner (for example, a shared team agent so others can use it), that pick stands. The evidence then becomes a readiness checklist, not a reason to overrule the pick.

4. SPEED UP: remove the wait, not the step

Check for ordering bugs (work that lands after the digest it belongs to), polling hops, lock clashes, relay hops (a human or coordinator agent passing a resolve on, when the owning agent could read the shared record), and bot-to-bot asks parked in the owner's file.

5. AUTOMATE: the escalation ladder is this step (default)

Every decision a bot would otherwise hand to the owner climbs this ladder, cheapest rung first, and stops at the first rung that settles it. A rung that is unsure, errors, is skipped or times out passes the item UP, never down and never to "yes".

| Rung | What | Settles | Never | | --- | --- | --- | --- | | 1. Deterministic check | Code: hard-gate class match, tampering flags (injection, hidden characters, look-alike letters, relayed yes), malformed or empty ask, already answered, caps, DNC, dedupe; for image