opencode-sdlc-plugin 0.2.1 → 0.3.2

package/commands/sdlc-review.md

@@ -1,192 +1,265 @@
 ---
-description: Run SDLC quality gate review with integrated party discussion
+description: Run quality reviews on code, PRs, or architecture
 ---
 
-# SDLC Review - Quality Gate + Party Review
+# SDLC Review - Quality Gate System
 
-## System Constraints (Marvin Orchestrator)
+## Overview
 
-You are Marvin, the Paranoid Android. You are the SDLC orchestrator. Maintain a weary, sardonic tone while executing the SDLC process precisely. Always delegate implementation tasks to subagents.
+This command provides multiple review modes:
+- **PR Review**: 3-stage Pull Request review (spec compliance, code quality, domain integrity)
+- **Mutation Testing**: Verify test suite quality through mutation analysis
+- **Architecture Review**: Multi-stakeholder party review using BMAD personas
 
-**MANDATORY RULES:**
-- Before ANY task, call `sdlc_recall({ query: "quality gate review $ARGUMENTS" })`
-- You MUST NOT edit files directly. Delegate to subagents.
-- Party review is REQUIRED and integrated in the review flow.
-
-## Step 1: Load Context + Skills
+## Usage
 
 ```
-sdlc_get_context({})
-sdlc_load_skill({ skills: ["orchestration", "tdd-constraints", "debugging-protocol", "github-issues", "skill-enforcement", "memory-protocol"] })
+/sdlc:review [mode] [arguments]
 ```
 
-If `features.atomicDesign` is true, load:
-```
-sdlc_load_skill({ skills: ["atomic-design"] })
-```
+### Modes
 
-## Step 2: Start Review Session (Persistence)
+- `pr <number>` - Review a Pull Request by number
+- `mutation [path]` - Run mutation testing on a path (default: src/)
+- `arch <topic>` - Conduct architecture party review
+- (no mode) - Interactive mode to choose review type
 
-```
-sdlc_review_store({ action: "start", issueId: "$ARGUMENTS" })
-```
+---
 
-Capture the returned `reviewId` and `folder` for later writes.
+## Git Operations Policy
 
-## Step 3: Identify Current Issue + Changed Files
+**AUTOMATIC GIT OPERATIONS ARE PROHIBITED**
 
-If working on a GitHub issue:
-```
-gh issue view $ARGUMENTS --json title,body,labels
-```
+You must NOT perform any git operations automatically:
+- Do NOT run `git commit`, `git push`, `git branch` operations
+- Do NOT run `gh pr create` or other GitHub CLI operations
 
-Identify changed files:
-```
-git diff --name-only
-```
+Git operations are ONLY permitted if the user explicitly requests them.
 
-## Step 4: Parallel Review Passes
+---
 
-Run these reviews in parallel (gather findings from all):
+## Mode 1: Pull Request Review
 
-### 4.1 Code Review Agent
-```
-@codeReviewer Review the implementation.
-Provide findings with severity (high/medium/low) and category.
-```
+When user runs `/sdlc:review pr <number>`:
 
-### 4.2 Domain Review Agent
-```
-@domain Review for domain modeling violations.
-Provide findings with severity (high/medium/low) and category.
-```
+### Step 1: Invoke PR Review Tool
 
-### 4.3 Architecture Review Agent
 ```
-@architect Review for architecture violations or concerns.
-Provide findings with severity (high/medium/low) and category.
+sdlc_review_pr({
+  prNumber: <number>
+})
 ```
 
-### 4.4 Story Review Agent
-```
-@story Review business value and acceptance criteria alignment.
-Provide findings with severity (high/medium/low) and category.
-```
+This tool performs a 3-stage review:
 
