diff --git a/README.md b/README.md index a11a981f..369b2836 100644 --- a/README.md +++ b/README.md @@ -15,14 +15,14 @@ 👻 **Kiro-inspired** — Similar Spec-Driven, AI-DLC style as Kiro IDE, so existing Kiro specs remain compatible and portable. -Stop losing 70% of development time to meetings, documentation ceremonies, and scattered context. cc-sdd brings structured **AI-DLC** (AI-Driven Development Lifecycle) and **Spec-Driven Development** to Claude Code, Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Qwen Code, and Windsurf. +Stop losing 70% of development time to meetings, documentation ceremonies, and scattered context. cc-sdd brings structured **AI-DLC** (AI-Driven Development Lifecycle) and **Spec-Driven Development** to Claude Code, Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Qwen Code, OpenCode, and Windsurf. ### What you get: - ✅ **Spec-first guarantees** — Approve requirements/design upfront, then AI implements exactly as specified - ✅ **Parallel execution ready** — Tasks decomposed for concurrent implementation with dependency tracking - ✅ **Team-aligned templates** — Customize once, all agents output docs that fit your approval process - ✅ **Project Memory** — AI remembers your architecture, patterns, and standards across sessions -- ✅ **7 agents, unified workflow** — Same spec-driven process across Claude, Cursor, Gemini, Codex, Copilot, Qwen, Windsurf +- ✅ **8 agents, unified workflow** — Same spec-driven process across Claude, Cursor, Gemini, Codex, Copilot, Qwen, OpenCode, Windsurf - ✅ **Hours instead of weeks** — Feature planning goes from days to hours with AI-assisted specs ## 🚀 Quick Start @@ -35,7 +35,7 @@ npx cc-sdd@latest --claude --lang en ## Claude Code # ✅ That's it! Now run: /kiro:spec-init ``` -**Installation takes 30 seconds.** Supports 7 agents (Claude (Commands / Subagents), Cursor, Gemini, Codex, Copilot, Qwen, Windsurf) × 13 languages. +**Installation takes 30 seconds.** Supports 8 agents (Claude (Commands / Subagents), Cursor, Gemini, Codex, Copilot, Qwen, OpenCode, Windsurf) × 13 languages. 📖 **Next steps:** [All installation options](#%EF%B8%8F-advanced-installation) | [Command Reference](docs/guides/command-reference.md) | [Spec-Driven Guide](docs/guides/spec-driven.md) @@ -90,6 +90,7 @@ npx cc-sdd@latest --gemini # Gemini CLI npx cc-sdd@latest --codex # Codex CLI npx cc-sdd@latest --copilot # GitHub Copilot npx cc-sdd@latest --qwen # Qwen Code +npx cc-sdd@latest --opencode # OpenCode npx cc-sdd@latest --windsurf # Windsurf IDE ``` diff --git a/docs/guides/ja/migration-guide.md b/docs/guides/ja/migration-guide.md index 7da8177e..1cb6dc7d 100644 --- a/docs/guides/ja/migration-guide.md +++ b/docs/guides/ja/migration-guide.md @@ -11,7 +11,7 @@ v1系（特に1.1.5）とv2.0.0は、**AI-DLCのコマンドや基本思想は | 目的 | 推奨アクション | | --- | --- | | 既存の1.x系ワークフローを維持したい | `npx cc-sdd@1.1.5` を明示的に指定し、旧バージョンのCLIを継続利用する。エージェント固有のプロンプトを直接編集する従来のスタイルを維持できるが、利用可能なコマンドは旧来の8つに限られる。 | -| 7種類のエージェントで共通のテンプレートや、調査（Research）と設計（Design）の分離といった新機能を利用したい | `npx cc-sdd@latest`（v2.0.0相当）を再インストールし、`.kiro/settings/templates/*` と `rules/` のみをカスタマイズする。これにより、`validate-*` コマンド群を含む全11コマンドが利用可能になる。 | +| 8種類のエージェントで共通のテンプレートや、調査（Research）と設計（Design）の分離といった新機能を利用したい | `npx cc-sdd@latest`（v2.0.0相当）を再インストールし、`.kiro/settings/templates/*` と `rules/` のみをカスタマイズする。これにより、`validate-*` コマンド群を含む全11コマンドが利用可能になる。 | > ⚠️ 1.x系と2.x系の `.kiro` ディレクトリ構成の混在は推奨されない。リポジトリやブランチ単位で、使用するバージョンをどちらか一方に固定すること。 @@ -47,7 +47,7 @@ npx cc-sdd@1.1.5 --lang ja # 旧来の言語オプション - **仕様駆動開発（Spec-Driven Development）の一貫性向上**: `research.md` が調査ログ、`design.md` がレビュー可能な一次情報（要約、要件カバレッジ、参考文献、適切な粒度に調整されたコンポーネント定義など）として、それぞれの役割を明確に担う。 - **プロジェクトメモリとしてのステアリング**: `.kiro/steering/*.md` のように、ドメイン知識を複数のファイルに分割して体系的に管理できるようになった。 - **既存プロジェクト（Brownfield）への安全な機能追加**: `/kiro:validate-gap`、`validate-design`、`validate-impl` といった検証コマンドや、調査と設計の分離により、既存機能の追加・改修時の安全性が向上する。 -- **7種類のエージェントで共通の体験**: Claude Code、Subagents、Cursor、Codex CLI、Gemini CLI、GitHub Copilot、Qwen Code、Windsurfが同じ11個のコマンドを共有する。これにより、例えばClaudeとCursorを併用する場合でも、追加のテンプレート修正は不要である。 +- **8種類のエージェントで共通の体験**: Claude Code、Subagents、Cursor、Codex CLI、Gemini CLI、GitHub Copilot、Qwen Code、OpenCode、Windsurfが同じ11個のコマンドを共有する。これにより、例えばClaudeとCursorを併用する場合でも、追加のテンプレート修正は不要である。 --- diff --git a/docs/guides/migration-guide.md b/docs/guides/migration-guide.md index 5de867a3..021c42ac 100644 --- a/docs/guides/migration-guide.md +++ b/docs/guides/migration-guide.md @@ -11,7 +11,7 @@ cc-sdd 1.x (especially 1.1.5) and 2.0.0 share the same AI-DLC philosophy and com | Goal | Recommended action | | --- | --- | | Keep the legacy 1.x workflow untouched | Run `npx cc-sdd@1.1.5` whenever you install/refresh files. Continue editing agent-specific prompt folders (only the original 8 spec/steering commands exist). | -| Adopt unified templates, research/design split, and consistent behavior across all 7 supported agents | Reinstall with `npx cc-sdd@latest` (=2.0.0) and customize only `.kiro/settings/templates/*` plus `.kiro/settings/rules/` (full 11-command set, including validate-*). | +| Adopt unified templates, research/design split, and consistent behavior across all 8 supported agents | Reinstall with `npx cc-sdd@latest` (=2.0.0) and customize only `.kiro/settings/templates/*` plus `.kiro/settings/rules/` (full 11-command set, including validate-*). | > ⚠️ Mixing 1.x and 2.x layouts in the same `.kiro` tree is not supported. Pick one path per repo/branch. @@ -47,7 +47,7 @@ npx cc-sdd@1.1.5 --lang ja # legacy i18n flags still work - **Spec fidelity** – Research.md captures discovery logs while Design.md becomes reviewer friendly with Summary tables, Req Coverage, Supporting References, and lighter Components/Interfaces blocks. - **Steering = Project Memory** – drop structured knowledge across `.kiro/steering/*.md` files and every command consumes it. - **Brownfield guardrails** – `/kiro:validate-gap`, `validate-design`, `validate-impl` plus the research/design split make gap analysis and existing-system upgrades much safer. -- **Unified coverage** – all 7 supported agents (Claude Code, Claude Subagents, Cursor, Codex CLI, Gemini CLI, GitHub Copilot, Qwen Code, Windsurf) run the same 11-command workflow, so mixing agents (e.g., Cursor + Claude) requires zero spec rewrites. +- **Unified coverage** – all 8 supported agents (Claude Code, Claude Subagents, Cursor, Codex CLI, Gemini CLI, GitHub Copilot, Qwen Code, OpenCode, Windsurf) run the same 11-command workflow, so mixing agents (e.g., Cursor + Claude) requires zero spec rewrites. --- diff --git a/tools/cc-sdd/README.md b/tools/cc-sdd/README.md index 13767ce7..85bfc5de 100644 --- a/tools/cc-sdd/README.md +++ b/tools/cc-sdd/README.md @@ -8,7 +8,7 @@ English | 日本語 | 繁體中文 -✨ **Transform Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / Windsurf from prototype to production-ready development.** +✨ **Transform Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / OpenCode / Windsurf from prototype to production-ready development.** 👻 **Kiro-inspired** — Similar Spec-Driven, AI-DLC style as Kiro IDE, so existing Kiro specs remain compatible and portable. @@ -17,7 +17,7 @@ English | 日本語 | - ✅ **Separate Research** — Keep discovery notes (Research.md) separate from final design (Design.md) - ✅ **Quality Gates** — validate-gap/design/impl commands catch integration issues before coding - ✅ **Customize Once** — Adapt templates to your team's process; all agents follow the same workflow -- ✅ **Universal Workflow** — 7 agents × 13 languages share the same 11-command process +- ✅ **Universal Workflow** — 8 agents × 13 languages share the same 11-command process --- diff --git a/tools/cc-sdd/README_ja.md b/tools/cc-sdd/README_ja.md index 6ab6978d..f2f2f7ac 100644 --- a/tools/cc-sdd/README_ja.md +++ b/tools/cc-sdd/README_ja.md @@ -8,7 +8,7 @@ English | 日本語 | 繁體中文 -✨ **Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / Windsurf をプロトタイプから本番仕様駆動へ。要件・設計・タスク・プロジェクトメモリをチームのワークフローに沿うようカスタマイズできます。** +✨ **Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / OpenCode / Windsurf をプロトタイプから本番仕様駆動へ。要件・設計・タスク・プロジェクトメモリをチームのワークフローに沿うようカスタマイズできます。** 👻 **Kiro互換** — Kiro IDE に似た Spec-Driven / AI-DLC スタイルで、既存の Kiro 仕様書もそのまま扱えます。 @@ -17,12 +17,12 @@ - ✅ **Research の分離** — 調査メモ（Research.md）と最終設計（Design.md）を分けて管理 - ✅ **品質ゲート** — validate-gap/design/impl コマンドでコーディング前に統合問題を検出 - ✅ **一度だけカスタマイズ** — テンプレートをチームプロセスに適応、全エージェントが同じワークフローに従う -- ✅ **統一ワークフロー** — 7エージェント × 13言語で同じ11コマンドプロセスを共有 +- ✅ **統一ワークフロー** — 8エージェント × 13言語で同じ11コマンドプロセスを共有 > インストール手順だけ知りたい場合は [インストール](#-インストール) へジャンプ。v1.1.5 維持なら `npx cc-sdd@1.1.5 --claude-code ...`、v2 移行は [Migration Guide](../../docs/guides/migration-guide.md) / [日本語版](../../docs/guides/ja/migration-guide.md) を参照。 -Claude Code、Cursor IDE、Gemini CLI、Codex CLI、GitHub Copilot、Qwen Code、Windsurfを **AI-DLC (AI駆動開発ライフサイクル)**へ。**AIネイティブプロセス**と**最小限の人間承認ゲート**：AIが実行を駆動し、人間が各フェーズで重要な決定を検証。 +Claude Code、Cursor IDE、Gemini CLI、Codex CLI、GitHub Copilot、Qwen Code、OpenCode、Windsurfを **AI-DLC (AI駆動開発ライフサイクル)**へ。**AIネイティブプロセス**と**最小限の人間承認ゲート**：AIが実行を駆動し、人間が各フェーズで重要な決定を検証。 ## 🚀 インストール @@ -46,6 +46,7 @@ npx cc-sdd@latest --gemini --lang ja # Gemini CLI npx cc-sdd@latest --codex --lang ja # Codex CLI npx cc-sdd@latest --copilot --lang ja # GitHub Copilot npx cc-sdd@latest --qwen --lang ja # Qwen Code +npx cc-sdd@latest --opencode --lang ja # OpenCode npx cc-sdd@latest --windsurf --lang ja # Windsurf IDE # 注: @nextは今後のアルファ/ベータ版用に予約されています diff --git a/tools/cc-sdd/README_zh-TW.md b/tools/cc-sdd/README_zh-TW.md index 4400738c..fa935fbf 100644 --- a/tools/cc-sdd/README_zh-TW.md +++ b/tools/cc-sdd/README_zh-TW.md @@ -8,7 +8,7 @@ English | 日本語 | 繁體中文 -✨ **將 Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / Windsurf 直接帶入 Spec-Driven / AI-DLC 的生產級流程，需求・設計・任務・指導文件一次對齊團隊審核。** +✨ **將 Claude Code / Cursor IDE / Gemini CLI / Codex CLI / GitHub Copilot / Qwen Code / OpenCode / Windsurf 直接帶入 Spec-Driven / AI-DLC 的生產級流程，需求・設計・任務・指導文件一次對齊團隊審核。** 👻 **Kiro 相容** — 與 Kiro IDE 相似的 Spec-Driven / AI-DLC 風格，可沿用既有 Kiro 規格並保持互通。 @@ -43,6 +43,7 @@ npx cc-sdd@latest --gemini --lang zh-TW # Gemini CLI npx cc-sdd@latest --codex --lang zh-TW # Codex CLI npx cc-sdd@latest --copilot --lang zh-TW # GitHub Copilot npx cc-sdd@latest --qwen --lang zh-TW # Qwen Code +npx cc-sdd@latest --opencode --lang zh-TW # OpenCode npx cc-sdd@latest --windsurf --lang zh-TW # Windsurf IDE # 注意：@next 現已保留給未來的 alpha/beta 版本 @@ -102,7 +103,7 @@ npx cc-sdd@latest --windsurf --lang zh-TW # Windsurf IDE ### 為何團隊選擇 cc-sdd 1. **規格是單一真實來源** — 需求、設計、任務、Supporting References 同步產出，審查更快。 2. **Greenfield / Brownfield 皆適用** — 新功能快速起步；既有系統靠 validate 系列與 Project Memory 保持安全。 -3. **可同時使用多個代理** — Claude、Cursor、Codex、Gemini、Copilot、Qwen、Windsurf 共用同一套模板/規則。 +3. **可同時使用多個代理** — Claude、Cursor、Codex、Gemini、Copilot、Qwen、OpenCode、Windsurf 共用同一套模板/規則。 4. **自訂只要一次** — 編輯 `.kiro/settings/templates/` 或 `.kiro/settings/rules/`，所有代理立即套用。 ## ✨ 主要功能 diff --git a/tools/cc-sdd/package.json b/tools/cc-sdd/package.json index 74af50b0..b7826f93 100644 --- a/tools/cc-sdd/package.json +++ b/tools/cc-sdd/package.json @@ -1,7 +1,7 @@ { "name": "cc-sdd", "version": "2.0.5", - "description": "Transform your coding workflow with AI-DLC and Spec-Driven Development. One command installs 11 powerful slash commands, Project Memory, and structured development workflows for 7 AI coding agents.", + "description": "Transform your coding workflow with AI-DLC and Spec-Driven Development. One command installs 11 powerful slash commands, Project Memory, and structured development workflows for 8 AI coding agents.", "keywords": [ "claude-code", "cursor", @@ -10,6 +10,7 @@ "codex", "github-copilot", "qwen-code", + "opencode", "sdd", "spec-driven-development", "kiro", diff --git a/tools/cc-sdd/src/agents/registry.ts b/tools/cc-sdd/src/agents/registry.ts index 989cb8e0..80b1704c 100644 --- a/tools/cc-sdd/src/agents/registry.ts +++ b/tools/cc-sdd/src/agents/registry.ts @@ -196,6 +196,23 @@ export const agentDefinitions = { }, manifestId: 'qwen-code', }, + 'opencode': { + label: 'OpenCode', + description: + 'Installs kiro prompts in `.opencode/commands/`, shared settings in `{{KIRO_DIR}}/settings/`, and an AGENTS.md quickstart.', + aliasFlags: ['--opencode'], + layout: { + commandsDir: '.opencode/commands', + agentDir: '.opencode', + docFile: 'AGENTS.md', + }, + commands: { + spec: '`/kiro-spec-init `', + steering: '`/kiro-steering`', + steeringCustom: '`/kiro-steering-custom `', + }, + manifestId: 'opencode', + }, } as const satisfies Record; export type AgentType = keyof typeof agentDefinitions; diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-design.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-design.md new file mode 100644 index 00000000..02446dd1 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-design.md @@ -0,0 +1,178 @@ +--- +description: Create comprehensive technical design for a specification +--- + + +# Technical Design Generator + + +- **Mission**: Generate comprehensive technical design document that translates requirements (WHAT) into architectural design (HOW) +- **Success Criteria**: + - All requirements mapped to technical components with clear interfaces + - Appropriate architecture discovery and research completed + - Design aligns with steering context and existing patterns + - Visual diagrams included for complex architectures + + + +## Core Task +Generate technical design document for feature **$1** based on approved requirements. + +## Execution Steps + +### Step 1: Load Context + +**Read all necessary context**: +- `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md` (if exists) +- **Entire `{{KIRO_DIR}}/steering/` directory** for complete project memory +- `{{KIRO_DIR}}/settings/templates/specs/design.md` for document structure +- `{{KIRO_DIR}}/settings/rules/design-principles.md` for design principles +- `{{KIRO_DIR}}/settings/templates/specs/research.md` for discovery log structure + +**Validate requirements approval**: +- If `-y` flag provided ($2 == "-y"): Auto-approve requirements in spec.json +- Otherwise: Verify approval status (stop if unapproved, see Safety & Fallback) + +### Step 2: Discovery & Analysis + +**Critical: This phase ensures design is based on complete, accurate information.** + +1. **Classify Feature Type**: + - **New Feature** (greenfield) → Full discovery required + - **Extension** (existing system) → Integration-focused discovery + - **Simple Addition** (CRUD/UI) → Minimal or no discovery + - **Complex Integration** → Comprehensive analysis required + +2. **Execute Appropriate Discovery Process**: + + **For Complex/New Features**: + - Read and execute `{{KIRO_DIR}}/settings/rules/design-discovery-full.md` + - Conduct thorough research using WebSearch/WebFetch: + - Latest architectural patterns and best practices + - External dependency verification (APIs, libraries, versions, compatibility) + - Official documentation, migration guides, known issues + - Performance benchmarks and security considerations + + **For Extensions**: + - Read and execute `{{KIRO_DIR}}/settings/rules/design-discovery-light.md` + - Focus on integration points, existing patterns, compatibility + - Use Grep to analyze existing codebase patterns + + **For Simple Additions**: + - Skip formal discovery, quick pattern check only + +3. **Retain Discovery Findings for Step 3**: +- External API contracts and constraints +- Technology decisions with rationale +- Existing patterns to follow or extend +- Integration points and dependencies +- Identified risks and mitigation strategies +- Potential architecture patterns and boundary options (note details in `research.md`) +- Parallelization considerations for future tasks (capture dependencies in `research.md`) + +4. **Persist Findings to Research Log**: +- Create or update `{{KIRO_DIR}}/specs/$1/research.md` using the shared template +- Summarize discovery scope and key findings (Summary section) +- Record investigations in Research Log topics with sources and implications +- Document architecture pattern evaluation, design decisions, and risks using the template sections +- Use the language specified in spec.json when writing or updating `research.md` + +### Step 3: Generate Design Document + +1. **Load Design Template and Rules**: +- Read `{{KIRO_DIR}}/settings/templates/specs/design.md` for structure +- Read `{{KIRO_DIR}}/settings/rules/design-principles.md` for principles + +2. **Generate Design Document**: +- **Follow specs/design.md template structure and generation instructions strictly** +- **Integrate all discovery findings**: Use researched information (APIs, patterns, technologies) throughout component definitions, architecture decisions, and integration points +- If existing design.md found in Step 1, use it as reference context (merge mode) +- Apply design rules: Type Safety, Visual Communication, Formal Tone +- Use language specified in spec.json +- Ensure sections reflect updated headings ("Architecture Pattern & Boundary Map", "Technology Stack & Alignment", "Components & Interface Contracts") and reference supporting details from `research.md` + +3. **Update Metadata** in spec.json: +- Set `phase: "design-generated"` +- Set `approvals.design.generated: true, approved: false` +- Set `approvals.requirements.approved: true` +- Update `updated_at` timestamp + +## Critical Constraints + - **Type Safety**: + - Enforce strong typing aligned with the project's technology stack. + - For statically typed languages, define explicit types/interfaces and avoid unsafe casts. + - For TypeScript, never use `any`; prefer precise types and generics. + - For dynamically typed languages, provide type hints/annotations where available (e.g., Python type hints) and validate inputs at boundaries. + - Document public interfaces and contracts clearly to ensure cross-component type safety. +- **Latest Information**: Use WebSearch/WebFetch for external dependencies and best practices +- **Steering Alignment**: Respect existing architecture patterns from steering context +- **Template Adherence**: Follow specs/design.md template structure and generation instructions strictly +- **Design Focus**: Architecture and interfaces ONLY, no implementation code +- **Requirements Traceability IDs**: Use numeric requirement IDs only (e.g. "1.1", "1.2", "3.1", "3.3") exactly as defined in requirements.md. Do not invent new IDs or use alphabetic labels. + + +## Tool Guidance +- **Read first**: Load all context before taking action (specs, steering, templates, rules) +- **Research when uncertain**: Use WebSearch/WebFetch for external dependencies, APIs, and latest best practices +- **Analyze existing code**: Use Grep to find patterns and integration points in codebase +- **Write last**: Generate design.md only after all research and analysis complete + +## Output Description + +**Command execution output** (separate from design.md content): + +Provide brief summary in the language specified in spec.json: + +1. **Status**: Confirm design document generated at `{{KIRO_DIR}}/specs/$1/design.md` +2. **Discovery Type**: Which discovery process was executed (full/light/minimal) +3. **Key Findings**: 2-3 critical insights from `research.md` that shaped the design +4. **Next Action**: Approval workflow guidance (see Safety & Fallback) +5. **Research Log**: Confirm `research.md` updated with latest decisions + +**Format**: Concise Markdown (under 200 words) - this is the command output, NOT the design document itself + +**Note**: The actual design document follows `{{KIRO_DIR}}/settings/templates/specs/design.md` structure. + +## Safety & Fallback + +### Error Scenarios + +**Requirements Not Approved**: +- **Stop Execution**: Cannot proceed without approved requirements +- **User Message**: "Requirements not yet approved. Approval required before design generation." +- **Suggested Action**: "Run `/kiro-spec-design $1 -y` to auto-approve requirements and proceed" + +**Missing Requirements**: +- **Stop Execution**: Requirements document must exist +- **User Message**: "No requirements.md found at `{{KIRO_DIR}}/specs/$1/requirements.md`" +- **Suggested Action**: "Run `/kiro-spec-requirements $1` to generate requirements first" + +**Template Missing**: +- **User Message**: "Template file missing at `{{KIRO_DIR}}/settings/templates/specs/design.md`" +- **Suggested Action**: "Check repository setup or restore template file" +- **Fallback**: Use inline basic structure with warning + +**Steering Context Missing**: +- **Warning**: "Steering directory empty or missing - design may not align with project standards" +- **Proceed**: Continue with generation but note limitation in output + +**Discovery Complexity Unclear**: +- **Default**: Use full discovery process (`{{KIRO_DIR}}/settings/rules/design-discovery-full.md`) +- **Rationale**: Better to over-research than miss critical context +- **Invalid Requirement IDs**: + - **Stop Execution**: If requirements.md is missing numeric IDs or uses non-numeric headings (for example, "Requirement A"), stop and instruct the user to fix requirements.md before continuing. + +### Next Phase: Task Generation + +**If Design Approved**: +- Review generated design at `{{KIRO_DIR}}/specs/$1/design.md` +- **Optional**: Run `/kiro-validate-design $1` for interactive quality review +- Then `/kiro-spec-tasks $1 -y` to generate implementation tasks + +**If Modifications Needed**: +- Provide feedback and re-run `/kiro-spec-design $1` +- Existing design used as reference (merge mode) + +**Note**: Design approval is mandatory before proceeding to task generation. + +think hard diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-impl.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-impl.md new file mode 100644 index 00000000..141ef63e --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-impl.md @@ -0,0 +1,109 @@ +--- +description: Execute spec tasks using TDD methodology +--- + + +# Implementation Task Executor + + +- **Mission**: Execute implementation tasks using Test-Driven Development methodology based on approved specifications +- **Success Criteria**: + - All tests written before implementation code + - Code passes all tests with no regressions + - Tasks marked as completed in tasks.md + - Implementation aligns with design and requirements + + + +## Core Task +Execute implementation tasks for feature **$1** using Test-Driven Development. + +## Execution Steps + +### Step 1: Load Context + +**Read all necessary context**: +- `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md`, `tasks.md` +- **Entire `{{KIRO_DIR}}/steering/` directory** for complete project memory + +**Validate approvals**: +- Verify tasks are approved in spec.json (stop if not, see Safety & Fallback) + +### Step 2: Select Tasks + +**Determine which tasks to execute**: +- If `$2` provided: Execute specified task numbers (e.g., "1.1" or "1,2,3") +- Otherwise: Execute all pending tasks (unchecked `- [ ]` in tasks.md) + +### Step 3: Execute with TDD + +For each selected task, follow Kent Beck's TDD cycle: + +1. **RED - Write Failing Test**: + - Write test for the next small piece of functionality + - Test should fail (code doesn't exist yet) + - Use descriptive test names + +2. **GREEN - Write Minimal Code**: + - Implement simplest solution to make test pass + - Focus only on making THIS test pass + - Avoid over-engineering + +3. **REFACTOR - Clean Up**: + - Improve code structure and readability + - Remove duplication + - Apply design patterns where appropriate + - Ensure all tests still pass after refactoring + +4. **VERIFY - Validate Quality**: + - All tests pass (new and existing) + - No regressions in existing functionality + - Code coverage maintained or improved + +5. **MARK COMPLETE**: + - Update checkbox from `- [ ]` to `- [x]` in tasks.md + +## Critical Constraints +- **TDD Mandatory**: Tests MUST be written before implementation code +- **Task Scope**: Implement only what the specific task requires +- **Test Coverage**: All new code must have tests +- **No Regressions**: Existing tests must continue to pass +- **Design Alignment**: Implementation must follow design.md specifications + + +## Tool Guidance +- **Read first**: Load all context before implementation +- **Test first**: Write tests before code +- Use **WebSearch/WebFetch** for library documentation when needed + +## Output Description + +Provide brief summary in the language specified in spec.json: + +1. **Tasks Executed**: Task numbers and test results +2. **Status**: Completed tasks marked in tasks.md, remaining tasks count + +**Format**: Concise (under 150 words) + +## Safety & Fallback + +### Error Scenarios + +**Tasks Not Approved or Missing Spec Files**: +- **Stop Execution**: All spec files must exist and tasks must be approved +- **Suggested Action**: "Complete previous phases: `/kiro-spec-requirements`, `/kiro-spec-design`, `/kiro-spec-tasks`" + +**Test Failures**: +- **Stop Implementation**: Fix failing tests before continuing +- **Action**: Debug and fix, then re-run + +### Task Execution + +**Execute specific task(s)**: +- `/kiro-spec-impl $1 1.1` - Single task +- `/kiro-spec-impl $1 1,2,3` - Multiple tasks + +**Execute all pending**: +- `/kiro-spec-impl $1` - All unchecked tasks + +think diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-init.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-init.md new file mode 100644 index 00000000..87705c3a --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-init.md @@ -0,0 +1,64 @@ +--- +description: Initialize a new specification with detailed project description +--- + + +# Spec Initialization + + +- **Mission**: Initialize the first phase of spec-driven development by creating directory structure and metadata for a new specification +- **Success Criteria**: + - Generate appropriate feature name from project description + - Create unique spec structure without conflicts + - Provide clear path to next phase (requirements generation) + + + +## Core Task +Generate a unique feature name from the project description ($ARGUMENTS) and initialize the specification structure. + +## Execution Steps +1. **Check Uniqueness**: Verify `{{KIRO_DIR}}/specs/` for naming conflicts (append number suffix if needed) +2. **Create Directory**: `{{KIRO_DIR}}/specs/[feature-name]/` +3. **Initialize Files Using Templates**: + - Read `{{KIRO_DIR}}/settings/templates/specs/init.json` + - Read `{{KIRO_DIR}}/settings/templates/specs/requirements-init.md` + - Replace placeholders: + - `{{FEATURE_NAME}}` → generated feature name + - `{{TIMESTAMP}}` → current ISO 8601 timestamp + - `{{PROJECT_DESCRIPTION}}` → $ARGUMENTS + - Write `spec.json` and `requirements.md` to spec directory + +## Important Constraints +- DO NOT generate requirements/design/tasks at this stage +- Follow stage-by-stage development principles +- Maintain strict phase separation +- Only initialization is performed in this phase + + +## Tool Guidance +- Use **Glob** to check existing spec directories for name uniqueness +- Use **Read** to fetch templates: `init.json` and `requirements-init.md` +- Use **Write** to create spec.json and requirements.md after placeholder replacement +- Perform validation before any file write operation + +## Output Description +Provide output in the language specified in `spec.json` with the following structure: + +1. **Generated Feature Name**: `feature-name` format with 1-2 sentence rationale +2. **Project Summary**: Brief summary (1 sentence) +3. **Created Files**: Bullet list with full paths +4. **Next Step**: Command block showing `/kiro-spec-requirements ` +5. **Notes**: Explain why only initialization was performed (2-3 sentences on phase separation) + +**Format Requirements**: +- Use Markdown headings (##, ###) +- Wrap commands in code blocks +- Keep total output concise (under 250 words) +- Use clear, professional language per `spec.json.language` + +## Safety & Fallback +- **Ambiguous Feature Name**: If feature name generation is unclear, propose 2-3 options and ask user to select +- **Template Missing**: If template files don't exist in `{{KIRO_DIR}}/settings/templates/specs/`, report error with specific missing file path and suggest checking repository setup +- **Directory Conflict**: If feature name already exists, append numeric suffix (e.g., `feature-name-2`) and notify user of automatic conflict resolution +- **Write Failure**: Report error with specific path and suggest checking permissions or disk space \ No newline at end of file diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-requirements.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-requirements.md new file mode 100644 index 00000000..f7f0a780 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-requirements.md @@ -0,0 +1,97 @@ +--- +description: Generate comprehensive requirements for a specification +--- + + +# Requirements Generation + + +- **Mission**: Generate comprehensive, testable requirements in EARS format based on the project description from spec initialization +- **Success Criteria**: + - Create complete requirements document aligned with steering context + - Follow the project's EARS patterns and constraints for all acceptance criteria + - Focus on core functionality without implementation details + - Update metadata to track generation status + + + +## Core Task +Generate complete requirements for feature **$1** based on the project description in requirements.md. + +## Execution Steps + +1. **Load Context**: + - Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata + - Read `{{KIRO_DIR}}/specs/$1/requirements.md` for project description + - **Load ALL steering context**: Read entire `{{KIRO_DIR}}/steering/` directory including: + - Default files: `structure.md`, `tech.md`, `product.md` + - All custom steering files (regardless of mode settings) + - This provides complete project memory and context + +2. **Read Guidelines**: + - Read `{{KIRO_DIR}}/settings/rules/ears-format.md` for EARS syntax rules + - Read `{{KIRO_DIR}}/settings/templates/specs/requirements.md` for document structure + +3. **Generate Requirements**: + - Create initial requirements based on project description + - Group related functionality into logical requirement areas + - Apply EARS format to all acceptance criteria + - Use language specified in spec.json + +4. **Update Metadata**: + - Set `phase: "requirements-generated"` + - Set `approvals.requirements.generated: true` + - Update `updated_at` timestamp + +## Important Constraints +- Focus on WHAT, not HOW (no implementation details) +- Requirements must be testable and verifiable +- Choose appropriate subject for EARS statements (system/service name for software) +- Generate initial version first, then iterate with user feedback (no sequential questions upfront) +- Requirement headings in requirements.md MUST include a leading numeric ID only (for example: "Requirement 1", "1.", "2 Feature ..."); do not use alphabetic IDs like "Requirement A". + + +## Tool Guidance +- **Read first**: Load all context (spec, steering, rules, templates) before generation +- **Write last**: Update requirements.md only after complete generation +- Use **WebSearch/WebFetch** only if external domain knowledge needed + +## Output Description +Provide output in the language specified in spec.json with: + +1. **Generated Requirements Summary**: Brief overview of major requirement areas (3-5 bullets) +2. **Document Status**: Confirm requirements.md updated and spec.json metadata updated +3. **Next Steps**: Guide user on how to proceed (approve and continue, or modify) + +**Format Requirements**: +- Use Markdown headings for clarity +- Include file paths in code blocks +- Keep summary concise (under 300 words) + +## Safety & Fallback + +### Error Scenarios +- **Missing Project Description**: If requirements.md lacks project description, ask user for feature details +- **Ambiguous Requirements**: Propose initial version and iterate with user rather than asking many upfront questions +- **Template Missing**: If template files don't exist, use inline fallback structure with warning +- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language +- **Incomplete Requirements**: After generation, explicitly ask user if requirements cover all expected functionality +- **Steering Directory Empty**: Warn user that project context is missing and may affect requirement quality +- **Non-numeric Requirement Headings**: If existing headings do not include a leading numeric ID (for example, they use "Requirement A"), normalize them to numeric IDs and keep that mapping consistent (never mix numeric and alphabetic labels). + +### Next Phase: Design Generation + +**If Requirements Approved**: +- Review generated requirements at `{{KIRO_DIR}}/specs/$1/requirements.md` +- **Optional Gap Analysis** (for existing codebases): + - Run `/kiro-validate-gap $1` to analyze implementation gap with current code + - Identifies existing components, integration points, and implementation strategy + - Recommended for brownfield projects; skip for greenfield +- Then `/kiro-spec-design $1 -y` to proceed to design phase + +**If Modifications Needed**: +- Provide feedback and re-run `/kiro-spec-requirements $1` + +**Note**: Approval is mandatory before proceeding to design phase. + +think diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-status.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-status.md new file mode 100644 index 00000000..9514d45f --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-status.md @@ -0,0 +1,86 @@ +--- +description: Show specification status and progress +--- + + +# Specification Status + + +- **Mission**: Display comprehensive status and progress for a specification +- **Success Criteria**: + - Show current phase and completion status + - Identify next actions and blockers + - Provide clear visibility into progress + + + +## Core Task +Generate status report for feature **$1** showing progress across all phases. + +## Execution Steps + +### Step 1: Load Spec Context +- Read `{{KIRO_DIR}}/specs/$1/spec.json` for metadata and phase status +- Read existing files: `requirements.md`, `design.md`, `tasks.md` (if they exist) +- Check `{{KIRO_DIR}}/specs/$1/` directory for available files + +### Step 2: Analyze Status + +**Parse each phase**: +- **Requirements**: Count requirements and acceptance criteria +- **Design**: Check for architecture, components, diagrams +- **Tasks**: Count completed vs total tasks (parse `- [x]` vs `- [ ]`) +- **Approvals**: Check approval status in spec.json + +### Step 3: Generate Report + +Create report in the language specified in spec.json covering: +1. **Current Phase & Progress**: Where the spec is in the workflow +2. **Completion Status**: Percentage complete for each phase +3. **Task Breakdown**: If tasks exist, show completed/remaining counts +4. **Next Actions**: What needs to be done next +5. **Blockers**: Any issues preventing progress + +## Critical Constraints +- Use language from spec.json +- Calculate accurate completion percentages +- Identify specific next action commands + + +## Tool Guidance +- **Read**: Load spec.json first, then other spec files as needed +- **Parse carefully**: Extract completion data from tasks.md checkboxes +- Use **Glob** to check which spec files exist + +## Output Description + +Provide status report in the language specified in spec.json: + +**Report Structure**: +1. **Feature Overview**: Name, phase, last updated +2. **Phase Status**: Requirements, Design, Tasks with completion % +3. **Task Progress**: If tasks exist, show X/Y completed +4. **Next Action**: Specific command to run next +5. **Issues**: Any blockers or missing elements + +**Format**: Clear, scannable format with emojis (✅/⏳/❌) for status + +## Safety & Fallback + +### Error Scenarios + +**Spec Not Found**: +- **Message**: "No spec found for `$1`. Check available specs in `{{KIRO_DIR}}/specs/`" +- **Action**: List available spec directories + +**Incomplete Spec**: +- **Warning**: Identify which files are missing +- **Suggested Action**: Point to next phase command + +### List All Specs + +To see all available specs: +- Run with no argument or use wildcard +- Shows all specs in `{{KIRO_DIR}}/specs/` with their status + +think diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-tasks.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-tasks.md new file mode 100644 index 00000000..80d1f5c7 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-spec-tasks.md @@ -0,0 +1,137 @@ +--- +description: Generate implementation tasks for a specification +--- + + +# Implementation Tasks Generator + + +- **Mission**: Generate detailed, actionable implementation tasks that translate technical design into executable work items +- **Success Criteria**: + - All requirements mapped to specific tasks + - Tasks properly sized (1-3 hours each) + - Clear task progression with proper hierarchy + - Natural language descriptions focused on capabilities + + + +## Core Task +Generate implementation tasks for feature **$1** based on approved requirements and design. + +## Execution Steps + +### Step 1: Load Context + +**Read all necessary context**: +- `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md` +- `{{KIRO_DIR}}/specs/$1/tasks.md` (if exists, for merge mode) +- **Entire `{{KIRO_DIR}}/steering/` directory** for complete project memory + +**Validate approvals**: +- If `-y` flag provided ($2 == "-y"): Auto-approve requirements and design in spec.json +- Otherwise: Verify both approved (stop if not, see Safety & Fallback) +- Determine sequential mode based on presence of `--sequential` + +### Step 2: Generate Implementation Tasks + +**Load generation rules and template**: +- Read `{{KIRO_DIR}}/settings/rules/tasks-generation.md` for principles +- If `sequential` is **false**: Read `{{KIRO_DIR}}/settings/rules/tasks-parallel-analysis.md` for parallel judgement criteria +- Read `{{KIRO_DIR}}/settings/templates/specs/tasks.md` for format (supports `(P)` markers) + +**Generate task list following all rules**: +- Use language specified in spec.json +- Map all requirements to tasks +- When documenting requirement coverage, list numeric requirement IDs only (comma-separated) without descriptive suffixes, parentheses, translations, or free-form labels +- Ensure all design components included +- Verify task progression is logical and incremental +- Collapse single-subtask structures by promoting them to major tasks and avoid duplicating details on container-only major tasks (use template patterns accordingly) +- Apply `(P)` markers to tasks that satisfy parallel criteria (omit markers in sequential mode) +- Mark optional test coverage subtasks with `- [ ]*` only when they strictly cover acceptance criteria already satisfied by core implementation and can be deferred post-MVP +- If existing tasks.md found, merge with new content + +### Step 3: Finalize + +**Write and update**: +- Create/update `{{KIRO_DIR}}/specs/$1/tasks.md` +- Update spec.json metadata: + - Set `phase: "tasks-generated"` + - Set `approvals.tasks.generated: true, approved: false` + - Set `approvals.requirements.approved: true` + - Set `approvals.design.approved: true` + - Update `updated_at` timestamp + +## Critical Constraints +- **Follow rules strictly**: All principles in tasks-generation.md are mandatory +- **Natural Language**: Describe what to do, not code structure details +- **Complete Coverage**: ALL requirements must map to tasks +- **Maximum 2 Levels**: Major tasks and sub-tasks only (no deeper nesting) +- **Sequential Numbering**: Major tasks increment (1, 2, 3...), never repeat +- **Task Integration**: Every task must connect to the system (no orphaned work) + + +## Tool Guidance +- **Read first**: Load all context, rules, and templates before generation +- **Write last**: Generate tasks.md only after complete analysis and verification + +## Output Description + +Provide brief summary in the language specified in spec.json: + +1. **Status**: Confirm tasks generated at `{{KIRO_DIR}}/specs/$1/tasks.md` +2. **Task Summary**: + - Total: X major tasks, Y sub-tasks + - All Z requirements covered + - Average task size: 1-3 hours per sub-task +3. **Quality Validation**: + - ✅ All requirements mapped to tasks + - ✅ Task dependencies verified + - ✅ Testing tasks included +4. **Next Action**: Review tasks and proceed when ready + +**Format**: Concise (under 200 words) + +## Safety & Fallback + +### Error Scenarios + +**Requirements or Design Not Approved**: +- **Stop Execution**: Cannot proceed without approved requirements and design +- **User Message**: "Requirements and design must be approved before task generation" +- **Suggested Action**: "Run `/kiro-spec-tasks $1 -y` to auto-approve both and proceed" + +**Missing Requirements or Design**: +- **Stop Execution**: Both documents must exist +- **User Message**: "Missing requirements.md or design.md at `{{KIRO_DIR}}/specs/$1/`" +- **Suggested Action**: "Complete requirements and design phases first" + +**Incomplete Requirements Coverage**: +- **Warning**: "Not all requirements mapped to tasks. Review coverage." +- **User Action Required**: Confirm intentional gaps or regenerate tasks + +**Template/Rules Missing**: +- **User Message**: "Template or rules files missing in `{{KIRO_DIR}}/settings/`" +- **Fallback**: Use inline basic structure with warning +- **Suggested Action**: "Check repository setup or restore template files" +- **Missing Numeric Requirement IDs**: + - **Stop Execution**: All requirements in requirements.md MUST have numeric IDs. If any requirement lacks a numeric ID, stop and request that requirements.md be fixed before generating tasks. + +### Next Phase: Implementation + +**Before Starting Implementation**: +- **IMPORTANT**: Clear conversation history and free up context before running `/kiro-spec-impl` +- This applies when starting first task OR switching between tasks +- Fresh context ensures clean state and proper task focus + +**If Tasks Approved**: +- Execute specific task: `/kiro-spec-impl $1 1.1` (recommended: clear context between each task) +- Execute multiple tasks: `/kiro-spec-impl $1 1.1,1.2` (use cautiously, clear context between tasks) +- Without arguments: `/kiro-spec-impl $1` (executes all pending tasks - NOT recommended due to context bloat) + +**If Modifications Needed**: +- Provide feedback and re-run `/kiro-spec-tasks $1` +- Existing tasks used as reference (merge mode) + +**Note**: The implementation phase will guide you through executing tasks with appropriate context and validation. + +think diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering-custom.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering-custom.md new file mode 100644 index 00000000..7be4f72b --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering-custom.md @@ -0,0 +1,127 @@ +--- +description: Create custom steering documents for specialized project contexts +--- + + +# Kiro Custom Steering Creation + + +**Role**: Create specialized steering documents beyond core files (product, tech, structure). + +**Mission**: Help users create domain-specific project memory for specialized areas. + +**Success Criteria**: +- Custom steering captures specialized patterns +- Follows same granularity principles as core steering +- Provides clear value for specific domain + + + +## Workflow + +1. **Ask user** for custom steering needs: + - Domain/topic (e.g., "API standards", "testing approach") + - Specific requirements or patterns to document + +2. **Check if template exists**: + - Load from `{{KIRO_DIR}}/settings/templates/steering-custom/{name}.md` if available + - Use as starting point, customize based on project + +3. **Analyze codebase** (JIT) for relevant patterns: + - **Glob** for related files + - **Read** for existing implementations + - **Grep** for specific patterns + +4. **Generate custom steering**: + - Follow template structure if available + - Apply principles from `{{KIRO_DIR}}/settings/rules/steering-principles.md` + - Focus on patterns, not exhaustive lists + - Keep to 100-200 lines (2-3 minute read) + +5. **Create file** in `{{KIRO_DIR}}/steering/{name}.md` + +## Available Templates + +Templates available in `{{KIRO_DIR}}/settings/templates/steering-custom/`: + +1. **api-standards.md** - REST/GraphQL conventions, error handling +2. **testing.md** - Test organization, mocking, coverage +3. **security.md** - Auth patterns, input validation, secrets +4. **database.md** - Schema design, migrations, query patterns +5. **error-handling.md** - Error types, logging, retry strategies +6. **authentication.md** - Auth flows, permissions, session management +7. **deployment.md** - CI/CD, environments, rollback procedures + +Load template when needed, customize for project. + +## Steering Principles + +From `{{KIRO_DIR}}/settings/rules/steering-principles.md`: + +- **Patterns over lists**: Document patterns, not every file/component +- **Single domain**: One topic per file +- **Concrete examples**: Show patterns with code +- **Maintainable size**: 100-200 lines typical +- **Security first**: Never include secrets or sensitive data + + + +## Tool guidance + +- **Read**: Load template, analyze existing code +- **Glob**: Find related files for pattern analysis +- **Grep**: Search for specific patterns +- **LS**: Understand relevant structure + +**JIT Strategy**: Load template only when creating that type of steering. + +## Output description + +Chat summary with file location (file created directly). + +``` +✅ Custom Steering Created + +## Created: +- {{KIRO_DIR}}/steering/api-standards.md + +## Based On: +- Template: api-standards.md +- Analyzed: src/api/ directory patterns +- Extracted: REST conventions, error format + +## Content: +- Endpoint naming patterns +- Request/response format +- Error handling conventions +- Authentication approach + +Review and customize as needed. +``` + +## Examples + +### Success: API Standards +**Input**: "Create API standards steering" +**Action**: Load template, analyze src/api/, extract patterns +**Output**: api-standards.md with project-specific REST conventions + +### Success: Testing Strategy +**Input**: "Document our testing approach" +**Action**: Load template, analyze test files, extract patterns +**Output**: testing.md with test organization and mocking strategies + +## Safety & Fallback + +- **No template**: Generate from scratch based on domain knowledge +- **Security**: Never include secrets (load principles) +- **Validation**: Ensure doesn't duplicate core steering content + +## Notes + +- Templates are starting points, customize for project +- Follow same granularity principles as core steering +- All steering files loaded as project memory +- Custom files equally important as core files +- Avoid documenting agent-specific tooling directories (e.g. `.cursor/`, `.gemini/`, `.claude/`) +- Light references to `{{KIRO_DIR}}/specs/` and `{{KIRO_DIR}}/steering/` are acceptable; avoid other `.kiro/` directories diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering.md new file mode 100644 index 00000000..5b149fec --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-steering.md @@ -0,0 +1,140 @@ +--- +description: Manage {{KIRO_DIR}}/steering/ as persistent project knowledge +--- + + +# Kiro Steering Management + + +**Role**: Maintain `{{KIRO_DIR}}/steering/` as persistent project memory. + +**Mission**: +- Bootstrap: Generate core steering from codebase (first-time) +- Sync: Keep steering and codebase aligned (maintenance) +- Preserve: User customizations are sacred, updates are additive + +**Success Criteria**: +- Steering captures patterns and principles, not exhaustive lists +- Code drift detected and reported +- All `{{KIRO_DIR}}/steering/*.md` treated equally (core + custom) + + + +## Scenario Detection + +Check `{{KIRO_DIR}}/steering/` status: + +**Bootstrap Mode**: Empty OR missing core files (product.md, tech.md, structure.md) +**Sync Mode**: All core files exist + + +## Bootstrap Flow + +1. Load templates from `{{KIRO_DIR}}/settings/templates/steering/` +2. Analyze codebase (JIT): + - `glob_file_search` for source files + - `read_file` for README, package.json, etc. + - `grep` for patterns +3. Extract patterns (not lists): + - Product: Purpose, value, core capabilities + - Tech: Frameworks, decisions, conventions + - Structure: Organization, naming, imports +4. Generate steering files (follow templates) +5. Load principles from `{{KIRO_DIR}}/settings/rules/steering-principles.md` +6. Present summary for review + +**Focus**: Patterns that guide decisions, not catalogs of files/dependencies. + + +## Sync Flow + +1. Load all existing steering (`{{KIRO_DIR}}/steering/*.md`) +2. Analyze codebase for changes (JIT) +3. Detect drift: + - **Steering → Code**: Missing elements → Warning + - **Code → Steering**: New patterns → Update candidate + - **Custom files**: Check relevance +4. Propose updates (additive, preserve user content) +5. Report: Updates, warnings, recommendations + +**Update Philosophy**: Add, don't replace. Preserve user sections. + + +## Granularity Principle + +From `{{KIRO_DIR}}/settings/rules/steering-principles.md`: + +> "If new code follows existing patterns, steering shouldn't need updating." + +Document patterns and principles, not exhaustive lists. + +**Bad**: List every file in directory tree +**Good**: Describe organization pattern with examples + + + +## Tool guidance + +- `glob_file_search`: Find source/config files +- `read_file`: Read steering, docs, configs +- `grep`: Search patterns +- `list_dir`: Analyze structure + +**JIT Strategy**: Fetch when needed, not upfront. + +## Output description + +Chat summary only (files updated directly). + +### Bootstrap: +``` +✅ Steering Created + +## Generated: +- product.md: [Brief description] +- tech.md: [Key stack] +- structure.md: [Organization] + +Review and approve as Source of Truth. +``` + +### Sync: +``` +✅ Steering Updated + +## Changes: +- tech.md: React 18 → 19 +- structure.md: Added API pattern + +## Code Drift: +- Components not following import conventions + +## Recommendations: +- Consider api-standards.md +``` + +## Examples + +### Bootstrap +**Input**: Empty steering, React TypeScript project +**Output**: 3 files with patterns - "Feature-first", "TypeScript strict", "React 19" + +### Sync +**Input**: Existing steering, new `/api` directory +**Output**: Updated structure.md, flagged non-compliant files, suggested api-standards.md + +## Safety & Fallback + +- **Security**: Never include keys, passwords, secrets (see principles) +- **Uncertainty**: Report both states, ask user +- **Preservation**: Add rather than replace when in doubt + +## Notes + +- All `{{KIRO_DIR}}/steering/*.md` loaded as project memory +- Templates and principles are external for customization +- Focus on patterns, not catalogs +- "Golden Rule": New code following patterns shouldn't require steering updates +- Avoid documenting agent-specific tooling directories (e.g. `.cursor/`, `.gemini/`, `.claude/`) +- `{{KIRO_DIR}}/settings/` content should NOT be documented in steering files (settings are metadata, not project knowledge) +- Light references to `{{KIRO_DIR}}/specs/` and `{{KIRO_DIR}}/steering/` are acceptable; avoid other `.kiro/` directories diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-design.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-design.md new file mode 100644 index 00000000..7f624bd0 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-design.md @@ -0,0 +1,91 @@ +--- +description: Interactive technical design quality review and validation +--- + + +# Technical Design Validation + + +- **Mission**: Conduct interactive quality review of technical design to ensure readiness for implementation +- **Success Criteria**: + - Critical issues identified (maximum 3 most important concerns) + - Balanced assessment with strengths recognized + - Clear GO/NO-GO decision with rationale + - Actionable feedback for improvements if needed + + + +## Core Task +Interactive design quality review for feature **$1** based on approved requirements and design document. + +## Execution Steps + +1. **Load Context**: + - Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata + - Read `{{KIRO_DIR}}/specs/$1/requirements.md` for requirements + - Read `{{KIRO_DIR}}/specs/$1/design.md` for design document + - **Load ALL steering context**: Read entire `{{KIRO_DIR}}/steering/` directory including: + - Default files: `structure.md`, `tech.md`, `product.md` + - All custom steering files (regardless of mode settings) + - This provides complete project memory and context + +2. **Read Review Guidelines**: + - Read `{{KIRO_DIR}}/settings/rules/design-review.md` for review criteria and process + +3. **Execute Design Review**: + - Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO + - Limit to 3 most important concerns + - Engage interactively with user + - Use language specified in spec.json for output + +4. **Provide Decision and Next Steps**: + - Clear GO/NO-GO decision with rationale + - Guide user on proceeding based on decision + +## Important Constraints +- **Quality assurance, not perfection seeking**: Accept acceptable risk +- **Critical focus only**: Maximum 3 issues, only those significantly impacting success +- **Interactive approach**: Engage in dialogue, not one-way evaluation +- **Balanced assessment**: Recognize both strengths and weaknesses +- **Actionable feedback**: All suggestions must be implementable + + +## Tool Guidance +- **Read first**: Load all context (spec, steering, rules) before review +- **Grep if needed**: Search codebase for pattern validation or integration checks +- **Interactive**: Engage with user throughout the review process + +## Output Description +Provide output in the language specified in spec.json with: + +1. **Review Summary**: Brief overview (2-3 sentences) of design quality and readiness +2. **Critical Issues**: Maximum 3, following design-review.md format +3. **Design Strengths**: 1-2 positive aspects +4. **Final Assessment**: GO/NO-GO decision with rationale and next steps + +**Format Requirements**: +- Use Markdown headings for clarity +- Follow design-review.md output format +- Keep summary concise + +## Safety & Fallback + +### Error Scenarios +- **Missing Design**: If design.md doesn't exist, stop with message: "Run `/kiro-spec-design $1` first to generate design document" +- **Design Not Generated**: If design phase not marked as generated in spec.json, warn but proceed with review +- **Empty Steering Directory**: Warn user that project context is missing and may affect review quality +- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language + +### Next Phase: Task Generation + +**If Design Passes Validation (GO Decision)**: +- Review feedback and apply changes if needed +- Run `/kiro-spec-tasks $1` to generate implementation tasks +- Or `/kiro-spec-tasks $1 -y` to auto-approve and proceed directly + +**If Design Needs Revision (NO-GO Decision)**: +- Address critical issues identified +- Re-run `/kiro-spec-design $1` with improvements +- Re-validate with `/kiro-validate-design $1` + +**Note**: Design validation is recommended but optional. Quality review helps catch issues early. diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-gap.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-gap.md new file mode 100644 index 00000000..34772152 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-gap.md @@ -0,0 +1,87 @@ +--- +description: Analyze implementation gap between requirements and existing codebase +--- + + +# Implementation Gap Validation + + +- **Mission**: Analyze the gap between requirements and existing codebase to inform implementation strategy +- **Success Criteria**: + - Comprehensive understanding of existing codebase patterns and components + - Clear identification of missing capabilities and integration challenges + - Multiple viable implementation approaches evaluated + - Technical research needs identified for design phase + + + +## Core Task +Analyze implementation gap for feature **$1** based on approved requirements and existing codebase. + +## Execution Steps + +1. **Load Context**: + - Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata + - Read `{{KIRO_DIR}}/specs/$1/requirements.md` for requirements + - **Load ALL steering context**: Read entire `{{KIRO_DIR}}/steering/` directory including: + - Default files: `structure.md`, `tech.md`, `product.md` + - All custom steering files (regardless of mode settings) + - This provides complete project memory and context + +2. **Read Analysis Guidelines**: + - Read `{{KIRO_DIR}}/settings/rules/gap-analysis.md` for comprehensive analysis framework + +3. **Execute Gap Analysis**: + - Follow gap-analysis.md framework for thorough investigation + - Analyze existing codebase using Grep and Read tools + - Use WebSearch/WebFetch for external dependency research if needed + - Evaluate multiple implementation approaches (extend/new/hybrid) + - Use language specified in spec.json for output + +4. **Generate Analysis Document**: + - Create comprehensive gap analysis following the output guidelines in gap-analysis.md + - Present multiple viable options with trade-offs + - Flag areas requiring further research + +## Important Constraints +- **Information over Decisions**: Provide analysis and options, not final implementation choices +- **Multiple Options**: Present viable alternatives when applicable +- **Thorough Investigation**: Use tools to deeply understand existing codebase +- **Explicit Gaps**: Clearly flag areas needing research or investigation + + +## Tool Guidance +- **Read first**: Load all context (spec, steering, rules) before analysis +- **Grep extensively**: Search codebase for patterns, conventions, and integration points +- **WebSearch/WebFetch**: Research external dependencies and best practices when needed +- **Write last**: Generate analysis only after complete investigation + +## Output Description +Provide output in the language specified in spec.json with: + +1. **Analysis Summary**: Brief overview (3-5 bullets) of scope, challenges, and recommendations +2. **Document Status**: Confirm analysis approach used +3. **Next Steps**: Guide user on proceeding to design phase + +**Format Requirements**: +- Use Markdown headings for clarity +- Keep summary concise (under 300 words) +- Detailed analysis follows gap-analysis.md output guidelines + +## Safety & Fallback + +### Error Scenarios +- **Missing Requirements**: If requirements.md doesn't exist, stop with message: "Run `/kiro-spec-requirements $1` first to generate requirements" +- **Requirements Not Approved**: If requirements not approved, warn user but proceed (gap analysis can inform requirement revisions) +- **Empty Steering Directory**: Warn user that project context is missing and may affect analysis quality +- **Complex Integration Unclear**: Flag for comprehensive research in design phase rather than blocking +- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language + +### Next Phase: Design Generation + +**If Gap Analysis Complete**: +- Review gap analysis insights +- Run `/kiro-spec-design $1` to create technical design document +- Or `/kiro-spec-design $1 -y` to auto-approve requirements and proceed directly + +**Note**: Gap analysis is optional but recommended for brownfield projects to inform design decisions. diff --git a/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-impl.md b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-impl.md new file mode 100644 index 00000000..15b69c30 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/commands/kiro-validate-impl.md @@ -0,0 +1,137 @@ +--- +description: Validate implementation against requirements, design, and tasks +--- + + +# Implementation Validation + + +- **Mission**: Verify that implementation aligns with approved requirements, design, and tasks +- **Success Criteria**: + - All specified tasks marked as completed + - Tests exist and pass for implemented functionality + - Requirements traceability confirmed (EARS requirements covered) + - Design structure reflected in implementation + - No regressions in existing functionality + + + +## Core Task +Validate implementation for feature(s) and task(s) based on approved specifications. + +## Execution Steps + +### 1. Detect Validation Target + +**If no arguments provided** (`$1` empty): +- Parse conversation history for `/kiro-spec-impl [tasks]` commands +- Extract feature names and task numbers from each execution +- Aggregate all implemented tasks by feature +- Report detected implementations (e.g., "user-auth: 1.1, 1.2, 1.3") +- If no history found, scan `{{KIRO_DIR}}/specs/` for features with completed tasks `[x]` + +**If feature provided** (`$1` present, `$2` empty): +- Use specified feature +- Detect all completed tasks `[x]` in `{{KIRO_DIR}}/specs/$1/tasks.md` + +**If both feature and tasks provided** (`$1` and `$2` present): +- Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`) + +### 2. Load Context + +For each detected feature: +- Read `{{KIRO_DIR}}/specs//spec.json` for metadata +- Read `{{KIRO_DIR}}/specs//requirements.md` for requirements +- Read `{{KIRO_DIR}}/specs//design.md` for design structure +- Read `{{KIRO_DIR}}/specs//tasks.md` for task list +- **Load ALL steering context**: Read entire `{{KIRO_DIR}}/steering/` directory including: + - Default files: `structure.md`, `tech.md`, `product.md` + - All custom steering files (regardless of mode settings) + +### 3. Execute Validation + +For each task, verify: + +#### Task Completion Check +- Checkbox is `[x]` in tasks.md +- If not completed, flag as "Task not marked complete" + +#### Test Coverage Check +- Tests exist for task-related functionality +- Tests pass (no failures or errors) +- Use Bash to run test commands (e.g., `npm test`, `pytest`) +- If tests fail or don't exist, flag as "Test coverage issue" + +#### Requirements Traceability +- Identify EARS requirements related to the task +- Use Grep to search implementation for evidence of requirement coverage +- If requirement not traceable to code, flag as "Requirement not implemented" + +#### Design Alignment +- Check if design.md structure is reflected in implementation +- Verify key interfaces, components, and modules exist +- Use Grep/LS to confirm file structure matches design +- If misalignment found, flag as "Design deviation" + +#### Regression Check +- Run full test suite (if available) +- Verify no existing tests are broken +- If regressions detected, flag as "Regression detected" + +### 4. Generate Report + +Provide summary in the language specified in spec.json: +- Validation summary by feature +- Coverage report (tasks, requirements, design) +- Issues and deviations with severity (Critical/Warning) +- GO/NO-GO decision + +## Important Constraints +- **Conversation-aware**: Prioritize conversation history for auto-detection +- **Non-blocking warnings**: Design deviations are warnings unless critical +- **Test-first focus**: Test coverage is mandatory for GO decision +- **Traceability required**: All requirements must be traceable to implementation + + +## Tool Guidance +- **Conversation parsing**: Extract `/kiro-spec-impl` patterns from history +- **Read context**: Load all specs and steering before validation +- **Bash for tests**: Execute test commands to verify pass status +- **Grep for traceability**: Search codebase for requirement evidence +- **LS/Glob for structure**: Verify file structure matches design + +## Output Description + +Provide output in the language specified in spec.json with: + +1. **Detected Target**: Features and tasks being validated (if auto-detected) +2. **Validation Summary**: Brief overview per feature (pass/fail counts) +3. **Issues**: List of validation failures with severity and location +4. **Coverage Report**: Requirements/design/task coverage percentages +5. **Decision**: GO (ready for next phase) / NO-GO (needs fixes) + +**Format Requirements**: +- Use Markdown headings and tables for clarity +- Flag critical issues with ⚠️ or 🔴 +- Keep summary concise (under 400 words) + +## Safety & Fallback + +### Error Scenarios +- **No Implementation Found**: If no `/kiro-spec-impl` in history and no `[x]` tasks, report "No implementations detected" +- **Test Command Unknown**: If test framework unclear, warn and skip test validation (manual verification required) +- **Missing Spec Files**: If spec.json/requirements.md/design.md missing, stop with error +- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language + +### Next Steps Guidance + +**If GO Decision**: +- Implementation validated and ready +- Proceed to deployment or next feature + +**If NO-GO Decision**: +- Address critical issues listed +- Re-run `/kiro-spec-impl [tasks]` for fixes +- Re-validate with `/kiro-validate-impl [feature] [tasks]` + +**Note**: Validation is recommended after implementation to ensure spec alignment and quality. diff --git a/tools/cc-sdd/templates/agents/opencode/docs/AGENTS.md b/tools/cc-sdd/templates/agents/opencode/docs/AGENTS.md new file mode 100644 index 00000000..e4c91f10 --- /dev/null +++ b/tools/cc-sdd/templates/agents/opencode/docs/AGENTS.md @@ -0,0 +1,45 @@ +# AI-DLC and Spec-Driven Development + +Kiro-style Spec Driven Development implementation on AI-DLC (AI Development Life Cycle) + +## Project Context + +### Paths +- Steering: `{{KIRO_DIR}}/steering/` +- Specs: `{{KIRO_DIR}}/specs/` + +### Steering vs Specification + +**Steering** (`{{KIRO_DIR}}/steering/`) - Guide AI with project-wide rules and context +**Specs** (`{{KIRO_DIR}}/specs/`) - Formalize development process for individual features + +### Active Specifications +- Check `{{KIRO_DIR}}/specs/` for active specifications +- Use `/kiro-spec-status [feature-name]` to check progress + +## Development Guidelines +{{DEV_GUIDELINES}} + +## Minimal Workflow +- Phase 0 (optional): `/kiro-steering`, `/kiro-steering-custom` +- Phase 1 (Specification): + - `/kiro-spec-init "description"` + - `/kiro-spec-requirements {feature}` + - `/kiro-validate-gap {feature}` (optional: for existing codebase) + - `/kiro-spec-design {feature} [-y]` + - `/kiro-validate-design {feature}` (optional: design review) + - `/kiro-spec-tasks {feature} [-y]` +- Phase 2 (Implementation): `/kiro-spec-impl {feature} [tasks]` + - `/kiro-validate-impl {feature}` (optional: after implementation) +- Progress check: `/kiro-spec-status {feature}` (use anytime) + +## Development Rules +- 3-phase approval workflow: Requirements → Design → Tasks → Implementation +- Human review required each phase; use `-y` only for intentional fast-track +- Keep steering current and verify alignment with `/kiro-spec-status` +- Follow the user's instructions precisely, and within that scope act autonomously: gather the necessary context and complete the requested work end-to-end in this run, asking questions only when essential information is missing or the instructions are critically ambiguous. + +## Steering Configuration +- Load entire `{{KIRO_DIR}}/steering/` as project memory +- Default files: `product.md`, `tech.md`, `structure.md` +- Custom files are supported (managed via `/kiro-steering-custom`) diff --git a/tools/cc-sdd/templates/manifests/opencode.json b/tools/cc-sdd/templates/manifests/opencode.json new file mode 100644 index 00000000..ad305a5d --- /dev/null +++ b/tools/cc-sdd/templates/manifests/opencode.json @@ -0,0 +1,33 @@ +{ + "version": 1, + "artifacts": [ + { + "id": "commands", + "source": { + "type": "templateDir", + "fromDir": "templates/agents/{{AGENT}}/commands", + "toDir": "{{AGENT_COMMANDS_DIR}}" + }, + "when": { "agent": "opencode" } + }, + { + "id": "doc_main", + "source": { + "type": "templateFile", + "from": "templates/agents/{{AGENT}}/docs/AGENTS.md", + "toDir": ".", + "rename": "{{AGENT_DOC}}" + }, + "when": { "agent": "opencode" } + }, + { + "id": "settings_common", + "source": { + "type": "templateDir", + "fromDir": "templates/shared/settings", + "toDir": "{{KIRO_DIR}}/settings" + }, + "when": { "agent": "opencode" } + } + ] +} \ No newline at end of file diff --git a/tools/cc-sdd/test/agentLayout.test.ts b/tools/cc-sdd/test/agentLayout.test.ts index 1ae033a5..8645191f 100644 --- a/tools/cc-sdd/test/agentLayout.test.ts +++ b/tools/cc-sdd/test/agentLayout.test.ts @@ -50,4 +50,13 @@ describe('resolveAgentLayout', () => { }); }); + it('returns opencode defaults', () => { + const res = resolveAgentLayout('opencode'); + expect(res).toEqual({ + commandsDir: '.opencode/commands', + agentDir: '.opencode', + docFile: 'AGENTS.md', + }); + }); + }); diff --git a/tools/cc-sdd/test/realManifestOpencode.test.ts b/tools/cc-sdd/test/realManifestOpencode.test.ts new file mode 100644 index 00000000..419f32ee --- /dev/null +++ b/tools/cc-sdd/test/realManifestOpencode.test.ts @@ -0,0 +1,102 @@ +import { describe, it, expect } from 'vitest'; +import { runCli } from '../src/index'; +import { mkdtemp, readFile, stat } from 'node:fs/promises'; +import { tmpdir } from 'node:os'; +import { join } from 'node:path'; + +const runtime = { platform: 'darwin' } as const; + +const makeIO = () => { + const logs: string[] = []; + const errs: string[] = []; + return { + io: { + log: (m: string) => logs.push(m), + error: (m: string) => errs.push(m), + exit: (_c: number) => { }, + }, + get logs() { + return logs; + }, + get errs() { + return errs; + }, + }; +}; + +const mkTmp = async () => mkdtemp(join(tmpdir(), 'ccsdd-real-manifest-')); +const exists = async (p: string) => { try { await stat(p); return true; } catch { return false; } }; + +// vitest runs in tools/cc-sdd; repoRoot is two levels up +const repoRoot = join(process.cwd(), '..', '..'); +const manifestPath = join(repoRoot, 'tools/cc-sdd/templates/manifests/opencode.json'); + +describe('real opencode manifest', () => { + it('dry-run prints plan for opencode.json with placeholders applied', async () => { + const ctx = makeIO(); + const code = await runCli(['--dry-run', '--lang', 'en', '--agent', 'opencode', '--manifest', manifestPath], runtime, ctx.io, {}); + expect(code).toBe(0); + const out = ctx.logs.join('\n'); + expect(out).toMatch(/Plan \(dry-run\)/); + expect(out).toContain('[templateDir] commands: templates/agents/opencode/commands -> .opencode/commands'); + expect(out).toContain('[templateFile] doc_main: templates/agents/opencode/docs/AGENTS.md -> ./AGENTS.md'); + expect(out).toContain('[templateDir] settings_common: templates/shared/settings -> .kiro/settings'); + }); + + it('apply writes AGENTS.md and command files to cwd', async () => { + const cwd = await mkTmp(); + const ctx = makeIO(); + const code = await runCli(['--lang', 'en', '--agent', 'opencode', '--manifest', manifestPath, '--overwrite=force'], runtime, ctx.io, {}, { cwd, templatesRoot: process.cwd() }); + expect(code).toBe(0); + + const doc = join(cwd, 'AGENTS.md'); + expect(await exists(doc)).toBe(true); + const text = await readFile(doc, 'utf8'); + expect(text).toMatch(/# AI-DLC and Spec-Driven Development/); + expect(text).toContain('Steering: `.kiro/steering/`'); + + const cmd = join(cwd, '.opencode/commands/kiro-spec-init.md'); + expect(await exists(cmd)).toBe(true); + + const settingsRule = join(cwd, '.kiro/settings/rules/design-principles.md'); + expect(await exists(settingsRule)).toBe(true); + + expect(ctx.logs.join('\n')).toMatch(/Setup completed: written=\d+, skipped=\d+/); + }); +}); + +describe('real opencode manifest (linux)', () => { + const runtimeLinux = { platform: 'linux' } as const; + + it('dry-run prints plan including commands for linux via windows template', async () => { + const ctx = makeIO(); + const code = await runCli(['--dry-run', '--lang', 'en', '--agent', 'opencode', '--manifest', manifestPath], runtimeLinux, ctx.io, {}); + expect(code).toBe(0); + const out = ctx.logs.join('\n'); + expect(out).toMatch(/Plan \(dry-run\)/); + expect(out).toContain('[templateDir] commands: templates/agents/opencode/commands -> .opencode/commands'); + expect(out).toContain('[templateFile] doc_main: templates/agents/opencode/docs/AGENTS.md -> ./AGENTS.md'); + expect(out).toContain('[templateDir] settings_common: templates/shared/settings -> .kiro/settings'); + }); + + it('apply writes AGENTS.md and command files to cwd on linux', async () => { + const cwd = await mkTmp(); + const ctx = makeIO(); + const code = await runCli(['--lang', 'en', '--agent', 'opencode', '--manifest', manifestPath, '--overwrite=force'], runtimeLinux, ctx.io, {}, { cwd, templatesRoot: process.cwd() }); + expect(code).toBe(0); + + const doc = join(cwd, 'AGENTS.md'); + expect(await exists(doc)).toBe(true); + const text = await readFile(doc, 'utf8'); + expect(text).toMatch(/# AI-DLC and Spec-Driven Development/); + expect(text).toContain('Steering: `.kiro/steering/`'); + + const cmd = join(cwd, '.opencode/commands/kiro-spec-init.md'); + expect(await exists(cmd)).toBe(true); + + const settingsTemplate = join(cwd, '.kiro/settings/templates/specs/init.json'); + expect(await exists(settingsTemplate)).toBe(true); + + expect(ctx.logs.join('\n')).toMatch(/Setup completed: written=\d+, skipped=\d+/); + }); +}); \ No newline at end of file