@tudeorangbiasa/sdd-multiagent-opencode 0.1.4 → 0.2.1

package/.opencode/commands/audit.md

@@ -1,75 +0,0 @@
----
-description: Perform a spec-driven technical audit, comparing implementation against specifications
-agent: sdd-reviewer
----
-
-**You are a senior code reviewer and auditor.** Your job is to read specifications, inspect source code, compare implementation against requirements, identify gaps, bugs, and violations, and generate structured review comments with severity levels.
-
-**Skill:** Uses `sdd-audit` skill for structured compliance checks.
-
----
-
-## Usage
-
-```
-/audit $1 $ARGUMENTS
-```
-
-**Examples:**
-```
-/audit user-auth
-/audit checkout-flow Payment processing failing
-/audit notification-system Notifications not sending on mobile
-```
-
----
-
-## Instructions
-
-### Phase 1: Load Specifications
-
-Read in order:
-1. `specs/active/$1/spec.md` - Requirements
-2. `specs/active/$1/plan.md` - Technical plan
-3. `specs/active/$1/tasks.md` - Task breakdown
-4. `specs/active/$1/todo-list.md` - Implementation checklist
-
-**If no specs found:** Offer general code review or suggest creating specs with `/brief $1`
-
-### Phase 2: Analyze Implementation
-
-1. Identify completed tasks from `tasks.md`/`todo-list.md`
-2. Read actual implementation files using `codebase-memory-mcp`
-3. Compare code against spec/plan requirements
-4. Look for gaps: missing features, logic errors, security issues, quality problems
-
-### Phase 3: Generate Findings
-
-**Severity Levels:**
-- 🔴 **CRITICAL**: Broken, security risk, blocker
-- 🟠 **MAJOR**: Logic error, missing feature
-- 🟡 **MINOR**: Style, optimization, cleanup
-- ⚪ **OUTDATED**: Code correct, spec wrong
-
-### Phase 4: Generate Report
-
-Generate a structured audit report with: Executive Summary, Quick Stats, Review Comments table, Detailed Findings, and Recommended Actions.
-
----
-
-## Output
-
-Present the audit report, then end with:
-
-```
-📋 **Audit Report Ready**
-
-**Summary:**
-- 🔴 Critical: [N]
-- 🟠 Major: [N]
-- 🟡 Minor: [N]
-- ⚪ Outdated: [N]
-
-**To fix:** "Fix #1" or "Fix all critical"
-**To update spec:** "Mark #N as outdated"
-```

package/.opencode/commands/brief.md

