How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

sdp-design-legacy - Prompt

Name: sdp-design-legacy
Author: Basio0916

Prompt file imported from Basio0916/spec-driven-planning (.windsurf/workflows/sdp-design-legacy.md). Fill in {{slug}} before use. Copyright stays with the author.

SDP Design Generation

Generate a detailed design document with decision rationale for a given requirement.

Input

slug: An existing requirement folder at .sdp/specs/<slug>/ containing requirement.md
Usage Example: /sdp-design add-user-authentication

Language Configuration

Read .sdp/config/language.yml to determine the output language:

If language: en, generate all content in English
If language: ja, generate all content in Japanese

Use templates from .sdp/templates/<lang>/ directory based on the configured language.

Context Files

Read these for context:

.sdp/specs/{{slug}}/requirement.md - The requirement to design
.sdp/tech.md - Technical stack and constraints
.sdp/structure.md - Code structure and architecture
.sdp/product.md - Business context and goals

Pre-Check

Before starting, verify that:

.sdp/specs/{{slug}}/ directory exists
.sdp/specs/{{slug}}/requirement.md file exists

Report errors if requirements are missing.

Design Process

1. Understand the Requirement

Read and analyze the requirement thoroughly
Extract key constraints from NFRs (security, performance, etc.)
Identify technical boundaries from .sdp/tech.md

2. Generate Design Alternatives

Propose 2-4 alternative design approaches. For each alternative:

Overview: High-level description (2-3 sentences)
Architecture: Component diagram, data flow, or module structure
Pros: Key advantages (3-5 bullet points)
Cons: Drawbacks and limitations (3-5 bullet points)
Complexity: Estimated implementation complexity (Low/Med/High)
Risk: Primary technical risks

3. Comparative Analysis

Create a comparison table covering:

Implementation effort
Maintainability
Performance characteristics
Scalability
Team familiarity
Technical debt implications

4. Recommended Solution

Selection rationale: Why this design was chosen (1-2 paragraphs)
Trade-offs: What we're sacrificing and why it's acceptable
Detailed design: Architecture, data models, APIs, integration points
Implementation notes: Key technical decisions and guidelines

Deliverable

Create .sdp/specs/{{slug}}/design.md following .sdp/templates/<lang>/design.md structure (use the language-specific template).

IMPORTANT - Response Length Management: If the design document is expected to be very long and may exceed response limit:

First, create the file with sections 1-4 (Overview through Recommended Solution)
Inform the user that detailed design sections will be added next
Wait for user confirmation, then append sections 5-8 (Detailed Design through Open Questions)
Use replace_string_in_file to append content, NOT rewrite the entire file

Design Document Structure

The output must include:

Phase 1 (Core Design):

Overview: Summary of what's being designed
Design Alternatives: 2-4 alternative approaches with pros/cons
Comparison Matrix: Side-by-side comparison table
Recommended Solution: Selected design with rationale

Phase 2 (Implementation Details): 5. Detailed Design: Architecture, data models, APIs, etc. 6. Trade-offs & Risks: What we're accepting and why 7. Implementation Guidelines: Technical decisions and conventions 8. Open Questions: Unresolved items requiring user input (if any)

Output Format

Generate all content based on the configured language (.sdp/config/language.yml).

For Phase 1 (Core Design) - After creating the initial file:

【設計（フェーズ1）完了】
📐 Slug: <slug>
📝 タイトル: <設計タイトル>
📁 ファイル: .sdp/specs/<slug>/design.md

📊 検討した設計案: <数>
✅ 採用案: <採用した設計名>
📌 主要な判断理由: <1行要約>

💡 次のステップ:
  - 続けて詳細設計セクション（データモデル、API設計など）を追加する場合は「続けてください」と入力
  - または設計内容を確認し、修正が必要な場合は自然言語で指示してください

For Phase 2 (Implementation Details) - After completing all sections:

【設計完了】
📐 Slug: <slug>
📝 タイトル: <設計タイトル>
📁 ファイル: .sdp/specs/<slug>/design.md

✅ すべてのセクションが完成しました

💡 次のステップ:
  - 設計内容を確認し、修正が必要な場合は自然言語で指示してください
  - 設計が確定したら /sdp-estimate でタスク分解を実行してください

User Iteration Support

After generating the design:

User can provide natural language feedback
Update the design document based on feedback
Maintain version notes in the document
Re-evaluate alternatives if requested

Allowed Tools

Read, Write, Edit, File Search, Grep only