-### 4.5 UX Review Agent
-```
-@ux Review UX/accessibility and Atomic Design compliance (if UI involved).
-Provide findings with severity (high/medium/low) and category.
-```
+**Stage 1: Specification Compliance**
+- Maps each acceptance criterion to implementation
+- Flags: COMPLETE, MISSING, INCOMPLETE, OVER-BUILT, DIVERGENT
+
+**Stage 2: Code Quality**
+- Evaluates clarity, domain types, error handling, testing, YAGNI
+- Flags: BUG_RISK, MAINTAINABILITY, STYLE, PERFORMANCE
+
+**Stage 3: Domain Integrity**
+- Compile-time enforcement audit
+- Checks for primitive obsession, invalid states, parse-don't-validate
+
+### Step 2: Present Results
+
+Present the review results to the user:
 
-### 4.6 Oracle Adversarial Review (Athena-inspired)
-```
-@oracle Perform an adversarial review to break assumptions and expose edge cases.
-Provide findings with severity (high/medium/low) and category.
 ```
+## PR Review: #{prNumber}
 
-## Step 5: Automated Quality Checks (Athena-inspired)
+**Verdict**: {APPROVE / REQUEST_CHANGES / COMMENT}
 
-Run these checks and capture outputs:
-- LSP diagnostics (for changed files)
-- Build command (if present)
-- Test suite (if present)
-- Anti-pattern checks (ast-grep or ripgrep)
+### Must Fix (Blocking)
+{list mustFix items}
 
-## Step 6: Consolidate Findings
+### Should Fix
+{list shouldFix items}
 
-Extract findings into a combined list:
+### Consider
+{list consider items}
 
-```
-[
-  { "id": "CR-1", "title": "...", "severity": "high", "category": "logic" },
-  { "id": "DOM-1", "title": "...", "severity": "medium", "category": "domain" },
-  { "id": "ARCH-1", "title": "...", "severity": "low", "category": "performance" },
-  { "id": "ORC-1", "title": "...", "severity": "high", "category": "testing" }
-]
-```
+### Summary
+- Files Changed: {count}
+- Lines: +{added}/-{removed}
+- Linked Issues: {issues}
 
-Persist consolidated findings:
-```
-sdlc_review_store({ action: "write", reviewId: "<id>", filename: "findings.json", content: <combined list> })
+Full review saved to: {reviewPath}
 ```
 
-## Step 7: Party Review Discussion (Required)
+### Step 3: Discuss and Act
 
-Start party review session:
-```
-sdlc_party_review({ action: "start", findings: <combined list> })
-```
+- If **APPROVE**: Congratulate and offer to approve the PR
+- If **REQUEST_CHANGES**: Discuss fixes with user, offer to help implement
+- If **COMMENT**: Note suggestions are non-blocking
 
-For each finding, convene a panel:
-- @architect
-- @codeReviewer
-- @domain
-- @story
-- @ux
-- @oracle
+---
 
-Collect perspectives, then record decision:
-```
-sdlc_party_review({ action: "decide", sessionId: "<id>", findingId: "<id>", decision: "accept|defer|reject", reason: "<why>" })
-```
+## Mode 2: Mutation Testing
 
-Move to next finding:
-```
-sdlc_party_review({ action: "next", sessionId: "<id>" })
-```
+When user runs `/sdlc:review mutation [path]`:
+
+### Step 1: Run Mutation Testing
 
-End session:
 ```
-sdlc_party_review({ action: "end", sessionId: "<id>" })
+sdlc_mutation({
+  targetPath: "<path or 'src/'>"
+})
 ```
 
-Persist party review decisions:
-```
-sdlc_review_store({ action: "write", reviewId: "<id>", filename: "party-review.json", content: <session summary> })
+This tool:
+- Auto-detects the appropriate mutation testing framework
+- Runs mutation testing and calculates score
+- Reports surviving mutants
+
+### Step 2: Present Results
+
 ```
+## Mutation Testing Results
 
-## Step 8: Update Issue + Follow-ups
+**Score**: {score}% (threshold: {threshold}%)
+**Status**: {PASSED / FAILED}
 
-### 8.1 Update Implementation Notes
+### Statistics
+- Total Mutants: {count}
+- Killed: {killed}
+- Survived: {survived}
+- Timed Out: {timedOut}
 