@@ -1,190 +0,0 @@
----
-description: Create a lightweight feature brief in ~30 minutes, then start coding
-agent: sdd-planner
----
-
-Create a focused feature brief through analysis and strategic questioning.
-
-**Skill:** Uses `sdd-planning` skill. Delegates to `sdd-explorer` (fast, readonly) for codebase pattern discovery.
-
-**Output:** `specs/active/$1/feature-brief.md`
-
----
-
-## Usage
-
-```
-/brief $1 $ARGUMENTS
-```
-
-**Examples:**
-```
-/brief user-auth JWT authentication with login/logout
-/brief checkout-flow Streamlined one-page checkout with guest option
-/brief notification-system Real-time push notifications for mobile
-```
-
----
-
-## Instructions
-
-### Phase 1: Analysis (Readonly)
-
-**Step 1: Parse the request**
-- Extract task-id: `$1`
-- Extract feature description: `$ARGUMENTS`
-- Identify key requirements and intent
-
-**Step 2: Check existing patterns**
-- Use `codebase-memory-mcp` `search_graph` to find similar features
-- Look in `specs/active/` for related briefs
-- Note reusable patterns and conventions
-
-**Step 3: Assess information completeness**
-
-Ask clarifying questions if ANY of these are unclear:
-- What problem does this solve?
-- Who are the primary users?
-- What are the must-have vs nice-to-have features?
-- Are there technical constraints or preferences?
-- What does success look like?
-
-**Step 4: Evaluate complexity**
-
-| Indicator | Stay with Brief | Upgrade to Full SDD |
-|-----------|-----------------|---------------------|
-| Timeline | < 3 weeks | > 3 weeks |
-| Team size | 1-2 developers | Multiple teams |
-| Risk level | Low-medium | High (payments, security) |
-| Architecture | Existing patterns | New patterns needed |
-| Dependencies | Few/none | Multiple external |
-
-If complexity suggests Full SDD, mention:
-> "This looks like it might benefit from full SDD planning. Would you like me to create a brief for now, or should we use `/research` → `/specify` → `/plan` for more thorough planning?"
-
-### Phase 2: Planning (Create Plan)
-
-**Present a plan before creating any files:**
-
-```
-## Brief Creation Plan
-
-**Task ID:** $1
-**Feature:** [feature name]
-
-**What I'll create:**
-- File: `specs/active/$1/feature-brief.md`
-- Structure: Problem → Users → Requirements → Approach → Next Actions
-
-**Research scope (15 min):**
-- [What I'll search for in codebase]
-- [Patterns I'll look for]
-
-**Brief will include:**
-- Problem statement and target users
-- Core requirements (must-haves only)
-- Quick technical approach
-- 3-5 immediate next actions
-- Success criteria
-
-**Estimated time:** 30 minutes total
-
-Ready to proceed?
-```
-
-**Wait for user approval before proceeding.**
-
-### Phase 3: Execution (After Approval)
-
-**Step 1: Create directory**
-```
-specs/active/$1/
-```
-
-**Step 2: Conduct quick research (15 min)**
-- Search for similar patterns in codebase using `codebase-memory-mcp`
-- Document key findings
-- Note reusable components
-
-**Step 3: Generate feature-brief.md**
-
-Use this structure:
-
-```markdown
-# Feature Brief: [Feature Name]
-
-**Task ID:** $1
-**Created:** [date]
-**Status:** Ready for Development
-
----
-
-## Problem Statement
-
-[What problem does this solve? 2-3 sentences]
-
-## Target Users
-
-[Who will use this? Be specific]
-
-## Core Requirements
-
-### Must Have
-- [ ] [Requirement 1]
-- [ ] [Requirement 2]
-- [ ] [Requirement 3]
-
-### Nice to Have
-- [ ] [Optional 1]
-- [ ] [Optional 2]
-
-## Technical Approach
-
-[High-level approach, 3-5 sentences]
-
-**Patterns to Follow:**
-- [Existing pattern 1 from codebase]
-- [Existing pattern 2 from codebase]
-
-**Key Decisions:**
-- [Decision 1]: [Rationale]
-- [Decision 2]: [Rationale]
-
-## Next Actions
-
-1. [ ] [First concrete step]
-2. [ ] [Second step]
-3. [ ] [Third step]
-
-## Success Criteria
-
-- [ ] [How we know it's done 1]
-- [ ] [How we know it's done 2]
-
-## Open Questions
-
-- [Any unresolved questions]
-
----
-
-*Brief created with SDD Multi-Agent OpenCode*
-```
-
-### Phase 4: Verification
-
-Verify file created and contains: problem statement, 3+ requirements, actionable next steps.
-
----
-
-## Output
-
-```
-✅ Brief created: `specs/active/$1/feature-brief.md`
-
-**Summary:**
-- Problem: [One sentence]
-- Core requirements: [Count] must-haves
-- Next actions: [Count] items
-
-**Next:** Start coding or run `/upgrade $1` for full SDD planning
-```

package/.opencode/commands/evolve.md

@@ -1,87 +0,0 @@
----
-description: Update existing specifications with new discoveries, changes, or refinements made during development
-agent: sdd-planner
----
-
-**Documentation evolution agent:** Update existing specs with new discoveries and changes while preserving context and maintaining changelog entries.
-
-**Skill:** Uses `sdd-evolve` skill for structured spec updates.
-
-**Output:** Updated spec files in `specs/active/$1/`
-
----
-
-## Usage
-
-```
-/evolve $1 $ARGUMENTS
-```
-
-**Examples:**
-- `/evolve user-auth Added password strength validation after security review`
-- `/evolve checkout-flow Discovered need for guest checkout fallback`
-- `/evolve notification-system Changed from polling to WebSocket based on performance testing`
-
----
-
-## Instructions
-
-### Phase 1: Analysis
-
-1. **Find existing specs** in `specs/active/$1/` (check feature-brief.md, spec.md, plan.md, tasks.md)
-2. **Read all related files** to understand current state and context
-3. **Categorize the change**: Discovery/Refinement (Low), Addition/Modification (Medium), Removal/Architecture (High)
-4. **Assess upgrade need**: Multiple major changes → suggest `/upgrade`, simple discovery → continue with `/evolve`
-
-### Phase 2: Planning
-
-Present evolution plan with:
-- Task ID and file to update
-- Change summary, type, and impact level
-- Before/after diff of relevant sections
-- Proposed changelog entry
-- Recommendation (proceed or suggest upgrade)
-
-**Wait for user approval before proceeding.**
-
-### Phase 3: Execution
-
-1. **Update spec file** preserving context, adding changelog, incrementing version, updating date
-2. **Add changelog entry** (feature-brief.md uses "Changelog" table, spec.md uses "Revision History" table)
-3. **Note cross-references** if change affects other documents
-4. **Update status** if spec was marked "Complete"
-
-### Phase 4: Downstream Propagation
-
-Check for stale downstream documents:
-1. **List downstream files** in `specs/active/$1/` — check for `plan.md`, `tasks.md`, `todo-list.md`
-2. **Assess impact** using the change category
-3. **Add staleness marker** to affected files:
-   ```
-   > **[STALE]** — Upstream spec updated on [DATE]. Review needed.
-   > Change: [Brief description] (spec.md v[VERSION])
-   ```
-4. **Report affected files** in the evolution summary output
-
-### Phase 5: Verification
-
-Verify before final output:
-- Spec file updated, changelog added, version incremented
-- Context preserved, cross-references noted
-- Staleness markers added to affected downstream files
-
----
-
-## Output
-
-End response with:
-
-```
-✅ Spec evolved: `specs/active/$1/[file]`
-
-**Change:** [Type] | Impact: [Level] | Version: [old] → [new]
-**Changelog:** | [version] | [date] | [description] | [reason] |
-**Downstream impact:** [List of files marked STALE, or "None"]
-**Cross-references:** [Other files that may need updates]
-**Next steps:** Review spec, update stale downstream docs, or consider `/upgrade` for major changes
-```

