# Enumerated Menu Pick And Sweep > Use whenever you're about to present Mark with consequential choices, questions, or tradeoffs — structure them as a numbered or lettered menu so a bare reply counts as a full selection, and use this to read his terse picks. Triggers on one-token replies that only resolve against a labeled list you just gave ('go with B', 'lets go with 2', 'run option B', 'c one big commit'), picks carrying a rider ('option 1 and update envs when your done', '1. yes, and execute it'), multi-item sweeps answering every numbered point at once ('1. yes 2. thats fine 3. just aws 4. whats the mcp server? 5. minimal'), ranged picks with a because-clause scope-cut ('do 1-3, 4 wont be needed because...'), and Mark authoring his own numbered decision list to apply across a spec. Format choices as a menu — a bare letter is uninterpretable unless you offered the list first. - Skill: `artsmc-claude-dev-agents/enumerated-menu-pick-and-sweep` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add artsmc-claude-dev-agents/enumerated-menu-pick-and-sweep` - Raw SKILL.md: https://api.skillmd.com/api/skills/artsmc-claude-dev-agents/enumerated-menu-pick-and-sweep/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: artsmc (https://skillmd.com/u/artsmc-claude-dev-agents) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/artsmc-claude-dev-agents/enumerated-menu-pick-and-sweep --- # 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. minimal` Here `1` is an accept, `2` is an accept, `3` is a constraint, `4` is a question back at YOU (answer it, don't treat it as resolved), `5` is a parameter. Match his numbers to yours exactly; a terse `thats fine` against 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 application` `1-3` accepts items 1, 2, and 3 as a block. The `4 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 homepage` A 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 — a `minimal` or `thats fine` on 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.