artsmc Offer Choices As An Enumerated Menu, Resolve Picks Item-By-Item
Mark decides by picking from a list. He does not want a wall of prose he has to parse and reply to in sentences — he wants you to do the structuring work so his answer can be a single character. When you surface consequential choices, questions, or findings, lay them out as a numbered or lettered menu; then he sweeps that menu item-by-item, accepting or cutting each one with a one-clause reason and pinning the single thing that actually matters. A bare B or #2 is a FULL selection, but it is uninterpretable unless a labeled list came first — so the menu shape is your responsibility, and reading his terse picks correctly is the rest of this skill.
1. Shape your own output as an enumerated menu — make a bare letter a valid answer
Whenever you are about to present consequential choices, open questions, tradeoffs, or findings, do NOT bury them in prose. Restructure them as a numbered (1. 2. 3.) or lettered (A. B. C.) list, one decision per line, each line self-contained. The test: could Mark resolve this whole message by typing B, option 1, or 1. yes 2. no? If not, you have under-structured it. This is what lets him reply run option B or c one big commit — the letter only carries meaning because you labeled the options first. Keep each item to a single decision; don't fuse two choices onto one number.
2. A bare letter/number IS the selection — execute it, don't re-ask
When his reply only makes sense against a list you just offered — go with B, lets go with #2, Option B, run option B, option 1 — that is a complete, committed choice. Map it back to the exact menu item and act on it. Do not re-explain the option, re-ask for confirmation, or re-present the menu. The whole point of the menu was to make his reply this cheap; honor it by moving immediately.
3. Parse the rider attached to the pick
His picks often carry a second clause bolted onto the chosen item — a follow-on action or an inline answer: option 1 and update envs when your done, 1. yes, and execute it. Treat the rider as part of the same instruction: do the selected option AND the appended directive in one move. The rider is scoped to that item — update envs when your done is the tail of choosing option 1, not a separate request to negotiate.
4. Resolve a multi-item sweep — answer every numbered point in one pass
When he answers several of your numbered items at once, walk his reply index-by-index against your menu and resolve each independently:
1. yes multi tenant, 2.thats fine, 3 just aws manage everything, 4.whats the mcp server for? 5. minimalHere1is an accept,2is an accept,3is a constraint,4is a question back at YOU (answer it, don't treat it as resolved),5is a parameter. Match his numbers to yours exactly; a tersethats fineagainst item 2 means item 2 is settled. If one of his numbered replies is a question (4.whats the mcp server for?), surface the answer before proceeding on that item — it is the one piece still open.
5. Honor a ranged selection and its because-clause scope-cut
He selects spans and prunes the remainder with an explicit reason:
lets do 1-3, 4 wont be needed because this is a small application1-3accepts items 1, 2, and 3 as a block. The4 wont be needed because...is a deliberate scope cut — drop item 4 and treat the because-clause as the recorded justification, not a point to argue back. When he gives a reason for cutting, the reason is final; don't re-pitch the dropped item. Reflect the cut in whatever plan/spec/tickets follow so it can't creep back in.
6. When HE authors the numbered list, it is the spec — apply each item across the artifact
Mark frequently writes his own #-numbered list of decisions to apply across a spec sheet or codebase — e.g. #1 in your spec sheet draw a mermaid uml of the schema. #2 same for the api. #4 the OTP from sentient-monorepo is the pattern we should match. #8 instead of linear we will use sentient-monrepo. Each numbered line is a directive; sweep them top to bottom and apply every one. His numbering can skip (#1 #2 #4 #8) — do not invent or fill the gaps, just resolve the items he actually wrote. Each #N is independent: some are tasks, some are source-of-truth declarations, some are scope cuts. Apply them all; do not collapse them into a vague summary.
7. Pin the one thing that matters; defer or derisk the rest
Inside a sweep, identify the single item Mark flags as the thing that actually matters and lead with it, letting the others wait or be handled cheaply. He says so explicitly:
the api is not important what is important is that its present on the homepageA pick can elevate one item and demote the rest in the same breath. When he does this, do the pinned item to the bar he set and don't over-invest in the demoted ones — aminimalorthats fineon an item is permission to do the cheap version.
8. If a menu was never offered, a bare letter is unparseable — say so or re-offer
A lone B or #2 with no prior labeled list in the thread is ambiguous, not a free choice for you to assign. Don't guess which B he means. Either re-surface the menu you should have presented, or ask the one blunt question that recovers the mapping. The fix is almost always upstream: you should have given him a menu to begin with (section 1).
Red flags
The full table of misreads and Mark's corrections (re-asking after a bare pick, dropping a rider, treating an in-sweep question as resolved, re-pitching a cut item, filling skip-numbered gaps, over-building a demoted item), plus the verbatim pick examples, lives in references/examples.md — read it when a terse reply maps ambiguously onto your menu.
See steer-and-correct-the-agent for his single terse directives (yes, no replace X with Y, method constraints) once a pick is in motion, and research-gated-build-plan for sequencing and scope-cutting a larger plan that a sweep resolves.