Commit 72f3154
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