Commit 9831b1b

@@ -0,0 +1,29 @@
+Implement a story's tasks, one at a time, test-first.
+
+# Role
+- Work through the Tasks in the story the user specifies (see plan.md for the naming convention)
+- Follow TDD: write a failing test, implement the minimal code to pass, then move on
+- Check off each task in the story file as it's completed
+
+# Process
+1. **Focus** - If the user didn't name a story, list .agents/backlog/ and stop -- do not guess which one
+2. **Read** - Load the story and its Tasks
+3. **Red** - Write a failing test for the next unchecked task
+4. **Green** - Write the minimal code to make it pass
+5. **Verify** - Run the test suite
+6. **Check** - Mark the task complete in the story file, then repeat from step 3 for the next task
+
+# Task Completion
+When a task is done, edit the story file:
+```markdown
+# Tasks
+
+* [x] Create FooService in lib/foo_service.rb  ← mark done
+* [ ] Add #bar method to handle X              ← next task
+```
+
+# Guidelines
+- One task at a time, in order
+- Minimal diffs -- only what the current task needs
+- No defensive code or speculative abstraction
+- Run the test suite after every change, not just at the end

@@ -0,0 +1,32 @@
+Research the codebase and turn a story's intent into a concrete task list.
+
+# Role
+- Read the story from .agents/backlog/ (see plan.md for the naming convention)
+- Explore the codebase to find where the change belongs and what it touches
+- Fill in the story's Tasks section
+- Note risks or dependencies in the story's DESCRIPTION or SEE ALSO
+
+Do not write or edit application/test code in this skill -- only the story
+file. That's what makes design safe to run before committing to an approach.
+
+# Process
+1. **Review** - Read the story in .agents/backlog/
+2. **Explore** - Trace code paths, find the extension points and existing patterns to follow
+3. **Plan** - Break the story into small, ordered, testable tasks
+4. **Update** - Edit the story file's Tasks section
+
+# Task Format
+In the story's # Tasks section:
+```markdown
+# Tasks
+
+* [ ] Write a failing spec for FooService#bar in spec/foo_service_spec.rb
+* [ ] Create FooService#bar in lib/foo_service.rb to pass it
+* [ ] Update config/routes.rb to add the endpoint
+```
+
+# Guidelines
+- Tasks should be small, atomic, and independently testable
+- Order by dependency (write the test before the implementation task it drives)
+- Reference specific files to modify or create
+- One task should map to roughly one red-green cycle during the build phase

@@ -0,0 +1,49 @@
+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.
+- 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.
+
+# 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.
+
+# Story Template
+```markdown
+As a `[persona]`, I `[want to]`, so that `[goal]`.
+
+# SYNOPSIS
+
+<one-line summary>
+
+# DESCRIPTION
+
+<detailed explanation, including any assumptions made to resolve ambiguity>
+
+# SEE ALSO
+
+* [ ] <open questions, related files, or concepts>
+
+# Tasks
+
+* [ ] TBD (filled in during the design phase, see design.md)
+
+# Acceptance Criteria
+
+* [ ] <testable criterion>
+```
+
+# Naming Convention
+Files: .agents/backlog/NNN-short-name.md (e.g., 001-user-login.md). NNN is
+zero-padded and continues from the highest existing number in the directory.
+
+# Guidelines
+- 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

@@ -1,30 +1,24 @@
----
-name: review
-description: Review code changes against a backlog story's acceptance criteria, checking test coverage, bugs, security, and quality, then report a verdict. Use when the user wants a code review of recent changes.
----
-
-You are in review mode. Verify changes meet acceptance criteria.
+Review code changes against a story's acceptance criteria.
 
 # Role
-- Review code changes against story acceptance criteria
+- Review code changes against the story's acceptance criteria
 - Check test coverage
 - Identify bugs, security issues, and quality concerns
 
 # Process
-1. **Context** - Read the story from .elelem/backlog/
+1. **Context** - Read the story from .agents/backlog/
 2. **Diff** - Run `git diff` to see changes
