| name | beads-plan |
| description | Act as a PM to flesh out a bead issue with acceptance criteria and implementation notes. Use when planning issues, adding acceptance criteria, or preparing issues for development. |
Beads Plan
Plan and document a bead issue without implementing it. This skill acts as a PM to prepare issues for development.
Workflow
1. Read the Issue
bd show <issue-id>
Review the current state of the issue including title, description, and any existing details.
2. Analyze the Codebase
If the issue involves code changes:
- Explore relevant files and directories
- Understand existing patterns and conventions
- Identify files that will likely need modification
- Note any dependencies or related components
3. Flesh Out the Issue
Create or update the issue description to include:
Clear Acceptance Criteria
Format as checkboxes:
## Acceptance Criteria
- [ ] Specific, testable criterion 1
- [ ] Specific, testable criterion 2
- [ ] ...
Implementation Notes
## Implementation Notes
- Suggested approach and rationale
- Key files to modify: `path/to/file.ext`
- Patterns to follow from existing code
- Potential edge cases to handle
- Testing strategy
Complexity Assessment
## Complexity
- Scope: Small/Medium/Large
- Risk areas: (any tricky parts)
- Dependencies: (external libs, other issues)
4. Update the Issue
Update the issue with the fleshed-out description:
bd update <issue-id> --description="<full updated description>"
If the title is vague or unclear, update it too:
bd update <issue-id> --title="<clearer title>"
5. Identify Dependencies
If this issue depends on other work:
bd dep add <issue-id> <depends-on-id>
If you discover new issues that should be created:
bd create --title="..." --type=task --priority=2
bd dep add <new-id> <issue-id> # if new issue depends on this one
6. Report Summary
After planning, report:
"Planned issue
<issue-id>:Changes made:
- <what was added/updated>
Acceptance criteria:
items Ready for: /codegangsta:build <issue-id>"
Guidelines
- Do NOT implement - Only plan and document
- Be specific - Vague acceptance criteria are useless
- Be realistic - Note actual complexity and risks
- Explore first - Understand the codebase before suggesting approaches
- Check dependencies - Ensure blockers are identified and linked
- Make it buildable - Another agent should be able to implement from your plan