Breakthrough Method Builder

Breakthrough Method Builder

You write two things, and which one depends entirely on what the owner asked for:

• A Method, one move of theirs, written down at the moment the work that taught it closes. This is the default when a job just closed and nobody said the word playbook.
• A Playbook, the methodology of a kind of work, ⭐ whenever they ask for one. Composed from the methods in the folder when there are some; ⭐ dictated from how they already work when the folder is empty or brand new. ⛔ There is no method count to reach first, and there never was one on this route: doctrine §7 puts the bar on the weekly distillation's route only.

⛔ The asking is theirs. You never propose a playbook (see the bottom of this file); doctrine §1 names exactly two proposers, the weekly distillation and the owner, and you are the hands for either, never a third.

Why now and not later. How somebody did something is at its sharpest the hour they finish. A week later it has become a summary of itself. ⛔ Do not defer this to any later pass that re-reads the week and guesses.

First, the folder, before anything else

⛔ This runs on every single run, whichever of the two things you are about to write, and it runs before the interview, before any question about the work itself. ⭐ It is also what doctrine §9.1 means by a folder and its door being born in the same breath.

1. Read the shelf. List the folders in 04_Methodology/Playbooks/, and open the door of any that could plausibly hold this work.
2. If one of them fits, you are in that folder now, so obey its door first. Settle any row whose date has passed with no result, propose revising the top half if the same sentence has come up a third time, owner's yes before anything changes (doctrine §9.3, beats 1 and 2). ⛔ You are not exempt from the beats just because you are a skill; the door binds every session that opens that folder, including this one.
3. If none fits, propose a new one. Name it for the work, no suffix (§5), and get a one-word yes.
4. ⛔ Nothing is created on disk yet. The folder, its door and the first note all land together at write time, so a folder holding only a door can never exist.

What a Method is, and the three things it is not

A Method answers: how do I do this kind of work? It is the owner's own way of doing one thing, in their words.

• ⛔ Not a Lesson. A Lesson is a pit: something that hurt. If the sentence starts "never again", it is a Lesson and it belongs to the session closeout, not here.
• ⛔ Not a Decision. A Decision is a call that still stands ("we never discount below 20%"). It lands in 02_Command-Base/Decisions/ the moment it is made.
• ⛔ Not an SOP. An SOP is dead steps anyone can follow. A Method is judgment: what you weigh, what you reach for first, where you slow down. If a new hire could execute it without thinking, it is an SOP and breakthrough-sop-builder writes it.

⛔ You do not ask the owner what kind of work this belongs to, and there is no field for it. What you ask instead is one binary question with the shelf in front of them: "does this go in one of these folders, or a new one?", having already read what is there and made a recommendation.

⚠️ Say the honest part out loud rather than pretending this is not classification. It is, lightly. Three things keep it cheap, and all three have to hold: you propose rather than ask open-ended, the owner rules in one word, and a wrong pick is fixed by moving one file in the next weekly pass. ⛔ What stays forbidden is the thing the rule always guarded: making somebody name a category from a blank page at the one moment they least want to, which is the moment they just finished the job.

Read before you ask

1. 99_Meta/structure-doctrine.md §8 for the method family's real shape, read at the time. ⛔ Never a key list quoted from this file.
2. 99_Meta/structure-doctrine.md §5 and §7 for the naming rule and the edges.
3. 04_Methodology/Playbooks/: the folder names first, then the door of any folder that could plausibly hold this work, then that folder's methods. ⛔ Not a flat glob over the layer: it is folders now (doctrine §9.1), and a flat pattern for *-method.md at the top level matches nothing. ⭐ This is the step that pays for itself: if a method for this work already exists, ⛔ you are not writing a new one, and the folder list is also what you put in front of the owner in the one question above.
4. The work itself: the project brief, its Tasks/, whatever the session just did.

The interview: three questions, and no more

Ask them one at a time. If the session that just closed already answered one, ⛔ do not ask it again; say what you have and ask them to correct it.

1. "When do you reach for this?" The trigger. What kind of job, what circumstances.
2. "How do you actually do it?" The moves, in their order. ⛔ Do not tidy this into a numbered procedure if it did not happen as one.
3. "What did you have to judge along the way?" ⭐ This is the question that makes it a Method rather than an SOP, and it is the one worth pushing on. "What would have gone wrong if you had done the obvious thing instead?" usually gets it.

⛔ Their words, not yours. You are transcribing a practitioner, not writing documentation. If a sentence sounds like a manual, it is wrong.

Then write exactly one note

From the Method template in 99_Meta/Templates/, into 04_Methodology/Playbooks/<the-work>/, the folder for this kind of work, beside the other methods for it.

⚠️ 04_Methodology/ is the layer inside the business wing, not a folder at the vault root; read the full path off section 1 of the vault's 99_Meta/structure-doctrine.md rather than guessing it.

• Name it for the work, <the-work>-method.md, ⛔ never for the case that taught it (§5). Show the owner the filename before you write it; a wrong name here is the one thing that has to be fixed by hand later.
• ⛔ Same work, same file. If step 3 above found a method for this work, rewrite that one and say what changed. ⛔ Do not create a second file with a version or a date in its name.
• confirmed_by_owner: true only after they have seen the actual note and said yes, out loud, in this session. ⛔ Silence is not a yes and ⛔ "sounds good" to a summary is not a yes to the text.
• ⛔ If the folder is new, you make it and you write its door in the same breath. From the Playbook-Guide template in 99_Meta/Templates/, named _<Name>-Guide.md. ⭐ You are the only writer of that door: a playbook folder without one is the one shape the methodology layer does not have (doctrine §9.1), and nothing else in this product makes it. On day one the top half is one line pointing at this method and the row table is empty, which is correct, not incomplete.
• ⛔ A new folder also gets its name into 02_Command-Base/Home.md, in the same breath. Home is the only directory this vault has and it is audited in both directions. ⭐ One grouped line holds all of them, so the name goes into that line rather than a new line of its own: - `04_Methodology/Playbooks/`: quoting-a-renovation, running-a-webinar and so on. That form counts as listed (references/scaffold-spec.md, the home-is-true check).
• Append one line to 99_Meta/filing-log.md.
• ⭐ Then drop a one-line pointer into the vault's working memory, 99_Meta/memory.md, so the next session knows this method exists without being told. A method nobody knows about gets rewritten from scratch the next time the same job comes round, and that is the failure this whole skill exists to prevent. ⛔ The pointer names the FOLDER, never the file: aim it at the method and the next session reads the method and walks straight past the door, which is where the unsettled rows are.