-3. **Trace** - Read surrounding context
-4. **Verify** - Check each acceptance criterion
-5. **Report** - Summarize findings
+3. **Trace** - Read surrounding context for anything the diff touches
+4. **Verify** - Check each acceptance criterion against the actual code
+5. **Report** - Summarize findings in the format below
 
 # Review Checklist
-- [ ] All tasks in story are checked off
+- [ ] All tasks in the story are checked off
 - [ ] Acceptance criteria are satisfied
 - [ ] Tests exist and pass
 - [ ] No logic errors or edge case bugs
 - [ ] No security vulnerabilities
 - [ ] No performance issues
-- [ ] SOLID principles followed
 - [ ] Code is readable and minimal
 
 # Output Format
@@ -45,5 +39,5 @@ Severity: critical | warning | nit
 
 # Guidelines
 - Be specific: cite file:line
-- Suggest fixes
-- Distinguish blocking from non-blocking issues
+- Suggest fixes, not just problems
+- Distinguish blocking issues from non-blocking ones

@@ -0,0 +1,32 @@
+---
+name: scrum
+description: Story-driven workflow for building a feature -- plan it into stories, design tasks, build test-first, review, then verify. Stories live in .agents/backlog/. Use when the user wants to work through a feature as a tracked, multi-step process rather than a single one-off change.
+---
+
+# Scrum
+
+A five-phase workflow, one story at a time, tracked as a markdown file in
+`.agents/backlog/`. Each phase is a separate file in this skill's directory
+-- read the one for the phase you're in.
+
+# Phases
+
+| Phase | File | When |
+|---|---|---|
+| Plan | [plan.md](plan.md) | Nothing is broken into stories yet |
+| Design | [design.md](design.md) | A story exists but has no Tasks, or its Tasks are stale |
+| Build | [build.md](build.md) | A story has Tasks and needs implementing |
+| Review | [review.md](review.md) | A story's Tasks are all checked off |
+| Verify | [verify.md](verify.md) | A story passed review |
+
+Read only the phase file you need for the current request -- each one is
+self-contained and says what to read the story for and what to write back.
+
+# Story Lifecycle
+
+A story file moves through the phases in order: plan creates it, design adds
+Tasks, build implements and checks them off, review approves the diff, verify
+confirms it works end-to-end and closes it out. Each phase only reads/writes
+the story file and the code it describes -- nothing here tracks phases across
+turns, so name the story explicitly once it exists (`.agents/backlog/NNN-*.md`)
+rather than relying on this skill to remember where you left off.

@@ -0,0 +1,38 @@
+Smoke-test a finished feature end-to-end and record what you found.
+
+# Role
+- Run the feature as a user would, not by re-reading the code
+- Walk through the happy path and at least one realistic error case
+- Verify the actual behavior matches the story's intent
+- Record demo notes in the story file
+
+# Process
+1. **Setup** - Read the story in .agents/backlog/ to know what to demo
+2. **Execute** - Run the feature end-to-end (real commands, not a read-through)
+3. **Observe** - Note actual behavior, output, and any issues
+4. **Document** - Append demo notes to the story file (format below)
+5. **Report** - Summarize the result
+
+# Demo Checklist
+- [ ] Feature works as described in the story
+- [ ] Happy path completes successfully
+- [ ] At least one error case was tried and handled gracefully
+- [ ] Actual output matches the story's acceptance criteria
+
+# Story Update
+Append to the story file:
+```markdown
+# Demo Notes
+
+Status: ACCEPTED | NEEDS WORK
+
+Observations:
+- <what was tested>
+- <what worked>
+- <what needs attention, if anything>
+```
+
+# Guidelines
+- Test from the user's perspective, not the developer's
+- Try realistic scenarios, not just the exact example from the story
+- Be honest about gaps -- NEEDS WORK is a valid, useful outcome

@@ -3,7 +3,7 @@
 module Elelem
   module Skills
     class Catalog
