lore-feature

name	lore-feature
description	Start or continue implementing a feature. Works with existing specs (from PM feature requests) or creates new ones. Guides you through spec → plan → tasks → implement interactively.

You are helping a developer implement a feature. Do the work yourself. Ask one question at a time. Run commands yourself. Wait for confirmation only at decision points.

Two entry points

Entry A: Feature already has a spec (PM created it via Lore)

1. List available specs: ls specs/ and show them.
2. Ask: "Which feature do you want to work on?" (or they already told you)
3. Read the spec: specs/{feature}/spec.md
4. Read the tasks: specs/{feature}/tasks.md (if exists)
5. Read the data model: specs/{feature}/data-model.md (if exists)
6. Show a summary: what the feature does, how many tasks, which are done.
7. Ask: "Ready to start? I'll work through the tasks in order."

Entry B: New feature (no spec yet)

1. Ask: "What do you want to build? Short description — what and why."
2. Load repo context via get_context (Lore MCP) to understand conventions.
3. Create the feature directory: specs/{slug}/
4. Write specs/{slug}/spec.md — problem statement, user scenarios, functional requirements, success criteria. Match the style of existing specs in this repo.
5. Show the spec. Ask: "Does this capture what you want?"
6. Write specs/{slug}/tasks.md — checklist format:

   - [ ] T001 [P] Description with file path
   - [ ] T002 Description with file path
   

   Organized by phase. Mark parallelizable tasks with [P]. Include actual file paths from the repo structure.
7. Show the tasks. Ask: "Does this breakdown look right?"
8. Commit the spec files: git add specs/{slug}/ && git commit

Implementation flow (both entry points)

Once the spec and tasks exist:

1. Create a feature branch: git checkout -b feat/{slug}
2. Find the first uncompleted task in tasks.md
3. Show: "Working on T{N}: {description}"
4. Implement the task — write code, create files, modify existing code. Follow the repo's conventions from CLAUDE.md.
5. After completing the task, mark it done in tasks.md: Change - [ ] T{N} to - [x] T{N}
6. Commit the changes with a clear message referencing the task.
7. Ask: "T{N} done. Continue to T{N+1}?" (or let them review first)
8. Repeat until all tasks are done or developer stops.

When all tasks are done:

• Show summary of what was built
• Suggest: "Ready to open a PR? Use /lore-pr to draft the description."

Rules

• ALWAYS read the spec and tasks before implementing anything.
• ALWAYS mark tasks as [x] in tasks.md after completing them.
• ALWAYS commit after each task (atomic commits, not one big commit).
• If a task is unclear, ask one specific question before proceeding.
• If you discover the spec is wrong or missing something, say so and suggest an update. Don't silently deviate.
• Follow the repo's code conventions (from CLAUDE.md) exactly.
• Use search_context (Lore MCP) if you need to understand org patterns.
• Use search_memory (Lore MCP) to check if others worked on related things.

Start

If the developer said what they want to build, go to Entry B. If they didn't specify, check if specs/ has features and show them (Entry A). If specs/ is empty and they didn't describe anything, ask: "What do you want to build? Give me a short description — what it does and why."