Install sdp-design-legacy and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# SDP Design Generation Generate a detailed design document with decision rationale for a given requirement. ## Input - **slug**: An existing requirement folder at `.sdp/specs/<slug>/` containing `requirement.md` - **Usage Example**: `/sdp-design add-user-authentication` ## Language Configuration Read `.sdp/config/language.yml` to determine the output language: - If `language: en`, generate all content in **English** - If `language: ja`, generate all content in **Japanese** Use templates from `.sdp/templates/<lang>/` directory based on the configured language. ## Context Files Read these for context: - `.sdp/specs/{{slug}}/requirement.md` - The requirement to design - `.sdp/tech.md` - Technical stack and constraints - `.sdp/structure.md` - Code structure and architecture - `.sdp/product.md` - Business context and goals ## Pre-Check Before starting, verify that: - `.sdp/specs/{{slug}}/` directory exists - `.sdp/specs/{{slug}}/requirement.md` file exists Report errors if requirements are missing. ## Design Process ### 1. Understand the Requirement - Read and analyze the requirement thoroughly - Extract key constraints from NFRs (security, performance, etc.) - Identify technical boundaries from `.sdp/tech.md` ### 2. Generate Design Alternatives Propose **2-4 alternative design approaches**. For each alternative: - **Overview**: High-level description (2-3 sentences) - **Architecture**: Component diagram, data flow, or module structure - **Pros**: Key advantages (3-5 bullet points) - **Cons**: Drawbacks and limitations (3-5 bullet points) - **Complexity**: Estimated implementation complexity (Low/Med/High) - **Risk**: Primary technical risks ### 3. Comparative Analysis Create a comparison table covering: - Implementation effort - Maintainability - Performance characteristics - Scalability - Team familiarity - Technical debt implications ### 4. Recommended Solution - **Selection rationale**: Why this design was chosen (1-2 paragraphs) - **Trade-offs**: What we're sacrificing and why it's acceptable - **Detailed design**: Architecture, data models, APIs, integration points - **Implementation notes**: Key technical decisions and guidelines ## Deliverable Create `.sdp/specs/{{slug}}/design.md` following `.sdp/templates/<lang>/design.md` structure (use the language-specific template). **IMPORTANT - Response Length Management:** If the design document is expected to be very long and may exceed response limit: 1. First, create the file with sections 1-4 (Overview through Recommended Solution) 2. Inform the user that detailed design sections will be added next 3. Wait for user confirmation, then append sections 5-8 (Detailed Design through Open Questions) 4. Use `replace_string_in_file` to append content, NOT rewrite the entire file ## Design Document Structure The output must include: **Phase 1 (Core Design):** 1. **Overview**: Summary of what's being designed 2. **Design Alternatives**: 2-4 alternative approaches with pros/cons 3. **Comparison Matrix**: Side-by-side comparison table 4. **Recommended Solution**: Selected design with rationale **Phase 2 (Implementation Details):** 5. **Detailed Design**: Architecture, data models, APIs, etc. 6. **Trade-offs & Risks**: What we're accepting and why 7. **Implementation Guidelines**: Technical decisions and conventions 8. **Open Questions**: Unresolved items requiring user input (if any) ## Output Format Generate all content based on the configured language (`.sdp/config/language.yml`). **For Phase 1 (Core Design) - After creating the initial file:** ``` 【設計（フェーズ1）完了】 📐 Slug: <slug> 📝 タイトル: <設計タイトル> 📁 ファイル: .sdp/specs/<slug>/design.md 📊 検討した設計案: <数> ✅ 採用案: <採用した設計名> 📌 主要な判断理由: <1行要約> 💡 次のステップ: - 続けて詳細設計セクション（データモデル、API設計など）を追加する場合は「続けてください」と入力 - または設計内容を確認し、修正が必要な場合は自然言語で指示してください ``` **For Phase 2 (Implementation Details) - After completing all sections:** ``` 【設計完了】 📐 Slug: <slug> 📝 タイトル: <設計タイトル> 📁 ファイル: .sdp/specs/<slug>/design.md ✅ すべてのセクションが完成しました 💡 次のステップ: - 設計内容を確認し、修正が必要な場合は自然言語で指示してください - 設計が確定したら /sdp-estimate でタスク分解を実行してください ``` ## User Iteration Support After generating the design: - User can provide natural language feedback - Update the design document based on feedback - Maintain version notes in the document - Re-evaluate alternatives if requested ## Allowed Tools Read, Write, Edit, File Search, Grep only

