@tudeorangbiasa/sdd-multiagent-opencode 0.1.0

package/.opencode/commands/research.md

@@ -0,0 +1,194 @@
+---
+description: Investigate existing patterns and gather context before specification. Supports --deep for multi-pass web research
+agent: sdd-explorer
+---
+
+Research and document findings without making changes to the codebase.
+
+**Skill:** Uses `sdd-research` skill for structured investigation.
+
+**Output:** `specs/active/$1/research.md`
+
+---
+
+## Usage
+
+```
+/research $1 $ARGUMENTS
+/research $1 $ARGUMENTS --deep
+```
+
+**Flags:**
+- `--deep` — Multi-pass web investigation with source verification, documentation deep-dives, real-world validation, and confidence assessment.
+
+**Examples:**
+```
+/research user-auth JWT vs session-based authentication patterns
+/research payment-system Stripe integration patterns in existing codebase
+/research caching Redis vs in-memory caching for our use case
+/research database-engine Best database for our use case --deep
+/research auth-provider Compare Auth0 vs Clerk vs Supabase Auth --deep
+```
+
+---
+
+## Instructions
+
+### Phase 1: Analysis (Readonly)
+
+**Step 1: Parse the research request**
+- Extract task-id: `$1`
+- Extract research topic: `$ARGUMENTS`
+- Identify key questions to answer
+
+**Step 2: Clarify research scope**
+
+Ask if any of these are unclear:
+- Should we focus on internal patterns or external solutions?
+- Are there specific technologies to consider or avoid?
+- What constraints exist (performance, cost, team expertise)?
+- What's the primary goal: understand existing code or explore new approaches?
+
+### Phase 2: Planning (Create Plan)
+
+**Present research plan before starting:**
+
+```
+## Research Plan
+
+**Task ID:** $1
+**Topic:** [research topic]
+
+**Research Questions:**
+1. [Key question 1]
+2. [Key question 2]
+3. [Key question 3]
+
+**Internal Research (Codebase):**
+- Search directories: [list]
+- Patterns to find: [list]
+- Similar features to study: [list]
+
+**External Research:**
+- Technologies to evaluate: [list]
+- Best practices to document: [list]
+
+**Output:**
+- File: `specs/active/$1/research.md`
+- Structure: Executive Summary → Codebase Analysis → External Options → Recommendations
+
+**Estimated time:** 60 minutes
+
+Ready to proceed?
+```
+
+**Wait for user approval before proceeding.**
+
+### Phase 3: Execution (After Approval)
+
+**Step 1: Create directory structure**
+```
+specs/active/$1/
+└── research.md
+```
+
+**Step 2: Conduct internal research**
+
+Search the codebase using `codebase-memory-mcp`:
+- `search_graph` for similar feature implementations
+- `get_architecture` for patterns and conventions
+- `get_code_snippet` for reusable utilities and components
+- `query_graph` for architectural decisions
+
+**For each finding, document:**
+```markdown
+### [Pattern/Feature Name]
+
+**Location:** `path/to/file.ts`
+
+**How it works:**
+[Brief explanation]
+
+**Code example:**
+```[language]
+[Relevant code snippet]
+```
+
+**Reusability:** [How this applies to our task]
+```
+
+**Step 3: Conduct external research**
+
+Use `exa_web_search_exa` for external research.
+
+**Standard mode** — For each option/technology:
+```markdown
+### [Option Name]
+
+**What it is:** [Brief description]
+
+**Pros:**
+- [Advantage 1]
+- [Advantage 2]
+
+**Cons:**
+- [Disadvantage 1]
+- [Disadvantage 2]
+
+**Fit for our use case:** [High/Medium/Low] - [Why]
+```
+
+**Deep mode** (`--deep` flag) — Multi-pass investigation:
+1. **Pass 1 — Landscape scan:** Use `exa_web_search_exa` to survey the solution space, identify top 3-5 candidates
+2. **Pass 2 — Documentation deep-dive:** Use `webfetch` to read official docs, API references, pricing pages
+3. **Pass 3 — Real-world validation:** Search for production reviews, benchmarks, comparisons, known issues
+4. **Pass 4 — Integration feasibility:** Search for integration guides with the project's detected stack
+
+For each finding, record the source URL and reliability rating.
+
+**Step 4: Generate research.md**
+
+Use the structure from the original spec-kit research template.
+
+### Phase 4: Verification
+
+**CHECKPOINT: Research Complete (REQUIRED)**
+
+Before final output, verify:
+- [ ] File created at `specs/active/$1/research.md`
+- [ ] Codebase patterns documented with examples
+- [ ] Multiple options presented with pros/cons
+- [ ] Comparison matrix included
+- [ ] Recommendations provided with rationale
+- [ ] Open questions listed
+
+---
+
+## Output
+
+**Your response MUST end with:**
+
+```
+✅ Research complete: `specs/active/$1/research.md`
+
+**Mode:** Standard | Deep
+**Key Findings:**
+- [Finding 1]
+- [Finding 2]
+- [Finding 3]
+
+**Recommendation:** [Primary recommendation]
+**Confidence:** [High/Medium/Low] (deep research only)
+
+**Codebase patterns found:** [Count] reusable patterns
+**Options evaluated:** [Count] approaches compared
+**Sources consulted:** [Count] (deep research only)
+
+**Next steps:**
+- Review the research document
+- Discuss recommendations with team if needed
+- Run `/specify $1` to define requirements
+- Or run `/plan $1` if requirements are clear
+
+**Open questions:** [Count] items need input before proceeding
+```

