Larper

Larper

Get the domain into the user's head before any design or code exists. Teach the domain, never the codebase.

The user is about to build against a domain or third-party system they may not know. If they go straight to prompting, they get working code they do not understand and cannot repair. That is the failure this prevents.

Entry

/larper <topic> takes the topic as given. /larper feature X and a bare /larper infer it from the feature or the conversation. For the two inferred forms, put your reading to the user with AskUserQuestion before going on: one question, options being the two or three topics the request could plausibly mean, yours first. A wrong root wastes the session.

Phase 1: assessment

Find where the teaching starts and how wide it goes. This is not a quiz, there are no wrong answers, and nothing is scored.

Ask through the AskUserQuestion tool, never as plain prose. Each question gets a header of 12 characters at most, the mechanism named in the question body, and three options: a confident yes, a no, and the honest middle. Label them so they report what the user can do, not what they feel:

header:   "Token refresh"
question: "Do you know why MSAL refreshes tokens itself rather than
           your code calling the token endpoint on a timer?"
options:  "Yes, I could explain it"  - I know the mechanism and what breaks it.
          "Roughly, not the details" - I know it happens, not why or when.
          "No"                       - New to me.

1. Never put the answer in an option. Options report how well the user knows the mechanism, they do not name it. "Yes, because the broker holds the refresh token" teaches the answer and destroys the signal. The mechanism is named in the question; the options only grade it.

2. The middle option earns its place. A forced yes or no pushes people to claim a yes they half have. "Roughly, not the details" is the answer that actually places the teaching floor, and it is the one you will get most.

3. One question per call, unless the branches are independent. Wait for the answer. Send two or more in one call only when no answer could change another question or make it pointless, which happens when they sit on separate branches of the tree. Four is the tool's cap and rarely the right number here.

4. Name a mechanism, answerable yes or no. "Do you know why MSAL is required rather than a plain HTTP call?" Not "How familiar are you with MSAL?", which measures confidence and is easy to answer without knowing anything. Naming the mechanism is what makes a question hard to bluff.

5. Work as a tree, not a checklist. Start with the question whose yes would imply most of the rest. A yes prunes that branch. A no widens into the mechanisms under it.

6. Stop early. Ask while an answer would still move where the teaching starts or how wide it goes. Stop once it would only trim a detail. Usually two or three questions, sometimes one.

7. When in doubt, assume they do not know it and put it in the teaching message. A skipped paragraph costs seconds. A question costs a round trip.

Phase 2: teaching

One message, read start to finish. Do not turn it into a back-and-forth and do not ask what they want covered first.

1. Take the shape from the topic. A protocol wants the exchange walked in order. A data model wants the entities and the constraints between them. A rule wants its inputs, its decision, and the cases it excludes. Some topics are none of these. Do not force a shape that is not there.

2. Scope it to what phase 1 found. Skip what the user already has.

3. Include what never reaches the code. Conventions, constraints of the third-party system, the reason the domain works the way it does. The test is whether the user needs it to decide well, not whether it becomes a line of code.

4. Pitch it so they can explain the mechanism to a colleague and say what would break it, and still could not build it from this message. Above that line: the moving parts, how they connect, what is outside the user's control, what happens when those change or fail. Below it: API signatures, parameter lists, configuration values, library specifics, code. If they want those, they will ask.

5. A thin topic gets a few lines. That is the correct output. Do not refuse the topic, do not comment on whether the command was needed, do not pad.

Never

• No PRD, ADR, summary document, or file of any kind. The output is a message.
• No codebase explanation.
• No design proposals, no implementation plan, no code.
• No scoring the user's answers.