Use when the user wants to add a new feature, enhancement, task, or idea to the project backlog in TASKS.md. Also use when user says "add a todo", "new task", "we should build X", "let's add Y", or discusses a feature they want to track. Brainstorms the idea first, then captures it as lightweight bullet points.
Capture new feature ideas into TASKS.md through a lightweight brainstorming process. The goal is to explore the idea just enough to write clear, actionable bullet points — not to create a full design or implementation plan. That happens later when the task is actually picked up.
Why this matters: jumping straight to writing a task entry produces vague or over-specified tasks. A few focused questions surface the real intent, uncover constraints, and identify which parts of the system are affected. The result is bullet points that give the implementer enough context without boxing them in.
Before anything else, read the project's current state:
TASKS.md — understand existing phases, task numbering, what's done vs. pendingPRD.md — product context and constraintsCLAUDE.mdThis grounds the brainstorm in reality. A feature that sounds new might already be partially built, or conflict with something in progress.
REQUIRED: Invoke superpowers:brainstorming skill for the ideation phase. However, communicate upfront that the goal here is task capture, not full design. The brainstorming should be scoped to:
Adapt the brainstorming output: Instead of producing a full design doc, the brainstorming should conclude with a concise summary of:
If the idea is simple and the user has a clear picture, the brainstorm can be brief (1-2 questions). Don't over-interview for straightforward additions.
Before writing the task entry, quickly assess which parts of the system the feature touches. Read relevant existing code — don't deep-dive, just enough to know what's affected.
Check each layer:
shared/types/?This prevents writing a task that unknowingly conflicts with existing architecture or misses a dependency.
Write the task entry following the established TASKS.md format:
### Task X.Y: [Feature Name]
**Priority:** P0/P1/P2
**Estimated Time:** [rough estimate]
**Deliverables:**
- [ ] [What to build, not how to build it]
- [ ] [Focused on outcomes and capabilities]
- [ ] [Each bullet = one verifiable deliverable]
**Key Considerations:**
- [Architectural note or constraint discovered during recon]
- [Relationship to existing features]
- [Any non-obvious requirement from brainstorm]
**Affected Areas:** [backend, frontend, shared, etc.]
**Dependencies:** [Task X.Y, etc. or None]
Writing good bullet points — this is the whole point:
Always show the user the proposed entry before writing it. Let them adjust wording, priority, or scope before committing to the file.
superpowers:writing-plans when the task is picked upsuperpowers:brainstorming at implementation timeUser says: "We need to add notifications so users know when an agent needs input"
After brainstorm (1-2 questions about scope and delivery) and architectural recon:
### Task 5.4: Push Notifications for Agent Input Requests
**Priority:** P1
**Estimated Time:** 1 day
**Deliverables:**
- [ ] Notify user when agent is awaiting input (browser push notification)
- [ ] Show unread/pending count badge in mobile nav
- [ ] Tapping notification navigates to the relevant task chat
- [ ] Respect notification permissions and provide settings toggle
**Key Considerations:**
- Builds on existing WebSocket event system for real-time delivery
- Service worker needed for push notifications when app is backgrounded
- Mobile-first: notification UX should work well on phone lock screens
**Affected Areas:** frontend (service worker, nav badge), backend (notification triggers)
**Dependencies:** Task 2.3 (WebSocket events)
Notice: no file paths, no function names, no implementation details. Just clear outcomes and enough context to plan properly when the work begins.