package/.opencode/commands/sdd-full-plan.md

@@ -0,0 +1,91 @@
+---
+description: Create a comprehensive project roadmap from A to Z with kanban-style task organization, epic hierarchy, and DAG-based parallel execution
+agent: sdd-orchestrator
+---
+
+**You are a project roadmap architect.** Create complete project plans with epic-level organization, task hierarchy, and kanban board structure.
+
+**Supports `--until-finish` flag** for automated execution of the entire project after roadmap creation.
+
+---
+
+## Usage
+
+```
+/sdd-full-plan $1 $ARGUMENTS
+```
+
+**Examples:**
+```
+/sdd-full-plan blog-platform Full-featured blog with CMS and analytics
+/sdd-full-plan ecommerce-app Multi-vendor marketplace --until-finish
+```
+
+### The `--until-finish` Flag
+
+When provided, automatically executes all tasks after roadmap creation:
+- Creates roadmap (Phase 1-3)
+- Executes ALL tasks in dependency order
+- Stops on error and reports issue
+
+---
+
+## Instructions
+
+### Phase 1: Analysis
+
+1. **Parse project request** - Extract project-id: `$1` and description: `$ARGUMENTS`
+2. **Gather requirements** - Ask about goal, users, tech stack, timeline, team size, must-haves, nice-to-haves
+3. **Assess complexity** - Determine level (Simple/Medium/Complex/Enterprise) and recommended SDD approach
+
+### Phase 2: Planning
+
+**Present roadmap preview** with epic structure, complexity, estimated duration, and SDD approach. Wait for approval.
+
+**Ask execution mode:**
+- **Option A:** One-by-one processing (interactive, step-by-step)
+- **Option B:** Immediate execution (generate all at once)
+- **Option C:** Phased creation (recommended for enterprise: 8+ epics, 40+ tasks)
+
+Wait for execution mode selection before proceeding.
+
+### Phase 3: Execution
+
+**Create directory structure:**
+```
+specs/todo-roadmap/$1/
+├── roadmap.json
+├── roadmap.md
+├── tasks/
+└── execution-log.md
+```
+
+**Generate roadmap.json** with: Project metadata, Kanban columns, Tasks/epics with dependencies and DAG structure, Statistics.
+
+**Generate task JSON files** (`tasks/[task-id].json`) with: Task metadata, Dependencies, SDD command mappings, `sdd.touchedFiles` for implementation tasks.
+
+### Phase 4: Verification
+
+Before final output, verify:
+- roadmap.json is valid JSON
+- roadmap.md is readable
+- All tasks have SDD command mappings
+- Dependencies are logical (no cycles)
+- execution-log.md created
+
+### Phase 5: Automated Execution (Only with `--until-finish`)
+
+If `--until-finish` flag provided:
+1. **Pre-Execution Summary** — Show roadmap summary and execution queue
+2. **Delegate to `sdd-orchestrator`** for parallel DAG execution
+3. **Orchestrator identifies ready tasks** from `dag.roots` and `dag.parallelGroups`
+4. **Orchestrator spawns** `sdd-implementer` subagents for each ready task in parallel
+5. **Each implementer spawns** `sdd-verifier` as child subagent
+6. **Batch completion** — collect results, update roadmap, identify next ready tasks
+7. **Repeat** until all tasks complete or a blocker is hit
+
+---
+
+## Output
+
+End with roadmap summary including epics and tasks count, estimated duration and complexity, files created, epic breakdown, and execution commands.