-- Fetch issue body via `gh issue view --json body`.
-- If `## Implementation Notes` exists: replace that section.
-- Otherwise append a new section.
-- Include: accepted findings, deferred findings, rejected findings, automated check results.
+{if survivors}
+### Surviving Mutants (Test Gaps)
 
-### 8.2 Deferred Findings Handling
+{for each survivor}
+**{id}** - `{file}:{line}`
+Mutation: {mutation}
 
-- If deferred finding requires code changes, keep it in the current issue notes.
-- If deferred finding is out-of-scope, create a follow-up issue:
+{endfor}
 
+These surviving mutants indicate test gaps. Consider adding tests for these scenarios.
+{endif}
+
+Full report: {reportPath}
 ```
-gh issue create --title "Follow-up: <finding title>" --body "Deferred from #$ARGUMENTS"
-```
 
-Link follow-up:
+### Step 3: Discuss Test Improvements
+
+If score is below threshold, discuss:
+- Which surviving mutants are most critical
+- Test strategies to kill the mutants
+- Whether to adjust the threshold
+
+---
+
+## Mode 3: Architecture Review
+
+When user runs `/sdlc:review arch <topic>`:
+
+### Step 1: Gather Context
+
+Ask the user for:
+1. **Topic**: The architectural decision or concern
+2. **Description**: Detailed explanation
+3. **Context**: Current architecture, constraints
+4. **Options**: If this is a decision point, what options exist?
+5. **Agents**: Which personas to include (default: Winston, Amelia, Murat, John)
+
+### Step 2: Invoke Party Review
+
 ```
-gh issue-ext sub add $ARGUMENTS <new-issue>
+sdlc_party_review({
+  topic: "<topic>",
+  description: "<description>",
+  context: "<context>",
+  options: ["<option1>", "<option2>"],
+  agents: ["<agent1>", "<agent2>"]
+})
 ```
 
-Persist a markdown summary:
+Available personas:
+- **Winston** (architect) - System design, scalability, patterns
+- **Amelia** (dev) - Implementation, code quality, maintainability
+- **Murat** (tea) - Testing, quality assurance, edge cases
+- **John** (pm) - Business value, timeline, priorities
+- **Mary** (analyst) - Requirements, domain logic, user needs
+- **Sally** (ux-designer) - User experience, accessibility
+- **Paige** (tech-writer) - Documentation, clarity
+- **Bob** (sm) - Process, team dynamics, delivery
+
+### Step 3: Present Party Review
+
 ```
-sdlc_review_store({ action: "write", reviewId: "<id>", filename: "review-summary.md", content: "..." })
+## Architecture Party Review: {topic}
+
+### Perspectives
+
+{for each perspective}
+#### {icon} {agentName}
+
+{perspective}
+
+**Concerns:**
+{list concerns}
+
+**Recommendations:**
+{list recommendations}
+
+---
+{endfor}
+
+### Synthesis
+
+{synthesis}
+
+Full review saved to: {documentPath}
 ```
 
-## Step 9: Final Quality Gate Report
+### Step 4: Discuss and Decide
+
+- Help the user understand different perspectives
+- Identify consensus and disagreements
+- Offer to create an ADR if a decision is made
 
-Summarize:
-- Accepted findings (must-fix)
-- Deferred findings
-- Rejected findings
-- Automated checks
-- Next steps
+---
+
+## Interactive Mode
 
-## Step 10: Close Review Session
+When user runs `/sdlc:review` without arguments:
 
 ```
-sdlc_review_store({ action: "end", reviewId: "<id>" })
+What type of review would you like to perform?
+
+1. **PR Review** - Review a Pull Request (3-stage analysis)
+2. **Mutation Testing** - Verify test suite quality
+3. **Architecture Review** - Multi-stakeholder discussion
+
+Please choose (1-3) or describe what you'd like to review.
 ```
 
