This method is a lightweight, MMO-inspired “UI layer” for managing multiple projects in parallel. It addresses the failure mode where context switching preserves only low-meaning details (e.g., “I was at line 49 of that very specific file”) while loosing purpose, intent, and next actions—causing motivation collapse and restart friction.
The approach externalizes project state into a small, canonical “quest object” per project:
The implementation fits naturally into Vimwiki (or any notes system) with:
Parallel projects create a structural problem:
MMOs solve the analogous problem with excellent UI:
This method recreates those UI properties for personal work by treating projects as “quests” with explicit, minimal state.
The project’s current truth must live outside your head in a single canonical place.
Preserve the “why this step matters” chain so that low-level tasks remain connected to meaning.
Motivation becomes a property of the system’s representation (clear intent + next action), not a fragile internal feeling.
The system must remain usable when tired. This requires mechanical prompts, fixed fields, and short updates at project exit.
A single overview page listing quests by status, each with a one-line “CURRENT” intent.
Recommended sections: ACTIVE / BLOCKED / PARKED / DONE (recent) (your text editor might have a tag system able to fill those automatically)
Each line answers: “What am I trying to do right now on this quest?”
Example:
- ACTIVE: [[proj_sideproject]]
- CURRENT: ship onboarding flow - [[proj_admin]]
- CURRENT: reply to legal questions
- BLOCKED - [[proj_featureB]]
- CURRENT: waiting on reviewer feedback
The Quest Log is for orientation, not thinking.
Each project has its own page whose primary purpose is re-entry (reload), not journaling.
It includes a stable structure (optional) plus a single authoritative SAVED GAME block. The SAVED GAME block is overwritten/edited over time, not appended repeatedly.
Daily logs are an event stream composed of raw thinking, debug traces, emotional notes & exploration.
They are not “state”. They feed state, but are not the canonical representation.
NEW GAME is used when a “task” feels hard to start because it is too big, too vague, or not yet a task.
NEW GAME is not: full planning / detailed decomposition - committing to the full strategy.
NEW GAME is:
NEW GAME diagnostic prompts (use until paralysis drops):
SAVE GAME is the 2–5 minute ritual performed when stopping work on a quest.
SAVE GAME is not: writing documentation / summarizing everything / refiling logs
SAVE GAME is:
SAVE GAME updates:
Delete or replace old SAVE GAMEs before inserting a new one (or edit in place).
LOAD GAME is simply reading the last SAVED GAME block and starting with NEXT. It explicitly avoids rummaging through daily logs to “reconstruct” state.
EntryFlow (60 seconds):
In effect, you stop relying on working memory and mood. You rely on persistent state and simple rituals.
= NEW GAME =
TASK: <a simple name>
30-MIN WIN: <A concrete artifact that would exist in 30 minutes>
PREMIÈRE ACTION CONCRÈTE: <smallest real action: new file/test/draft/function declaration>
ALLOWED TO BE WRONG: <Placeholders / mocks / TODOs allowed?>
INFO I LACK: <none | what — next step to obtain one datapoint>
FAILURE COST: <low | medium | high — needs decision first>
= SAVED GAME =
INTENT: <What am I currently trying to do?>
NEXT ACTION: <Next non-thinking action (open/run/write/add…)>
BLOCKERS: <none | blocker + owner + next attempt>
WHY: <This step unblocks … → enables …>
REENTRY EASY: <YES | NOT REALLY — missing: repro/decision/pointers>
STATUS: <:doing: | :waiting: | :parked: | :done:>
UPDATED:
“Understand / think / explore” is not NEXT. NEXT starts with verbs like: open, run, write, add, remove, rename, send, schedule, reproduce, log, draft, test.
Either: - refine NEXT to be more mechanical, or - add CONTEXT pointers so the next session is startable.
Keep “CAUSE” short and local: this step → unblocks … → enables … Put life-story causality in a stable WHY section elsewhere if needed.