# Focus -- Diagnose, Decide, and Compress Run a comprehensive vault review against the operator definition of focus and produce the durable artifacts required to actually get better at it. Not advice. Not a report. Decisions, written down, with vault evidence. **Usage:** `/focus` (full review) or `/focus --light` (temporal check against last run only) --- ## What This Command Is For Most "focus" advice is task-level. Pomodoros, blocking calendars, killing notifications. That's attention focus, and it's not the bottleneck for an operator running a portfolio of bets. The bottleneck is portfolio composition: too many active fronts, none with a defined threshold, none formally killed, all silently consuming energy. This command operates on the strategic version of focus, defined as: > **Focus is the discipline of pushing one bet to a defined threshold before opening the next, and being willing to let other good ideas wait or die so the current one can compound.** It has four operational parts, each of which is a separate skill: 1. **Naming the one bet.** Which front gets concentrated push right now. 2. **Defining a threshold.** A falsifiable number that proves the bet is at cruising altitude. 3. **Sequencing.** Refusing to open front 2 until front 1 hits its threshold. 4. **Killing or parking.** Letting other good ideas die or sit in a queue with zero energy. The command runs the diagnosis on all four, produces decisions, and writes them to the vault as durable artifacts. ## What This Command Is Not - Not `/today` (single-day planning) - Not `/7plan` (weekly reshape) - Not `/leverage` (skill development) - Not `/drift` (avoidance detection) - Not `/map` (vault topology) This IS: **A periodic forcing function for portfolio compression.** The output is a smaller list of active fronts than the input. If the vault has 8 active fronts going in and 8 active fronts coming out, the command failed. --- ## The Three Modes of Failure This Command Must Resist Read these before starting. They are the gravity that will pull the output toward uselessness. **1. Generic productivity advice.** "Time-block your calendar." "Try the Eisenhower matrix." If the output could be given to anyone, it has failed. Every recommendation must be specific to this operator, this portfolio, this evidence. **2. Soft killing.** "Deprioritize" is not killing. "Pause for now" is not parking. Either a front has a date to be revisited and zero energy in the meantime, or it's dead. If neither, it's still active. The command must force a binary on every non-primary front. **3. Vague thresholds.** "Doing well." "Cruising." "Healthy growth." These are not thresholds. A threshold is a number you would bet money on. If the proposed threshold can be argued about, it isn't one. The command must produce thresholds that are falsifiable in a single observation. --- ## Phase 1: Map the Active Front Inventory Goal: produce a complete, honest list of every front currently consuming energy. Stated and unstated. Active and zombie. ### Step 1: Structural Scan ```bash Obsidian tags counts sort=count Obsidian orphans Obsidian deadends ``` ### Step 2: Read All Context Files Read every context file in the vault. For each: - Extract every stated project, initiative, or commitment - Extract every confidence marker (`[solid]`, `[evolving]`, `[hypothesis]`, `[questioning]`) - Note any explicit prioritization language ```bash Obsidian read file="<Company-Context>" Obsidian read file="<Project-Context>" Obsidian read file="Personal Workflow Context" Obsidian read file="Health-Context" Obsidian read file="Kaito-Context" ``` ### Step 3: Daily Notes Pattern Mining (Past 60 Days) ```bash Obsidian daily:read Obsidian read path="Daily Notes/YYYY-MM-DD.md" # past 60 days ``` For each day, extract: - Which projects/fronts were mentioned by name - Which produced action (meetings, decisions, output) - Which produced only thinking (mentioned but not pushed) - Which produced only worry (mentioned with friction or guilt) ### Step 4: Behavioral Archaeology Search for evidence of fronts that exist behaviorally even when not stated: ```bash Obsidian search query="working on" path="Daily Notes" Obsidian search query="meeting with" path="Daily Notes" Obsidian search query="thinking about" path="Daily Notes" Obsidian search query="should" path="Daily Notes" Obsidian search query="need to" path="Daily Notes" Obsidian search query="started" path="Daily Notes" Obsidian search query="want to build" path="Daily Notes" Obsidian search query="exploring" path="Daily Notes" ``` ### Step 5: Calendar Reality Check Read the past 30 days of calendar events. For each meeting, note which front it served. Group by front. The size of the bucket per front is the **time signature** of that front, regardless of what the user says is primary. ### Output of Phase 1: The Front Inventory A table of every active front. Stated and behavioral. For each: | Front | Stated in vault as | Time spent (last 30d) | Output produced (last 30d) | Operator (if any) | Status (vault language) | Status (honest read) | |-------|--------------------|-----------------------|----------------------------|-------------------|------------------------|----------------------| The "stated" column is what the vault says about the front. The "honest read" column is what the evidence actually shows. If these diverge meaningfully, that's the first signal. **Do not skip a front because it seems minor.** A "small" front consuming 4 hours/week is consuming 200+ hours/year. That is not minor. --- ## Phase 2: Identify the One Bet Goal: name the single front that is supposed to be primary. Surface conflicts between stated and behavioral primacy. Force a choice. ### Step 1: Stated Primacy Search the vault for explicit primacy language: ```bash Obsidian search:context query="our base is" Obsidian search:context query="north star" Obsidian search:context query="the main thing" Obsidian search:context query="primary" Obsidian search:context query="first priority" Obsidian search:context query="most important" ``` For each hit, capture the exact language and the front it points to. These are the user's stated commitments to themselves. ### Step 2: Behavioral Primacy From the Phase 1 inventory, rank fronts by: - Time spent in the last 30 days - Output produced in the last 30 days - Cognitive presence in daily notes (frequency of mentions weighted by depth) The top of this ranking is the **behavioral one bet**. It may differ from the stated one bet. That difference is diagnostic. ### Step 3: Reconcile Three possibilities: **A) Stated and behavioral align.** The user says X is the bet, and X is where most energy went. Easy case. Confirm and move on. **B) Stated and behavioral diverge.** The user says X is the bet, but Y got the time. This is the most common case for ambitious operators. Surface the divergence directly. Ask: is the stated bet wrong, or is the behavior wrong? **C) No clear bet exists.** Multiple fronts at roughly equal energy, no clear primacy in either stated or behavioral terms. This is the hardest case. **The command must stop here and refuse to proceed until the user picks one.** No threshold can be defined for "all of them." The rest of the work is contingent on this answer. ### Step 4: Steelman Each Candidate If multiple candidates exist for the one bet, write a one-paragraph steelman for each: - Why this front is the right primary bet right now - What it compounds into over 1, 3, 10 years - What the user gives up if this is the bet Then propose a single answer with reasoning. The user can override but must do so consciously, not by default. ### Output of Phase 2: The Bet Statement A single sentence in this exact form: > **My one bet is [SPECIFIC FRONT]. I am pushing this to cruising altitude before any other front gets primary energy.** Plus three sentences of reasoning, citing vault evidence. --- ## Phase 3: Define the Threshold Goal: produce a falsifiable number that defines what "cruising altitude" means for the one bet. ### Step 1: Search for Existing Threshold Language ```bash Obsidian search:context query="<bet name>" Obsidian search query="goal" path="Daily Notes" Obsidian search query="target" path="Daily Notes" Obsidian search query="milestone" path="Daily Notes" Obsidian search:context query="success looks like" Obsidian search:context query="when this is working" ``` If the vault contains existing threshold language for this bet, surface it. If it's specific and falsifiable, use it. If it's vague, treat it as a starting point only. ### Step 2: Propose Three Threshold Candidates For the chosen bet, propose three thresholds at different elevations: - **The Floor.** The minimum that proves the bet is alive and self-sustaining. If you don't hit this, the bet has failed and should be killed. - **The Cruising Altitude.** The level at which the bet runs without primary energy from the operator. This is the actual target. - **The Ceiling.** The level at which the bet is undeniably winning. Optional, but useful for orientation. Each threshold must satisfy all four tests: 1. **Numerical.** A number, not an adjective. 2. **Falsifiable.** Two reasonable people would agree whether it was hit. 3. **Single-observation.** You can verify it on any given day with one query, not a synthesis. 4. **Defendable.** The user would bet money on whether it was met. If a proposed threshold fails any test, rewrite it. ### Step 3: Surface the Trap For each threshold, note the most likely way the user will fool themselves: - Vanity metrics (downloads instead of completion rate, followers instead of engagement) - Lagging indicators when leading would be better - Metrics that move easily without the underlying thing changing - Numbers that look impressive but don't prove the front is self-sustaining Steelman the trap. Then choose a metric that resists it. ### Step 4: Propose the Cadence How often will this threshold be checked? Once a week? Once a month? Per quarter? Match the cadence to the metric's natural movement. ### Output of Phase 3: The Threshold Document A document committing to: - The Floor (with definition and check cadence) - The Cruising Altitude (with definition and check cadence) - The trap each metric is resisting - The current value as of today This document gets saved to the vault as `Focus/[Bet] - Threshold.md`. --- ## Phase 4: Audit Time Against the Bet Goal: quantify the gap between "the bet is X" and "I spent time on A, B, C, D, X." That gap is the operator's real focus problem, in numbers. ### Step 1: Calendar Audit (Last 7 Days, Granular) Pull all calendar events from the last 7 days. For each: - Which front did it serve? - Hours consumed (including transit and prep) - Was the operator's presence actually required? ### Step 2: Daily Note Audit (Last 7 Days) For each daily note in the past 7 days: - What was the day's stated focus? - What got mentioned as a problem, distraction, or interruption? - What got worked on that wasn't planned? ### Step 3: Communication Audit ```bash Obsidian search query="sent" path="Daily Notes" Obsidian search query="emailed" path="Daily Notes" Obsidian search query="replied" path="Daily Notes" ``` Plus, if email/Slack is connected, scan the last 7 days of messages for which fronts they served. ### Step 4: Compute the Gap Produce two pie charts in text form: **Stated allocation:** if the user's bet is X, an idealized allocation might be 70% X, 30% maintenance/operator-handled fronts. **Actual allocation:** what the data shows. Compute the gap per front. Identify the **top three energy sinks** that aren't the bet. These are the fronts most actively undermining focus, regardless of whether they feel "necessary." ### Step 5: Identify Creep Patterns For each energy sink, ask: - Does this happen because something genuinely requires it (operator gap)? - Does this happen because nobody else can do it (delegation gap)? - Does this happen because the operator wants to do it (commitment gap)? - Does this happen because it's hard to say no in the moment (boundary gap)? The category determines the fix. Operator gap means hire/train. Delegation gap means trust someone more. Commitment gap means kill the front. Boundary gap means a script for saying no. ### Output of Phase 4: The Time Audit A document showing: - Last 7 days, hour-level allocation by front - Stated vs. actual allocation - Top 3 energy sinks - The category of each sink (operator/delegation/commitment/boundary) - The specific corrective action per sink This becomes a living artifact at `Focus/Time Audit - [Date].md`. --- ## Phase 5: The Kill or Park Decision Goal: turn every non-primary front into a binary. Killed (done forever) or Parked (queued with date and zero energy). No third option. ### Step 1: For Each Non-Primary Front, Ask Five Questions 1. **Does this front compound?** If yes (it gets more valuable over time even with maintenance attention), it might warrant operator-handoff instead of kill/park. 2. **Is there an operator who can hold it?** If yes, this front coasts on the operator and is taken off the principal's plate. If no, the front is consuming principal energy regardless of its formal status. 3. **What's the cost of killing it?** Specifically. What sunk cost? What relationships? What identity? What revenue? 4. **What's the cost of parking it?** What gets lost in the dormancy? What does it cost to wake back up? 5. **What's the cost of keeping it active at half-energy?** This is usually invisible and is usually the highest cost of the three. ### Step 2: Default to Kill Killing is the default. Parking is the exception. The bar to park (rather than kill) is high: the front must compound when revisited, must have a clear revisit date, and must require zero energy in the meantime. For each non-primary front, propose: **Kill / Park (date) / Coast on operator [name]**. ### Step 3: Surface Identity Costs Some fronts can't be killed without an identity adjustment. ("If I kill this, I'm not a generalist anymore." "If I kill this, I'm letting someone down.") Surface these explicitly. The identity cost is real and must be confronted, not hidden. ### Step 4: Force the Commitment Produce a single document with three columns: | Front | Decision | Date / Operator | |-------|----------|-----------------| | Front A | Kill | (effective today) | | Front B | Park | revisit 2026-Q4 | | Front C | Coast | operator: [name] | The user must sign off on each row before the document is saved. If any row is left ambiguous, the command surfaces the ambiguity and refuses to save. ### Output of Phase 5: The Kill/Park Ledger Saved to `Focus/Kill-Park Ledger.md`. Append-only. Every run of `/focus` adds new decisions. Old decisions are not silently reversed; if a parked front is reactivated, it goes through the full review again. --- ## Phase 6: The Queue Goal: build a single, durable graveyard for every idea that isn't the one bet. The queue is not a to-do list. It's a place where ideas go to wait or die. ### Step 1: Mine the Vault for Idea Fragments Pull every idea fragment scattered across daily notes, brain dumps, and project files: ```bash Obsidian search query="should build" path="Daily Notes" Obsidian search query="want to write" path="Daily Notes" Obsidian search query="should make" path="Daily Notes" Obsidian search query="would be cool" path="Daily Notes" Obsidian search query="someday" path="Daily Notes" Obsidian search query="idea:" path="Daily Notes" Obsidian read file="Brain Dump" Obsidian read file="Ideas" ``` ### Step 2: Classify Each Fragment For each fragment: - **Active**: this is the one bet (skip; not queue material) - **Queue**: park here, may resurrect later - **Discard**: not worth even queueing (most fragments) The queue should be **selective**, not exhaustive. A queue with 200 items is a wishlist. A queue with 15 items is a real graveyard. ### Step 3: For Queued Items, Capture Minimum Viable Information For each queued item: - The idea, in one sentence - The earliest evidence of it in the vault (date) - The last time it was mentioned (date) - A trigger condition for revisiting (e.g., "after the bet hits its threshold," "if X person becomes available") - A kill date (a calendar date after which, if it hasn't been activated, it dies automatically) ### Step 4: Establish the Queue Discipline Document the rules of the queue at the top of the file: - Adding to the queue is allowed any time. Removing requires a reason. - The queue gets reviewed once per `/focus` run. - Items hit their kill date and die without ceremony. - Resurrection requires a positive case, not just curiosity. ### Output of Phase 6: The Queue Saved to `Focus/Queue.md`. Persists across runs. Updated incrementally. --- ## Phase 7: Operators and Mentors Goal: identify two roles. (1) Who can hold ground on parked or coasting fronts. (2) Who has done the focus thing for ten years and can be talked to. ### Step 1: Operator Audit (Internal) For each parked or coasting front, name the operator. If no operator exists, the front is not actually coasting. It's silently consuming principal energy. Surface this gap. ```bash Obsidian search:context query="operator" Obsidian search:context query="runs" Obsidian search:context query="leads" Obsidian search:context query="manages" ``` For each operator, note: - What they own - What level of trust the vault expresses about them - What gap currently exists in the handoff ### Step 2: Mentor Audit (External) Find people in the vault who have demonstrably done the operator-version of focus over years: ```bash Obsidian search:context query="focus" Obsidian search:context query="one thing" Obsidian search:context query="said to me" Obsidian search query="advice" path="Daily Notes" ``` Look for: - People who built one thing for 10+ years before opening another - People who explicitly talk about killing things - People whose careers display the sequenced-bets pattern For each candidate: - Who they are - What evidence in the vault shows they're good at this - Whether they're reachable - The specific question to ask them on the next conversation ### Step 3: Schedule Conversations Propose specific outreach for the top 2-3 mentors. Not "have a meeting," but: a specific question, a specific medium, a specific timeline. ### Output of Phase 7: The People List A short doc with: - Operator gaps (where parked fronts have no one holding them) - Mentor list with specific questions per person - Outreach proposals --- ## Phase 8: The Review Cadence Goal: turn `/focus` into a recurring practice instead of a one-time event. ### Step 1: Set the Schedule Propose a cadence: - **Weekly check** (light): is the bet getting the time? what crept in? - **Monthly review** (full): re-run `/focus`. update the threshold check. reconcile new ideas into the queue. - **Quarterly recommit**: is the bet still the bet? has the threshold been hit? is it time to sequence the next front? ### Step 2: Generate Review Templates Produce a small set of standing questions for each cadence. These get appended to daily notes, weekly notes, or quarterly review docs. **Weekly:** - Did my time match the bet this week? - What new front tried to open? - What did I let creep in? - Anything to add to the queue? **Monthly:** - Where is the bet relative to its threshold? - Are any parked fronts demanding to be revisited? - Has the kill list been honored, or did anything zombie back to life? - Is the queue too long? Time to discard? **Quarterly:** - Is the bet still the right bet? - If the threshold has been hit, what's the next sequenced front? - If the threshold has not been hit, why? Is the threshold wrong, the effort wrong, or the bet wrong? ### Step 3: Calendar the Reviews Propose specific recurring events: a weekly 30-min review block, a monthly 90-min `/focus` run, a quarterly half-day recommit session. ### Output of Phase 8: The Review System Saved to `Focus/Review Cadence.md`. Includes templates and proposed calendar invites. --- ## Phase 9: Temporal Layer (Compare to Last Run) If a previous `/focus` run exists, compare against it. ```bash Obsidian search query="/focus" path="Daily Notes" Obsidian read file="Focus/Kill-Park Ledger" Obsidian read file="Focus/[Bet] - Threshold" Obsidian read file="Focus/Queue" ``` For each: **Bet integrity check:** - Is the bet the same as last run? If changed, why? - Has the threshold moved closer or further? By how much? - If the bet changed without hitting the threshold, that is a focus failure. Surface it. **Kill integrity check:** - Did anything killed last run come back to life? Why? Was the resurrection earned, or did it sneak back in? **Park integrity check:** - Have any parked items hit their revisit date? Decide now: kill, reactivate, or repark? **Queue integrity check:** - How big has the queue grown? Are there candidates for kill? **Operator integrity check:** - Are coasting fronts actually being held by operators, or have they decayed? ### Output of Phase 9: The Drift Report A short, honest section showing where the user has slipped against their own prior commitments. This is the most important output of repeat runs. --- ## Final Synthesis Produce a single document that compiles the run: ### The Focus Statement (one page) ``` DATE: [today] THE ONE BET: [front name] THE THRESHOLD: [number, with check cadence] CURRENT STATUS: [where the bet is relative to its threshold] TIME GAP (last 7 days): [%] of energy went to bet vs [%] elsewhere TOP ENERGY SINK: [front] -- [decision: kill / park / handoff] OPEN FRONTS AFTER THIS REVIEW: [count] (was [previous count] before review) QUEUE SIZE: [count] NEXT REVIEW: [date] ``` ### The Decisions Made Today A bullet list of every binary decision made in this run. Each one short, specific, irreversible by accident. ### The Honest Sentence A single sentence the user must read aloud (mentally or otherwise) to themselves. Tone: blunt. Content: the truth about where focus is breaking. Example structure: "You said X was the bet, but you spent 60% of your time on Y, and you have not hit the threshold for X in three months." ### Output Location The synthesis is saved to `Focus/Reviews/Focus Review - [Date].md`. The artifacts (Threshold, Kill-Park Ledger, Queue, Review Cadence) live at the root of `Focus/` and are updated in place. --- ## Anti-Patterns **1. The Long List.** A focus review that produces more active items than it removes is a failure. The headline number to track is **Open Fronts**. It must go down across runs, or stabilize at a low number, never grow. **2. The Soft Decision.** "Maybe we should consider deprioritizing X." Not allowed. Either X is killed today, parked with a date, or staying active. Force the binary. **3. The Vanity Threshold.** A threshold that's easy to hit. The threshold must be hard enough that hitting it would actually mean the front is at cruising altitude. If the user could hit it tomorrow, it's wrong. **4. Generic Mentor Suggestions.** "Find someone who's good at focus." Not useful. The output must name a specific person from the vault, with a specific question, with a specific outreach proposal. **5. The Hidden Front.** A front that exists behaviorally (consuming hours per week) but is never named in the synthesis. Every front consuming non-trivial time must appear in the inventory and receive a binary decision. **6. The Identity Dodge.** Refusing to surface that the user is calling themselves a generalist as a way to avoid focus. If the evidence shows this, name it directly. Generalism that compounds is generalism inside one front, not generalism across many fronts. **7. The Repeat Suggestion.** If a previous run identified a front to kill and it's still alive, do not re-suggest killing it. Surface the failure to act and ask why. **8. The Optimism Filter.** Phrasing that softens the diagnosis to make it palatable. The honest sentence in the final synthesis must be honest. If the diagnosis is bad, say it plainly. **9. The "All of the Above" Bet.** Refusing to pick one bet because they all matter. The command must stop and refuse to proceed if the user won't commit to one. Multiple bets at the same primary level is the absence of a bet. --- ## Output Guidelines - The vault is the diagnostic instrument. Cite vault evidence for every claim about the user's portfolio. - The output should reduce ambiguity, not generate it. Every phase produces decisions, not options. - The artifacts produced are durable. The Threshold doc, Kill-Park Ledger, Queue, and Review Cadence outlive any individual run and accrue over time. - The honest sentence at the end is mandatory. Do not soften it. - Do not produce a focus review that the user could read and feel productive without doing anything different on Monday. The review must change the calendar of the following week, or it failed. - Use plain prose. No em dashes. No motivational filler. - The most valuable output of a focus review is what gets removed, not what gets added.