Initial commit
This commit is contained in:
Zhongwei Li
216
commands/create-stories.md
Normal file
216
commands/create-stories.md
Normal file
@@ -0,0 +1,216 @@
|
||||
---
|
||||
name: re:create-stories
|
||||
description: Break down an epic into user stories following INVEST criteria and create story issues in GitHub Projects
|
||||
allowed-tools: [AskUserQuestion, Bash, Read]
|
||||
---
|
||||
|
||||
# Create User Stories
|
||||
|
||||
Break down a selected epic into user stories following INVEST criteria and create story issues in GitHub Projects as children of the epic issue.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **user-story-creation** skill to access methodology, INVEST criteria, and templates.
|
||||
|
||||
### Step 1: Select Epic to Break Down
|
||||
|
||||
1. **List Available Epics:**
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Filter for Type = "Epic"
|
||||
- If no epics: Suggest running `/re:identify-epics` first, exit
|
||||
|
||||
2. **Present Epic Menu:**
|
||||
Use AskUserQuestion:
|
||||
- Question: "Which epic would you like to break down into user stories?"
|
||||
- Header: "Select Epic"
|
||||
- Options: One option per epic (label = epic name, description = brief desc from issue)
|
||||
- multiSelect: false
|
||||
|
||||
3. **Read Epic Issue:**
|
||||
- Use `gh issue view [epic-issue-number] --repo [repo] --json body,title`
|
||||
- Extract epic content for story creation
|
||||
|
||||
### Step 2: Story Discovery & Drafting
|
||||
|
||||
Using user-story-creation skill methodology:
|
||||
|
||||
**Analyze Epic for User Journeys:**
|
||||
- What tasks do users need to complete?
|
||||
- What scenarios or use cases exist?
|
||||
- Do different user types need different stories?
|
||||
|
||||
**Draft Initial Stories:**
|
||||
Suggest 5-15 user stories for the epic using standard format:
|
||||
```
|
||||
As a [user type],
|
||||
I want [goal],
|
||||
So that [benefit].
|
||||
```
|
||||
|
||||
Present suggestions:
|
||||
```
|
||||
Based on the epic "[Epic Name]", here are suggested user stories:
|
||||
|
||||
**Core Functionality:**
|
||||
1. As a [user], I want [goal], so that [benefit]
|
||||
2. As a [user], I want [goal], so that [benefit]
|
||||
|
||||
**Supporting Features:**
|
||||
3. As a [user], I want [goal], so that [benefit]
|
||||
|
||||
**Edge Cases & Enhancements:**
|
||||
4. As a [user], I want [goal], so that [benefit]
|
||||
|
||||
These cover the main user journeys - would you like to add, remove, or modify any?
|
||||
```
|
||||
|
||||
### Step 3: Story Refinement
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "Which stories should we include?"
|
||||
- Header: "Story Selection"
|
||||
- Options: One per suggested story (label = short title, description = full story)
|
||||
- multiSelect: true
|
||||
|
||||
Then ask:
|
||||
- Question: "Any additional stories to add?"
|
||||
- Header: "Add Stories"
|
||||
- Options: Custom text input
|
||||
|
||||
### Step 4: INVEST Criteria Check
|
||||
|
||||
For each selected story, verify INVEST criteria:
|
||||
- **Independent**: Can be completed separately
|
||||
- **Negotiable**: Details open for discussion
|
||||
- **Valuable**: Delivers user value
|
||||
- **Estimable**: Team can estimate size
|
||||
- **Small**: Fits in 1-5 days
|
||||
- **Testable**: Has clear acceptance criteria
|
||||
|
||||
If story fails INVEST, suggest refinements:
|
||||
- Too large? Suggest splitting
|
||||
- Not valuable? Suggest reframing or removing
|
||||
- Not testable? Suggest adding acceptance criteria
|
||||
|
||||
### Step 5: Add Acceptance Criteria
|
||||
|
||||
For each story, define acceptance criteria. Use format from user-story-creation skill:
|
||||
|
||||
**Given-When-Then format:**
|
||||
```
|
||||
- Given [context]
|
||||
When [action]
|
||||
Then [outcome]
|
||||
```
|
||||
|
||||
**Or checklist format:**
|
||||
```
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
```
|
||||
|
||||
For each story, present suggested acceptance criteria and ask user to confirm/refine.
|
||||
|
||||
### Step 6: Create Story Issues
|
||||
|
||||
For each finalized story:
|
||||
|
||||
1. **Compile Story Description:**
|
||||
Use template from user-story-creation skill's references: `${CLAUDE_PLUGIN_ROOT}/skills/user-story-creation/references/story-template.md`:
|
||||
```markdown
|
||||
## User Story: [Short title]
|
||||
|
||||
### Story
|
||||
As a [user type],
|
||||
I want [goal],
|
||||
So that [benefit].
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
|
||||
### Notes
|
||||
[Any assumptions or constraints]
|
||||
|
||||
**Parent:** [Link to Epic Issue #]
|
||||
```
|
||||
|
||||
2. **Create Issue:**
|
||||
- Use `gh issue create --repo [repo] --title "[Story short title]" --body "[story description]" --label "type:story"`
|
||||
- Capture issue number and URL
|
||||
|
||||
3. **Add to Project:**
|
||||
- Use `gh project item-add [project-number] --owner [owner] --url [issue-url]`
|
||||
|
||||
4. **Set Custom Fields:**
|
||||
- Type: Story
|
||||
- Status: Not Started
|
||||
- Priority: (Inherit from epic or set during prioritization)
|
||||
|
||||
5. **Link to Epic (Parent):**
|
||||
- Add comment to story: "Parent: #[epic-issue-number]"
|
||||
|
||||
### Step 7: Story Count Validation
|
||||
|
||||
Check total number of stories:
|
||||
- If < 3: Might be too few, epic might be too small
|
||||
- If > 20: Might be too many, epic might be too large
|
||||
- Ideal range: 5-15 stories per epic
|
||||
|
||||
### Step 8: Next Story or Next Phase
|
||||
|
||||
After creating all stories for current epic, ask:
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "What would you like to do next?"
|
||||
- Header: "Next Step"
|
||||
- Options:
|
||||
- "Create stories for another epic" (description: "Select a different epic and create stories")
|
||||
- "Prioritize stories" (description: "Use MoSCoW to prioritize these stories")
|
||||
- "Create tasks for a story" (description: "Break down a story into tasks")
|
||||
- "Done for now" (description: "Stop here")
|
||||
- multiSelect: false
|
||||
|
||||
**Handle response:**
|
||||
- "Create stories for another epic": Restart from Step 1
|
||||
- "Prioritize stories": Execute `/re:prioritize`
|
||||
- "Create tasks for a story": Execute `/re:create-tasks`
|
||||
- "Done for now": Show success message
|
||||
|
||||
### Step 9: Success Message
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Created [N] user stories for epic #[epic-num]!
|
||||
|
||||
Stories:
|
||||
- #[num] - [Story 1 title]
|
||||
- #[num] - [Story 2 title]
|
||||
...
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:prioritize` to rank stories
|
||||
2. Run `/re:create-tasks` to break down highest-priority story
|
||||
3. Review stories and refine acceptance criteria
|
||||
4. Use `/re:status` to see progress
|
||||
|
||||
Pro tip: Tackle stories one at a time - implement, test, ship, repeat!
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no epics exist: Guide to `/re:identify-epics`
|
||||
- If epic has no content: Suggest updating epic issue first
|
||||
- If story violates INVEST: Provide refinement suggestions
|
||||
- If too many/few stories: Guidance on right-sizing
|
||||
|
||||
## Notes
|
||||
|
||||
- Use user-story-creation skill for INVEST criteria and methodology
|
||||
- Each story follows standard "As a... I want... So that..." format
|
||||
- Minimum 3-5 acceptance criteria per story
|
||||
- Stories should be 1-5 days of work
|
||||
- Split large stories using techniques from skill
|
||||
- Ensure every story delivers user value
|
||||
255
commands/create-tasks.md
Normal file
255
commands/create-tasks.md
Normal file
@@ -0,0 +1,255 @@
|
||||
---
|
||||
name: re:create-tasks
|
||||
description: Break down a user story into implementation tasks with acceptance criteria and create GitHub issues in a GitHub Project.
|
||||
allowed-tools: [AskUserQuestion, Bash, Read]
|
||||
---
|
||||
|
||||
# Create Tasks
|
||||
|
||||
Break down a selected user story into concrete implementation tasks with clear acceptance criteria. Tasks are created as GitHub issues in a GitHub Project and automatically linked to the parent story.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **task-breakdown** skill to access methodology, patterns, and templates.
|
||||
|
||||
### Step 1: Select Story to Break Down
|
||||
|
||||
1. **List Available Stories:**
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Filter for Type = "Story"
|
||||
- If no stories: Suggest running `/re:create-stories` first, exit
|
||||
|
||||
2. **Present Story Menu:**
|
||||
Use AskUserQuestion:
|
||||
- Question: "Which user story would you like to break down into tasks?"
|
||||
- Header: "Select Story"
|
||||
- Options: One option per story (label = story title, description = user story text)
|
||||
- multiSelect: false
|
||||
|
||||
3. **Read Story Issue:**
|
||||
- Use `gh issue view [story-issue-number] --repo [repo] --json body,title`
|
||||
- Extract story content and acceptance criteria
|
||||
|
||||
### Step 2: Task Identification by Layer
|
||||
|
||||
Using task-breakdown skill methodology, identify tasks across implementation layers:
|
||||
|
||||
**Suggest tasks organized by layer:**
|
||||
|
||||
**Frontend/UI Tasks:**
|
||||
- Create UI components
|
||||
- Implement user interactions
|
||||
- Client-side validation
|
||||
- State management
|
||||
|
||||
**Backend/API Tasks:**
|
||||
- Implement API endpoints
|
||||
- Business logic
|
||||
- Data validation
|
||||
- Error handling
|
||||
|
||||
**Data/Database Tasks:**
|
||||
- Schema changes (if needed)
|
||||
- Data access layer
|
||||
- Queries and optimization
|
||||
|
||||
**Testing Tasks:**
|
||||
- Unit tests
|
||||
- Integration tests
|
||||
- User acceptance testing
|
||||
|
||||
**Documentation Tasks:**
|
||||
- API documentation
|
||||
- User-facing docs
|
||||
- Code comments
|
||||
|
||||
Present suggested tasks:
|
||||
```
|
||||
Based on the story "[Story Title]", here are suggested implementation tasks:
|
||||
|
||||
**Frontend:**
|
||||
1. Create [component] component
|
||||
2. Implement [interaction] functionality
|
||||
|
||||
**Backend:**
|
||||
3. Implement GET/POST [endpoint] API endpoint
|
||||
4. Add validation for [data]
|
||||
|
||||
**Data:**
|
||||
5. [If needed] Add database indexes for [performance]
|
||||
|
||||
**Testing:**
|
||||
6. Write unit tests for [module]
|
||||
7. Create integration tests for [feature]
|
||||
|
||||
**Documentation:**
|
||||
8. Document [API/feature] in user guide
|
||||
|
||||
Estimated: [X] tasks total
|
||||
```
|
||||
|
||||
### Step 3: Task Refinement
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "Which tasks should we create?"
|
||||
- Header: "Task Selection"
|
||||
- Options: One per suggested task
|
||||
- multiSelect: true
|
||||
|
||||
Then ask:
|
||||
- Question: "Any additional tasks to add?"
|
||||
- Header: "Add Tasks"
|
||||
- Options: Custom text input
|
||||
|
||||
### Step 4: Define Acceptance Criteria
|
||||
|
||||
For each selected task, define specific acceptance criteria:
|
||||
|
||||
#### Use checklist format
|
||||
|
||||
```
|
||||
- [ ] Specific, testable outcome 1
|
||||
- [ ] Specific, testable outcome 2
|
||||
- [ ] Specific, testable outcome 3
|
||||
```
|
||||
|
||||
#### Minimum 3-5 criteria per task
|
||||
|
||||
Present suggested criteria for each task and confirm with user.
|
||||
|
||||
### Step 5: Task Size Validation
|
||||
|
||||
Check each task:
|
||||
- Should be 2-8 hours (up to 1-2 days max)
|
||||
- If larger: Suggest splitting
|
||||
- If too small: Consider merging or if it's really a subtask
|
||||
|
||||
### Step 6: Create Task Issues in GitHub
|
||||
|
||||
For each task:
|
||||
|
||||
1. **Compile Task Description:**
|
||||
Use template from task-breakdown skill's references `${CLAUDE_PLUGIN_ROOT}/skills/task-breakdown/references/task-template.md`:
|
||||
```markdown
|
||||
## Task: [Action-oriented title]
|
||||
|
||||
### Description
|
||||
[Clear description of what needs to be done]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
|
||||
### Technical Notes
|
||||
**Files to Modify:**
|
||||
- [File 1]
|
||||
- [File 2]
|
||||
|
||||
**Patterns to Follow:**
|
||||
- [Reference to existing code pattern]
|
||||
|
||||
**Parent:** [Link to Story Issue #]
|
||||
```
|
||||
|
||||
2. **Create GitHub Issue in GitHub Project:**
|
||||
- Use `gh issue create --repo [repo] --title "[Task title]" --body "[task description]" --label "type:task,[technical-area]"`
|
||||
- Add technical area labels: frontend, backend, database, testing, docs
|
||||
- Capture issue number and URL
|
||||
|
||||
3. **Add to Project:**
|
||||
- Use `gh project item-add [project-number] --owner [owner] --url [issue-url]`
|
||||
|
||||
4. **Set Custom Fields:**
|
||||
- Type: Task
|
||||
- Status: Not Started
|
||||
- Priority: (Inherit from story)
|
||||
|
||||
5. **Link to Story (Parent):**
|
||||
- Add comment to task: "Parent: #[story-issue-number]"
|
||||
|
||||
### Step 7: Task Sequencing
|
||||
|
||||
After creating all tasks, identify dependencies:
|
||||
- Which tasks must come first?
|
||||
- What's the critical path?
|
||||
- Can any tasks be done in parallel?
|
||||
|
||||
Display task execution order:
|
||||
```
|
||||
📋 Task Sequence:
|
||||
|
||||
**Phase 1 (Can start immediately):**
|
||||
- #[num] - [Task requiring no dependencies]
|
||||
- #[num] - [Another independent task]
|
||||
|
||||
**Phase 2 (After Phase 1):**
|
||||
- #[num] - [Task depending on Phase 1]
|
||||
|
||||
**Phase 3 (Integration & Testing):**
|
||||
- #[num] - Integration tests
|
||||
- #[num] - Documentation
|
||||
|
||||
Tip: Mark tasks as "In Progress" in GitHub Projects as you work on them!
|
||||
```
|
||||
|
||||
### Step 8: Success Message & Assignment
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Created [N] tasks for story #[story-num]!
|
||||
|
||||
Tasks:
|
||||
- #[num] - [Task 1] (frontend)
|
||||
- #[num] - [Task 2] (backend)
|
||||
- #[num] - [Task 3] (testing)
|
||||
...
|
||||
|
||||
All tasks have been:
|
||||
- Created as GitHub issues in a GitHub Project
|
||||
- Added to the project
|
||||
- Linked to parent story #[story-num]
|
||||
- Labeled by technical area
|
||||
|
||||
Next Steps:
|
||||
1. Review tasks in GitHub Projects
|
||||
2. Assign tasks to team members (if working with a team)
|
||||
3. Start with Phase 1 tasks (no dependencies)
|
||||
4. Update task status as you progress
|
||||
5. When all tasks complete, story is complete!
|
||||
|
||||
Pro tip: Use `gh issue list --label type:task --assignee @me` to see your assigned tasks!
|
||||
```
|
||||
|
||||
### Step 9: Continue or Stop
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "What would you like to do next?"
|
||||
- Header: "Next Step"
|
||||
- Options:
|
||||
- "Create tasks for another story" (description: "Select a different story")
|
||||
- "Check project status" (description: "See overall progress")
|
||||
- "Done for now" (description: "Stop here")
|
||||
- multiSelect: false
|
||||
|
||||
**Handle response:**
|
||||
- "Create tasks for another story": Restart from Step 1
|
||||
- "Check project status": Execute `/re:status`
|
||||
- "Done for now": Exit
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no stories exist: Guide to `/re:create-stories`
|
||||
- If story has no acceptance criteria: Suggest updating story first
|
||||
- If tasks too large: Provide splitting guidance
|
||||
- If no technical tasks identified: Might be story is too vague
|
||||
|
||||
## Notes
|
||||
|
||||
- Use task-breakdown skill for methodology and patterns
|
||||
- Task titles should be action-oriented (start with verbs)
|
||||
- Each task: 2-8 hours of work
|
||||
- Minimum 3-5 acceptance criteria per task
|
||||
- Label tasks by technical area (frontend, backend, database, testing, docs)
|
||||
- Tasks are created as GitHub issues in a GitHub Project (not local files)
|
||||
- Full traceability: Vision → Epic → Story → Task
|
||||
155
commands/discover-vision.md
Normal file
155
commands/discover-vision.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
name: re:discover-vision
|
||||
description: Guide user through interactive vision discovery and create vision issue in GitHub Projects
|
||||
allowed-tools: [AskUserQuestion, Bash]
|
||||
---
|
||||
|
||||
# Discover Product Vision
|
||||
|
||||
Guide the user through an interactive vision discovery session using the vision-discovery skill methodology. Create a vision issue in GitHub Projects with the discovered vision.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **vision-discovery** skill to access methodology and question templates.
|
||||
|
||||
### Step 1: Verify GitHub Project Exists
|
||||
|
||||
1. Check if a GitHub Project exists for this repository:
|
||||
- Use `gh project list --owner [owner] --format json`
|
||||
- If no projects found: Suggest running `/re:init` first, then exit
|
||||
- If multiple projects: Use AskUserQuestion to ask which project to use
|
||||
- Store project number for later use
|
||||
|
||||
### Step 2: Check for Existing Vision
|
||||
|
||||
1. Search for existing vision issues:
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Filter for items with Type = "Vision"
|
||||
- If vision exists: Ask user if they want to update it or create new one
|
||||
|
||||
### Step 3: Interactive Vision Discovery
|
||||
|
||||
Use AskUserQuestion to guide through vision discovery. Ask questions from the vision-discovery skill:
|
||||
|
||||
**Problem Space Questions (First Question):**
|
||||
- Question: "What problem are you trying to solve?"
|
||||
- Header: "Problem"
|
||||
- Options: Let user provide custom text (multiSelect: false)
|
||||
|
||||
**After receiving problem answer, ask:**
|
||||
- Question: "Who experiences this problem? Describe your target users."
|
||||
- Header: "Users"
|
||||
- Options: Custom text input
|
||||
|
||||
**Then ask:**
|
||||
- Question: "How do they currently address this problem? What workarounds or competitors exist?"
|
||||
- Header: "Current State"
|
||||
- Options: Custom text input
|
||||
|
||||
**Then ask:**
|
||||
- Question: "In one sentence, what does your solution do?"
|
||||
- Header: "Solution"
|
||||
- Options: Custom text input
|
||||
|
||||
**Then ask:**
|
||||
- Question: "What makes your solution different or better than alternatives?"
|
||||
- Header: "Differentiator"
|
||||
- Options: Custom text input
|
||||
|
||||
**Finally ask:**
|
||||
- Question: "How will you measure success? What are 2-3 key metrics?"
|
||||
- Header: "Success Metrics"
|
||||
- Options: Custom text input
|
||||
|
||||
### Step 4: Compile Vision Document
|
||||
|
||||
Using the answers, create a vision document following the template from vision-discovery skill's `${CLAUDE_PLUGIN_ROOT}/skills/vision-discovery/references/vision-template.md`.
|
||||
|
||||
Structure the vision as:
|
||||
```markdown
|
||||
# Product Vision: [Inferred from solution]
|
||||
|
||||
## Problem Statement
|
||||
[User's problem description]
|
||||
|
||||
**Why it matters:** [Synthesized from answers]
|
||||
|
||||
**Current State:** [How users currently address it]
|
||||
|
||||
## Target Users
|
||||
[User's description of target users]
|
||||
|
||||
## Solution Overview
|
||||
[User's one-sentence solution]
|
||||
|
||||
**Unique Value Proposition:**
|
||||
[What makes it different/better]
|
||||
|
||||
## Success Metrics
|
||||
[User's 2-3 key metrics]
|
||||
|
||||
## Scope & Boundaries
|
||||
[To be defined - suggest running /re:identify-epics to define scope via epics]
|
||||
```
|
||||
|
||||
### Step 5: Create Vision Issue
|
||||
|
||||
1. Create issue in GitHub:
|
||||
- Use `gh issue create --repo [repo] --title "Product Vision: [Product Name]" --body "[vision document]" --label "type:vision"`
|
||||
- Capture issue number and URL
|
||||
|
||||
2. Add issue to project:
|
||||
- Use `gh project item-add [project-number] --owner [owner] --url [issue-url]`
|
||||
|
||||
3. Set custom fields:
|
||||
- Type: Vision
|
||||
- Status: Active
|
||||
- Use `gh project item-edit` commands to set these fields
|
||||
|
||||
### Step 6: Success Message & Next Steps
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Vision created successfully!
|
||||
|
||||
Issue: #[number] - Product Vision: [Product Name]
|
||||
URL: [issue-url]
|
||||
|
||||
Your vision has been documented and added to the project.
|
||||
|
||||
Next Steps:
|
||||
1. Review the vision issue and add any additional details
|
||||
2. Share with stakeholders for feedback
|
||||
3. Run `/re:identify-epics` to identify major capabilities
|
||||
4. Use `/re:review` to validate the vision
|
||||
|
||||
Pro tip: The vision is a living document - update it as you learn more!
|
||||
```
|
||||
|
||||
### Step 7: Offer to Continue
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "Would you like to continue to identify epics now?"
|
||||
- Header: "Continue"
|
||||
- Options:
|
||||
- "Yes, identify epics" (description: "Continue to epic identification")
|
||||
- "No, I'll do it later" (description: "Stop here for now")
|
||||
- multiSelect: false
|
||||
|
||||
If user selects "Yes":
|
||||
- Execute `/re:identify-epics` command
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If GitHub CLI not available: Provide installation instructions
|
||||
- If not authenticated: Suggest `gh auth login`
|
||||
- If project doesn't exist: Suggest `/re:init`
|
||||
- If issue creation fails: Show error and suggest checking permissions
|
||||
|
||||
## Notes
|
||||
|
||||
- Use vision-discovery skill for methodology
|
||||
- Keep questions conversational but focused
|
||||
- Synthesize user answers into coherent vision document
|
||||
- Vision should be concise (500-1000 words)
|
||||
- Encourage iteration and refinement
|
||||
187
commands/identify-epics.md
Normal file
187
commands/identify-epics.md
Normal file
@@ -0,0 +1,187 @@
|
||||
---
|
||||
name: re:identify-epics
|
||||
description: Identify major capabilities (epics) from vision and create epic issues in GitHub Projects
|
||||
allowed-tools: [AskUserQuestion, Bash, Read]
|
||||
---
|
||||
|
||||
# Identify Epics
|
||||
|
||||
Identify major capabilities (epics) from the product vision and create epic issues in GitHub Projects as children of the vision issue.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **epic-identification** skill to access methodology and templates.
|
||||
|
||||
### Step 1: Verify Prerequisites
|
||||
|
||||
1. **Check for Vision:**
|
||||
- Use `gh project item-list [project-number] --format json` to list items
|
||||
- Filter for Type = "Vision"
|
||||
- If no vision found: Inform user they need to run `/re:discover-vision` first, then exit
|
||||
- Store vision issue number/URL for parent linking
|
||||
|
||||
2. **Read Vision Issue:**
|
||||
- Use `gh issue view [vision-issue-number] --repo [repo] --json body`
|
||||
- Extract vision content to use for epic identification
|
||||
|
||||
### Step 2: Automated Epic Suggestion
|
||||
|
||||
Analyze the vision and suggest potential epics using epic-identification skill methodology:
|
||||
|
||||
**Use these discovery techniques:**
|
||||
- User Journey Mapping: What end-to-end journeys do users take?
|
||||
- Capability Decomposition: What major capabilities are needed?
|
||||
- Stakeholder Needs: What do different user types need?
|
||||
- Technical Enablers: What infrastructure is required?
|
||||
|
||||
**Suggest 5-10 potential epics based on the vision:**
|
||||
- Present as a numbered list
|
||||
- Brief description (1-2 sentences) for each
|
||||
- Categorize (User-Facing, Infrastructure, Integration, etc.)
|
||||
|
||||
Display:
|
||||
```
|
||||
Based on your vision, I've identified these potential epics:
|
||||
|
||||
**User-Facing Capabilities:**
|
||||
1. [Epic name] - [Brief description]
|
||||
2. [Epic name] - [Brief description]
|
||||
|
||||
**Infrastructure:**
|
||||
3. [Epic name] - [Brief description]
|
||||
|
||||
**Integration:**
|
||||
4. [Epic name] - [Brief description]
|
||||
|
||||
These are suggestions - you can accept, modify, or add your own.
|
||||
```
|
||||
|
||||
### Step 3: Epic Selection & Refinement
|
||||
|
||||
Use AskUserQuestion to refine the epic list:
|
||||
|
||||
**Question 1:**
|
||||
- Question: "Which of these suggested epics should we include? (Select all that apply)"
|
||||
- Header: "Epic Selection"
|
||||
- multiSelect: true
|
||||
- Options: One option per suggested epic (label = epic name, description = brief desc)
|
||||
|
||||
**Question 2:**
|
||||
- Question: "Are there any additional epics we should add?"
|
||||
- Header: "Additional Epics"
|
||||
- Options: Custom text input
|
||||
|
||||
### Step 4: Validate Epic Count
|
||||
|
||||
Check the total number of epics:
|
||||
- If < 5: Suggest this might be too few, ask if more decomposition needed
|
||||
- If > 15: Suggest this might be too many, ask if some can be combined
|
||||
- Ideal range: 5-12 epics
|
||||
|
||||
### Step 5: Create Epic Issues
|
||||
|
||||
For each selected/added epic:
|
||||
|
||||
1. **Compile Epic Description:**
|
||||
Use template from epic-identification skill's `${CLAUDE_PLUGIN_ROOT}/skills/epic-identification/references/epic-template.md`:
|
||||
```markdown
|
||||
## Epic: [Epic Name]
|
||||
|
||||
### Overview
|
||||
[Brief description of what this epic delivers]
|
||||
|
||||
### User Value
|
||||
[Who benefits and how]
|
||||
|
||||
### Scope
|
||||
**Included:**
|
||||
- [Capability 1]
|
||||
- [Capability 2]
|
||||
|
||||
**Excluded:**
|
||||
- [Not included 1]
|
||||
|
||||
### Success Criteria
|
||||
- [Criterion 1]
|
||||
- [Criterion 2]
|
||||
|
||||
### Dependencies
|
||||
[None identified yet - will be defined during story creation]
|
||||
|
||||
**Parent:** [Link to Vision Issue #]
|
||||
```
|
||||
|
||||
2. **Create Issue:**
|
||||
- Use `gh issue create --repo [repo] --title "[Epic Name]" --body "[epic description]" --label "type:epic"`
|
||||
- Capture issue number and URL
|
||||
|
||||
3. **Add to Project:**
|
||||
- Use `gh project item-add [project-number] --owner [owner] --url [issue-url]`
|
||||
|
||||
4. **Set Custom Fields:**
|
||||
- Type: Epic
|
||||
- Status: Not Started
|
||||
- Priority: (Will be set in prioritization step)
|
||||
|
||||
5. **Link to Vision (Parent):**
|
||||
- Add comment to epic issue: "Parent: #[vision-issue-number]"
|
||||
- Use GitHub's task list syntax in vision issue to track epics
|
||||
|
||||
### Step 6: Initial Prioritization Prompt
|
||||
|
||||
After creating all epics, ask:
|
||||
```
|
||||
✅ Created [N] epics successfully!
|
||||
|
||||
Epics:
|
||||
- #[num] - [Epic 1 name]
|
||||
- #[num] - [Epic 2 name]
|
||||
...
|
||||
|
||||
Would you like to prioritize these epics now using MoSCoW framework?
|
||||
```
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "Prioritize epics now?"
|
||||
- Header: "Prioritize"
|
||||
- Options:
|
||||
- "Yes, prioritize now" (description: "Use MoSCoW framework to prioritize")
|
||||
- "No, I'll prioritize later" (description: "Skip prioritization for now")
|
||||
- multiSelect: false
|
||||
|
||||
If "Yes": Execute `/re:prioritize` command
|
||||
|
||||
If "No": Show next steps
|
||||
|
||||
### Step 7: Success Message & Next Steps
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Epic identification complete!
|
||||
|
||||
Created [N] epics linked to Vision (#[vision-num])
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:prioritize` to rank epics by importance
|
||||
2. Review epic issues and add details as needed
|
||||
3. Run `/re:create-stories` to break down highest-priority epic
|
||||
4. Use `/re:status` to see project overview
|
||||
|
||||
Pro tip: Start with one epic, create stories for it, then move to the next!
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no vision exists: Guide to `/re:discover-vision`
|
||||
- If vision is incomplete: Suggest reviewing and updating it first
|
||||
- If issue creation fails: Show error and permissions guidance
|
||||
- If too many/few epics: Provide guidance on right-sizing
|
||||
|
||||
## Notes
|
||||
|
||||
- Use epic-identification skill for methodology
|
||||
- Aim for 5-12 epics (sweet spot)
|
||||
- One epic per file (separate issues)
|
||||
- Each epic links to vision as parent
|
||||
- Epics should be distinct and non-overlapping
|
||||
- Use common epic patterns (User-Facing, Infrastructure, Integration, Data)
|
||||
280
commands/init.md
Normal file
280
commands/init.md
Normal file
@@ -0,0 +1,280 @@
|
||||
---
|
||||
name: re:init
|
||||
description: Initialize a GitHub Project for requirements management with custom fields and views
|
||||
allowed-tools: [Bash, AskUserQuestion]
|
||||
---
|
||||
|
||||
# Initialize Requirements Project
|
||||
|
||||
Initialize a GitHub Project for requirements management. This command is **idempotent** - safe to run multiple times without creating duplicates.
|
||||
|
||||
## Prerequisites Validation
|
||||
|
||||
1. **Check GitHub CLI:**
|
||||
- Verify `gh` command exists: `command -v gh`
|
||||
- If not found: "GitHub CLI (gh) is not installed. Install it:"
|
||||
- macOS: `brew install gh`
|
||||
- Other: <https://cli.github.com/>
|
||||
|
||||
2. **Check Authentication:**
|
||||
- Run: `gh auth status`
|
||||
- If command fails: "Not authenticated with GitHub. Run: `gh auth login`"
|
||||
- Check output for required scopes: `repo` and `project`
|
||||
- If missing `project` scope: "Refresh authentication with: `gh auth refresh -s project`"
|
||||
- Note: Output could show "Token scopes: 'gist', 'project', 'read:org', 'repo', 'workflow'" format
|
||||
|
||||
3. **Detect Repository:**
|
||||
- Get repository info: `gh repo view --json nameWithOwner`
|
||||
- If fails: "Not in a git repository with GitHub remote. Navigate to your project repository."
|
||||
- Parse JSON to extract nameWithOwner (format: `{"nameWithOwner":"owner/repo"}`)
|
||||
- Split nameWithOwner on "/" to get the owner (before the "/")
|
||||
- Example: "sjnims/requirements-expert" → owner="sjnims"
|
||||
|
||||
## Project Setup
|
||||
|
||||
4. **Get Project Name:**
|
||||
- Use AskUserQuestion:
|
||||
- question: "What should we name the GitHub Project for requirements tracking?"
|
||||
- header: "Project Name"
|
||||
- multiSelect: false
|
||||
- options:
|
||||
- label: "[Repository Name] Requirements"
|
||||
description: "Standard naming convention following best practices (recommended)"
|
||||
- label: "[Repository Name] Backlog"
|
||||
description: "Alternative naming for backlog-style requirements tracking"
|
||||
- label: "[Repository Name] Roadmap"
|
||||
description: "Emphasizes long-term planning and feature roadmap view"
|
||||
- Note: User can select "Other" to provide a custom project name
|
||||
- Replace [Repository Name] placeholder with the repository name (the part after the "/" in `nameWithOwner` from step 3). For example, if `nameWithOwner` is "sjnims/requirements-expert", use "requirements-expert"
|
||||
- Store the user's choice for project creation
|
||||
|
||||
5. **Check for Existing Project (Idempotency):**
|
||||
- List existing projects: `gh project list --owner [owner] --format json`
|
||||
- Parse JSON response: `{"projects":[{"id":"...","number":4,"title":"...","url":"..."}]}`
|
||||
- Search the `projects` array for a project where `title` matches the chosen name
|
||||
- If found:
|
||||
- Inform user: "Found existing project '[title]' at [url]"
|
||||
- Capture project `number` (not `id`) for subsequent commands
|
||||
- Note: Project number is the sequential number (1, 2, 3...) visible in the URL
|
||||
- Skip to step 7 (field creation)
|
||||
- If not found:
|
||||
- Proceed to create project
|
||||
|
||||
6. **Create GitHub Project:**
|
||||
- Create project: `gh project create --owner [owner] --title "[name]" --format json`
|
||||
- Parse JSON response to extract `number` and `url`
|
||||
- If creation fails:
|
||||
- Display the actual error message from gh CLI
|
||||
- Use AskUserQuestion for interactive recovery:
|
||||
- question: "Project creation failed. How would you like to proceed?"
|
||||
- header: "Recovery"
|
||||
- multiSelect: false
|
||||
- options:
|
||||
- label: "Retry"
|
||||
description: "Try creating the project again"
|
||||
- label: "Check permissions"
|
||||
description: "Show commands to verify and fix GitHub CLI permissions"
|
||||
- label: "Exit"
|
||||
description: "Stop and let me fix the issue manually"
|
||||
- Handle user choice:
|
||||
- If "Retry": Re-execute the project creation command (line 64). If creation fails again, present the recovery options again (allowing user to continue trying, check permissions, or exit)
|
||||
- If "Check permissions":
|
||||
- Run: `gh auth status`
|
||||
- Display the output
|
||||
- Show refresh command: `gh auth refresh -s project`
|
||||
- Explain: "Projects require 'repo' and 'project' scopes"
|
||||
- Note: Projects are owner-scoped (user/org), not repository-scoped
|
||||
- After showing diagnostics, present the same recovery options again (Retry, Check permissions, or Exit)
|
||||
- If "Exit": Exit gracefully with message:
|
||||
```
|
||||
Project creation failed. Manual steps to resolve:
|
||||
|
||||
1. Check authentication: `gh auth status`
|
||||
2. Verify scopes include 'repo' and 'project'
|
||||
3. Refresh token if needed: `gh auth refresh -s project`
|
||||
4. Ensure you have permission to create projects for owner: [owner]
|
||||
5. Retry the command: `/re:init`
|
||||
|
||||
Error details: [show original error message]
|
||||
```
|
||||
- If creation succeeds:
|
||||
- Inform user: "Created project: [name] at [url]"
|
||||
- Capture project `number` for subsequent commands
|
||||
|
||||
## Custom Fields Setup
|
||||
|
||||
7. **Check Existing Fields:**
|
||||
- List all existing fields once: `gh project field-list [project-number] --owner [owner] --format json`
|
||||
- If command fails:
|
||||
- Log warning: "Could not retrieve existing fields, will attempt to create all fields"
|
||||
- Set field names list to empty (this ensures subsequent steps will attempt creation)
|
||||
- Continue to step 8
|
||||
- If command succeeds:
|
||||
- Parse JSON response to extract field names
|
||||
- Store the list of existing field names for use in subsequent steps
|
||||
- Example: If response contains fields with names "Title", "Status", "Assignees", store these names
|
||||
- This single query replaces multiple redundant field-list calls
|
||||
|
||||
8. **Create Type Field (If Missing):**
|
||||
- Check if "Type" exists in the stored field names list from step 7
|
||||
- If exists:
|
||||
- Inform user: "Type field already exists, skipping creation"
|
||||
- If not exists:
|
||||
- Create field with all options in one command:
|
||||
```
|
||||
gh project field-create [project-number] --owner [owner] \
|
||||
--name "Type" \
|
||||
--data-type SINGLE_SELECT \
|
||||
--single-select-options "Vision,Epic,Story,Task" \
|
||||
--format json
|
||||
```
|
||||
- If command fails: Note the failure but continue (user can add field manually)
|
||||
- Inform user: "Created Type field with options: Vision, Epic, Story, Task"
|
||||
|
||||
9. **Create Priority Field (If Missing):**
|
||||
- Check if "Priority" exists in the stored field names list from step 7
|
||||
- If exists:
|
||||
- Inform user: "Priority field already exists, skipping creation"
|
||||
- If not exists:
|
||||
- Create field with all options:
|
||||
```
|
||||
gh project field-create [project-number] --owner [owner] \
|
||||
--name "Priority" \
|
||||
--data-type SINGLE_SELECT \
|
||||
--single-select-options "Must Have,Should Have,Could Have,Won't Have" \
|
||||
--format json
|
||||
```
|
||||
- If command fails: Note the failure but continue
|
||||
- Inform user: "Created Priority field with MoSCoW options"
|
||||
|
||||
10. **Create Status Field (If Missing):**
|
||||
- Check if "Status" exists in the stored field names list from step 7
|
||||
- If exists:
|
||||
- Inform user: "Status field already exists, skipping creation"
|
||||
- If not exists:
|
||||
- Create field with all options:
|
||||
```
|
||||
gh project field-create [project-number] --owner [owner] \
|
||||
--name "Status" \
|
||||
--data-type SINGLE_SELECT \
|
||||
--single-select-options "Not Started,In Progress,Completed" \
|
||||
--format json
|
||||
```
|
||||
- If command fails: Note the failure but continue
|
||||
- Inform user: "Created Status field with workflow states"
|
||||
|
||||
## Views Setup (Manual Configuration Required)
|
||||
|
||||
11. **Views Setup - Manual Instructions:**
|
||||
- Note: GitHub CLI does not support view creation or configuration
|
||||
- All views must be created manually via the GitHub web interface
|
||||
- Inform user: "Project views require manual setup in the GitHub web interface"
|
||||
- Display project URL: [project-url]
|
||||
|
||||
**Manual Setup Instructions:**
|
||||
|
||||
1. **Access the project**:
|
||||
- Open the project in your browser: [project-url]
|
||||
- Or navigate to: Repository → Projects → [Project Name]
|
||||
|
||||
2. **Create recommended views**:
|
||||
|
||||
**View 1: "By Type" (Board View)**
|
||||
- Click "+ New view" → Board
|
||||
- Name: "By Type"
|
||||
- Layout: Board
|
||||
- Group by: Type
|
||||
- Shows: All items grouped by Vision/Epic/Story/Task
|
||||
|
||||
**View 2: "By Priority" (Board View)**
|
||||
- Click "+ New view" → Board
|
||||
- Name: "By Priority"
|
||||
- Layout: Board
|
||||
- Group by: Priority
|
||||
- Shows: All items grouped by Must Have/Should Have/Could Have/Won't Have
|
||||
|
||||
**View 3: "Active Work" (Table View)**
|
||||
- Click "+ New view" → Table
|
||||
- Name: "Active Work"
|
||||
- Layout: Table
|
||||
- Filter: Status = "In Progress"
|
||||
- Shows: Only items currently being worked on
|
||||
|
||||
**View 4: "Backlog" (Table View)**
|
||||
- Click "+ New view" → Table
|
||||
- Name: "Backlog"
|
||||
- Layout: Table
|
||||
- Filter: Status = "Not Started"
|
||||
- Shows: Work ready to be started
|
||||
|
||||
3. **Set default view** (optional):
|
||||
- Click "..." menu on preferred view
|
||||
- Select "Set as default"
|
||||
|
||||
## Success Reporting
|
||||
|
||||
12. **Display Success Message:**
|
||||
```
|
||||
✅ GitHub Project initialized successfully!
|
||||
|
||||
Project: [Project Name]
|
||||
URL: [Project URL]
|
||||
|
||||
Custom Fields Created:
|
||||
- Type (Vision, Epic, Story, Task)
|
||||
- Priority (Must Have, Should Have, Could Have, Won't Have)
|
||||
- Status (Not Started, In Progress, Completed)
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:discover-vision` to create your product vision
|
||||
2. Then `/re:identify-epics` to identify major capabilities
|
||||
3. Use `/re:status` anytime to see project overview
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- Exit gracefully on any validation failure (steps 1-3)
|
||||
- Display clear, actionable error messages
|
||||
- If project creation fails: Show gh error output and suggest remedies
|
||||
- If field creation fails: Note which fields failed but continue
|
||||
- Views require manual setup: Provide comprehensive manual instructions
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Key Architectural Points:**
|
||||
|
||||
- **Projects are owner-scoped, not repository-scoped**: Use `--owner [owner]` not `--repo`
|
||||
- **Use project number, not project ID**: Commands expect the sequential number (1, 2, 3...) visible in URLs, not the GraphQL ID (PVT_xxx)
|
||||
- **Field creation supports comma-separated options**: Use `--single-select-options "option1,option2,option3"` to create field and options in one command
|
||||
- **Idempotency is critical**: Always check for existing resources before creating
|
||||
|
||||
**State Management:**
|
||||
|
||||
This command intentionally does NOT persist local state (e.g., project number in a `.local.md` file). Design rationale:
|
||||
|
||||
1. **GitHub is the source of truth**: All requirements data lives in GitHub Issues and Projects
|
||||
2. **Idempotency**: Commands query GitHub directly, ensuring they always reflect current state
|
||||
3. **Multi-machine support**: No local state means the plugin works identically across machines
|
||||
4. **No sync issues**: Local state could become stale; direct queries are always accurate
|
||||
|
||||
Other `/re:*` commands will query GitHub to discover the project rather than relying on cached references.
|
||||
|
||||
**Command Execution:**
|
||||
|
||||
- All operations should be non-interactive (use `--format json` where available)
|
||||
- Parse JSON output using `jq` or similar tools
|
||||
- Use `--owner [owner]` for all project and field commands
|
||||
- Project number is extracted from JSON response during creation or listing
|
||||
|
||||
**Error Handling:**
|
||||
|
||||
- Exit gracefully on validation failures (steps 1-3)
|
||||
- Continue on non-critical failures (field/view creation)
|
||||
- Provide clear, actionable error messages
|
||||
- Include fallback manual instructions when CLI lacks functionality
|
||||
|
||||
**Testing Notes:**
|
||||
|
||||
- Verified with gh CLI version 2.x on macOS
|
||||
- Commands tested: `gh project list`, `gh project create`, `gh project field-list`, `gh project field-create`
|
||||
- View creation is not supported via CLI; manual setup via web interface is required
|
||||
200
commands/prioritize.md
Normal file
200
commands/prioritize.md
Normal file
@@ -0,0 +1,200 @@
|
||||
---
|
||||
name: re:prioritize
|
||||
description: Prioritize requirements (epics, stories, or tasks) using MoSCoW framework (Must/Should/Could/Won't Have)
|
||||
allowed-tools: [AskUserQuestion, Bash, Read]
|
||||
---
|
||||
|
||||
# Prioritize Requirements
|
||||
|
||||
Prioritize requirements at any level (epics, stories, or tasks) using the MoSCoW framework. Updates GitHub Project issues with priority labels and custom fields.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **prioritization** skill to access MoSCoW framework methodology.
|
||||
|
||||
### Step 1: Determine What to Prioritize
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "What would you like to prioritize?"
|
||||
- Header: "Prioritization Level"
|
||||
- Options:
|
||||
- "Epics" (description: "Prioritize all epics - determine which capabilities to build first")
|
||||
- "Stories for an epic" (description: "Prioritize user stories within a specific epic")
|
||||
- "Tasks for a story" (description: "Prioritize implementation tasks within a story")
|
||||
- multiSelect: false
|
||||
|
||||
### Step 2: Retrieve Items to Prioritize
|
||||
|
||||
Based on selection:
|
||||
|
||||
**If Epics:**
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Filter for Type = "Epic"
|
||||
- If no epics: Suggest running `/re:identify-epics`, exit
|
||||
|
||||
**If Stories:**
|
||||
- First ask which epic (use AskUserQuestion with epic options)
|
||||
- Then retrieve stories for that epic
|
||||
- Filter for Type = "Story" and parent = selected epic
|
||||
|
||||
**If Tasks:**
|
||||
- First ask which story (use AskUserQuestion with story options)
|
||||
- Then retrieve tasks for that story
|
||||
- Filter for Type = "Task" and parent = selected story
|
||||
|
||||
### Step 3: Present Items for Prioritization
|
||||
|
||||
Display items to be prioritized:
|
||||
```
|
||||
Let's prioritize these [N] [epics/stories/tasks] using MoSCoW framework:
|
||||
|
||||
**MoSCoW Categories:**
|
||||
- **Must Have**: Critical for success, can't ship without
|
||||
- **Should Have**: Important but not critical, can defer if needed
|
||||
- **Could Have**: Nice to have, include if time permits
|
||||
- **Won't Have**: Explicitly out of scope for now
|
||||
|
||||
**Items to prioritize:**
|
||||
1. [Item 1 title]
|
||||
2. [Item 2 title]
|
||||
3. [Item 3 title]
|
||||
...
|
||||
|
||||
We'll go through each item and assign a priority.
|
||||
```
|
||||
|
||||
### Step 4: Interactive Prioritization
|
||||
|
||||
For each item, use AskUserQuestion:
|
||||
|
||||
#### For each item
|
||||
|
||||
- Question: "[Item title] - What priority should this be?"
|
||||
- Header: "Priority"
|
||||
- Options:
|
||||
- "Must Have" (description: "Critical - cannot ship without this")
|
||||
- "Should Have" (description: "Important - defer only if Must Haves at risk")
|
||||
- "Could Have" (description: "Nice to have - include if time permits")
|
||||
- "Won't Have" (description: "Explicitly out of scope for now")
|
||||
- multiSelect: false
|
||||
- **Collect all priorities before updating GitHub**
|
||||
|
||||
### Step 5: Validate Distribution
|
||||
|
||||
After collecting all priorities, check distribution:
|
||||
|
||||
```
|
||||
Priority Distribution:
|
||||
- Must Have: [X] items ([%]%)
|
||||
- Should Have: [Y] items ([%]%)
|
||||
- Could Have: [Z] items ([%]%)
|
||||
- Won't Have: [W] items ([%]%)
|
||||
```
|
||||
|
||||
**Check against recommendations from prioritization skill:**
|
||||
- Must Haves should be <60% of total
|
||||
- If more than 60% are Must Have: Warn user and ask to review
|
||||
|
||||
If distribution is problematic, ask:
|
||||
```
|
||||
⚠️ Distribution check: [X]% of items are "Must Have"
|
||||
|
||||
Recommendation: Aim for <60% Must Haves to maintain focus and flexibility.
|
||||
|
||||
Would you like to review and adjust priorities?
|
||||
```
|
||||
|
||||
Use AskUserQuestion with Yes/No options. If Yes, restart Step 4.
|
||||
|
||||
### Step 6: Update GitHub Issues in GitHub Project
|
||||
|
||||
For each item, update GitHub:
|
||||
|
||||
1. **Update Priority Custom Field:**
|
||||
- Use `gh project item-edit` to set Priority field to selected MoSCoW category
|
||||
|
||||
2. **Add Priority Label:**
|
||||
- Use `gh issue edit [issue-number] --add-label "priority:[moscow-level]"`
|
||||
- Labels: `priority:must-have`, `priority:should-have`, `priority:could-have`, `priority:wont-have`
|
||||
|
||||
3. **Add Comment with Rationale:**
|
||||
- Ask user for brief rationale for each Must Have and Won't Have
|
||||
- Add comment to issue: "Priority: [level] - Rationale: [user-provided text]"
|
||||
|
||||
### Step 7: Sequence Within Categories
|
||||
|
||||
After prioritization, determine execution order:
|
||||
|
||||
**For Must Haves:**
|
||||
Ask about sequencing factors:
|
||||
- Dependencies (what must come first?)
|
||||
- Risk (tackle unknowns early?)
|
||||
- Value (highest value first?)
|
||||
|
||||
Present suggested sequence and ask for confirmation.
|
||||
|
||||
### Step 8: Success Message & Summary
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Prioritization complete!
|
||||
|
||||
**Summary:**
|
||||
- Must Have: [X] items
|
||||
- Should Have: [Y] items
|
||||
- Could Have: [Z] items
|
||||
- Won't Have: [W] items
|
||||
|
||||
**Execution Order (Must Haves):**
|
||||
1. #[num] - [Item title]
|
||||
2. #[num] - [Item title]
|
||||
3. #[num] - [Item title]
|
||||
|
||||
**Next Steps:**
|
||||
[If Epics were prioritized:]
|
||||
- Start with first Must Have epic
|
||||
- Run `/re:create-stories` for that epic
|
||||
- Focus on completing Must Haves before Should Haves
|
||||
|
||||
[If Stories were prioritized:]
|
||||
- Start with first Must Have story
|
||||
- Run `/re:create-tasks` for that story
|
||||
- Complete stories in priority order
|
||||
|
||||
[If Tasks were prioritized:]
|
||||
- Begin implementation with Must Have tasks
|
||||
- Follow dependency order within priority level
|
||||
- Update task status in GitHub Projects as you progress
|
||||
|
||||
Pro tip: Re-prioritize regularly as you learn more!
|
||||
```
|
||||
|
||||
### Step 9: Offer Next Action
|
||||
|
||||
Use AskUserQuestion:
|
||||
- Question: "What would you like to do next?"
|
||||
- Header: "Next Step"
|
||||
- Options:
|
||||
- "Prioritize another level" (description: "Prioritize epics/stories/tasks")
|
||||
- "Check project status" (description: "See overall progress")
|
||||
- "Continue with highest priority item" (description: "Create stories/tasks for top priority item")
|
||||
- "Done for now" (description: "Stop here")
|
||||
- multiSelect: false
|
||||
- **Handle response appropriately**
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no items to prioritize: Guide to appropriate creation command
|
||||
- If all items are Must Have: Provide guidance on right-sizing
|
||||
- If no items are Must Have: Confirm this is intentional
|
||||
- If priorities conflict with dependencies: Highlight and suggest resolution
|
||||
|
||||
## Notes
|
||||
|
||||
- Use prioritization skill for MoSCoW framework details
|
||||
- Must Haves should be <60% of total items
|
||||
- "Won't Have" is important - makes exclusions explicit
|
||||
- Re-prioritize as you learn (monthly/quarterly)
|
||||
- Dependencies should influence sequencing
|
||||
- Document rationale for priorities (especially Must Have and Won't Have)
|
||||
- Update priorities in both custom fields AND labels for visibility
|
||||
270
commands/review.md
Normal file
270
commands/review.md
Normal file
@@ -0,0 +1,270 @@
|
||||
---
|
||||
name: re:review
|
||||
description: Validate requirements for completeness, consistency, quality, and traceability
|
||||
allowed-tools: [Bash, Read]
|
||||
---
|
||||
|
||||
# Review & Validate Requirements
|
||||
|
||||
Comprehensive validation of requirements at all levels (vision, epics, stories, tasks) checking for completeness, consistency, quality, and traceability.
|
||||
|
||||
## Instructions
|
||||
|
||||
Load the **requirements-validator** agent OR implement validation logic directly.
|
||||
|
||||
### Step 1: Scan Requirements
|
||||
|
||||
1. **Retrieve All Requirements:**
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Categorize by Type: Vision, Epic, Story, Task
|
||||
- Count items at each level
|
||||
|
||||
2. **Check Hierarchy:**
|
||||
- Verify vision exists (exactly 1)
|
||||
- Verify epics link to vision
|
||||
- Verify stories link to epics
|
||||
- Verify tasks link to stories
|
||||
|
||||
### Step 2: Completeness Check
|
||||
|
||||
**Vision Level:**
|
||||
- [ ] Problem statement exists and is clear
|
||||
- [ ] Target users are defined
|
||||
- [ ] Solution overview exists
|
||||
- [ ] Success metrics are defined
|
||||
- [ ] Scope boundaries are set
|
||||
|
||||
**Epic Level:**
|
||||
- [ ] Each epic has clear description
|
||||
- [ ] User value is articulated
|
||||
- [ ] Scope (included/excluded) is defined
|
||||
- [ ] Success criteria exist
|
||||
- [ ] All vision elements are covered by epics
|
||||
|
||||
**Story Level:**
|
||||
- [ ] Each story follows "As a... I want... So that..." format
|
||||
- [ ] Acceptance criteria are present (minimum 3-5)
|
||||
- [ ] Stories are small enough (1-5 days estimate)
|
||||
- [ ] All epic scope is covered by stories
|
||||
|
||||
**Task Level:**
|
||||
- [ ] Each task has clear, action-oriented title
|
||||
- [ ] Acceptance criteria are specific and testable (minimum 3-5)
|
||||
- [ ] Tasks are right-sized (2-8 hours)
|
||||
- [ ] All story acceptance criteria are covered by tasks
|
||||
|
||||
### Step 3: Consistency Check
|
||||
|
||||
**Traceability:**
|
||||
- [ ] Every epic links to vision
|
||||
- [ ] Every story links to an epic
|
||||
- [ ] Every task links to a story
|
||||
- [ ] No orphaned issues (items without parents)
|
||||
|
||||
**Naming & IDs:**
|
||||
- [ ] Consistent terminology across levels
|
||||
- [ ] No duplicate or conflicting requirements
|
||||
- [ ] Labels are applied consistently
|
||||
|
||||
**Priority Alignment:**
|
||||
- [ ] Child priorities don't exceed parent priorities
|
||||
- [ ] Dependencies respect priority order
|
||||
|
||||
### Step 4: Quality Check (INVEST for Stories)
|
||||
|
||||
For each user story, verify INVEST criteria:
|
||||
- [ ] **Independent**: Can be completed without depending on others
|
||||
- [ ] **Negotiable**: Details open for discussion
|
||||
- [ ] **Valuable**: Delivers clear user value
|
||||
- [ ] **Estimable**: Team can estimate size
|
||||
- [ ] **Small**: Fits in single iteration
|
||||
- [ ] **Testable**: Clear acceptance criteria
|
||||
|
||||
### Step 5: Validation Report
|
||||
|
||||
Generate comprehensive report:
|
||||
|
||||
```
|
||||
# Requirements Validation Report
|
||||
|
||||
**Generated:** [Date/Time]
|
||||
**Project:** [Project Name]
|
||||
|
||||
## Summary
|
||||
|
||||
| Level | Count | Complete | Issues |
|
||||
|-------|-------|----------|--------|
|
||||
| Vision | [N] | [✓/✗] | [N] |
|
||||
| Epics | [N] | [✓/✗] | [N] |
|
||||
| Stories | [N] | [✓/✗] | [N] |
|
||||
| Tasks | [N] | [✓/✗] | [N] |
|
||||
|
||||
**Overall Status:** [✓ Pass / ⚠️ Warning / ✗ Fail]
|
||||
|
||||
---
|
||||
|
||||
## Critical Issues (Must Fix)
|
||||
|
||||
[List any critical issues that prevent requirements from being actionable]
|
||||
|
||||
### Missing Vision
|
||||
- [ ] No vision issue found - run `/re:discover-vision`
|
||||
|
||||
### Broken Traceability
|
||||
- [ ] Epic #[num] has no parent vision
|
||||
- [ ] Story #[num] has no parent epic
|
||||
- [ ] Task #[num] has no parent story
|
||||
|
||||
### Incomplete Requirements
|
||||
- [ ] Epic #[num] missing scope definition
|
||||
- [ ] Story #[num] has no acceptance criteria
|
||||
- [ ] Task #[num] missing acceptance criteria
|
||||
|
||||
---
|
||||
|
||||
## Warnings (Should Address)
|
||||
|
||||
[List issues that should be fixed but don't block progress]
|
||||
|
||||
### Quality Issues
|
||||
- [ ] Story #[num] too large (>5 days) - consider splitting
|
||||
- [ ] Task #[num] too vague - needs clearer description
|
||||
- [ ] Epic #[num] overlaps with Epic #[num2]
|
||||
|
||||
### INVEST Violations
|
||||
- [ ] Story #[num] not independent (depends on #[num2])
|
||||
- [ ] Story #[num] not valuable (too technical, no user benefit)
|
||||
- [ ] Story #[num] not testable (vague acceptance criteria)
|
||||
|
||||
### Priority Issues
|
||||
- [ ] Must Have items exceed 60% - review priorities
|
||||
- [ ] No Won't Haves defined - consider scope boundaries
|
||||
- [ ] Child priority higher than parent
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable suggestions for improvement]
|
||||
|
||||
1. **Add Missing Content:**
|
||||
- Update Epic #[num] with success criteria
|
||||
- Add acceptance criteria to Story #[num]
|
||||
|
||||
2. **Split Large Items:**
|
||||
- Story #[num] - suggest splitting into [X] stories
|
||||
|
||||
3. **Clarify Vague Items:**
|
||||
- Task #[num] - add specific technical notes
|
||||
|
||||
4. **Fix Traceability:**
|
||||
- Link Story #[num] to Epic #[num2]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
Based on validation results:
|
||||
|
||||
**If Critical Issues Found:**
|
||||
1. Fix critical issues before proceeding
|
||||
2. Re-run `/re:review` after fixes
|
||||
|
||||
**If Only Warnings:**
|
||||
1. Address high-priority warnings
|
||||
2. Proceed with implementation
|
||||
3. Refine as you learn
|
||||
|
||||
**If All Pass:**
|
||||
✅ Requirements are solid! Ready for implementation.
|
||||
|
||||
---
|
||||
|
||||
## Validation Details
|
||||
|
||||
### Vision Validation
|
||||
[Detailed findings for vision]
|
||||
- Status: [✓ Pass / ⚠️ Warning / ✗ Fail]
|
||||
- Issues: [List]
|
||||
|
||||
### Epic Validation
|
||||
[Detailed findings for epics]
|
||||
- Epics validated: [N]
|
||||
- Pass: [N], Warnings: [N], Fail: [N]
|
||||
- Issues: [List]
|
||||
|
||||
### Story Validation
|
||||
[Detailed findings for stories]
|
||||
- Stories validated: [N]
|
||||
- INVEST compliance: [%]%
|
||||
- Issues: [List]
|
||||
|
||||
### Task Validation
|
||||
[Detailed findings for tasks]
|
||||
- Tasks validated: [N]
|
||||
- Avg acceptance criteria per task: [N]
|
||||
- Issues: [List]
|
||||
```
|
||||
|
||||
### Step 6: Offer to Fix Issues
|
||||
|
||||
After presenting report, offer to help fix issues:
|
||||
|
||||
```
|
||||
Would you like help fixing any of these issues?
|
||||
|
||||
I can:
|
||||
- Update issues with missing content
|
||||
- Split large stories/tasks
|
||||
- Add missing acceptance criteria
|
||||
- Fix broken traceability links
|
||||
|
||||
Which would you like to address first?
|
||||
```
|
||||
|
||||
**If user wants help:**
|
||||
- For each issue, provide specific guidance or make updates
|
||||
- Update GitHub issues in GitHub Project as needed
|
||||
- Re-run validation after fixes
|
||||
|
||||
### Step 7: Success Message
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Requirements review complete!
|
||||
|
||||
**Status:** [Overall status]
|
||||
**Critical Issues:** [N]
|
||||
**Warnings:** [N]
|
||||
|
||||
[If issues found:]
|
||||
Address critical issues before proceeding with implementation.
|
||||
Use the validation report above to guide fixes.
|
||||
|
||||
[If no issues:]
|
||||
Requirements look good! You're ready to start implementation.
|
||||
|
||||
**Recommendations:**
|
||||
- Re-run `/re:review` periodically (weekly/monthly)
|
||||
- Update requirements as you learn during implementation
|
||||
- Use feedback from testing to refine acceptance criteria
|
||||
|
||||
**Next Steps:**
|
||||
[Based on validation status, suggest appropriate next actions]
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no requirements exist: Guide to appropriate creation commands
|
||||
- If project doesn't exist: Suggest `/re:init`
|
||||
- If validation fails: Provide clear, actionable guidance
|
||||
|
||||
## Notes
|
||||
|
||||
- Validation checks all levels: vision, epics, stories, tasks
|
||||
- Focus on actionable findings
|
||||
- Distinguish critical issues from warnings
|
||||
- Provide specific guidance for each issue type
|
||||
- Offer to help fix issues automatically where possible
|
||||
- Can be run at any time - recommended weekly/monthly
|
||||
- Use as quality gate before sprint planning or releases
|
||||
341
commands/status.md
Normal file
341
commands/status.md
Normal file
@@ -0,0 +1,341 @@
|
||||
---
|
||||
name: re:status
|
||||
description: Show comprehensive overview of requirements project status, progress, and health
|
||||
allowed-tools: [Bash, Read]
|
||||
---
|
||||
|
||||
# Requirements Project Status
|
||||
|
||||
Display a comprehensive overview of the requirements project including counts, progress, priorities, validation status, and recent activity.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Gather Project Data
|
||||
|
||||
1. **Get Project Info:**
|
||||
- Use `gh project list --owner [owner] --format json`
|
||||
- Identify the requirements project
|
||||
- Get project URL and metadata
|
||||
|
||||
2. **Retrieve All Items:**
|
||||
- Use `gh project item-list [project-number] --format json`
|
||||
- Get full details including custom fields (Type, Priority, Status)
|
||||
|
||||
3. **Categorize by Type:**
|
||||
- Vision: Count and status
|
||||
- Epics: Count, priorities, status
|
||||
- Stories: Count, priorities, status, parent epic
|
||||
- Tasks: Count, priorities, status, parent story
|
||||
|
||||
4. **Get Recent Activity:**
|
||||
- Use `gh issue list --repo [repo] --label type:epic,type:story,type:task --limit 10 --json number,title,updatedAt,state`
|
||||
- Show last updated items
|
||||
|
||||
### Step 2: Calculate Metrics
|
||||
|
||||
**Counts by Type:**
|
||||
- Total Vision issues (should be 1)
|
||||
- Total Epics
|
||||
- Total Stories
|
||||
- Total Tasks
|
||||
|
||||
**Progress by Status:**
|
||||
- Not Started: [Count] ([%]%)
|
||||
- In Progress: [Count] ([%]%)
|
||||
- Completed: [Count] ([%]%)
|
||||
|
||||
**Priority Distribution:**
|
||||
- Must Have: [Count] ([%]%)
|
||||
- Should Have: [Count] ([%]%)
|
||||
- Could Have: [Count] ([%]%)
|
||||
- Won't Have: [Count] ([%]%)
|
||||
|
||||
**Completion Metrics:**
|
||||
- Epics: [X] of [Total] completed ([%]%)
|
||||
- Stories: [X] of [Total] completed ([%]%)
|
||||
- Tasks: [X] of [Total] completed ([%]%)
|
||||
|
||||
**Velocity (if applicable):**
|
||||
- Tasks completed in last 7 days
|
||||
- Stories completed in last 30 days
|
||||
|
||||
### Step 3: Generate Status Dashboard
|
||||
|
||||
Display comprehensive status:
|
||||
|
||||
```
|
||||
# 📊 Requirements Project Status
|
||||
|
||||
**Project:** [Project Name]
|
||||
**URL:** [Project URL]
|
||||
**Last Updated:** [Current Date/Time]
|
||||
|
||||
---
|
||||
|
||||
## 📈 Overview
|
||||
|
||||
| Level | Total | Not Started | In Progress | Completed | % Complete |
|
||||
|-------|-------|-------------|-------------|-----------|------------|
|
||||
| Vision | [N] | [N] | [N] | [N] | [%]% |
|
||||
| Epics | [N] | [N] | [N] | [N] | [%]% |
|
||||
| Stories | [N] | [N] | [N] | [N] | [%]% |
|
||||
| Tasks | [N] | [N] | [N] | [N] | [%]% |
|
||||
|
||||
**Overall Progress:** [Progress bar visualization]
|
||||
████████░░░░░░░░░░░░ [%]%
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Priority Breakdown
|
||||
|
||||
**Must Have:**
|
||||
- Epics: [N] | Stories: [N] | Tasks: [N]
|
||||
- Status: [N] complete, [N] in progress, [N] not started
|
||||
|
||||
**Should Have:**
|
||||
- Epics: [N] | Stories: [N] | Tasks: [N]
|
||||
- Status: [N] complete, [N] in progress, [N] not started
|
||||
|
||||
**Could Have:**
|
||||
- Epics: [N] | Stories: [N] | Tasks: [N]
|
||||
- Status: [N] complete, [N] in progress, [N] not started
|
||||
|
||||
**Won't Have:**
|
||||
- Epics: [N] | Stories: [N] | Tasks: [N]
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Current Focus
|
||||
|
||||
**Active Work (In Progress):**
|
||||
- #[num] - [Epic/Story/Task title] (type: [type])
|
||||
- #[num] - [Epic/Story/Task title] (type: [type])
|
||||
[List all items with Status = "In Progress"]
|
||||
|
||||
**Next Up (Highest Priority Not Started):**
|
||||
1. #[num] - [Epic/Story/Task title] (priority: Must Have)
|
||||
2. #[num] - [Epic/Story/Task title] (priority: Must Have)
|
||||
3. #[num] - [Epic/Story/Task title] (priority: Must Have)
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Epic Status Detail
|
||||
|
||||
[For each epic, show progress]
|
||||
|
||||
### Epic: [Epic Title] (#[num])
|
||||
- **Priority:** [Must/Should/Could Have]
|
||||
- **Status:** [Not Started/In Progress/Completed]
|
||||
- **Stories:** [X] of [Total] complete ([%]%)
|
||||
- **Tasks:** [X] of [Total] complete ([%]%)
|
||||
- **Progress:** ████░░░░░░ [%]%
|
||||
|
||||
[Repeat for all epics]
|
||||
|
||||
---
|
||||
|
||||
## ✅ Validation Status
|
||||
|
||||
**Last Validation:** [Date or "Never"]
|
||||
|
||||
**Quick Health Check:**
|
||||
- [ ] Vision exists: [✓/✗]
|
||||
- [ ] All epics linked to vision: [✓/✗]
|
||||
- [ ] All stories linked to epics: [✓/✗]
|
||||
- [ ] All tasks linked to stories: [✓/✗]
|
||||
- [ ] Priority distribution balanced: [✓/⚠️/✗]
|
||||
- [ ] No orphaned issues: [✓/✗]
|
||||
|
||||
**Issues Found:** [N critical, N warnings]
|
||||
|
||||
[If issues:] Run `/re:review` for detailed validation report.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Velocity & Trends
|
||||
|
||||
**Recent Activity (Last 7 days):**
|
||||
- Tasks completed: [N]
|
||||
- Stories completed: [N]
|
||||
- Epics completed: [N]
|
||||
- New items created: [N]
|
||||
|
||||
**Last 10 Updated Items:**
|
||||
1. #[num] - [Title] ([type]) - Updated [timeago]
|
||||
2. #[num] - [Title] ([type]) - Updated [timeago]
|
||||
[...]
|
||||
|
||||
---
|
||||
|
||||
## 📊 Coverage Analysis
|
||||
|
||||
**Vision → Epics:**
|
||||
- Vision coverage: [All vision elements covered by epics? ✓/✗]
|
||||
|
||||
**Epics → Stories:**
|
||||
[For each epic]
|
||||
- Epic #[num]: [Has stories? ✓/✗] ([N] stories)
|
||||
|
||||
**Stories → Tasks:**
|
||||
[Sample or summary]
|
||||
- [N] stories have tasks
|
||||
- [N] stories need task breakdown
|
||||
|
||||
---
|
||||
|
||||
## 💡 Recommendations
|
||||
|
||||
[Based on status, provide actionable suggestions]
|
||||
|
||||
**Immediate Actions:**
|
||||
[If no vision:] Run `/re:discover-vision` to create vision
|
||||
[If no epics:] Run `/re:identify-epics` to identify major capabilities
|
||||
[If epics not prioritized:] Run `/re:prioritize` to rank epics
|
||||
[If highest priority epic has no stories:] Run `/re:create-stories` to break down top epic
|
||||
[If highest priority story has no tasks:] Run `/re:create-tasks` to create implementation tasks
|
||||
|
||||
**Health Issues:**
|
||||
[If validation issues:] Run `/re:review` to identify and fix issues
|
||||
[If too many In Progress:] Focus on completing work before starting new items
|
||||
[If progress stalled:] Review blockers and dependencies
|
||||
|
||||
**Next Steps:**
|
||||
[Contextual suggestions based on current state]
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Quick Links
|
||||
|
||||
- **GitHub Project:** [URL]
|
||||
- **Vision Issue:** #[num]
|
||||
- **All Epics:** [Filter URL]
|
||||
- **All Stories:** [Filter URL]
|
||||
- **All Tasks:** [Filter URL]
|
||||
- **Must Haves:** [Filter URL]
|
||||
- **In Progress:** [Filter URL]
|
||||
|
||||
---
|
||||
|
||||
## 📅 Suggested Actions
|
||||
|
||||
Based on current status:
|
||||
|
||||
1. [Most logical next action based on project state]
|
||||
2. [Second priority action]
|
||||
3. [Third priority action]
|
||||
|
||||
**Commands:**
|
||||
- `/re:discover-vision` - [If no vision]
|
||||
- `/re:identify-epics` - [If vision but no epics]
|
||||
- `/re:create-stories` - [If epics but incomplete stories]
|
||||
- `/re:create-tasks` - [If stories but incomplete tasks]
|
||||
- `/re:prioritize` - [If items not prioritized]
|
||||
- `/re:review` - [Regular validation]
|
||||
```
|
||||
|
||||
### Step 4: Provide Context-Aware Guidance
|
||||
|
||||
Based on the status, provide specific next steps:
|
||||
|
||||
**If just starting (no vision):**
|
||||
```
|
||||
🚀 Getting Started
|
||||
|
||||
Your requirements project is newly initialized!
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:discover-vision` to define your product vision
|
||||
2. Then `/re:identify-epics` to identify major capabilities
|
||||
3. Use `/re:prioritize` to rank epics
|
||||
4. Start implementing highest-priority epics
|
||||
|
||||
Estimated time to complete vision + epics: 1-2 hours
|
||||
```
|
||||
|
||||
**If vision exists but few epics:**
|
||||
```
|
||||
📝 Vision Defined - Define Epics Next
|
||||
|
||||
You have a solid vision. Time to break it down!
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:identify-epics` to identify 5-12 major capabilities
|
||||
2. Prioritize epics with `/re:prioritize`
|
||||
3. Create stories for top epic with `/re:create-stories`
|
||||
```
|
||||
|
||||
**If epics exist but few stories:**
|
||||
```
|
||||
🎯 Epics Identified - Create Stories
|
||||
|
||||
You have [N] epics. Let's create user stories!
|
||||
|
||||
Focus: [Highest priority epic name]
|
||||
|
||||
Next Steps:
|
||||
1. Run `/re:create-stories` for epic #[num]
|
||||
2. Prioritize stories with `/re:prioritize`
|
||||
3. Create tasks for top story with `/re:create-tasks`
|
||||
```
|
||||
|
||||
**If well underway:**
|
||||
```
|
||||
💪 In Full Swing - Keep the Momentum!
|
||||
|
||||
Progress: [X]% complete
|
||||
|
||||
Current Focus: [In progress items]
|
||||
|
||||
Next Steps:
|
||||
1. Complete in-progress items
|
||||
2. Run `/re:status` regularly to track progress
|
||||
3. Run `/re:review` weekly for quality checks
|
||||
```
|
||||
|
||||
**If near complete:**
|
||||
```
|
||||
🎉 Almost There!
|
||||
|
||||
You're [X]% complete - great progress!
|
||||
|
||||
Remaining Work:
|
||||
- [N] epics to complete
|
||||
- [N] stories to finish
|
||||
- [N] tasks remaining
|
||||
|
||||
Keep going! Run `/re:status` to track final progress.
|
||||
```
|
||||
|
||||
### Step 5: Export Option
|
||||
|
||||
Offer to export status report:
|
||||
|
||||
```
|
||||
Would you like to export this status report?
|
||||
|
||||
I can save it as:
|
||||
- Markdown file (status-report-[date].md)
|
||||
- Add as comment to vision issue
|
||||
- Both
|
||||
|
||||
[Use AskUserQuestion for choice]
|
||||
```
|
||||
|
||||
If user wants export, create the file or add comment as requested.
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If no project exists: Guide to `/re:init`
|
||||
- If project empty: Guide to `/re:discover-vision`
|
||||
- If GitHub API fails: Show cached/partial data with warning
|
||||
|
||||
## Notes
|
||||
|
||||
- Can be run anytime - no prerequisites
|
||||
- Provides complete project snapshot
|
||||
- Context-aware recommendations
|
||||
- Shows trends and velocity
|
||||
- Validates project health
|
||||
- Suggests next logical actions
|
||||
- Export-friendly format
|
||||
- Run regularly (daily/weekly) to track progress
|
||||
Reference in New Issue
Block a user