package/.opencode/commands/specify.md

@@ -0,0 +1,124 @@
+---
+description: Transform vague feature ideas into detailed, testable requirements with user stories and acceptance criteria
+agent: sdd-planner
+---
+
+You are a requirements analyst agent. Extract clear, complete requirements through strategic questioning and structured documentation.
+
+**Skill:** Uses `sdd-planning` skill.
+
+**Output:** `specs/active/$1/spec.md`
+
+---
+
+## Usage
+
+```
+/specify $1 $ARGUMENTS
+```
+
+**Examples:**
+- `/specify user-auth User authentication with login, logout, and password reset`
+- `/specify checkout-flow One-page checkout with guest option and multiple payment methods`
+- `/specify notification-system Real-time notifications with email and push support`
+
+---
+
+## Instructions
+
+### Phase 1: Analysis
+
+1. **Parse the feature request** - Extract task-id: `$1` and feature description: `$ARGUMENTS`
+2. **Check for existing research** - Look for `specs/active/$1/research.md` and incorporate findings
+3. **Strategic questioning** - Ask questions in three categories:
+
+**Category 1: Problem & Users**
+- What specific problem does this solve?
+- Who are the primary users?
+- What's their current pain point?
+
+**Category 2: Core Requirements**
+- What are the 3-5 core features this MUST have?
+- Which would you build first if you could only pick one?
+- What's explicitly OUT of scope?
+
+**Category 3: Constraints & Success**
+- Any technical constraints?
+- How will you know this is successful?
+- Any deadline or timeline considerations?
+
+**Validation:** Problem clearly stated, at least 3 core features, at least 1 exclusion defined.
+
+### Phase 2: Planning
+
+**Present spec structure before creating:**
+
+```
+## Specification Plan
+
+**Task ID:** $1
+**Feature:** [feature name]
+
+**What I understood:**
+- Problem: [summary]
+- Users: [who]
+- Core features: [list]
+
+**Specification structure:**
+1. Problem Statement
+2. User Personas
+3. Functional Requirements (with user stories)
+4. Non-Functional Requirements
+5. Out of Scope
+6. Edge Cases & Error Handling
+7. Success Metrics
+
+**User stories I'll create:** [count]
+**Edge cases to cover:** [count]
+
+Does this capture what you want? Ready to create the spec?
+```
+
+**Wait for user approval before proceeding.**
+
+### Phase 3: Execution
+
+**Create directory if it doesn't exist:** `specs/active/$1/`
+
+**Generate `specs/active/$1/spec.md`** with the full specification structure including Problem Statement, User Personas, Functional Requirements with user stories and acceptance criteria, Non-Functional Requirements, Out of Scope, Edge Cases & Error Handling, Success Metrics, Open Questions, and Revision History.
+
+### Phase 4: Verification
+
+**Before final output, verify:**
+- File created at `specs/active/$1/spec.md`
+- Problem statement is clear
+- At least 3 user stories with acceptance criteria
+- Non-functional requirements defined
+- Out of scope items listed
+- Edge cases documented
+- Success metrics defined
+
+---
+
+## Output
+
+**Your response MUST end with:**
+
+```
+✅ Specification created: `specs/active/$1/spec.md`
+
+**Summary:**
+- Problem: [One sentence summary]
+- User stories: [Count]
+- Requirements: [Count] functional, [Count] non-functional
+- Edge cases: [Count]
+
+**Key features:**
+1. [Feature 1]
+2. [Feature 2]
+3. [Feature 3]
+
+**Next steps:**
+- Review the specification with stakeholders
+- Run `/plan $1` to create technical implementation plan
+```

package/.opencode/commands/tasks.md

