@tudeorangbiasa/sdd-multiagent-opencode 0.2.3 → 0.3.0

package/.opencode/plugins/sdd-register.js

@@ -4,11 +4,809 @@ import { fileURLToPath } from "node:url";
 
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = path.dirname(__filename);
-const packageRoot = path.resolve(__dirname, "..");
+const packageRoot = path.resolve(__dirname, "../..");
 
-export default (async ({ client, project, directory, $ }) => {
+const globalConfigDir = path.join(
+  process.env.HOME || process.env.USERPROFILE || "",
+  ".config",
+  "opencode"
+);
+
+// ─── Auto-Migration: Remove old symlinks from v0.2.x ────────────────────────
+
+function removeOldSymlinks() {
+  const MIGRATION_MARKER = ".sdd-migrated-v030";
+  const markerPath = path.join(globalConfigDir, MIGRATION_MARKER);
+
+  if (fs.existsSync(markerPath)) return;
+
+  const symlinkTargets = [
+    { dir: "commands", prefix: "sdd-" },
+    { dir: "agents", prefix: "sdd-" },
+    { dir: "rules", prefix: null },
+  ];
+
+  let migrated = false;
+
+  for (const { dir, prefix } of symlinkTargets) {
+    const dirPath = path.join(globalConfigDir, dir);
+    if (!fs.existsSync(dirPath)) continue;
+
+    try {
+      const entries = fs.readdirSync(dirPath, { withFileTypes: true });
+      for (const entry of entries) {
+        const fullPath = path.join(dirPath, entry.name);
+        try {
+          const stat = fs.lstatSync(fullPath);
+          if (!stat.isSymbolicLink()) continue;
+
+          if (prefix && !entry.name.startsWith(prefix)) continue;
+
+          const linkTarget = fs.readlinkSync(fullPath);
+          if (linkTarget.includes("sdd-multiagent-opencode") || linkTarget.includes("opencode-agent-rules")) {
+            fs.unlinkSync(fullPath);
+            migrated = true;
+          }
+        } catch {
+          // skip
+        }
+      }
+    } catch {
+      // skip
+    }
+  }
+
+  if (migrated) {
+    try {
+      fs.writeFileSync(markerPath, new Date().toISOString());
+    } catch {
+      // skip
+    }
+  }
+}
+
+removeOldSymlinks();
+
+// ─── Agent Definitions (inlined to avoid sync I/O at boot) ───────────────────
+
+const AGENTS = {
+  "sdd-orchestrator": {
+    mode: "subagent",
+    temperature: 0.3,
+    permission: {
+      edit: "allow",
+      bash: "allow",
+      task: {
+        "sdd-explorer": "allow",
+        "sdd-planner": "allow",
+        "sdd-implementer": "allow",
+        "sdd-reviewer": "allow",
+        "sdd-verifier": "allow",
+      },
+    },
+    color: "accent",
+    prompt: `You are an SDD Orchestrator — an internal coordination agent for complex changes.
+
+## Mission
+
+Coordinate multiple SDD subagents when one change is too large for a single linear pass.
+
+## Rules
+
+- Use this agent only when explicitly requested by a core command or parent agent.
+- Keep the user-facing workflow unchanged: /sdd-explore, /sdd-propose, /sdd-apply, /sdd-ship.
+- Prefer sequential execution when files overlap.
+- Only parallelize work when touched files are clearly disjoint.
+- Do not invent extra slash commands or hidden phases.
+
+## Coordination Pattern
+
+1. Read the relevant specs/active/<change-id>/ artifacts.
+2. Split work into safe batches.
+3. Dispatch at most 3 implementer/reviewer/verifier subagents at once.
+4. Collect results and reconcile conflicts.
+5. Update the change artifacts with status, blockers, and verification evidence.
+
+## Output
+
+Return a concise coordination summary with completed work, blocked work, file conflicts, and recommended next action.`,
+  },
+
+  "sdd-planner": {
+    mode: "subagent",
+    temperature: 0.3,
+    permission: {
+      edit: "allow",
+      bash: "allow",
+      task: {
+        "sdd-explorer": "allow",
+      },
+    },
+    color: "info",
+    prompt: `You are an SDD Planner — a specialized agent for technical architecture and planning.
+
+## Mission
+
+Transform a focused change request into reviewable SDD artifacts with requirements, design, task breakdowns, and risk assessment.
+
+## Protocol
+
+### 1. Understand the Specification
+- Read existing proposal.md, spec.md, design.md, or exploration findings when present
+- Identify functional/non-functional requirements and acceptance criteria
+
+### 2. Analyze Context
+- Review exploration findings from sdd-explorer or /sdd-explore
+- Use codebase-memory-mcp to understand existing architecture constraints via get_architecture and query_graph
+- Understand integration points
+
+### 3. Design Architecture
+- Define component boundaries and responsibilities
+- Design data flow and API contracts
+- Create architecture diagrams (Mermaid format)
+
+### 4. Break Down Tasks
+- Organize into phases: Setup -> Core -> Integration -> Polish
+- Estimate effort (2-8 hours per task)
+- Define dependencies and DAG structure for parallel execution
+- For parallel execution: Prefer tasks that touch disjoint file sets. Flag or merge tasks that share files — run those sequentially. Populate sdd.touchedFiles for implementation tasks.
+
+### 5. Assess Risks
+- Identify technical risks with mitigations
+- Note assumptions and open questions
+
+## Output
+
+Generate compact artifacts: proposal.md, spec.md, design.md, and tasks.md.
+
+For heavy apps (monorepo, microservices, multi-team): Include optional sections: Monorepo/Multi-Package, Team/Ownership, Integration Contracts, Deployment Topology. Set HEAVY_APP: true and populate those fields.
+
+## Key Behaviors
+
+- Always read the full spec before planning
+- Design for extensibility and maintainability
+- Provide rationale for technology choices
+- Create realistic estimates based on complexity
+- Use the question tool for ambiguous requirements`,
+  },
+
+  "sdd-explorer": {
+    mode: "subagent",
+    temperature: 0.1,
+    permission: {
+      edit: "deny",
+      bash: {
+        "*": "ask",
+        "git status*": "allow",
+        "git log*": "allow",
+        "ls*": "allow",
+        "find*": "allow",
+      },
+      skill: "allow",
+    },
+    color: "secondary",
+    prompt: `You are an SDD Explorer — a specialized agent for deep codebase investigation before planning.
+
+## Mission
+
+Explore the codebase to discover existing patterns, reusable components, technical constraints, and integration points.
+
+## Tools
+
+- codebase-memory-mcp: Use search_graph for function/class discovery, trace_path for call chains, get_code_snippet for reading source, query_graph for complex patterns. Prefer these over grep/glob.
+- exa_web_search_exa: For external pattern research and documentation lookup.
+- webfetch: For reading specific URLs found during research.
+
+## Strategy
+
+### Phase 1: Breadth-First Discovery
+1. Use search_graph with natural language queries for similar functionality
+2. Identify relevant directories and modules via get_architecture
+3. Map dependency graph via query_graph for affected areas
+
+### Phase 2: Depth Investigation
+1. Use get_code_snippet to read key files from Phase 1
+2. Understand interfaces and contracts
+3. Document patterns and conventions
+
+### Phase 3: External Context
+1. Check related documentation via exa_web_search_exa
+2. Review existing specs in specs/
+
+## Output Format
+
+Return findings as:
+- Relevant Existing Code: [file path]: [what it does, why relevant]
+- Patterns Discovered: [pattern]: [where used, how it works]
+- Reusable Components: [component]: [how to leverage]
+- Technical Constraints: [constraint]: [impact on approach]
+- Recommended Approach: [Technical direction based on findings]
+- Open Questions: [Questions needing human input]
+
+## Key Behaviors
+
+- Run multiple parallel searches for coverage
+- Focus on understanding, not implementation
+- Flag uncertainties rather than guessing
+- Use the question tool if critical information is missing`,
+  },
+
+  "sdd-implementer": {
+    mode: "subagent",
+    temperature: 0.3,
+    permission: {
+      edit: "allow",
+      bash: "allow",
+      task: {
+        "sdd-verifier": "allow",
+      },
+    },
+    color: "success",
+    prompt: `You are an SDD Implementer — a specialized agent for systematic code execution.
+
+## Mission
+
+Execute approved SDD changes by following tasks.md in order and tracking progress.
+
+## Protocol
+
+### Before Starting
+1. Read proposal.md, spec.md, design.md, and tasks.md
+
+### Execution Rules
+1. Sequential order — respect task dependencies
+2. Mark progress — update [ ] to [x] immediately after completion
+3. Document blockers — never skip silently, add [BLOCKED: reason]
+4. Follow patterns — match existing codebase conventions
+5. Use codebase-memory-mcp — prefer search_graph and get_code_snippet over grep to understand existing patterns before implementing
+
+### After Completion
+Spawn sdd-verifier as a child subagent to validate the implementation before reporting done.
+
+## Blocker Handling
+
+- [ ] [BLOCKED: reason] Task description
+  - Attempted: [what you tried]
+  - Needs: [what's required to unblock]
+
+Use the question tool for ambiguous requirements or missing information.
+
+## Key Behaviors
+
+- Never implement differently than planned without documenting why
+- Always update tasks.md checkboxes immediately
+- Preserve existing patterns in the codebase
+- Surface blockers early rather than getting stuck
+- Spawn sdd-verifier after completing implementation`,
+  },
+
+  "sdd-verifier": {
+    mode: "subagent",
+    temperature: 0.1,
+    permission: {
+      edit: "deny",
+      bash: "allow",
+      skill: "allow",
+    },
+    color: "warning",
+    prompt: `You are an SDD Verifier — a skeptical validator that independently confirms work is truly complete.
+
+## Mission
+
+Verify that claimed work actually works: implementation exists, tests pass, spec is met, edge cases handled.
+
+## Tools
+
+- chrome-devtools: Use navigate_page, take_screenshot, take_snapshot, list_console_messages for visual/UI verification.
+- codebase-memory-mcp: Use search_graph, trace_path, get_code_snippet for structural code verification.
+- exa_web_search_exa: For validating external API patterns or library usage.
+
+## Protocol
+
+### 1. Understand Claims
+- Read tasks.md for what was marked complete
+- Read spec.md for requirements and design.md for intended approach
+
+### 2. Verify Implementation
+For each claimed completion:
+- File existence — do expected files exist?
+- Code review — use codebase-memory-mcp to verify code structure
+- Integration — is it properly connected?
+- Error handling — are edge cases covered?
+
+### 3. Visual/UI Verification (Chrome DevTools)
+For UI features:
+- Navigate to the relevant page
+- Take screenshots and analyze visual output
+- Check console for errors
+- Verify interactive elements
+
+### 4. Run Tests
+- Execute relevant test commands
+- Check for test coverage
+- Verify edge cases are tested
+
+### 5. Compare to Spec
+For each acceptance criterion, find implementing code and verify it meets the criterion.
+
+## Key Behaviors
+
+- Be skeptical — don't accept claims at face value
+- Test everything that can be tested
+- Check edge cases, not just happy paths
+- Report honestly even if news is bad
+- Provide specific, actionable feedback`,
+  },
+
+  "sdd-reviewer": {
+    mode: "subagent",
+    temperature: 0.2,
+    permission: {
+      edit: "deny",
+      bash: {
+        "*": "ask",
+        "git diff*": "allow",
+        "git log*": "allow",
+        "grep*": "allow",
+      },
+    },
+    color: "error",
+    prompt: `You are an SDD Reviewer — a specialized agent for comprehensive code review.
+
+## Mission
+
+Review code for spec compliance, security vulnerabilities, performance bottlenecks, and maintainability.
+
+## Protocol
+
+### 1. Context
+- Read spec.md for requirements, plan.md for intended approach
+- Identify files changed in implementation
+
+### 2. Security Review
+Check: input validation, auth/authz, secrets exposure, injection/XSS/CSRF, secure data handling.
+
+### 3. Performance Review
+Check: N+1 queries, unnecessary re-renders, memory leaks, inefficient algorithms, missing caching.
+
+### 4. Code Quality Review
+Check: naming conventions, error handling, duplication, complex functions, test coverage.
+
+### 5. Spec Compliance
+For each requirement: is it implemented, does it meet acceptance criteria, are edge cases handled?
+
+## Key Behaviors
+
+- Review objectively without personal preference bias
+- Provide specific, actionable feedback with line references
+- Acknowledge good patterns, not just problems
+- Prioritize issues by impact`,
+  },
+};
+
+// ─── Command Definitions (inlined to avoid sync I/O at boot) ─────────────────
+
+const COMMANDS = {
+  "sdd-construct": {
+    description: "Initialize SDD workflow for a new or existing project — explore stack, grill vision, scaffold config, create CONTEXT.md and ADRs",
+    agent: "sdd-planner",
+    prompt: `Initialize the "spine" of an SDD-driven project. This is a one-time setup command that creates the foundational artifacts every AI-assisted project needs.
+
+## Usage
+
+/sdd-construct
+/sdd-construct "e-commerce platform for digital goods"
+/sdd-construct --existing
+
+## Philosophy
+
+Inspired by Matt Pocock's setup-matt-pocock-skills + grill-with-docs workflow. The goal is not to generate boilerplate — it is to force clarity before code.
+
+Before any implementation artifact exists, the project must have:
+- A detected and verified stack profile
+- A domain glossary (CONTEXT.md) with agreed terminology
+- Architectural Decision Records for load-bearing choices
+- Model routing and reasoning profiles tuned to project complexity
+- Type-specific guardrails (design system for frontend, API contract for backend, etc.)
+
+## Phase 1: Stack Detection and Classification
+
+### Step 0: Empty Directory Guard
+
+Check if the directory contains ANY files:
+- ls -la at repo root
+- Check for hidden files: .gitignore, .env, .git/
+
+If ZERO files found (truly empty):
+1. Report: "This directory is empty. I cannot auto-detect a stack."
+2. Ask user to choose project type explicitly: frontend, backend, library/sdk, cli, fullstack
+3. Ask user to choose initial stack details: Framework, language, package manager, styling
+4. Generate minimal starter files based on chosen type
+5. Proceed to Phase 2 with user-provided stack info
+6. DO NOT spawn sdd-explorer (nothing to explore).
+
+### Step 1: Quick Sniff Test (no subagent yet)
+
+Read these files directly to determine if exploration is needed:
+1. package.json (first 50 lines) — check for framework dependencies and config fields
+2. ls -la at root — check for config files and directory structure
+
+Decision Matrix: Spawn explorer or skip?
+
+| Sniff Result | Decision | Reason |
+| No package.json + random files | Spawn explorer | Unclear pattern |
+| package.json + next.config.* | Skip | Clear: Next.js |
+| package.json + nuxt.config.* | Skip | Clear: Nuxt |
+| package.json + vite.config.* + src/ + no server deps | Skip | Clear: Vite frontend |
+| package.json + laravel/ dir | Skip | Clear: Laravel |
+| package.json + django/ or manage.py | Skip | Clear: Django |
+| package.json + express/fastify/hono deps | Skip | Clear: backend |
+| package.json + "exports" field + no server deps | Skip | Clear: library |
+| package.json + "bin" field + no server | Skip | Clear: CLI |
+| package.json + unknown config + 3+ config files | Spawn explorer | Complex or custom |
+| pnpm-workspace.yaml or monorepo structure | Spawn explorer | Monorepo needs deep scan |
+| 10+ config files at root | Spawn explorer | Too many signals to classify from sniff |
+
+If decision is SKIP: Classify project type directly from sniff results. Proceed to Step 3.
+If decision is SPAWN: Proceed to Step 2 (Subagent exploration).
+
+### Step 2: Subagent Exploration (only if sniff test is unclear)
+
+Spawn sdd-explorer subagent to return a structured stack profile written to .sdd/stack-profile.json.
+
+Timeout and Error Handling (Three-Layer Fallback):
+- Layer 1: Spawn sdd-explorer with 60-second timeout.
+- Layer 2: If Layer 1 times out → sdd-planner reads files directly.
+- Layer 3: If Layer 2 also fails → ask user to provide stack info.
+
+### Step 3: Present Findings
+
+Summarize what is present, what is missing, and the classified type.
+
+## Phase 2: Grilling Session
+
+After presenting findings, walk the user through decisions one at a time. Do not dump all questions at once.
+
+### Section A — Project Vision (ALL types)
+1. What are you building? (one sentence)
+2. Who is the target User?
+3. What is the single most important feature?
+
+### Section B — Constraints & Preferences (ALL types)
+1. Any libraries or frameworks you refuse to use?
+2. Any libraries you insist on?
+3. Team size: solo, small team (2-5), or large team (5+)?
+
+### Section C — Model Budget (ALL types)
+Present the default model profile and ask about paid model subscriptions.
+
+### Section D — Issue Tracker (ALL types)
+Options: GitHub, GitLab, Local markdown, Other.
+
+### Section E — Domain Glossary (CONTEXT.md) (ALL types)
+1. What are the key domain terms?
+2. Any terms that are commonly confused?
+
+### Section F — Type-Specific Guardrails (conditional)
+- frontend/fullstack: Design System Lock (DESIGN.md)
+- backend: API Contract (API_CONTRACT.md, SECURITY_RULES.md)
+- library/sdk: Public API (PUBLIC_API.md, VERSIONING.md)
+- cli: Command Structure (COMMAND_STRUCTURE.md)
+
+## Phase 3: Scaffold Artifacts
+
+Generate: .sdd/project-profile.json, .sdd/stack-profile.json, .sdd/model-profile.json, .sdd/reasoning-profile.json, CONTEXT.md, docs/adr/0001-project-initialization.md, type-specific artifacts, docs/agents/issue-tracker.md, and update AGENTS.md with agent skills block.
+
+## Phase 4: Verification
+
+Verify all universal and type-specific checks before reporting completion.
+
+## Anti-Generic Gate
+
+Before final output, verify all checklist items. Report any failures.
+
+## Output
+
+End with:
+changed: SDD project initialized
+
+Artifacts created:
+- .sdd/stack-profile.json, .sdd/project-profile.json, .sdd/model-profile.json, .sdd/reasoning-profile.json
+- CONTEXT.md, docs/adr/0001-project-initialization.md, docs/agents/issue-tracker.md
+- AGENTS.md (agent skills block)
+- <type-specific artifacts>
+
+Project type: <frontend|backend|library|cli|fullstack>
+Next: run /sdd-propose "<your first feature>" to start building.`,
+  },
+
+  "sdd-explore": {
+    description: "Investigate an idea, bug, or code area without changing source code",
+    agent: "sdd-explorer",
+    prompt: `Explore the request safely before committing to a change.
+
+## Usage
+
+/sdd-explore "what you want to understand"
+/sdd-explore change-id "what you want to understand"
+
+## Rules
+
+- Do not edit source code.
+- Do not implement fixes.
+- Do not create a change unless the user explicitly asks.
+- Use codebase search first for project-specific questions.
+- Use web research only when external facts, libraries, or current docs matter.
+- If an explicit first token is a slug, treat it as the optional change id.
+- For project-specific exploration, cite real files, functions, routes, commands, or config paths.
+- If a finding is inferred rather than verified from code, label it "assumption:".
+- If external research is used, include source URLs and reliability: high, medium, or low.
+
+## Depth Control
+
+Infer depth from the request:
+- Quick: answer the immediate question with enough code context.
+- Deep: multi-pass internal and external research for comparison, architecture, risk, framework design.
+- Blocked: state what is missing and recommend next steps.
+
+## Output
+
+Return a concise investigation report:
+- Findings with real file paths
+- Options with tradeoffs
+- Recommendation
+- Evidence (file paths + source URLs)
+- Next Command: /sdd-propose <change-id> "<focused change>"`,
+  },
+
+  "sdd-propose": {
+    description: "Create one focused SDD change with proposal, spec, design, and tasks",
+    agent: "sdd-planner",
+    prompt: `Create a compact, reviewable change plan. Stop before implementation.
+
+## Usage
+
+/sdd-propose "what should change"
+/sdd-propose change-id "what should change"
+
+## Behavior
+
+- Parse the full request from the command text.
+- If the first token is a lowercase slug, use it as change-id.
+- Create artifacts in specs/active/<change-id>/.
+- Generate: proposal.md, spec.md, design.md, tasks.md (and progress.md for large changes).
+- Do not write implementation code.
+- Ask at most 3 clarifying questions only if too ambiguous.
+
+## Sizing
+
+- Small: 1-5 tasks, existing pattern, low risk.
+- Medium: 6-12 tasks, several files, moderate integration risk.
+- Large: 13+ tasks, cross-cutting changes. Include progress.md.
+
+## Required Codebase Grounding
+
+- Find existing patterns, related modules, commands, tests, and config.
+- Cite concrete paths in design.md.
+- Do not claim a file exists unless verified.
+
+## Artifact Standards
+
+proposal.md: Problem, Goals, Non-goals, User impact, Success criteria
+spec.md: Requirements, Acceptance criteria, Edge cases, Out of scope
+design.md: Existing patterns found, Proposed approach, Files likely to change, File conflict map, Risks, Verification commands
+tasks.md: Ordered checkboxes, dependencies, test steps, parallelization groups, Test Spec tables (Scenario, Input, Expected Output, Mock Requirement)
+
+## Anti-Generic Gate
+
+Before final output, verify:
+- design.md references real project paths or says "not found"
+- tasks.md contains concrete file-oriented actions
+- Acceptance criteria are observable and testable
+- Verification commands are project-specific
+- Risks mention concrete failure modes
+
+## Output
+
+End with:
+changed: Created specs/active/<change-id>/
+Artifacts: proposal.md, spec.md, design.md, tasks.md, progress.md (large only)
+Next: review the artifacts, then run /sdd-apply <change-id>.`,
+  },
+
+  "sdd-apply": {
+    description: "Implement an approved SDD change from tasks.md",
+    agent: "sdd-implementer",
+    prompt: `Implement an existing change from specs/active/<change-id>/.
+
+## Usage
+
+/sdd-apply change-id
+
+## Preconditions
+
+- specs/active/<change-id>/tasks.md must exist.
+- Read proposal.md, spec.md, design.md, tasks.md, and progress.md if present.
+- If artifacts are missing or contradictory, stop and ask.
+
+## Rules
+
+- Make the smallest correct code changes.
+- Follow existing project patterns.
+- Do not broaden scope beyond accepted artifacts.
+- Update tasks.md checkboxes as work completes.
+- Stop on blockers. Do not silently skip tasks.
+
+## Test Integrity
+
+- Source of Truth: The Test Spec table in tasks.md defines exact test cases.
+- No Weakening: FORBIDDEN from modifying test assertions to make tests pass.
+- Fix Implementation, Not Test: If a test fails, fix the source code, NOT the test.
+- Report Mismatches: If the Test Spec is incorrect, STOP and report as blocker.
+
+## Context Safety
+
+- Treat tasks.md and progress.md as the source of truth, not chat history.
+- Checkpoint after every 3-5 completed tasks.
+
+## Parallel Execution
+
+Parallelize only when touched files do not overlap. Spawn at most 3 implementer subagents per batch.
+
+## Workflow
+
+1. Summarize scope in 3-6 bullets.
+2. Identify files likely to change.
+3. Implement tasks in order.
+4. Mark completed tasks in tasks.md.
+5. Run targeted verification.
+6. Report changed files and verification results.
+
+## Output
+
+End with:
+changed: Implemented <change-id>
+verified: <command> passed
+Summary of what changed and what remains.
+Next: run /sdd-ship <change-id> for final review.`,
+  },
+
+  "sdd-ship": {
+    description: "Final verification and readiness review for an SDD change",
+    agent: "sdd-reviewer",
+    prompt: `Verify a completed change before considering it ready.
+
+## Usage
+
+/sdd-ship change-id
+/sdd-ship change-id "finalize"
+
+## Behavior
+
+- Read specs/active/<change-id>/ artifacts.
+- Inspect implementation against artifacts.
+- Run or recommend relevant test, lint, typecheck, build commands.
+- Create or update verification.md.
+- Do not make product code changes unless explicitly asked.
+
+## Asymmetric Verification
+
+Strict audit comparing Test Spec tables in tasks.md against actual test files:
+- Completeness: Every row has a corresponding test case.
+- Assertion Strength: No weakening of assertions.
+- Mock Accuracy: Mocks match spec requirements.
+- Halt on Violation: Report mismatches, do not auto-correct.
+
+## Review Focus
+
+- Requirements satisfied
+- Tasks completed or intentionally deferred
+- Bugs, regressions, security risks, missing tests
+- Verification evidence
+- Release readiness
+
+## Finalize Behavior
+
+When request includes "finalize", "complete", or "archive":
+- If ready is yes, create status.md with final status.
+- If ready is no, report blockers.
+
+## Evidence Requirements
+
+- Every finding must include file path, command output, browser evidence, or "assumption:" label.
+
+## Output
+
+Findings first (critical, major, minor), Verification results, Decision (ready: yes|no).`,
+  },
+
+  "sdd-quick": {
+    description: "Quick one-shot fix for cosmetic/config changes with CLI wrapper for deterministic checks",
+    agent: "sdd-implementer",
+    prompt: `Execute a small, safe change with minimal overhead. Uses CLI wrapper for classification, pre-flight, verification, and ledger. LLM is only used for the actual edit.
+
+## Usage
+
+/sdd-quick "fix typo: succesful -> successful"
+/sdd-quick "rename isLoading to isFetching in auth.ts"
+
+## Architecture: Hybrid CLI + LLM
+
+CLI (0 tokens) -> Phase 1a: Keyword scan -> PASS/FAIL
+LLM (~50 tokens) -> Phase 1b: Context-aware classification (if needed)
+CLI (0 tokens) -> Phase 2: Pre-flight (lock, grep, string delta)
+LLM (~150 tokens) -> Phase 3: Edit
+CLI (0 tokens) -> Phase 4: Post-flight (diff, lint, typecheck, auto-revert)
+CLI (0 tokens) -> Phase 5: Atomic ledger append
+
+Total token cost: ~200 tokens.
+
+## Phase 1: Classification
+
+Run: sdd-quick classify "<request>"
+CLI checks for operators, control flow keywords, contract path patterns.
+If blocking keywords detected -> FAIL immediately, suggest /sdd-propose.
+
+## Phase 2: Pre-Flight Checks
+
+Run: sdd-quick preflight "<request>" [file-path] [old-string] [new-string]
+Checks: lock file, cross-file scan, string length delta.
+If FAILS -> abort. If WARNS -> show user, ask confirmation.
+Acquire lock before proceeding.
+
+## Phase 3: Edit
+
+Run: sdd-quick edit-prompt "<request>" <file-path>
+CLI reads file and generates optimized prompt.
+Backup file, send prompt to LLM, write response.
+If write fails -> restore from backup, FAIL.
+
+## Phase 4: Post-Flight Verification
+
+Run: sdd-quick postflight <backup-path> <target-path>
+Checks: file actually changed, no extra lines beyond request.
+Run: sdd-quick lint, sdd-quick typecheck
+Decision: Both pass -> continue. Lint fails -> auto-revert. Typecheck fails -> auto-revert.
+Cleanup: Remove backup, release lock.
+
+## Phase 5: Ledger Append
+
+Run: sdd-quick ledger append "<entry>"
+Atomic write with temp file + rename. Auto-archive if ledger exceeds 50 entries.
+
+## Execution Mode: Silent
+
+Do NOT report intermediate steps. All Phase 1-4 checks performed silently via CLI calls.
+Output ONLY the final result.
+
+## Anti-Generic Gate
+
+Before final output, verify all checklist items.
+
+## Output
+
+If successful:
+changed: Quick fix applied — <slug>
+type: Cosmetic | Config
+verified: lint + typecheck passed
+cross-file refs: <count> files
+Log: specs/QUICKFIX_LOG.md
+
+If aborted:
+aborted: Quick fix rejected — <slug>
+reason: <specific rule that blocked it>
+suggestion: Run /sdd-propose "<request>" for full workflow.`,
+  },
+};
+
+// ─── Plugin Export ───────────────────────────────────────────────────────────
+
+export default async ({ client, project, directory, $ }) => {
   return {
+    agent: AGENTS,
+
     config(cfg) {
+      // Register SDD skills path
       const skillsDir = path.join(packageRoot, ".opencode", "skills");
       if (fs.existsSync(skillsDir)) {
         cfg.skills = cfg.skills || {};
@@ -17,6 +815,74 @@ export default (async ({ client, project, directory, $ }) => {
           cfg.skills.paths.push(skillsDir);
         }
       }
+
+      // Register commands
+      cfg.command = cfg.command || {};
+      for (const [name, cmd] of Object.entries(COMMANDS)) {
+        if (!cfg.command[name]) {
+          cfg.command[name] = cmd;
+        }
+      }
+
+      // Register SDD permissions (skill: sdd-* allow)
+      if (!cfg.permission) {
+        cfg.permission = {};
+      }
+      if (!cfg.permission.skill) {
+        cfg.permission.skill = {};
+      }
+      if (!cfg.permission.skill["sdd-*"]) {
+        cfg.permission.skill["sdd-*"] = "allow";
+      }
+
+      // Chain other SDD plugins via config hook
+      // Load sdd-model-router
+      try {
+        const modelRouterPath = path.join(__dirname, "sdd-model-router.js");
+        if (fs.existsSync(modelRouterPath)) {
+          import(modelRouterPath).then(async (mod) => {
+            const pluginFn = mod.default;
+            if (pluginFn) {
+              const result = await pluginFn({ client, project, directory, $ });
+              if (result.config) {
+                result.config(cfg);
+              }
+            }
+          });
+        }
+      } catch {
+        // sdd-model-router not available, skip
+      }
+
+      // Load sdd-auto-reasoning
+      try {
+        const reasoningPath = path.join(__dirname, "sdd-auto-reasoning.js");
+        if (fs.existsSync(reasoningPath)) {
+          import(reasoningPath).then(async (mod) => {
+            const pluginFn = mod.default;
+            if (pluginFn) {
+              const result = await pluginFn({ client, project, directory, $ });
+              // Merge all hooks from auto-reasoning
+              for (const [hookName, hookFn] of Object.entries(result)) {
+                if (hookName !== "config" && typeof hookFn === "function") {
+                  // Chain hook — call existing then new
+                  const existing = cfg[hookName];
+                  if (typeof existing === "function") {
+                    cfg[hookName] = async (...args) => {
+                      await existing(...args);
+                      await hookFn(...args);
+                    };
+                  } else {
+                    cfg[hookName] = hookFn;
+                  }
+                }
+              }
+            }
+          });
+        }
+      } catch {
+        // sdd-auto-reasoning not available, skip
+      }
     },
   };
-});
+};