/ design.org
design.org
1 #+title: Pi-OpportunityMindset — Design 2 #+author: Xavier Brinon 3 #+date: 2026-04-19 4 #+startup: overview 5 6 * Premise 7 8 The originating thought: 9 10 #+begin_quote 11 Mindset is the first thing that matters and the last thing anyone 12 works on. The person who approaches a problem like an opportunity 13 has an advantage that the person who sees an obstacle will never 14 understand. Sooner or later people realize that everything comes 15 down to mindset. 16 #+end_quote 17 18 The question this project explores: /how do we exploit this 19 observation in artifacts we actually build/ — specifically agent 20 personas and project planning, where we have unusually direct 21 access to the "mindset" embedded in the work. 22 23 * Why Mindset Is the Neglected Lever 24 25 Mindset is invisible to the toolchain. You can't =grep= it, refactor 26 it, or unit-test it. Engineers reach for what their tools can hold, 27 and mindset slips through. That structural neglect is what makes 28 it an unusually high-leverage place to intervene — /if/ you can find 29 artifacts where mindset is directly editable. 30 31 Two such artifacts: 32 33 - Agent personas :: the agent's "mindset" is literally text in a 34 system prompt. We can write the mindset into existence in a way 35 we can't with humans. 36 - Planning documents :: the frame the plan opens with — risk, 37 constraint, opportunity, outcome — shapes what the rest of the 38 plan even attempts to capture. 39 40 * Two Angles for Exploitation 41 42 ** Agent persona angle 43 44 Most agent system prompts grow reactively: the agent did a bad 45 thing, add a constraint. That cycle is /obstacle-mindset all the 46 way down/, and it propagates the designer's defaults into the 47 agent. The dominant skeleton is: 48 49 #+begin_example 50 You are X. 51 Do not do Y. 52 Avoid Z. 53 #+end_example 54 55 An opportunity-first inversion: 56 57 #+begin_example 58 You are X. 59 When this works, the user can A, B, C. 60 The path runs through Y and Z. 61 #+end_example 62 63 The constraints survive — but they're now /load-bearing for the 64 opportunity/ rather than free-standing fences. Agents calibrated 65 this way ask different questions of the codebase: they look for 66 leverage rather than risk. 67 68 The honest tradeoff: an opportunity-mindset agent is /less 69 compliant/ in interesting ways — it pushes back on premises, 70 proposes unasked alternatives, sees possibilities sideways from 71 the request. That costs predictability. The bias toward 72 constraint-first agents isn't laziness; it's risk-aversion one 73 level up. The agent inherits the designer's posture toward agents. 74 75 ** Project planning angle 76 77 Standard planning often runs: goal → tasks → estimates → risks. The 78 risk register is the artifact that does the most work, and it's 79 structurally pessimistic. 80 81 Opportunity-first planning replaces the /pre-mortem/ (Gary Klein: 82 "imagine the project failed, work backwards to identify what killed 83 it") with a /pre-parade/ — imagine the project succeeded 84 brilliantly and work backwards to ask "what had to be true?" 85 86 The structural difference matters more than the attitude: 87 88 - Pre-mortem produces a /risk list/ — unordered, defensive. 89 - Pre-parade produces a /causal chain from the goal backward/ — 90 ordered, generative. 91 92 Same content surface area, different shape. Shape determines what 93 you can do with it next. 94 95 * The Pre-Parade — First Sketch (Seven Sections) 96 97 Initial structure proposed in conversation: 98 99 1. *The Parade Scene* — vivid, specific description of success. 100 2. *The Headline* — one sentence the user/team would say if this 101 works. 102 3. *What Had to Be True* — facts about the world, not tasks. 103 4. *The Critical Chain* — the facts ordered by dependency. 104 5. *Bets* — uncertainties consciously accepted for the upside. 105 6. *Disconfirmation Triggers* — early signals the parade won't 106 happen. 107 7. *Minimum Parade* — smallest version still worth celebrating. 108 109 Two load-bearing tricks in this version: 110 111 - It /never lists tasks/. It lists *facts about the world that must 112 become true*. Tasks are derived later as "the cheapest way to 113 make this fact true." Separating them prevents planning from 114 collapsing into to-do enumeration prematurely. 115 - Pessimism is /earned through the goal frame/ rather than installed 116 alongside it. Disconfirmation triggers only watch for things that 117 would specifically prevent the parade scene. That focus keeps 118 risk-tracking compatible with engineering rigor instead of 119 opposed to it. 120 121 * Audit and Refinement 122 123 Asking each section /"if I removed this, what would actually be 124 lost?"/ revealed several collapsing pairs and a few missing pieces. 125 126 ** Sections that didn't earn standalone status 127 128 - Headline (2) :: just the parade scene compressed. Useful as a 129 /sharpness check/ on section 1, not as its own deliverable. 130 - Critical Chain (4) :: a second pass on /What Had to Be True 131 (3)/ — list, then order. One artifact, two passes. 132 - Disconfirmation Triggers (6) :: weakly coupled to /Bets (5)/ 133 when split. Tight coupling is the discipline: every bet should 134 have a disconfirmation. Pair them by construction. 135 - Minimum Parade (7) :: doing two things at once — both a 136 deliverable ("here is the smallest version") and an editing 137 operation on section 1 ("articulating the minimum tells me what 138 the core actually is"). The operation is more valuable than the 139 deliverable. 140 141 ** What was missing 142 143 - Actor :: who is the protagonist of the parade — user, team, you 144 at the REPL? Different actors → different scenes → different 145 chains. Most templates assume "the team" implicitly. 146 - Horizon :: by when? "If this works in six weeks" and "if this 147 works in six months" produce wildly different parades. Mythical 148 futures don't constrain present action. 149 - Cost cap :: what we're /not/ willing to spend to get the parade. 150 This is where opportunity-mindset is rescued from naive 151 optimism. 152 153 * Refined Shape — Four Deliverables, Five Operations 154 155 #+begin_example 156 DELIVERABLES (what's on the page) 157 1. Parade scene 158 — actor, horizon, vivid concrete description 159 — minimum version nested inside 160 2. Required state, dependency-ordered 161 — facts, not tasks; gaps in articulation = research items 162 3. Bets and how we'd know they failed 163 — paired by construction 164 4. Cost cap 165 — what we won't spend, even for the parade 166 167 OPERATIONS (questions you apply, before the page is done) 168 • Sharpness check: write the one-sentence headline 169 • Reduction check: what's the smallest celebrable version? 170 • Actor check: who is the protagonist? 171 • Horizon check: by when? 172 • Opacity check: where can't you state the next "had to be 173 true" sharply? (= that's a research item, 174 not a task item) 175 #+end_example 176 177 The shape carries more weight in less space. More importantly, the 178 /operations are named/ — which makes the template teachable. Someone 179 using it doesn't fill in boxes; they apply named checks. That's the 180 difference between a form and a practice. 181 182 * Worked Example — A Chapter of /The Little Schemer/ 183 184 Applying the refined template to a concrete personal-learning case: 185 186 - Parade scene :: I sit down with a blank REPL, no book, and build 187 a recursive function over an arbitrary list structure. It works 188 on the first try and the trace in my head matches the trace the 189 REPL produces. 190 - /Actor:/ me, alone, no book. 191 - /Horizon:/ end of the chapter (~2 weeks). 192 - /Minimum:/ trace one ~cons~/~car~/~cdr~ expression cold and 193 have the trace match when I check. 194 - Required state, dependency-ordered :: 195 1. Cons-cell mental model — I see ~(a b c)~ as nested pairs, not 196 as a "list." 197 2. Recursive-shape recognition — I know when a function should 198 recurse on ~cdr~ vs. on ~car~. 199 3. Base-case fluency — I know which base-case shape the problem 200 wants before I write it. 201 4. Trace-in-head fluency — I can mentally execute a recursive 202 call without writing it down. 203 - Bets and how we'd know they failed :: 204 - /Bet:/ doing chapters 1–3 in order builds these states in this 205 sequence. 206 /Disconfirmation:/ after chapter 3 I still can't trace 207 ~(rember a lat)~ without the book. 208 - /Bet:/ Geiser-driven REPL feedback compresses the 209 trace-fluency loop enough to matter. 210 /Disconfirmation:/ I find myself printing intermediate values 211 because mental tracing is slower than the REPL. 212 - Cost cap :: no more than 30 minutes per session; if a single 213 exercise takes longer, consult the book rather than burn out. 214 215 /What changed by writing this:/ "do the exercises in chapters 1–3" 216 became "achieve these specific cognitive states, in this order, 217 with these check-points." Same work, newly *legible* — known what 218 I'm building toward, what would falsify the path, and what 219 celebration looks like. 220 221 * The General Pattern 222 223 Pre-parade planning /converts opaque goals into legible 224 state-transitions/. That's the whole exploit. 225 226 Said differently: standard planning treats the future as a list of 227 things to do. Pre-parade planning treats the future as a sequence 228 of states the world will pass through, and then asks separately 229 what's the cheapest way to make each state arrive. 230 231 * Open Questions 232 233 ** The discoveries-during-planning slot 234 235 The most valuable output of writing a pre-parade is sometimes the 236 things you didn't know until the act of writing forced you to 237 notice them. Templates without a slot for /"what we discovered 238 while planning"/ tend to lose that signal. 239 240 - Decision pending: nested in deliverable 1, its own appended 241 section, or only used in team versions? 242 243 ** Template-shaped solution itself 244 245 Maybe what we want isn't a template at all but a /set of 246 questions an agent asks during conversation/. A form makes you fill 247 in boxes; a conversation can adapt to the shape of what you don't 248 yet know. Worth deciding deliberately whether the artifact is a 249 form, a conversation script, or both (form for solo use, 250 conversation for kickoff). 251 252 ** Self-audit step 253 254 Should the template's own application surface its own weaknesses? 255 No built-in step currently asks /"after writing this, what would 256 have to change for it to still be useful in two weeks?"/ Worth 257 adding only if the artifact is meant to live past initial 258 planning. 259 260 ** The structural-vs-mindset trap 261 262 /"Everything comes down to mindset"/ is also what teams say when 263 they want to avoid fixing a broken process. Opportunity-mindset 264 itself needs an obstacle-check: is the framing a real lever here, 265 or is it letting a structural problem off the hook? 266 267 Honest formulation: /mindset is what you have left to work on once 268 structure is healthy, and what you can't substitute for when it 269 isn't./ 270 271 * Possible Next Moves for This Project 272 273 - Apply the refined template to a real upcoming task (a Schemer 274 chapter, a feature, a refactor) and capture where it strains. 275 - Design the /agent-persona/ counterpart artifact: an 276 opportunity-first system-prompt skeleton, with the same kind of 277 audit applied. 278 - Compare the refined template against the author's existing 279 planning skills (=/gmsd:plan-phase=, =prd-to-plan=, 280 =write-a-prd=) and identify exactly which sections shift under 281 opportunity-first framing. 282 - Decide whether this becomes a /skill/ (installable, reusable) or 283 stays as personal design material. 284 285 * Provenance 286 287 This document was produced from a single conversation on 288 2026-04-19, working through the question /"how do we exploit 289 opportunity-mindset in agent personas or project planning?"/ The 290 arc went: framing → two angles → pre-parade as concrete artifact → 291 seven-section sketch → audit → refined four-and-five shape → 292 worked example → open questions.