@tudeorangbiasa/sdd-multiagent-opencode 0.1.3 → 0.2.0

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.
-```

package/.opencode/commands/grill-me.md

@@ -1,99 +0,0 @@
----
-description: Interview the user relentlessly about a plan or design until reaching shared understanding. Use before /brief to clarify vague ideas, or to stress-test existing plans
----
-
-Interview the user relentlessly about every aspect of their plan until you reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one.
-
----
-
-## Usage
-
-```
-/grill-me $ARGUMENTS
-```
-
-**Examples:**
-```
-/grill-me I want to add authentication to my app
-/grill-me We need a notification system
-/grill-me I'm thinking of rebuilding the checkout flow
-```
-
----
-
-## Protocol
-
-### Rules
-
-1. **Ask ONE question at a time.** Never batch multiple questions.
-2. **For each question, provide your recommended answer.** Make it easy for the user to just say "yes" if they agree.
-3. **If a question can be answered by exploring the codebase, explore the codebase instead.** Use `codebase-memory-mcp` to find existing patterns before asking.
-4. **Track the decision tree mentally.** Walk down each branch until resolved, then move to the next.
-5. **Stop when all branches are resolved** and you have enough clarity to proceed.
-
-### Question Categories
-
-Ask questions from these categories in order, skipping ones already answered:
-
-1. **Problem & Goal** — What are we building and why?
-2. **Users** — Who will use this? What do they need?
-3. **Scope** — What's in v1? What's explicitly out?
-4. **Technical** — Existing patterns? New tech? Constraints?
-5. **Success** — How do we know it's done? What metrics matter?
-
-### Question Format
-
-```
-**Question N:** [Your question]
-
-**My recommendation:** [Your suggested answer with brief rationale]
-
-Does this work, or would you change it?
-```
-
-### Codebase Exploration
-
-Before asking about technical decisions, check the codebase first:
-
-```
-Let me check how your codebase currently handles [topic]...
-
-[Use codebase-memory-mcp to explore]
-
-Found: [existing pattern at path/to/file]
-
-Given this, I'd recommend [recommendation]. Does that align with your thinking?
-```
-
-### Completion
-
-When all branches are resolved, summarize the shared understanding:
-
-```
-## Shared Understanding
-
-Here's what we've agreed on:
-
-1. **Problem:** [summary]
-2. **Users:** [who]
-3. **Scope:** [in v1 / out of v1]
-4. **Technical approach:** [direction]
-5. **Success criteria:** [metrics]
-
-**Ready to create a brief?** Run `/brief [task-id] [description]` and I'll generate the feature brief document.
-```
-
----
-
-## When to Use
-
-- User has a vague idea and needs to clarify it before planning
-- User has a plan but wants to stress-test it for holes
-- User mentions "grill me" or "interrogate me"
-- After `/brief` if the brief feels incomplete and needs deeper exploration
-
-## When NOT to Use
-
-- User already has a clear, detailed spec → skip to `/specify` or `/plan`
-- User wants quick planning → use `/brief` directly
-- User is in a hurry → batch questions instead

package/.opencode/commands/implement.md

@@ -1,149 +0,0 @@
----
-description: Execute the planned implementation with systematic todo-list execution and continuous progress tracking
-agent: sdd-implementer
-subtask: true
----
-
-**You are an implementation agent.** Execute the planned implementation systematically:
-- Read all planning documents (plan.md, tasks.md, spec.md)
-- Generate a todo-list if one doesn't exist
-- Execute todos in order, respecting dependencies
-- Mark each item complete as you finish it
-- Document blockers and deviations
-- Write production-quality code
-
----
-
-## Prerequisites
-
-- `plan.md` file in `specs/active/$1/`
-
-## Usage
-
-```
-/implement $1
-/implement $1 --tdd
-```
-
-**Flags:**
-| Flag | Description |
-|------|-------------|
-| `--tdd` | Test-Driven Development: write failing test first, then implement to pass |
-
----
-
-## Instructions
-
-### Phase 1: Analysis
-
-Read planning documents in order:
-1. `specs/active/$1/plan.md` (REQUIRED)
-2. `specs/active/$1/spec.md` (if exists)
-3. `specs/active/$1/tasks.md` (if exists)
-4. `specs/active/$1/research.md` (if exists)
-5. `specs/active/$1/feature-brief.md` (if exists)
-
-**If plan.md doesn't exist:** Suggest running `/plan $1` or `/brief $1` first.
-
-Check for existing `todo-list.md` in the task directory.
-
-### Phase 2: Planning
-
-Present implementation plan before starting:
-- What will be built
-- Execution order/phases
-- Files to create/modify
-- Patterns to follow
-- Todo-list preview (5-10 key items)
-
-**Wait for user approval before proceeding.**
-
-### Phase 3: Execution
-
-**Create directory if it doesn't exist:** `specs/active/$1/`
-
-**Create or update todo-list.md** with task phases, individual todos with dependencies, and progress log table.
-
-**Execute todos systematically:**
-1. Read entire todo-list before starting
-2. Execute in order, respecting dependencies
-3. Mark completion: `- [ ]` → `- [x]` after each item
-4. Document blockers - never skip silently
-5. Update progress log
-
-**Show progress** after every 3-5 completed items.
-
-### Phase 3b: TDD Mode (if --tdd flag)
-
-When `--tdd` is specified, follow this loop for each todo:
-
-**Step 1: Define expected behavior**
-- Read the todo description
-- Write a failing test that captures the expected behavior
-- Test should fail with clear error message
-
-**Step 2: Write minimum code to pass**
-- Implement only what's needed to make the test pass
-- Do NOT add extra features or polish
-- Keep it minimal
-
-**Step 3: Run test**
-- Execute the specific test
-- Verify it passes
-
-**Step 4: Refactor (optional)**
-- Only after test passes, refactor if needed
-- Ensure tests still pass after refactor
-
-**TDD todo format in todo-list.md:**
-```markdown
-- [ ] [Task name] --tdd
-  - Test file: `tests/[feature].test.ts`
-  - Test describes: [expected behavior]
-```
-
-**Rules for TDD:**
-- Never write implementation code before the failing test
-- Test must fail before implementation starts
-- Only implement enough to make test pass
-- Refactor AFTER tests pass, not before
-
-### Phase 4: Verification
-
-Spawn `sdd-verifier` subagent to independently validate:
-- [ ] All todos complete or blocked
-- [ ] Code follows project patterns
-- [ ] No linter errors
-- [ ] Tests pass (if applicable)
-- [ ] Spec requirements met
-
----
-
-## Output
-
-**End response with:**
-
-```
-✅ Implementation complete: $1
-
-**Summary:**
-- Completed: [X]/[Y] tasks
-- Blocked: [N] items (if any)
-- Files created: [count]
-- Files modified: [count]
-
-**What was built:**
-- [Feature/component 1]
-- [Feature/component 2]
-
-**Blocked items (if any):**
-- [Item]: [Reason]
-
-**Next steps:**
-- Run tests: `[test command]`
-- Review changes in IDE
-- Update specs: `/evolve $1 [discovery]`
-
-**Files:**
-- Todo list: `specs/active/$1/todo-list.md`
-```

package/.opencode/commands/init-sdd.md

@@ -1,141 +0,0 @@
----
-description: Install or refresh SDD workflow into current project
-agent: sdd-orchestrator
----
-
-Install Spec-Driven Development workflow (commands, agents, skills, templates) into a project that already has base rules.
-
----
-
-## Usage
-
-```
-/init-sdd
-```
-
----
-
-## Prerequisites
-
-This command expects `opencode-agent-rules` to be installed first. Check for:
-- `AGENTS.md` in project root
-- `.opencode/rules/context-budget.md` exists
-
-If missing, output:
-```
-⚠️ Base rules not found.
-
-Please install opencode-agent-rules first:
-1. Clone or copy base rules to project
-2. Run /init-rules
-3. Then run /init-sdd
-```
-
----
-
-## Behavior
-
-### Phase 1: Verify Prerequisites
-
-1. Check if `AGENTS.md` exists
-2. Check if `.opencode/rules/context-budget.md` exists
-3. If either missing, abort and show install instructions
-
-### Phase 2: Create Directory Structure
-
-Create if missing:
-```
-.sdd/
-├── config.json
-├── templates/
-specs/
-├── active/
-├── backlog/
-├── completed/
-└── todo-roadmap/
-```
-
-### Phase 3: Install SDD Files
-
-Copy from this repo:
-- `.opencode/agents/*` → `.opencode/agents/`
-- `.opencode/commands/*` → `.opencode/commands/`
-- `.opencode/skills/*` → `.opencode/skills/`
-- `.sdd/config.json` → `.sdd/config.json`
-- `.sdd/templates/*` → `.sdd/templates/`
-
-Note: Do NOT overwrite existing `.opencode/` directories if project has custom commands.
-
-### Phase 4: Create Project Profile
-
-Create `.sdd/project-profile.json` with this structure:
-
-```json
-{
-  "projectState": "unknown",
-  "initialized": "DATE",
-  "stack": {
-    "framework": null,
-    "language": null,
-    "packageManager": null,
-    "styling": null
-  },
-  "commands": {
-    "dev": null,
-    "build": null,
-    "test": null,
-    "lint": null
-  },
-  "design": {
-    "sourceOfTruth": null,
-    "hasDesignMd": false,
-    "hasProductMd": false,
-    "componentRoots": []
-  },
-  "skillRouting": {
-    "uiDefault": "existing-design-system",
-    "visualVerification": "sdd-verifier",
-    "codeReview": "sdd-reviewer"
-  }
-}
-```
-
-### Phase 5: Merge opencode.json
-
-If project has `opencode.json`, merge these sections:
-- `agents` definitions
-- `permission` rules
-
-If project doesn't have `opencode.json`, create from this repo's template.
-
----
-
-## Output
-
-```
-✅ SDD workflow installed
-
-Files installed:
-- .opencode/agents/ (6 agents)
-- .opencode/commands/ (16 commands)
-- .opencode/skills/ (5 skills)
-- .sdd/config.json
-- .sdd/templates/ (8 templates)
-- .sdd/project-profile.json
-
-⚠️ Next steps:
-1. Update project-profile.json with your stack
-2. Run /brief <feature> to start
-
-Available commands:
-/brief /research /specify /plan /tasks /implement /audit
-```
-
----
-
-## Re-run Behavior
-
-If running again (project already has SDD):
-- Report: "SDD already installed"
-- Offer to refresh: "Run with --force to refresh all files"
-- Update `initialized` date in project-profile.json

package/.opencode/commands/plan.md

@@ -1,96 +0,0 @@
----
-description: Generate a detailed technical implementation plan from specifications, including architecture decisions, tech stack, and design patterns
-agent: sdd-planner
----
-
-**You are a technical architect agent.** Transform requirements into a detailed technical implementation strategy without writing implementation code.
-
-**Skill:** Uses `sdd-planning` skill.
-
-**Output:** `specs/active/$1/plan.md`
-
----
-
-## Prerequisites
-
-- Must have existing `spec.md` OR `feature-brief.md` in task directory
-
-## Usage
-
-```
-/plan $1
-```
-
-**Examples:**
-```
-/plan user-auth-system
-/plan checkout-flow
-/plan notification-system
-```
-
----
-
-## Instructions
-
-### Phase 1: Analysis
-
-1. **Read specifications** in order:
-   - `specs/active/$1/spec.md` (preferred)
-   - `specs/active/$1/feature-brief.md` (alternative)
-   - `specs/active/$1/research.md` (if exists)
-
-   **If no spec found:** Prompt user to run `/specify` or `/brief` first.
-
-2. **Extract requirements:** Functional and non-functional requirements, constraints, user stories, acceptance criteria
-
-3. **Analyze codebase:** Use `codebase-memory-mcp` to understand existing patterns, tech stack, conventions, integration points
-
-4. **Identify decisions needed:** Architecture style, data storage, API design, integrations, security
-
-### Phase 2: Plan Preview
-
-**Present plan structure and wait for approval:**
-
-```
-## Technical Plan Preview
-
-**Task ID:** $1
-**Architecture:** [High-level approach]
-**Tech stack:** [Key technologies with rationale]
-**Components:** [Main components and purposes]
-**Data model:** [Key entities]
-**API design:** [Key endpoints]
-
-Ready to generate the full plan?
-```
-
-### Phase 3: Generate Plan
-
-**Create directory if it doesn't exist:** `specs/active/$1/`
-
-**Generate `plan.md`** with: System Architecture (with Mermaid diagram), Technology Stack, Component Design, Data Model, API Contracts, Security Considerations, Performance Strategy, Implementation Phases, Risk Assessment, Open Questions, Next Steps.
-
-**Verify:** Read the file back to confirm it was created correctly.
-
----
-
-## Output
-
-**End your response with:**
-
-```
-✅ Plan created: `specs/active/$1/plan.md`
-
-**Architecture:** [Brief description]
-**Components:** [Count] main components
-**Phases:** [Count] implementation phases
-
-**Key decisions:**
-- [Decision 1]: [Choice]
-- [Decision 2]: [Choice]
-
-**Next steps:**
-- Review the technical plan
-- Run `/tasks $1` to generate implementation tasks
-- Or run `/implement $1` if tasks are clear
-```