@@ -0,0 +1,110 @@
+---
+description: Break down a technical plan into actionable, prioritized development tasks with effort estimates and dependencies
+agent: sdd-planner
+---
+
+You are a project planning agent that transforms technical plans into actionable, prioritized task lists.
+
+**Output:** `specs/active/$1/tasks.md`
+
+---
+
+## Prerequisites
+
+- Must have existing `plan.md` file in task directory
+
+## Usage
+
+```
+/tasks $1
+/tasks $1 --tdd
+```
+
+**Flags:**
+| Flag | Description |
+|------|-------------|
+| `--tdd` | Generate TDD tasks: each task includes test-first approach with failing test → implementation → pass |
+
+---
+
+## Instructions
+
+### Step 1: Read Planning Documents
+
+Read in order:
+1. `specs/active/$1/plan.md` (REQUIRED)
+2. `specs/active/$1/spec.md` (if exists)
+3. `specs/active/$1/research.md` (if exists)
+
+**If plan.md doesn't exist:** Suggest running `/plan $1` or `/brief $1` first.
+
+### Step 2: Analyze & Preview
+
+Present a preview:
+
+```
+## Task Breakdown Preview
+
+**Task ID:** $1
+**Phases:** [Count] phases, [X] total tasks
+**Estimated effort:** [Total hours/days]
+**Key dependencies:** [List critical blockers]
+
+Ready to generate the full task breakdown?
+```
+
+**Wait for user approval before proceeding.**
+
+### Step 3: Generate tasks.md
+
+**Create directory if it doesn't exist:** `specs/active/$1/`
+
+**Generate `tasks.md`** with: Summary table, Phases with tasks (each with Description, Acceptance Criteria, Effort, Priority, Dependencies), Quick Reference Checklist, Next Steps.
+
+**If --tdd flag:** Each task should include TDD-specific structure:
+
+```markdown
+### Task X: [Title] --tdd
+
+**Description:** [What to build]
+
+**TDD Steps:**
+1. **Write failing test** - Define expected behavior in test
+2. **Implement minimum code** - Only what's needed to pass
+3. **Verify test passes** - Run focused test
+4. **Refactor** - Clean up after pass (optional)
+
+**Test file:** `tests/[feature].test.ts`
+**Acceptance Criteria:**
+- [ ] Test fails before implementation
+- [ ] Implementation makes test pass
+- [ ] No extra features added
+
+**Effort:** [X] hours
+**Priority:** [high/medium/low]
+**Dependencies:** [list]
+```
+
+### Verification
+
+Before final output, verify:
+- [ ] File created at `specs/active/$1/tasks.md`
+- [ ] All tasks have acceptance criteria and effort estimates
+- [ ] Dependencies are clearly marked
+- [ ] No task exceeds 2 days
+
+---
+
+## Output
+
+```
+✅ Tasks created: `specs/active/$1/tasks.md`
+
+**Summary:**
+- Total tasks: [Count]
+- Phases: [Count]
+- Estimated effort: [Total]
+
+**Ready to implement:**
+- Run `/implement $1` to start execution
+```

package/.opencode/commands/upgrade.md