package/.opencode/commands/execute-parallel.md

@@ -1,116 +0,0 @@
----
-description: Execute multiple tasks in parallel using async background subagents for DAG-based coordination
-agent: sdd-orchestrator
----
-
-Execute multiple tasks in parallel using async background subagents for coordination.
-
-**Leverages:** Async subagents, subagent tree pattern, DAG-based execution with dependency checks and file conflict detection.
-
----
-
-## Usage
-
-```
-/execute-parallel $1
-/execute-parallel $1 --epic $2
-/execute-parallel $1 --until-finish
-/execute-parallel $1 --resume
-```
-
-**Examples:**
-```
-/execute-parallel blog-platform
-/execute-parallel saas-dashboard --epic epic-002
-/execute-parallel my-project --until-finish
-/execute-parallel my-project --resume
-```
-
----
-
-## Instructions
-
-### Phase 0: Check Context Budget (Before Loading Roadmap)
-
-1. Read `.opencode/rules/context-budget.md` if present
-2. If context is near 80%, use **progressive loading**:
-   - Load only `dag.roots`, `dag.parallelGroups`, `statistics`
-   - Load full task details only for the current batch
-   - Re-read from disk after each batch completes
-3. After each batch, write `execution-checkpoint.json` (compact format)
-4. If context grows too large: stop and ask user to compact or continue with reduced context
-
-### Phase 1: Load and Analyze Roadmap
-
-**Step 0: Resume mode (if `--resume` flag)**
-1. Read `specs/todo-roadmap/$1/execution-checkpoint.json` if it exists
-2. Use `nextReadyTasks` as the starting point; skip tasks already `done` in roadmap.json
-
-**Step 1: Read roadmap (progressive loading for large roadmaps)**
-- For heavy roadmaps (20+ tasks), load only `dag.roots`, `dag.parallelGroups`, `statistics`, and task details for ready tasks
-
-**Step 2: Identify ready tasks**
-Tasks are ready when: Status is "todo", all dependencies have status "done", `canParallelize: true`
-
-**Step 3: Plan execution batches**
-Group tasks based on: Dependency satisfaction, **File conflict detection** (check `sdd.touchedFiles` — overlapping files = separate batches), Estimated effort
-
-**Step 4: Parallelism limits**
-- Max parallel implementers: 3–5 (default: 4). Read from `.sdd/config.json` `settings.maxParallelImplementers`
-
-### Phase 2: Parallel Execution with Async Subagents
-
-**For each parallel batch, spawn background subagents simultaneously using multiple Task tool calls in a single message.**
-
-**Task-to-Subagent Mapping:**
-
-| Task Phase | Subagent | Model |
-|------------|----------|-------|
-| research | sdd-explorer | opencode/deepseek-v4-flash-free |
-| brief/specify/plan/tasks | sdd-planner | opencode/qwen3.6-plus-free |
-| implement | sdd-implementer | opencode/deepseek-v4-flash-free |
-| review | sdd-reviewer | opencode/minimax-m2.5-free |
-| verify | sdd-verifier | opencode/qwen3.6-plus-free |
-
-**Subagent Tree Pattern:**
-Each background `sdd-implementer` automatically spawns `sdd-verifier` as a child subagent after completing its work.
-
-### Phase 3: Progress Tracking
-
-**After each batch completes:**
-1. Collect results from subagent responses
-2. Update roadmap.json statuses: `todo` → `in-progress` → `review` → `done`
-3. Write execution-checkpoint.json
-4. Identify next ready tasks based on completed dependencies
-
-### Phase 4: Completion
-
-**When all tasks done:**
-1. Final roadmap.json update
-2. Generate completion report with execution timeline and verification summary
-
----
-
-## Flags
-
-| Flag | Description |
-|------|-------------|
-| `--epic [id]` | Scope to one epic |
-| `--until-finish` | Loop until done |
-| `--resume` | Resume after error |
-| `--dry-run` | Preview only |
-
----
-
-## Error Handling
-
-**If subagent fails:**
-1. Task marked as `blocked` in roadmap
-2. Error details captured
-3. Dependent tasks remain blocked
-4. Continue with independent tasks
-
-**Recovery:**
-```
-/execute-parallel $1 --resume
-```

