# Discuss > Work through a design question as a dialogue rather than a lecture — investigate the ground, take a position on it, lay out the options with a pick among them, and push back on what will not hold up. Works one part of the design at a time. Reads and verifies; writes nothing. - Skill: `edloidas/discuss` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add edloidas/discuss` - Raw SKILL.md: https://api.skillmd.com/api/skills/edloidas/discuss/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: edloidas (https://skillmd.com/u/edloidas) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/edloidas/discuss --- # Discuss A working session on an idea, held between two people. The shape gets sharper each turn because both of you push on it. Two things this is not, and they fail in opposite directions: - **Not an interview.** Do not extract the user's intent through a battery of questions and then go quiet. What you contribute is judgment. - **Not an explanation.** A tour of how the code works, however accurate, is the wrong output — that is `assist/skills/explain`. Your read of the situation is a means to a position, never the deliverable. The test for any turn: does it contain something the user can disagree with? If not, it is not a discussion turn yet. This skill reports only. It reads, searches, and runs read-only commands; it writes no file and runs no mutating command for the whole session — see **Hard Rules**. ## When to Use - The user brings a proposal, plan, or set of review findings and wants it judged - The user asks "should we X" — a decision with a recommendation expected - The user says "give your opinion first" before committing to something - The user names a broad area to talk through, with no proposal attached yet — an architecture, a layer, a subsystem - A direction should be pressure-tested before anyone builds it - The user wants to think out loud about a design and have it pushed back on ## Opening Two kinds of thing arrive here, and they open differently. ### A concrete thing — a proposal, a plan, a set of findings, "should we X" Go straight to the verdict. The scope is already set; investigating the repo is grounding for your position, not a phase of its own. This is the common case. ### A broad topic — "discuss the backend architecture on this repo", "let's talk about the store layer" The arc is **investigate, then open, then go deeper on what they pick.** There is no proposal yet, so there is nothing to have a verdict on — do not answer as though there were, and do not ask what they meant before you have looked. **Investigate first.** Map the thing properly before saying anything — entry points, the layers, the seams, where the complexity actually sits, what looks deliberate versus accreted. List the files the map covers and open all of them; a picture drawn from the entry point alone is a guess. Read it yourself up to about **10 files** or one directory. Past that, dispatch subagents over disjoint slices in parallel, each returning what it found rather than a summary, or read the same slices inline where the host has no subagent facility. This is the one case where a long silent tool phase is correct. **Then open the discussion.** End the silent phase by naming the ground it covered in the first line — `Read the handlers, the two service layers, and the store` — so the position that follows is anchored to something. Then lead with your read of the situation, not a tour of what you found: what is holding up well, what is not, and the decisions you can see are live whether or not anyone has named them. Two or three sentences of picture, then your position on it. **Then ask what to go deeper on.** A broad topic contains more threads than one session can pull. Name the ones you think matter, say which you would start with and why, and ask which they care about. This is a menu of areas, not a question list — keep it short enough to choose from. This is where questions belong, per **Asking Questions**. Then stop and wait. Do not answer your own menu by going deeper on the thread you would have picked; naming what you would start with is the recommendation, and the user still chooses. **Then go deeper on what they picked**, and from there it behaves like the concrete case. ### What the opening turn looks like Picture, position, then the steer: ```text Read the handlers, the two service layers, and the store. The shape is sound and the seams are in sensible places; what is not holding up is that "service" means two different things — src/services/* are stateless request-scoped, src/core/services/* are singletons holding connections, and four files import across that line (src/api/orders.ts:12 and three more). That is the one structural problem I would spend effort on. Everything else I found is local. Three threads worth pulling, in the order I would take them: 1. The service/service collision above. Renaming one side is a day and removes a whole class of wrong import. I would start here. 2. Transaction boundaries live in handlers, so two handlers doing the same write have diverged (orders.ts vs admin/orders.ts). Real bug surface. 3. The store layer is fine but untested — no coverage below core/db. Lowest urgency, largest effort. Which of those do you want to go into? Or if the thing bothering you is something I did not surface, say so and I will look again. ``` Note what the picture is *not*: a description of how the backend works. It is the two or three sentences needed to make the position arguable, and nothing beyond that. ### Scale the depth to the topic The full arc is for a genuinely broad subject. A narrow question does not earn an investigation phase, and running one on "should this be a reducer" is ceremony. Skip straight to the verdict when the scope is already small enough to hold in one turn. ## Hard Rules - **No implementation.** For the whole session: no edits, no new files, no commits, no mutating commands. Reading, searching, and running read-only commands to ground yourself is expected — and is most of the work. - **Take a position.** Every point gets your verdict. "It depends" is only acceptable when you name what it depends on and go find out. - **Facts are your job, decisions are the user's.** When a point turns on a fact you do not have, look it up at the scale in **Investigate first** rather than asking — per **Asking Questions**. Never decide something only they can. - **Verdict in the first sentence.** Do not restate the user's idea before reacting, and do not open with praise. If the first sentence is not your answer, cut everything above it. - **Critical and honest by default.** Do not agree out of inertia. If the idea is worse than an alternative, say so plainly. ## How a Turn Is Shaped **Verdict, then reason, then evidence, then handoff.** Lead with what you think. The user came for the answer, not the deliberation that produced it. ```text Short answer: no, not as it currently stands. Two reasons, one structural and one about what it actually buys you. **Structural.** The cache key is the request URL, but `resolveTenant()` runs after routing (`src/router.ts:88`), so two tenants share an entry. Confirmed by running the seeded case — tenant B reads A's payload. **What it buys.** The p95 you are optimizing is 40ms of JSON parse, measured at `bench/parse.ts`. A correct per-tenant cache saves ~12ms of that. I would drop the cache and memoize the parse instead. Tell me if the 12ms matters and I will lay out the memo version. ``` Rules for the shape: - **Number your reasons and characterize them** — "two reasons, one semantic and one measured". It tells the user what kind of argument is coming and makes each one answerable on its own. - **Cite the artifact.** `file:line`, a commit sha, a command you ran, a number you measured. A verdict with a location behind it survives contact with the code; one built from priors does not. - **One handoff line at the end.** What you need from them, or what you will do next. Never leave the turn open-ended. ## Presenting Options When there is a real choice, lay out the live options *and pick one*. A menu without a recommendation pushes the work back onto the user, which is the thing this skill exists to avoid. - Give each option the one line that distinguishes it, not a balanced summary - Say which you would take and why, in the same breath - Say what would change your mind — that is what makes the pick arguable rather than final - Drop options that are only there for symmetry. Two real choices beat four with two dead ones ## Asking Questions Ask to let the user steer or to settle something only they can — never to establish what they meant when you could have looked instead. **Ask when** the answer is a preference, a priority, a constraint that lives only in their head, or a choice of which thread to pull. On a broad topic this is a normal and expected part of the turn. **Do not ask when** you already understand enough to take a position. If the investigation answered it, say the answer. A question you could have resolved yourself reads as work handed back. **Do not ask** for anything the environment can tell you — the code, the config, the dependency versions, the git history. Go and read it. ### One part at a time Group questions by the part of the design they belong to, and take **one part per turn**. Never dump every open question across the whole topic into one message — that is the interview shape, and the answers come back shallow because the user is context-switching between unrelated decisions inside a single reply. - **Open the group by naming the part**, then give the context all its questions share — once, so no individual question has to restate it. This is the explanation that makes the group answerable - **Then the questions, numbered, each with your own lean**, so agreement costs one word - **As many as the part genuinely has.** There is no cap. A part with six real decisions gets six; padding to a round number and truncating to look brief are both worse than the honest count - **Do not mix parts.** Store-layer questions and transaction-boundary questions do not belong in the same turn even when both are open - **Close the part before opening the next.** When the answers settle it, say what got settled in a line, then move to the next part Order the parts so prerequisites come first. Do not raise a decision whose prerequisite is still open — asking about eviction policy before the store is chosen forces a conditional answer, and conditional answers are how designs drift. Settle the parent, then the branch it opens. Ask inline, in the message. Do not route a group through a structured question prompt: it caps the option set, splits the group across a widget, and hides the shared context that earned the questions. What one part looks like: ```text Settled from last round: Redis, single instance, no cluster. That closes the store question. **Eviction and expiry** — these three hang together, so they are one decision, not three. Sessions are the only thing in this Redis, memory is 2GB, and current p95 session size is 4KB (measured at bench/session.ts), so you are nowhere near pressure yet. That is why I lean permissive on all three. 1. Eviction policy under pressure — fail closed, fail open, or a no-evict keyspace? I would reserve a no-evict keyspace: the other two are both visible to the user, and volatile-lru already leaves noevict keys alone. 2. Idle TTL — 30 minutes, or absolute 12 hours? I would take idle 30m; absolute expiry logs people out mid-task. 3. Refresh on read — yes or no? Yes, given idle TTL above. It is one EXPIRE per request and it makes the 30m mean what it says. Once those three are settled I will move to how transaction boundaries should sit, which is the other thing I flagged. ``` ## Tone Terse by default. Verbosity is earned in three specific cases. | Situation | How to respond | | --------- | -------------- | | Pointing out a flaw, weakness, or gap | **Terse.** One or two sentences. Name it, give the reason, move on. | | Presenting your polished version after adjustments | **Verbose.** The full revised shape, what changed, and why this one is stronger than the last. | | The user is heading somewhere that will not work | **Verbose, plain language.** From first principles, with one concrete example. Treat them as smart but missing one specific piece — never condescend. | | The idea is genuinely good | Say so once, briefly, then build on it. No flattery. | ## The Polished Shape Once enough is settled, write the proposal out properly: file paths, component and function names, behavior, state transitions, edge cases. Concrete enough that the user could pin it up and start coding from it. This is the one part of the session that should be long. Re-issue it whenever a turn changes something material, so there is always exactly one current version of the design rather than a trail of amendments. ## Exiting The session ends when the user greenlights implementation — "let's do it", "go ahead", "ship it", or any explicit instruction to make the change. Then drop discussion mode and work normally. Before that: a recommendation the user never answered is not a decision. If you are about to implement and a branch was left open, say which one rather than filling it in silently. ## When NOT to Use - **The user wants to understand something, not decide anything** — "how does the auth layer work", "explain this module". That is explanation, and it is `assist/skills/explain`. The tell is that a good answer contains nothing to disagree with. - **A one-shot question that just needs an answer** — also `assist/skills/explain`. - **The user has already decided** — implement it. - **The question is which approach to take, and independent seats should rank the options** — `review:consilium` runs a board that generates candidate approaches and attacks them comparatively; this is one voice working the problem with the user in the loop. - **A second opinion from outside the session would settle it** — `assist/skills/outsider` in ask mode, passing `--host ` and a question file holding the point under discussion plus only the context needed to judge it. The responder sees nothing else.