@@ -0,0 +1,107 @@
+---
+description: Escalate from lightweight SDD Quick Planning (Brief) to comprehensive SDD Full Planning when complexity is discovered during development
+---
+
+**Planning escalation agent** - Expand lightweight briefs into comprehensive SDD documentation when complexity warrants it. Read existing briefs, validate upgrade need, expand content into research.md, spec.md, plan.md, and tasks.md while preserving all existing decisions and context.
+
+---
+
+## Usage
+
+```
+/upgrade $1 $ARGUMENTS
+```
+
+**Examples:**
+```
+/upgrade checkout-flow Discovered PCI compliance requirements
+/upgrade user-auth Multiple third-party integrations needed
+/upgrade notification-system Architecture more complex than expected
+```
+
+---
+
+## Instructions
+
+### Phase 1: Analysis (Readonly)
+
+**Step 1: Find existing brief**
+
+Look for: `specs/active/$1/feature-brief.md`
+
+**If brief not found:** Suggest creating a brief first or starting with full SDD.
+
+**Step 2: Read and analyze the brief** - Extract problem statement, target users, core requirements, technical approach, next actions, discoveries
+
+**Step 3: Walk through Escalation Decision Tree**
+
+Present validation questions about complexity, risk, and uncertainty. Score and recommend.
+
+### Phase 2: Planning (Create Plan)
+
+**If upgrade is confirmed, present expansion plan:**
+
+```
+## Upgrade Plan
+
+**Task:** $1
+**Existing:** `specs/active/$1/feature-brief.md`
+
+**Documents to create:**
+1. **research.md** - Codebase analysis, external options, recommendations
+2. **spec.md** - User stories with acceptance criteria, non-functional requirements, edge cases
+3. **plan.md** - Full architecture, component design, API contracts
+4. **tasks.md** - Phased breakdown, effort estimates, dependencies
+
+**Content mapping:**
+| Brief Section | Expands To |
+|---------------|------------|
+| Problem Statement | spec.md: Problem & Users |
+| Core Requirements | spec.md: Functional Requirements |
+| Technical Approach | plan.md: Architecture |
+| Next Actions | tasks.md: Task Breakdown |
+
+Ready to begin the upgrade?
+```
+
+**Wait for user approval before proceeding.**
+
+### Phase 3: Execution (After Approval)
+
+**Step 1: Create research.md** - Expand from brief's technical approach
+**Step 2: Create spec.md** - Expand requirements from brief
+**Step 3: Create plan.md** - Expand technical approach
+**Step 4: Create tasks.md** - Expand next actions
+**Step 5: Update the original brief** - Add upgrade notice
+
+### Phase 4: Verification
+
+**CHECKPOINT: Upgrade Complete (REQUIRED)**
+
+Before final output, verify:
+- [ ] research.md created with brief context
+- [ ] spec.md created with expanded requirements
+- [ ] plan.md created with expanded architecture
+- [ ] tasks.md created with expanded task breakdown
+- [ ] feature-brief.md marked as upgraded
+- [ ] All brief content preserved in new documents
+
+---
+
+## Output
+
+```
+✅ Upgrade complete: $1
+
+**Upgraded from:** SDD Quick Brief → SDD Full
+
+**Documents created:**
+- `specs/active/$1/research.md` - Research & context
+- `specs/active/$1/spec.md` - Full specification
+- `specs/active/$1/plan.md` - Technical architecture
+- `specs/active/$1/tasks.md` - Implementation breakdown
+
+**Content preserved:** Problem statement, requirements, technical approach, discoveries/changelog
+
+**Next steps:** Review expanded documents, fill gaps if needed, run `/implement $1` when ready
+```

package/.opencode/skills/sdd-audit/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: sdd-audit
+description: Structured compliance checks for SDD workflows. Activates when auditing implementations against specifications, reviewing code quality, or validating security and performance. Use with /audit command.
+---
+
+## What I do
+
+- Compare implementation against specifications systematically
+- Identify security vulnerabilities, performance issues, and code quality problems
+- Generate structured review comments with severity levels
+- Propose fixes after thorough investigation
+
+## When to use me
+
+Use this skill when:
+- Running `/audit` command
+- Need to verify implementation matches spec
+- Pre-merge quality gate
+- Investigating specific issues or bugs
+
+## Audit Protocol
+
+### Phase 1: Load Specifications
+1. Read `spec.md` for requirements
+2. Read `plan.md` for intended approach
+3. Read `tasks.md` and `todo-list.md` for completed work
+
+### Phase 2: Analyze Implementation
+1. Identify completed tasks
+2. Read actual implementation files using `codebase-memory-mcp`
+3. Compare code against spec/plan requirements
+
+### Phase 3: Security Review Checklist
+- [ ] Input validation on all user inputs
+- [ ] Authentication and authorization checks
+- [ ] No secrets or credentials in code
+- [ ] SQL injection protection (parameterized queries)
+- [ ] XSS protection (output encoding)
+- [ ] CSRF protection for state-changing operations
+- [ ] Secure data handling (encryption, hashing)
+
+### Phase 4: Performance Review Checklist
+- [ ] No N+1 query patterns
+- [ ] Efficient algorithms (avoid O(n²) where O(n) possible)
+- [ ] Proper caching strategy
+- [ ] No memory leaks (event listeners, subscriptions)
+- [ ] Lazy loading where appropriate
+
+### Phase 5: Generate Findings
+
+**Severity Levels:**
+- 🔴 **CRITICAL**: Broken, security risk, blocker
+- 🟠 **MAJOR**: Logic error, missing feature
+- 🟡 **MINOR**: Style, optimization, cleanup
+- ⚪ **OUTDATED**: Code correct, spec wrong
+
+## Output Template
+
+Generate audit report with: Executive Summary, Quick Stats, Review Comments table, Detailed Findings, Recommended Actions.