{ "prompt": "# SDP Design Generation\n\nGenerate a detailed design document with decision rationale for a given requirement.\n\n## Input\n\n- **slug**: An existing requirement folder at `.sdp/specs/<slug>/` containing `requirement.md`\n- **Usage Example**: `/sdp-design add-user-authentication`\n\n## Language Configuration\n\nRead `.sdp/config/language.yml` to determine the output language:\n- If `language: en`, generate all content in **English**\n- If `language: ja`, generate all content in **Japanese**\n\nUse templates from `.sdp/templates/<lang>/` directory based on the configured language.\n\n## Context Files\n\nRead these for context:\n- `.sdp/specs/{{slug}}/requirement.md` - The requirement to design\n- `.sdp/tech.md` - Technical stack and constraints\n- `.sdp/structure.md` - Code structure and architecture\n- `.sdp/product.md` - Business context and goals\n\n## Pre-Check\n\nBefore starting, verify that:\n- `.sdp/specs/{{slug}}/` directory exists\n- `.sdp/specs/{{slug}}/requirement.md` file exists\n\nReport errors if requirements are missing.\n\n## Design Process\n\n### 1. Understand the Requirement\n\n- Read and analyze the requirement thoroughly\n- Extract key constraints from NFRs (security, performance, etc.)\n- Identify technical boundaries from `.sdp/tech.md`\n\n### 2. Generate Design Alternatives\n\nPropose **2-4 alternative design approaches**. For each alternative:\n\n- **Overview**: High-level description (2-3 sentences)\n- **Architecture**: Component diagram, data flow, or module structure\n- **Pros**: Key advantages (3-5 bullet points)\n- **Cons**: Drawbacks and limitations (3-5 bullet points)\n- **Complexity**: Estimated implementation complexity (Low/Med/High)\n- **Risk**: Primary technical risks\n\n### 3. Comparative Analysis\n\nCreate a comparison table covering:\n- Implementation effort\n- Maintainability\n- Performance characteristics\n- Scalability\n- Team familiarity\n- Technical debt implications\n\n### 4. Recommended Solution\n\n- **Selection rationale**: Why this design was chosen (1-2 paragraphs)\n- **Trade-offs**: What we're sacrificing and why it's acceptable\n- **Detailed design**: Architecture, data models, APIs, integration points\n- **Implementation notes**: Key technical decisions and guidelines\n\n## Deliverable\n\nCreate `.sdp/specs/{{slug}}/design.md` following `.sdp/templates/<lang>/design.md` structure (use the language-specific template).\n\n**IMPORTANT - Response Length Management:**\nIf the design document is expected to be very long and may exceed response limit:\n1. First, create the file with sections 1-4 (Overview through Recommended Solution)\n2. Inform the user that detailed design sections will be added next\n3. Wait for user confirmation, then append sections 5-8 (Detailed Design through Open Questions)\n4. Use `replace_string_in_file` to append content, NOT rewrite the entire file\n\n## Design Document Structure\n\nThe output must include:\n\n**Phase 1 (Core Design):**\n1. **Overview**: Summary of what's being designed\n2. **Design Alternatives**: 2-4 alternative approaches with pros/cons\n3. **Comparison Matrix**: Side-by-side comparison table\n4. **Recommended Solution**: Selected design with rationale\n\n**Phase 2 (Implementation Details):**\n5. **Detailed Design**: Architecture, data models, APIs, etc.\n6. **Trade-offs & Risks**: What we're accepting and why\n7. **Implementation Guidelines**: Technical decisions and conventions\n8. **Open Questions**: Unresolved items requiring user input (if any)\n\n## Output Format\n\nGenerate all content based on the configured language (`.sdp/config/language.yml`).\n\n**For Phase 1 (Core Design) - After creating the initial file:**\n\n```\n【設計（フェーズ1）完了】\n📐 Slug: <slug>\n📝 タイトル: <設計タイトル>\n📁 ファイル: .sdp/specs/<slug>/design.md\n\n📊 検討した設計案: <数>\n✅ 採用案: <採用した設計名>\n📌 主要な判断理由: <1行要約>\n\n💡 次のステップ:\n - 続けて詳細設計セクション（データモデル、API設計など）を追加する場合は「続けてください」と入力\n - または設計内容を確認し、修正が必要な場合は自然言語で指示してください\n```\n\n**For Phase 2 (Implementation Details) - After completing all sections:**\n\n```\n【設計完了】\n📐 Slug: <slug>\n📝 タイトル: <設計タイトル>\n📁 ファイル: .sdp/specs/<slug>/design.md\n\n✅ すべてのセクションが完成しました\n\n💡 次のステップ:\n - 設計内容を確認し、修正が必要な場合は自然言語で指示してください\n - 設計が確定したら /sdp-estimate でタスク分解を実行してください\n```\n\n## User Iteration Support\n\nAfter generating the design:\n- User can provide natural language feedback\n- Update the design document based on feedback\n- Maintain version notes in the document\n- Re-evaluate alternatives if requested\n\n## Allowed Tools\n\nRead, Write, Edit, File Search, Grep only", "variables": [ "slug" ], "notes": "Generate a detailed design document with decision rationale for a given requirement Mode: agent.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/Basio0916/spec-driven-planning", "path": ".windsurf/workflows/sdp-design-legacy.md", "ref": "f07eb62df7be33395bb2db35eba02b0a1271b7f6", "url": "https://github.com/Basio0916/spec-driven-planning/blob/f07eb62df7be33395bb2db35eba02b0a1271b7f6/.windsurf/workflows/sdp-design-legacy.md", "key": "Basio0916/spec-driven-planning/.windsurf/workflows/sdp-design-legacy.md" } } }

sdp-design-legacy

About