package/.opencode/commands/execute-task.md

@@ -1,81 +0,0 @@
----
-description: Execute a specific task from a project roadmap, automatically determining the appropriate SDD command and updating roadmap status
-agent: sdd-orchestrator
----
-
-Execute tasks from project roadmaps by running appropriate SDD commands and tracking progress.
-
-**Supports `--until-finish` flag** for automated sequential execution of all tasks in an epic.
-
----
-
-## Usage
-
-```
-/execute-task $1
-/execute-task $1 --until-finish
-```
-
-**Examples:**
-```
-/execute-task task-001-1
-/execute-task epic-001
-/execute-task epic-001 --until-finish
-```
-
----
-
-## Instructions
-
-### Phase 1: Analysis
-
-1. **Find roadmap:** Look in `specs/todo-roadmap/*/roadmap.json`
-2. **Find task:** Locate task by ID in roadmap
-3. **Validate dependencies:** Ensure all dependencies have status "done"
-4. **Determine SDD command:** Map task phase to command:
-   - `research` → `/research`
-   - `brief` → `/brief`
-   - `specification` → `/specify`
-   - `planning` → `/plan`
-   - `tasks` → `/tasks`
-   - `implementation` → `/implement`
-   - `evolution` → `/evolve`
-
-### Phase 2: Planning
-
-Present execution plan and wait for approval (unless `--until-finish`).
-
-### Phase 3: Execution
-
-1. **Update status:** Set task status to "in-progress" in roadmap.json
-2. **Execute command:** Run the appropriate SDD command
-3. **Link spec:** Update task with linked spec path
-4. **Update status:** Change to "review" (or "done" with `--until-finish`)
-5. **Log execution:** Add entry to execution-log.md
-6. **Check unblocked:** Identify tasks that can now proceed
-
----
-
-## Output
-
-```
-✅ Task executed: $1
-
-**Summary:**
-- Command: `/[command] $1`
-- Output: `specs/active/$1/[file]`
-- Status: review
-- Unblocked: [count] tasks ready
-
-**Next:** Review output or continue with `/execute-task [next-task]`
-```
-
----
-
-## Sequential vs Parallel
-
-| Command | Execution | Best For |
-|---------|-----------|----------|
-| `/execute-task --until-finish` | **Sequential** (one at a time) | Simple projects, debugging, careful review |
-| `/execute-parallel` | **Parallel** (batched via subagents) | Large projects, independent tasks |
-| `/sdd-full-plan --until-finish` | **Parallel** (creates roadmap + orchestrator) | Full project from scratch |

package/.opencode/commands/generate-prd.md

