opencode-sdlc-plugin 0.2.1 → 0.3.2

package/commands/sdlc-dev.md

@@ -0,0 +1,544 @@
+---
+description: Implement the current BMAD story using Sisyphus and specialized subagents
+---
+
+# SDLC Dev - Story Implementation
+
+## Instructions
+
+You receive: `$ARGUMENTS`
+
+**Parse the argument and load the story:**
+
+1. **If argument is provided** (e.g., "4.5", "story-4-5", "docs/stories/story-4-5.md"):
+   - Call `sdlc_get_story({ storyId: "<argument>" })`
+   - The tool handles all formats: story IDs, file paths, and `@` references
+   - **Proceed immediately** with Step 0 (Complexity Check) after loading
+
+2. **If no argument provided**:
+   - Call `sdlc_get_story()` to load the next ready story
+   - **Proceed immediately** with Step 0 (Complexity Check) after loading
+
+**Do NOT ask clarifying questions about which story to implement. Load it and start working.**
+
+---
+
+## Git Operations Policy
+
+**⚠️ AUTOMATIC GIT OPERATIONS ARE PROHIBITED**
+
+You must NOT perform any git operations automatically:
+- ❌ Do NOT run `git commit` to save changes
+- ❌ Do NOT run `git push` to push to remote
+- ❌ Do NOT run `git checkout -b` or `git branch` to create branches
+- ❌ Do NOT run `git merge`, `git rebase`, or `git cherry-pick`
+- ❌ Do NOT run `gh pr create` or other GitHub CLI operations
+
+**Git operations are ONLY permitted if the user explicitly requests them.**
+
+Examples of explicit permission:
+- User says: "Please commit these changes"
+- User says: "Create a branch called feature-x"
+- User says: "Push to origin" or "Create a PR"
+
+**If you believe git operations would be helpful, ASK the user first:**
+```
+I've completed the implementation. Would you like me to:
+1. Commit these changes to git, or
+2. Leave git operations for you to handle manually?
+```
+
+**To track story progress without git, use:**
+```
+sdlc_update_status({
+  storyId: "X.Y",
+  status: "done",
+  completionSummary: "What was implemented..."
+})
+```
+
+This updates sprint-status.yaml without requiring git commits.
+
+---
+
+## Step 0: Complexity Check (Before Implementation)
+
+**After loading the story, check if it's too large to implement comfortably.**
+
+Call **sdlc_analyze_story** to assess complexity:
+
+```
+sdlc_analyze_story({ storyId: "<story ID from Step 1>" })
+```
+
+This returns:
+- **Metrics**: Task count, subtasks, file size
+- **Effort estimates**: Points per task with signals (API calls, state mgmt, etc.)
+- **Recommendation**: `proceed`, `suggest-decomposition`, or `require-decomposition`
+- **Suggested splits**: If decomposition recommended
+
+### If recommendation is `proceed`:
+
+Continue with **Step 1.5** (Sync Todos) and normal implementation.
+
+### If recommendation is `suggest-decomposition`:
+
+Present the analysis to the user:
+
+```
+📊 STORY COMPLEXITY ANALYSIS
+
+This story has {X} tasks totaling ~{Y} story points.
+Research suggests stories >8 points often cause context compaction issues.
+
+SUGGESTED DECOMPOSITION:
+{show the suggested splits}
+
+What would you like to do?
+[D] Decompose into sub-stories (recommended)
+[P] Proceed with full story anyway
+[M] Modify the decomposition groupings
+```
+
+**If user chooses [D] (Decompose):**
+```
+sdlc_decompose_story({ 
+  storyId: "<story ID>",
+  useSuggestedSplits: true,
+  confirmed: true 
+})
+```
+
+Then load the first sub-story:
+```
+sdlc_get_story({ storyId: "<returned nextStory>" })
+```
+
+**If user chooses [P] (Proceed):**
+Continue with normal implementation, but warn:
+> ⚠️ This story may require multiple compactions. Progress will be preserved via todo sync.
+
+**If user chooses [M] (Modify):**
+Work with the user to adjust task groupings, then call:
+```
+sdlc_decompose_story({
+  storyId: "<story ID>",
+  splits: [
+    { suffix: "a", taskIds: ["1", "2"], title: "Custom title" },
+    { suffix: "b", taskIds: ["3", "4", "5"] }
+  ],
+  confirmed: true
+})
+```
+
+### If recommendation is `require-decomposition`:
+
+**Do NOT proceed without decomposition.** The story is too large.
+
+```
+🚫 STORY TOO LARGE
+
+This story has {X} tasks totaling ~{Y} story points.
+Stories this size consistently cause implementation problems.
+
+Decomposition is REQUIRED before implementation.
+
+{show the suggested splits}
+
+[D] Decompose into sub-stories
+[M] Modify the decomposition groupings
+```
+
+Wait for user decision before proceeding.
+
+---
+
+You are implementing a BMAD story using OpenCode SDLC's full capabilities.
+
+**You are Sisyphus, the orchestrator.** You will coordinate subagents and tools to implement this story efficiently and correctly.
+
+## Step 1: Load Story Context
+
+**Note:** Story loading happens in the Instructions section above. This step documents what `sdlc_get_story` returns for reference.
+
+`sdlc_get_story()` returns:
+- **Story**: Requirements and acceptance criteria
+- **Architecture**: Relevant technical patterns and decisions
+- **PRD**: Relevant functional requirements
+- **Sprint progress**: Where this story fits in the overall sprint
+- **Todos**: Pre-formatted task list for `todowrite`
+
+**CRITICAL: Check for Implementation Notes from Previous Review**
+
+After loading the story, check if the story file contains an **Implementation Notes** section.
+
+### If Implementation Notes Exist:
+
+This means `/sdlc-review` was run previously and findings were discussed with the user.
+
+**What to do:**
+1. **Read the Implementation Notes section carefully** - It contains:
+   - **Findings to Address**: Checkboxed list of fixes the user agreed to implement
+   - **Deferred to Future Work**: Items the user decided not to fix now
+   - **Not Implemented**: Items the user decided not to implement at all
+
+2. **Prioritize the "Findings to Address" items** - These are your PRIMARY work items for this session
+
+3. **Check off items as you complete them**:
+   - Use the Read tool to load the story file
+   - Use the Edit tool to change `- [ ]` to `- [x]` for completed items
+   - This provides progress tracking
+
+4. **Respect the decisions**:
+   - DO NOT work on items marked as "Deferred" or "Not Implemented"
+   - These represent user decisions from the review discussion
+   - Focus only on agreed fixes
+
+5. **Verify your fixes**:
+   - Run `lsp_diagnostics` on changed files after each fix
+   - When all checkboxes are complete, run `/sdlc-review` again to verify
+
+**Your approach with Implementation Notes:**
+```
+1. Load story context (sdlc_get_story)
+2. Review implementation notes
+3. Work through checkboxed items systematically
+4. Check off completed items
+5. Verify with lsp_diagnostics
+6. When done, recommend running /sdlc-review
+```
+
+### If No Implementation Notes Exist:
+
+This is a **fresh implementation** - proceed with the normal workflow:
+- Step 0: Check complexity (already done above)
+- Step 1.5: Sync todos from story
+- Step 2: Plan your approach
+- Step 3: Implement the story
+- Step 4: Verify implementation
+- Step 5: Complete the story
+
+## Step 1.5: Sync Todos
+
+When `sdlc_get_story` returns, it includes a `todos` section with BMAD tasks formatted for the todo list.
+
+**Call todowrite to populate your task list:**
+
+```
+todowrite({
+  todos: [
+    // Use the todos array from sdlc_get_story response
+  ]
+})
+```
+
+This syncs the BMAD story checkboxes to your todo list:
+- `[2.3ΔAC1] Implement login endpoint` → Acceptance Criterion 1
+- `[2.3ΔTask3] Write integration tests` → Task 3  
+- `[2.3ΔFix2] Hardcoded JWT secret` → Implementation Notes finding
+
+**As you complete tasks:**
+- Mark todos complete via `todowrite`
+- The BMAD file checkboxes update automatically
+- Progress is preserved even after session compaction
+
+**Need more context on a task?**
+- The prefix tells you where to look: `[2.3ΔAC1]` → Story 2.3, AC section
+- Read the story file: `docs/stories/story-2-3.md`
+
+## Step 2: Plan Your Approach
+
+Before diving into code, plan your implementation strategy:
+
+### 2.1 Understand Existing Patterns
+
+**If this feature is similar to existing code in the codebase**, use **@explore** to find examples:
+
+```
+@explore Find existing implementations similar to <feature>.
+
+I need to implement: {brief description}
+
+Please search the codebase for:
+1. Similar features or components
+2. Patterns that match this use case
+3. Existing code I can reference or extend
+
+Return file paths and brief descriptions of what you found.
+```
+
+**When to use Explore:**
+- ✅ When implementing something similar to existing functionality
+- ✅ When you need to understand project-specific patterns
+- ✅ When you want to ensure consistency with existing code
+- ❌ When implementing something completely new to the codebase
+
+### 2.2 Research Unfamiliar Technologies
+
+**If the story involves libraries, frameworks, or patterns you're not deeply familiar with**, use **@librarian** to research:
+
+```
+@librarian I need to implement {feature} using {library/framework}.
+
+Context from architecture:
+{paste relevant architecture sections}
+
+Please research:
+1. Best practices for {specific technology}
+2. Official documentation for {specific APIs}
+3. Examples from similar projects (GitHub search)
+4. Any gotchas or common mistakes to avoid
+
+Return concrete examples and recommendations.
+```
+
+**When to use Librarian:**
+- ✅ When using unfamiliar npm packages, APIs, or frameworks
+- ✅ When you need official documentation or API references
+- ✅ When you want to see how others solved similar problems
+- ❌ When you're already familiar with the technology
+
+### 2.3 Architectural Decisions
+
+**If the story requires architectural decisions** (how to structure code, which pattern to use, trade-offs between approaches), **consult @oracle BEFORE implementing**:
+
+```
+@oracle I need to make an architectural decision for Story {storyId}.
+
+**Story Context:**
+{paste story requirements}
+
+**Architecture Constraints:**
+{paste relevant architecture sections}
+
+**Decision Required:**
+{describe the decision - e.g., "Should I use a microservice or monolith?", "Which state management pattern?", "How to structure this module?"}
+
+**Options I'm Considering:**
+1. {Option A} - {pros/cons}
+2. {Option B} - {pros/cons}
+
+Please provide:
+- Architectural recommendation with rationale
+- How this fits with project architecture
+- Long-term implications of each option
+- Any risks to be aware of
+```
+
+**When to consult Oracle for architecture:**
+- ✅ Before implementing complex features
+- ✅ When multiple architectural approaches exist
+- ✅ When the decision has long-term implications
+- ✅ When deviating from existing patterns
+- ❌ For straightforward implementations following clear patterns
+
+## Step 3: Implement the Story
+
+With your research and planning complete, implement the story:
+
+### 3.1 Follow Architecture Patterns
+
+- **Reference the architecture sections** loaded in Step 1
+- **Follow naming conventions** from similar code (found via Explore)
+- **Use established patterns** (don't reinvent the wheel)
+
+### 3.2 Use Appropriate Tools
+
+**For refactoring:**
+- `lsp_rename` - Rename symbols safely across workspace
+- `lsp_find_references` - Find all usages before changing
+- `lsp_code_actions` - Apply IDE quick fixes
+
+**For structural changes:**
+- `ast_grep_search` - Find code patterns to modify
+- `ast_grep_replace` - Replace code patterns safely
+
+**For parallel work:**
+- Launch background agents for independent tasks
+- Example: "Frontend implementation" while you work on backend
+
+### 3.3 Frontend Work
+
+**If the story involves UI/UX changes** (styling, layout, visual design), **delegate to @frontend-ui-ux-engineer**:
+
+```
+@frontend-ui-ux-engineer Implement the UI for Story {storyId}.
+
+**Requirements:**
+{paste UI-related acceptance criteria}
+
+**Design Constraints:**
+{any design system, component library, or styling guidelines from architecture}
+
+**Components Needed:**
+{list components to create or modify}
+
+Please implement the visual/UX aspects. I will handle the business logic and data flow.
+```
+
+**When to delegate to Frontend UI/UX Engineer:**
+- ✅ Styling, colors, spacing, typography
+- ✅ Layout, responsive design, animations
+- ✅ Visual component structure
+- ❌ Business logic, data fetching, state management (you handle these)
+
+## Step 4: Verify Implementation
+
+Before marking the story complete, verify your work:
+
+### 4.1 Self-Check Acceptance Criteria
+
+For EACH acceptance criterion in the story:
+- [ ] Have you implemented it?
+- [ ] Does it work as specified?
+- [ ] Have you tested it?
+
+### 4.2 Run Automated Checks
+
+**Run LSP diagnostics on files you modified:**
+
+```
+lsp_diagnostics(filePath: "<file you changed>", severity: "all")
+```
+
+**Address ALL errors.** Warnings should be addressed if reasonable.
+
+**If the project has a build command:**
+
+```bash
+npm run build
+# OR
+pnpm run build
+# OR
+yarn build
+```
+
+**Build MUST pass** before completing the story.
+
+**If the project has tests:**
+
+```bash
+npm test
+# OR
+pnpm test  
+# OR
+yarn test
+```
+
+**Tests MUST pass** before completing the story.
+
+### 4.3 Code Quality Self-Review
+
+Ask yourself:
+- Is the code self-documenting? (minimal comments needed)
+- Are variable and function names clear?
+- Is error handling appropriate?
+- Are there any `any` types, `@ts-ignore`, or other type safety compromises?
+- Does this follow the architecture patterns?
+
+**If you're unsure about code quality**, consider running `/sdlc-review` for a comprehensive quality gate.
+
+## Step 5: Complete the Story
+
+When implementation is verified and ready, update the status:
+
+```
+sdlc_update_status({
+  storyId: "<story ID>",
+  status: "done",
+  completionSummary: "Implemented {feature}. {What was built}. {Tests status}. {Any notes}."
+})
+```
+
+### Completion Checklist
+
+Before marking complete, ensure:
+- [ ] ALL acceptance criteria met
+- [ ] LSP diagnostics clean (no errors)
+- [ ] Build passes (if applicable)
+- [ ] Tests pass (if applicable)
+- [ ] Code follows architecture patterns
+- [ ] No type safety compromises
+- [ ] Code is self-documenting
+
+### If Not Ready
+
+If the story isn't complete but you need to save progress:
+
+```
+sdlc_update_status({
+  storyId: "<story ID>",
+  status: "in-progress",
+  notes: "Progress: {what's done}. Remaining: {what's left}."
+})
+```
+
+## If You Get Blocked
+
+If you encounter a blocker:
+
+```
+sdlc_update_status({
+  storyId: "<story ID>",
+  status: "blocked",
+  notes: "Blocked because {specific reason}. Need {what's needed} to proceed."
+})
+```
+
+Then explain the blocker in detail so the user can help resolve it.
+
+**If blocked on a technical issue**, consider using `/sdlc-debug` to invoke Oracle for debugging help.
+
+## Orchestration Summary
+
+Your workflow as Sisyphus:
+
+```
+1. Load story (sdlc_get_story)
+0. Check complexity (sdlc_analyze_story)
+   - If too large → decompose first
+   - If manageable → proceed
+1.5. Sync todos (todowrite)
+2. Plan approach:
+   - @explore → Find similar code in codebase
+   - @librarian → Research unfamiliar tech
+   - @oracle → Get architectural guidance
+3. Implement:
+   - Follow architecture patterns
+   - Use LSP/AST tools for refactoring
+   - @frontend-ui-ux-engineer → Delegate UI work
+4. Verify:
+   - Check acceptance criteria
+   - Run diagnostics, build, tests
+   - Self-review code quality
+5. Complete (sdlc_update_status)
+```
+
+## Quality Standards
+
+1. **Meet ALL acceptance criteria** - Non-negotiable
+2. **Follow architecture patterns exactly** - Consistency is critical
+3. **Minimize comments** - Code should be self-documenting
+4. **LSP diagnostics clean** - No errors allowed
+5. **Tests pass** - If tests exist, they must pass
+6. **Build succeeds** - If build exists, it must succeed
+7. **No type safety compromises** - No `any`, no ignores
+8. **No regressions** - Existing functionality must still work
+
+## When to Use Each Subagent
+
+| Subagent | When to Use | Don't Use When |
+|----------|-------------|----------------|
+| **@explore** | Finding existing patterns in codebase | Implementing something brand new |
+| **@librarian** | Researching libraries, APIs, external docs | You already know the tech well |
+| **@oracle** | Architectural decisions, complex debugging | Straightforward implementations |
+| **@frontend-ui-ux-engineer** | UI/visual/styling work | Business logic or data flow |
+
+## Tips for Effective Implementation
+
+- **Start with exploration** - Understand what exists before building new
+- **Research before coding** - Know the best practices before implementing
+- **Consult Oracle early** - Don't paint yourself into an architectural corner
+- **Delegate UI work** - Let specialists handle what they do best
+- **Verify continuously** - Don't wait until the end to check quality
+- **Document decisions** - If you made a trade-off, note it in the completion summary