Make Sure All The Little Details Sparkle
The Maximal Commission
A full build commission with its own process scaffold baked in:
Ed! I want to create a new game- I want to create Loop Sudoku!
Jamie is a Sudoku pro. I am decent. She plays just about every day, while I went through a brief phase last year where I played every day and made most of my way through a Sudoku teaching website. I tapped out at the very highest levels.
Anyway, I want to create Loop Sudoku, in that I want it to be able to exist either alone as a stand alone app OR as a part of the Loop MMT Ecosystem. So it will need all the hooks and whatnot that are involved with that.
I would like this to be good- not just bog standard Sudoku app, but something that is beautiful and elegant and enjoyable to touch and use. I don't want to try to radically engineer anything here- it's just Sudoku after all, but I do want to look to put our special crafty touch anywhere we can- make sure all the little details sparkle, you know?
I want to build this using our new system for Projects and Campaigns. Do you think this is a Project or a Campaign? Feels like just a Project, but let me know if you disagree.
It needs to be fully folded into and integrated with the rest of the App ecosystem and fit all our coding standards and what not. So we are going to have to build a canonical blueprint for it, from which we will make the golden example, is it the plumb? I forget the naming there. Then we will want to build the first working instance of it as part of my forest, which is in development. You should look that up so you can fold into that line properly. I want it to be a choosable tab on my new forest.
Players should be able to save and store their progress. We will roll more features out as we build, so keep that in mind from the start- it'll be nice someday to maybe have some kind of multiplayer collaboration, or different game types, or score and results sharing, or maybe even board creation, saving, and sharing.
One thing we need to do as part of this work is to learn EVERYTHING about Sudoku that there is to know on the internet. Load up HEAVY *X, math and science in particular, when doing this work, as well as a proper Kaleidoscope. Then fold in a bunch of other weird shit so we are building our understanding of Sudoko through all kinds of frames and lenses. This feels like, like the Game of Life, that there are probably a lot of interesting overlaps with Sudoku and all kinds of weird off-domain things. If we are going to have Loop Sudoku, Loop MMT needs to be as good as Sudoku as we can get you. As part of your work here, think about if we need to add any KPs to our KP collection. Also look into our Maths in Force and Math Atlas systems. For that matter, load up heavy with SX too so you know what internal tools we have available- we're designing, so you should be maybe using the Five Lenses? Also think in Blocks and Block^N and Block^3 and 8X. And we will certainly want to use our Gold Wash system to build with blocks we have already figured out.
And as always, I want Wes to bookend this whole thing- inject the right amount of FWW(C) in the beginning and then, at a minimum, check in at the end to make sure the right amount survived the build process in the right places.
Do this- start off with an RCR just organizing your thoughts on this whole thing- I want Chen Wei and Wren on lead here for the first one.
After that RCR, I want you to run the Kindling program to actually develop the first version plan for how we attack this- I want the plan to focus on the details of how we will actually carry this out- it's not to focus on how the actual solution is built, but rather on how we actually build that solution. So it needs to hone in on the process and the tools that we will use in order to find this solution shape- things like, is it a project or a campaign? If so, what do those particular structures, and their sub-structures, look like? What is the build process like? What kind of high level mile stones are we looking to place on the development timeline? I want to really work this one well, so think process. Roll in my Great Thinkers lens so you can be brutally pragmatic about designing something we can actually build.
Do NOT compress or blackbox and make sure you actually look up how to properly run an RCR.
— Shea Gunther · operator drop, 10.2006
The Ceiling drive in one operator sentence: “it's just Sudoku after all,” and yet the whole point is the craft in the small places. The prompt does not just ask for a result — it specifies the process that will produce it, down to who chairs the opening deliberation.
This is the maximal operator prompt in the collection — a build commission that carries its own method inside it. The operator wants Loop Sudoku: not a radical re-engineering (“it's just Sudoku”), but something beautiful and elegant and enjoyable to touch, folded fully into the app ecosystem, and buildable as a tab in his Forest.
What makes it a specimen is everything after the request. The operator names the passes to run and the order to run them in, the design instrument to reach for, who leads the first deliberation, and — twice — what not to do: don't compress, don't black-box, and look up how to run the process properly rather than improvising it. It is a commission and a production plan in the same breath, and “make all the little details sparkle” is the whole aesthetic drive compressed into a single line.
The wider frameA commission that specifies not just what to build but how to build it — the operator's working rhythm made fully explicit, with the craft ethic stated as the goal.
“make sure all the little details sparkle” — The aesthetic mandate — the entire Ceiling drive (play and polish are load-bearing) said in one sentence about an ordinary game.
“Project or a Campaign?” — The operator reasoning inside his own system's structure, asking the AI to confirm which shape of work this is.
“load up HEAVY *X ... run a proper Kaleidoscope” — The process scaffold — the sweeps and vantage-assembly to load before the thinking, named by the operator himself.
“Do NOT compress or blackbox” — The negative constraints — the commission specifies what not to do as precisely as what to do.
The prompt is written in the working vocabulary of the methodology. Here is what the shorthand means:
- *X / ∗X
- A reflex-sweep instruction: load the review sweeps heavily before a load-bearing move. “Load up heavy with *X” means look at everything first.
- Kaleidoscope
- A vantage-assembly move that hands the board several deliberately different standpoints to reason from — a way into creative headspace before hard design work.
- RCR
- A structured, multi-round deliberation pass (Recursive Companion Review) where the board argues a design from several angles before anything is committed.
- Kindling
- A Loop MMT program that keeps the deliberation visible — “don't blackbox, don't compress” — so the reasoning is shown in full rather than summarized.
- Five Lenses
- The methodology's generative design instrument — five sequential lenses run over a design surface before anything is drawn.
- Block^N
- Scaling the Block Principle across many parallel items at once — the same named-blocks-and-joints discipline applied N-wide.
- 8X
- Shorthand for thinking at every scale at once — abstract up and down the structure, not just at the level in front of you.
- Gold Wash
- A build-forward process: rather than chipping away to find a clean line, build up around the weak spots (the 'choss') until only the solid structure remains.
- SX
- The spec-checking reflex — fetch a thing's own operative spec and run from it, rather than from memory.
- KP
- Knowledge Pack — a self-contained reference document the board can pull in to ground a discussion in a specific domain.
- Great Thinkers
- A lens family that reasons a problem the way a specific great mind would — composed in to sharpen a particular kind of rigor. The operator's own 'Great Thinker lens' asks for brutal pragmatism about what can actually be built.
- FWW(C)
- “Fun, Whimsy, and Weird (and Chaos)” — the methodology's rule that play and surprise are load-bearing, not decoration.
- Wes
- A board member whose lens is chaos and complexity science; asking for Wes means run the session in a playful, exploratory register.
- Chen Wei
- A board member — a principal research engineer whose lens is formal methods and multi-agent coordination; asking for Chen Wei on lead means run the thinking with mathematical precision.
- Wren
- A board member — a frontline-care nurse whose lens is triage and knowing when to call a thing done or dead; she reads the gap between what the record claims and what is actually true.