-      GEM_SKILLS = File.expand_path("../../../skills", __dir__).freeze
+      GEM_SKILLS = File.expand_path("builtin", __dir__).freeze
 
       LOAD_PATHS = [
         GEM_SKILLS,

@@ -1,44 +0,0 @@
----
-name: build
-description: Execute tasks from a backlog story test-first (write failing test, implement, refactor), checking off tasks as they complete. Use when the user wants to implement a story from .elelem/backlog/.
----
-
-Terminal coding agent. Execute tasks from a story.
-
-# Role
-- Work through Tasks in the story the user specifies
-- Check off completed tasks
-- Follow TDD: write failing test, implement, refactor
-
-# Process
-1. **Focus** - Ask which story to work on if not specified
-2. **Read** - Load the story from .elelem/backlog/
-3. **Test** - Write failing test first
-4. **Implement** - Minimal code to pass
-5. **Verify** - Run tests
-6. **Check** - Mark task complete in story file
-
-# Editing
-Multi-line: `echo "DIFF" | patch -p1`
-Single-line: `sed -i'' 's/old/new/' file`
-New files: write tool
-
-# Search
-`rg -n "pattern" .` - text search
-`fd -e rb .` - file discovery
-
-# Task Completion
-When a task is done, edit the story file:
-```markdown
-# Tasks
-
-* [x] Create FooService in lib/foo_service.rb  ← mark done
-* [ ] Add #bar method to handle X              ← next task
-```
-
-# Guidelines
-- Work on what the user asks for
-- One task at a time
-- Minimal diffs
-- No defensive code
-- Verify after every change

@@ -1,46 +0,0 @@
----
-name: design
-description: Research the codebase and fill in the Tasks section of backlog stories in .elelem/backlog/. Use when the user wants to plan implementation, break a story into tasks, or design before coding, without changing code yet.
----
-
-You are in design mode. Research and plan implementation for backlog stories.
-
-# Role
-- Read stories from .elelem/backlog/
-- Explore codebase to understand existing patterns
-- Fill in the Tasks section of each story
-- Identify risks and dependencies
-
-# Constraints
-Allowed: read, glob, grep, task, execute (read-only), edit (.elelem/backlog/ only)
-Blocked: code changes, test changes
-
-# Process
-1. **Review** - Read stories in .elelem/backlog/
-2. **Explore** - Trace code paths, find extension points
-3. **Research** - Consider design options and trade-offs
-4. **Plan** - Break each story into implementation tasks
-5. **Update** - Edit story files to add Tasks
-
-# Task Format
-In the story's # Tasks section:
-```markdown
-# Tasks
-
-* [ ] Create FooService in lib/foo_service.rb
-* [ ] Add #bar method to handle X
-* [ ] Write spec in spec/foo_service_spec.rb
-* [ ] Update config/routes.rb to add endpoint
-```
-
-# Guidelines
-- Tasks should be small, atomic, and independently testable
-- Order tasks by dependency (do X before Y)
-- Reference specific files to modify
-- Note if new files are needed
-- Consider test-first ordering
-
-# Trade-off Dimensions
-- Simplicity vs Flexibility
-- Performance vs Readability
-- Coupling vs Cohesion

@@ -1,64 +0,0 @@
----
-name: plan
-description: Interview the user as Product Owner to capture requirements as small, testable user stories in .elelem/backlog/. Use when the user wants to plan a feature, write user stories, or capture requirements before building.
----
-
-You are a Scrum Master capturing requirements. Interview the user as if they are the Product Owner.
-
-# Role
-- Ask clarifying questions to understand the feature
-- Break large requests into focused user stories
-- Capture acceptance criteria in testable terms
-- Write each story to .elelem/backlog/ as a separate file
-
-# Tools
-- interview(question, context?): Ask the user a question and wait for response
-- read(path): Read existing stories or code
-- glob(pattern): Find files
-- grep(pattern): Search contents
-- write(path, content): Write story files to .elelem/backlog/
-
-# Constraints
-Allowed: interview, read, glob, grep, task, execute (read-only), write (.elelem/backlog/ only)
-Blocked: code changes, test changes
-
-# Process
-1. **Listen** - Understand what the user wants to achieve
-2. **Clarify** - Ask questions about personas, goals, edge cases
-3. **Scope** - Break large features into small, deliverable stories
-4. **Document** - Create story files in .elelem/backlog/
-5. **Confirm** - Read back the stories for user approval
-
-# Story Template
-```markdown
-As a `[persona]`, I `[want to]`, so that `[goal]`.
-
-# SYNOPSIS
-
-<one-line summary>
-
-# DESCRIPTION
-
-<detailed explanation>
-
-# SEE ALSO
-
-* [ ] <related files or concepts>
-
-# Tasks
-
-* [ ] TBD (filled in design mode)
-
-# Acceptance Criteria
-
-* [ ] <testable criterion>
-```
-
-# Naming Convention
-Files: .elelem/backlog/NNN-short-name.md (e.g., 001-user-login.md)
-
-# Guidelines
-- 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?"

@@ -1,44 +0,0 @@
----
-name: verify
-description: Smoke-test an implemented feature end-to-end as if demoing to the Product Owner, then record demo notes in the backlog story. Use when the user wants to demo or verify a finished feature.
----
-
-You are in verify mode. Demo the feature to the Product Owner.
-
-# Role
-- Perform a smoke test of implemented features
-- Walk through the feature as if demoing to the Product Owner
-- Verify the user experience matches the story intent
-
-# Process
-1. **Setup** - Identify what to demo from .elelem/backlog/
-2. **Execute** - Run the feature end-to-end
-3. **Observe** - Note behavior, output, any issues
-4. **Document** - Add demo notes to story file
-5. **Report** - Summarize for Product Owner
-
-# Demo Checklist
-- [ ] Feature works as described in story
-- [ ] Happy path completes successfully
-- [ ] Error cases are handled gracefully
-- [ ] Output/behavior matches user expectations
-
-# Story Update
-After demo, add to story file:
-```markdown
-# Demo Notes
-
-Verified: <date>
-Status: ACCEPTED | NEEDS WORK
-
-Observations:
-- <what was tested>
-- <what worked>
-- <what needs attention>
-```
-
-# Guidelines
-- Test from user perspective, not developer
-- Try realistic scenarios
-- Note any UX issues
-- Be honest about gaps

@@ -36,10 +36,16 @@ RSpec.describe Elelem::Skills::Catalog do
   end
 
   describe "GEM_SKILLS" do
-    it "bundles the plan/design/build/review/verify skills with the gem" do
+    it "bundles the scrum skill with the gem" do
       catalog = described_class.new
 
-      expect(catalog.all.map(&:name)).to include("plan", "design", "build", "review", "verify")
+      expect(catalog.all.map(&:name)).to include("scrum")
+    end
+
+    it "does not treat the scrum skill's phase files as separate skills" do
+      catalog = described_class.new
+
+      expect(catalog.all.map(&:name)).not_to include("plan", "design", "build", "review", "verify")
     end
   end
 

@@ -20,10 +20,11 @@ description: Test-driven development. Use when the user wants tests written firs
 
 `elelem-skills` scans, in this order (later paths shadow earlier ones by name):
 
-1. `skills/*/SKILL.md` bundled with this gem -- `plan`, `design`, `build`,
-   `review`, `verify`: a lightweight story-driven workflow (backlog files
-   under `.elelem/backlog/`) that used to live as ERB system prompts before
-   the skills standard existed.
+1. `lib/elelem/skills/builtin/*/SKILL.md` bundled with this gem -- currently
+   just `scrum`: a lightweight story-driven workflow (backlog files under
+   `.agents/backlog/`) with five phases (plan, design, build, review, verify)
+   as sibling files the model reads on demand. Used to live as five separate
+   ERB system prompts before the skills standard existed.
 2. `~/.agents/skills/*/SKILL.md` (user-level)
 3. `.agents/skills/*/SKILL.md` (project-level)