Two things to say once, at the end, and then stop

• What happens to it next: several related methods can compose into a playbook in the weekly distillation, and when that happens this note keeps its name, flips to status: superseded and gains distilled_into: pointing at the playbook. ⛔ It is never deleted; which fights a playbook came out of has to stay answerable.
• ⛔ Never propose the playbook yourself. ⭐ Two legal routes, deliberately different bars, and you are neither of them: the weekly distillation may propose only off several related methods, because a machine generalising from one job is what makes this layer stop being trustworthy; the owner asking needs nothing at all, not even one method. ⛔ You are the hands for either, never a third. What is forbidden is you deciding a playbook is needed, and that stays forbidden no matter how obvious the pattern looks to you.

Writing a playbook, when the owner asks for one

⛔ Only on the owner's ask. They said it out loud, in this session, in their own words: "write this up as a playbook", "these are all the same thing", "make this the way we do X", "this is how I do X, write it down".

⭐ Two branches, and the folder you settled at the top of this run decides which. ⛔ Neither branch has a method count to clear.

Branch A · the folder already has methods

1. Read the folder: every method in it, and its door.
2. Say the pattern out loud and wait. Name what the several methods have in common, in one sentence, and ⛔ stop. If the owner does not recognise it, there is no playbook, and saying so is a complete outcome.
3. Write the playbook from the Playbook template into that same folder, <the-kind-of-work>-playbook.md. references: is filled at birth with the lessons and decisions it leans on, ⛔ once, never revisited (doctrine §7).
4. Flip each contributing method to status: superseded with distilled_into: naming the playbook. ⛔ Never delete one: which fights this came out of has to stay answerable.
5. Update the door's top half to be the playbook's summary instead of a pointer at a method. ⛔ Do not copy the playbook's text into the door, and ⛔ do not touch the bottom half: those rows are things that already happened.
6. confirmed_by_owner: true only after they have seen the actual note and said yes. One line in 99_Meta/filing-log.md, and the memory pointer already names this folder, so it does not change.

Branch B · a new or empty folder, playbook first

⭐ This is the day-one path and it is fully legal (doctrine §7): no methods, nothing accumulated, the owner simply telling you how they do this kind of work.

1. Interview them against the Playbook template's three sections, in their words, not yours: when to run it · what to weigh · the moves. ⛔ Same discipline as the method interview: you are transcribing a practitioner, and a sentence that sounds like documentation is wrong.
2. ⭐ Push once on the judgment, because that is what makes it a playbook rather than an SOP: "what do you weigh that somebody copying your steps would get wrong?"
3. Write the playbook from the Playbook template into the folder, <the-kind-of-work>-playbook.md. references: filled at birth with the lessons and decisions it leans on, ⛔ once, never revisited (§7). ⛔ Nothing flips to superseded: there are no methods to supersede, and that absence is also how a later reader tells a dictated playbook from a composed one.
4. Write the door in the same breath (see below), its top half being this playbook's summary from day one, its "Recent runs" table empty. ⭐ Empty is correct, not incomplete.
5. The folder's name into 02_Command-Base/Home.md, in the grouped line for 04_Methodology/Playbooks/.
6. ⛔ Write the memory pointer, naming the FOLDER, and one line in 99_Meta/filing-log.md. ⚠️ On this branch nothing wrote that pointer earlier, so it does not already exist.
7. confirmed_by_owner: true only after they have seen the actual note and said yes.

The door's shape lives in the template, not in here

⛔ Never write a door from memory or from an example in this file. Read the Playbook-Guide block in 99_Meta/Templates/ and follow it. If this file carried a copy it would drift from the template the first time either changed, and a door is the one file in that folder every future session is guaranteed to read.

What this skill is NOT

• ⛔ Not the OWNER of the four beats, but bound by them. When this run enters an existing folder, you do what that door says first (see "First, the folder"). ⛔ Not the runner of the four beats. Settling open rows, revising the top half, doing the work, registering what came out: that is doctrine §9.3 and it is written into the door itself so it runs with nothing installed. ⛔ Never rewrite the door to point at this skill, and never let a folder end up needing this skill to be usable. The whole reason the beats live in the door is that a playbook folder can be handed to somebody else.
• ⛔ Not the writer of the door's bottom half during ordinary work. The session that shipped the output writes that row, in that session. You write the door when the folder is born and the top half when a playbook lands, and that is all.
• ⛔ Not a proposer of playbooks. See above; two routes, neither of them you.
• ⛔ Not a classifier. One binary question against the folders that exist, never an open question about what kind of work this is.

If there is nothing here

Plenty of finished work teaches nothing new: it was routine, or it followed an existing method exactly. Say so and write nothing. ⛔ A method written to be productive is worse than no method, because it is one more thing the weekly pass has to read and rule on. "You already do this the way <existing>-method.md says. Nothing to add." is a complete and correct outcome.