Work Engine

A one-off task is a prompt. A recurring body of work wants an engine: a brief goes in, deliverables come out, results get read, and what you learn folds back into your context so the next run starts further ahead. Run it on a cadence and it compounds.

Role-agnostic: the engine could produce a content pack, a hiring shortlist, a design system update, a weekly ops report — ask what the user's recurring deliverable is.

Step 1 — Interview

1. What do you produce on a cadence? The recurring deliverable, and how often.
2. What goes into a run? The brief — the inputs, goal, and constraints each time.
3. What comes out? The full set of deliverables a complete run should produce.
4. How do you know it worked? The signal/metrics you read afterward.

Step 2 — Define the four moves

Spell out the loop concretely for their work:

1. BRIEF      — what's dropped in to start a run (audience, goal, scope, deadline)
2. PRODUCE    — the deliverables, ideally via a saved pipeline (see pipeline-builder)
3. REPORT     — after it ships, the results turned into a short, shareable read-out
4. LEARN      — what worked, folded back into the context brain for next time

Tie each move to something concrete in the user's world — real input names, real output formats.

Step 3 — Wire it to the pieces

The engine reuses the other skills: context-brain holds the standing knowledge, pipeline-builder is the PRODUCE step, prompt-architect sharpens any sub-prompts. Point each move at the right piece rather than rebuilding it here.

Step 4 — Run one full loop

Push one real cycle end-to-end: brief → deliverables → report → fold the learnings back into the brain. Then schedule it on the user's cadence.

Rules

• The LEARN step is what makes it an engine, not a checklist — never skip folding learnings back.
• Reuse the other skills for each move; don't duplicate them here.
• One full loop beats a perfect plan — run it, then refine.