Commit 72f3154

mo khan <mo@mokhan.ca>
2026-09-08 05:55:20
fix(scrum/plan): interview the user instead of assuming
plan.md told the model to make reasonable assumptions and document them rather than ask, on the premise that elelem has no way to pause mid-turn for an answer. That premise was wrong: Agent#repl loops turn-by-turn over persistent conversation state, so asking a question and ending the turn (no tool call, just text) genuinely works -- the next repl input continues the same conversation. That constraint only applies to `elelem ask` (one-shot), not `elelem chat`. plan now interviews until ~95% confident, one focused question per turn, and never fills gaps with assumptions. Verified end to end via `elelem chat` with piped stdin: on an empty workspace it checked repo context first, then asked one clarifying question and stopped -- no story file written, no assumption made, no tool call after the question. The `elelem ask` carve-out stays, since that command genuinely has no next turn to read an answer from.
1 parent 674fd80
Changed files (1)
lib
elelem
skills
builtin
scrum
lib/elelem/skills/builtin/scrum/plan.md
@@ -1,17 +1,35 @@
 Turn the user's request into a backlog of small, testable user stories.
 
 # Role
-- Read the user's request as the requirement; do not wait for a live back-and-forth interview -- there is no way to pause and ask a question mid-turn.
+- Interview the user before writing anything. Ask clarifying questions, one
+  turn at a time, until you are at least 95% sure you understand the
+  request -- personas, goals, edge cases, what's explicitly out of scope.
+- Never make assumptions to fill a gap. If something is unclear or
+  unstated, ask about it instead of guessing.
 - Break large requests into small, independently deliverable stories.
-- Where the request is ambiguous, make a reasonable assumption, state it in the story's DESCRIPTION, and list the real open question under SEE ALSO instead of stalling.
 - Capture acceptance criteria in testable terms.
 - Write each story to .agents/backlog/ as a separate file.
 
+# Asking Questions
+This is a chat REPL: each response you give ends your turn and the user's
+next message continues the same conversation, so a real back-and-forth
+interview works here. To ask, just respond with the question as plain text
+and stop -- do not call a tool, do not write a story file yet. Ask one
+focused question (or a short related group) at a time rather than a long
+questionnaire in one message; that keeps the interview conversational and
+lets the user's answer to one question inform the next.
+
+(If you're running as `elelem ask` rather than `elelem chat`, there's no
+next turn to read an answer from. Say so, then proceed with your best
+understanding and mark the actual gaps as SEE ALSO items -- this is the
+one situation where documenting an assumption is the only option.)
+
 # Process
-1. **Read** - Reread the user's request; identify the distinct capabilities inside it.
-2. **Scope** - Split into stories small enough to finish in one build session.
-3. **Document** - Write each as a story file (template below).
-4. **List** - After writing, list the story filenames and one-line summaries back to the user so they can redirect before build starts.
+1. **Read** - Take in the user's request; identify the distinct capabilities inside it.
+2. **Interview** - Ask clarifying questions, one exchange at a time, until you're at least 95% sure you understand each capability -- what it is, who it's for, and what's out of scope.
+3. **Scope** - Split into stories small enough to finish in one build session.
+4. **Document** - Write each as a story file (template below).
+5. **List** - After writing, list the story filenames and one-line summaries back to the user so they can redirect before build starts.
 
 # Story Template
 ```markdown
@@ -23,11 +41,11 @@ As a `[persona]`, I `[want to]`, so that `[goal]`.
 
 # DESCRIPTION
 
-<detailed explanation, including any assumptions made to resolve ambiguity>
+<detailed explanation, informed by the interview -- not by assumptions>
 
 # SEE ALSO
 
-* [ ] <open questions, related files, or concepts>
+* [ ] <related files or concepts; not a place to park unanswered questions>
 
 # Tasks
 
@@ -46,4 +64,4 @@ zero-padded and continues from the highest existing number in the directory.
 - One story per file
 - Stories should be small enough to complete in one session
 - Acceptance criteria must be objectively testable -- ask "how will we know this is done?"
-- Prefer a documented assumption over a blocked story
+- Don't write a story until the interview has resolved its open questions