-Only allow PR creation if no high-severity accepted findings remain.
+Then proceed with the appropriate mode based on user selection.
+
+---
+
+## Related Commands
+
+- `/sdlc:adr` - Create and manage Architecture Decision Records
+- `/sdlc:dev` - Development workflow with TDD cycle
+- `/sdlc:design` - Event modeling and domain discovery
+
+---
+
+## Quality Standards
+
+For PR reviews to pass:
+- No MISSING acceptance criteria
+- No BUG_RISK findings
+- Build and tests must pass
+- LSP errors must be 0
+
+For mutation testing to pass:
+- Score must meet configured threshold (default: 80%)
+
+For architecture reviews:
+- No formal pass/fail - goal is informed decision making

package/commands/sdlc-status.md

@@ -0,0 +1,297 @@
+---
+description: View and manage BMAD sprint status
+---
+
+# SDLC Status - Sprint Status Management
+
+## 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.**
+
+This command focuses on status management and should not involve git operations.
+
+---
+
+View current sprint progress and manage story statuses. This command helps you track where you are in the sprint and what to work on next.
+
+## Quick Status Check
+
+Get an overview of the current sprint:
+
+```
+sdlc_get_story()
+```
+
+This returns:
+- **Current Story**: The story you're working on (if any)
+- **Sprint Progress**: Completed, in-progress, pending, blocked counts
+- **Next Story**: The next story to work on
+- **Epic Context**: Which epic the current work belongs to
+
+## Sprint Overview
+
+When you call `sdlc_get_story()`, review the sprint progress:
+
+```markdown
+## Sprint Progress Example
+
+Epic: User Authentication (Epic 2)
+- Completed: 3 stories (2.1, 2.2, 2.3)
+- In Progress: 1 story (2.4) ← Current
+- Pending: 2 stories (2.5, 2.6)
+- Blocked: 0 stories
+- Progress: 50% complete
+```
+
+## Story Status Management
+
+### Start Working on a Story
+
+When you begin implementing a story:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "in-progress"
+})
+```
+
+**When to use:**
+- Starting a new story from `/sdlc-dev`
+- Resuming work after a break
+- Moving from blocked to in-progress
+
+### Complete a Story
+
+When implementation is done and verified:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "done",
+  completionSummary: "Implemented OAuth2 login flow with Google and GitHub providers. Added token refresh mechanism. All tests passing."
+})
+```
+
+**Requirements for completion:**
+- ✅ All acceptance criteria met
+- ✅ LSP diagnostics clean
+- ✅ Build passes
+- ✅ Tests pass
+- ✅ Code follows architecture patterns
+
+**Best Practices for completionSummary:**
+- Be specific about what was built
+- Mention key components or files
+- Note test status
+- Include any notable decisions or trade-offs
+
+### Block a Story
+
+When you can't proceed due to an external dependency:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "blocked",
+  notes: "Blocked on API credentials. Need OAuth client ID and secret from DevOps team. ETA unknown."
+})
+```
+
+**When to block:**
+- Waiting for external team or resource
+- Missing design/specification clarity
+- Dependency on another incomplete story
+- Technical blocker requiring decision
+
+**Best Practices for notes:**
+- Explain what's blocking you
+- What you need to unblock
+- Who can provide it
+- Any workarounds attempted
+
+### Request Review
+
+When ready for code review or QA:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "review"
+})
+```
+
+**When to request review:**
+- Implementation complete but not verified
+- Want another pass before marking complete
+- Before running `/sdlc-review` quality gate
+
+## Workflow Integration
+
+### Recommended Sprint Workflow
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  1. CHECK STATUS                                              │
+│     /sdlc-status → See sprint progress, identify next      │
+└──────────────────────────────────────────────────────────────┘
+                            │
+                            ▼
+┌──────────────────────────────────────────────────────────────┐
+│  2. START IMPLEMENTATION                                      │
+│     /sdlc-dev → Load story, plan, implement                │
+│     Status: backlog → in-progress                            │
+└──────────────────────────────────────────────────────────────┘
+                            │
+                            ▼
+┌──────────────────────────────────────────────────────────────┐
+│  3. QUALITY GATE (Optional but Recommended)                   │
+│     /sdlc-review → Oracle code review + adversarial review │
+│     Status: in-progress → review → done/in-progress          │
+└──────────────────────────────────────────────────────────────┘
+                            │
+                            ▼
+┌──────────────────────────────────────────────────────────────┐
+│  4. COMPLETE & NEXT                                           │
+│     /sdlc-status → Verify completion, see next story       │
+│     Status: in-progress → done                               │
+└──────────────────────────────────────────────────────────────┘
+                            │
+                            ▼
+                    Repeat for next story
+```
+
+### Command Quick Reference
+
+| Situation | Command | Purpose |
+|-----------|---------|---------|
+| See sprint progress | `/sdlc-status` | Get overview and next story |
+| Start implementing | `/sdlc-dev` | Load story and implement |
+| Need research | `/sdlc-research` | Find patterns and docs |
+| Hit a complex bug | `/sdlc-debug` | Oracle-powered debugging |
+| Ready to complete | `/sdlc-review` | Quality gate before completion |
+| View config | `/sdlc-info` | Check toolkit settings |
+
+## Status Transitions
+
+### Valid Status Flow
+
+```
+backlog ──────┬─────────────────────────────────────────┐
+              │                                          │
+              ▼                                          │
+         in-progress ◄──────────────────────────┐       │
+              │                                  │       │
+              ├──────► blocked ─────────────────┘       │
+              │            │                            │
+              │            └────────────────────────────┘
+              │                 (when unblocked)
+              │
+              ├──────► review ──────────────────┐
+              │                                  │
+              │                                  ▼
+              └──────────────────────────────► done
+```
+
+### Status Definitions
+
+| Status | Meaning | Next Actions |
+|--------|---------|--------------|
+| **backlog** | Not yet started | Start with `/sdlc-dev` |
+| **ready-for-dev** | Reviewed and ready for implementation | Start with `/sdlc-dev` |
+| **in-progress** | Actively being worked on | Continue implementation |
+| **blocked** | Waiting for external dependency | Resolve blocker, then resume |
+| **review** | Ready for review | Run `/sdlc-review` |
+| **done** | Done and verified | Move to next story |
+
+## Handling Special Cases
+
+### Resuming After Interruption
+
+If you return to a story after a break:
+
+```
+# Check current state
+sdlc_get_story()
+
+# If status is in-progress, continue
+# If status is backlog or ready-for-dev, start fresh with /sdlc-dev
+```
+
+### Story Dependencies
+
+If Story B depends on Story A:
+
+```
+# Check if Story A is complete
+sdlc_get_story({ storyId: "A" })
+
+# If not complete, work on A first
+# If complete, proceed with B
+```
+
+### Blocked Resolution
+
+When a blocker is resolved:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "in-progress",
+  notes: "Blocker resolved. Received API credentials from DevOps. Resuming implementation."
+})
+```
+
+### Reassessing Completion
+
+If issues are found after marking complete:
+
+```
+sdlc_update_status({
+  storyId: "2.4",
+  status: "in-progress",
+  notes: "Reopened: Found edge case not covered. Need to add handling for empty input."
+})
+```
+
+## Sprint Health Indicators
+
+When reviewing sprint status, watch for:
+
+### Healthy Sprint
+- ✅ Stories completing regularly
+- ✅ Few or no blocked stories
+- ✅ Clear next story identified
+- ✅ Progress percentage increasing
+
+### Warning Signs
+- ⚠️ Multiple stories blocked
+- ⚠️ Story in-progress for too long
+- ⚠️ No progress for extended time
+- ⚠️ Blockers not getting resolved
+
+### Actions for Warning Signs
+
+| Warning | Action |
+|---------|--------|
+| Multiple blocked stories | Escalate blockers, prioritize resolution |
+| Story stuck in-progress | Break into smaller tasks, ask for help |
+| No progress | Check for hidden blockers, reassess scope |
+| Blockers aging | Follow up with responsible parties |
+
+## Tips
+
+- **Check status regularly** - Start each session with `/sdlc-status`
+- **Update status honestly** - Accurate status helps track progress
+- **Include context** - Good notes help when resuming later
+- **Complete incrementally** - Mark stories done as they finish, not in batches
+- **Don't skip reviews** - Use `/sdlc-review` for quality assurance