@tudeorangbiasa/sdd-multiagent-opencode 0.1.3 → 0.2.0

package/.opencode/commands/refine.md

@@ -1,115 +0,0 @@
----
-description: Refine existing prompts, briefs, or specifications through continued discussion and iteration
----
-
-**Refinement facilitator** - Help users iterate on existing documentation through conversational exploration, making targeted improvements.
-
----
-
-## Usage
-
-```
-/refine $1
-```
-
-**Examples:**
-```
-/refine user-auth
-/refine checkout-flow
-/refine notification-system
-```
-
----
-
-## Instructions
-
-### Phase 1: Analysis (Readonly)
-
-**Step 1: Find refinement targets**
-
-Search for:
-1. `specs/active/$1/feature-brief.md`
-2. `specs/active/$1/spec.md`
-3. `specs/active/$1/plan.md`
-4. `specs/active/$1/tasks.md`
-
-**Step 2: Present what's available**
-
-```
-## Refinement Targets Found
-
-**Task:** $1
-
-**Available documents:**
-| # | Document | Last Updated | Size |
-|---|----------|--------------|------|
-| 1 | feature-brief.md | [date] | [lines] |
-| 2 | spec.md | [date] | [lines] |
-| 3 | plan.md | [date] | [lines] |
-
-**What would you like to refine?**
-1. Feature brief - Requirements and approach
-2. Specification - User stories and acceptance criteria
-3. Technical plan - Architecture and design
-4. Something specific - Tell me what
-```
-
-### Phase 2: Exploration (Conversation)
-
-**Start the refinement conversation** by summarizing the current state and asking what to refine.
-
-Conduct conversational refinement:
-- Ask follow-up questions
-- Track refinement requests
-- Present proposed changes before applying
-
-### Phase 3: Planning (Show Changes)
-
-**Present proposed changes before applying** with before/after diffs, change types (ADD/MODIFY/REMOVE/CLARIFY), and proposed changelog entry.
-
-**Wait for user approval before proceeding.**
-
-### Phase 4: Execution (After Approval)
-
-**Step 1: Apply changes** - Update the document with all approved changes, change labels, updated version number, updated timestamp
-
-**Step 2: Add changelog entry**
-
-**Step 3: Verify changes** - Read the file back to confirm updates applied
-
-### Phase 5: Completion
-
-**CHECKPOINT: Refinement Complete (REQUIRED)**
-
-Before final output, verify:
-- [ ] All requested changes applied
-- [ ] Original context preserved
-- [ ] Changelog updated
-- [ ] Version incremented
-- [ ] File verified
-
----
-
-## Output
-
-```
-✅ Refinement complete: `specs/active/$1/[file]`
-
-**Changes applied:**
-- [ADD] [Count] new items
-- [MODIFY] [Count] existing items
-- [REMOVE] [Count] items
-- [CLARIFY] [Count] items
-
-**Version:** [old] → [new]
-
-**Key changes:**
-1. [Change 1 summary]
-2. [Change 2 summary]
-
-**Next steps:**
-- Review the updated document
-- Make more refinements: `/refine $1`
-- Update related docs if needed
-- Proceed with implementation: `/implement $1`
-```

package/.opencode/commands/research.md

@@ -1,194 +0,0 @@
----
-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

@@ -1,91 +0,0 @@
----
-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

@@ -1,124 +0,0 @@
----
-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

@@ -1,110 +0,0 @@
----
-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
-```