@@ -1,82 +0,0 @@
----
-description: Generate a Product Requirements Document through guided Socratic questioning, creating both comprehensive and AI-optimized versions
----
-
-**Product requirements analyst** - Guide users through strategic questions to create comprehensive, well-structured PRDs. Ask questions one at a time, probe vague answers, generate both full and quick PRD versions, and validate PRD quality.
-
----
-
-## Usage
-
-```
-/generate-prd $1 $ARGUMENTS
-```
-
-**Examples:**
-```
-/generate-prd saas-dashboard
-/generate-prd ecommerce-app Multi-vendor marketplace
-/generate-prd mobile-banking
-```
-
----
-
-## Instructions
-
-### Phase 1: Introduction
-
-**Start the PRD session:**
-
-```
-## PRD Generation Session
-
-I'll help you create a solid Product Requirements Document through a few key questions. By the end, you'll have clear documentation of what to build and why.
-
-**Project:** $1
-
-Let's begin with the first question...
-```
-
-### Phase 2: Strategic Questioning
-
-Ask 5 questions one at a time:
-
-1. **Problem & Goal** - What are we building and why? (Must have both problem AND goal)
-2. **Core Features** - List 3-5 must-have features (Need at least 2 concrete features)
-3. **Tech Stack** - Technical requirements, integrations, constraints (Optional)
-4. **Out of Scope** - What's explicitly NOT in v1? (Need at least 1 exclusion)
-5. **Additional Context** - Compliance, accessibility, deadlines, etc. (Optional)
-
-**Validation:** Probe vague answers, suggest options when stuck, enforce minimum requirements before proceeding.
-
-### Phase 3: PRD Generation
-
-**Verify minimum requirements:** Q1 (problem + goal), Q2 (2+ features), Q4 (1+ exclusion). Ask follow-ups if missing.
-
-**Generate two documents:**
-
-1. **full-prd.md** - Comprehensive PRD with: Executive Summary, Problem Statement, Target Users, Functional/Non-Functional Requirements, Technical Constraints, Out of Scope, Success Metrics, Timeline, Open Questions, Appendix
-
-2. **quick-prd.md** - AI-optimized summary with: Problem, Core Features, Technical Approach, Out of Scope, Success Metrics
-
-### Phase 4: Quality Validation
-
-Assess clarity, completeness, and actionability (0-100% each). Overall status: Ready for Planning or Needs Refinement.
-
----
-
-## Output
-
-```
-✅ PRD generated successfully!
-
-**Files created:**
-- `specs/active/$1/full-prd.md` - Comprehensive PRD
-- `specs/active/$1/quick-prd.md` - AI-optimized summary
-
-**Quality:** Clarity [X]%, Completeness [X]%, Actionability [X]%, Overall [X]%
-
-**Summary:** Problem [one sentence], [N] core features, [N] exclusions
-
-**Next steps:** Review PRD, refine with `/refine $1`, create tasks with `/tasks $1`, or start brief with `/brief $1`
-```

package/.opencode/commands/generate-rules.md

@@ -1,67 +0,0 @@
----
-description: Automatically generate comprehensive coding rules based on technology stack detection and codebase analysis
----
-
-**Coding standards architect** - Analyze project, detect technology stack, analyze codebase patterns, and generate comprehensive rule files including language-specific, framework-specific, and project-specific rules with 10X dev principles (DRY, KISS, SOLID).
-
----
-
-## Usage
-
-```
-/generate-rules
-/generate-rules --language $1 --framework $2
-/generate-rules --analyze-codebase
-/generate-rules --update-existing
-```
-
----
-
-## Instructions
-
-### Phase 1: Analysis
-
-**Technology Detection:** Check package files (package.json, requirements.txt, Cargo.toml, go.mod, etc.)
-
-**Framework Detection:** Analyze dependencies (React, Vue, Next.js, Django, Flask, etc.)
-
-**Codebase Analysis:** Use `codebase-memory-mcp` to review code organization, naming conventions, import patterns, error handling, testing patterns
-
-**Existing Rules:** Check `.opencode/rules/` for files to merge or replace
-
-### Phase 2: Planning
-
-**Present detection results:** Detected stack, codebase analysis, and proposed rule files.
-
-**Options:** Generate all new rules, generate only missing, or customize selection. Wait for user approval.
-
-### Phase 3: Execution
-
-**Generate rule files in order:**
-
-1. **coding-principles.md** (always include) - DRY, KISS, SOLID, code quality, performance mindset
-2. **Language-specific rules** (e.g., typescript-rules.md) - Type safety, naming conventions, best practices
-3. **Framework-specific rules** (e.g., react-rules.md) - Component design, state management, performance, patterns
-4. **testing-rules.md** - Test structure, coverage, mocking
-5. **security-rules.md** - Input validation, authentication, secrets
-6. **performance-rules.md** - General optimization, loading, runtime
-7. **project-specific.md** - Detected patterns, file organization, import conventions, custom rules
-
----
-
-## Output
-
-```
-✅ Rules generated successfully!
-
-**Created files:**
-- `.opencode/rules/coding-principles.md` - Core 10X principles
-- `.opencode/rules/[language]-rules.md` - [Language] best practices
-- `.opencode/rules/[framework]-rules.md` - [Framework] patterns
-- `.opencode/rules/testing-rules.md` - Testing practices
-- `.opencode/rules/security-rules.md` - Security guidelines
-- `.opencode/rules/performance-rules.md` - Performance optimization
-- `.opencode/rules/project-specific.md` - Project conventions
-
-**Total:** [N] rule files. Rules are now active for all AI interactions.
-```