📦 その他コミュニティ

tech-design-doc

適切な構成、図表、実装詳細を含む技術設計書を、英語またはユーザーが指定する中国語で作成し、システム開発や改善に必要なドキュメント作成を効率化するSkill。

📜 元の英語説明(参考)

Generate technical design documents with proper structure, diagrams, and implementation details. Default language is English unless user requests Chinese.

🇯🇵 日本人クリエイター向け解説

一言でいうと

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux

mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o tech-design-doc.zip https://jpskill.com/download/9214.zip && unzip -o tech-design-doc.zip && rm tech-design-doc.zip

🪟 Windows (PowerShell)

$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9214.zip -OutFile "$d\tech-design-doc.zip"; Expand-Archive "$d\tech-design-doc.zip" -DestinationPath $d -Force; ri "$d\tech-design-doc.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)

1. 下の青いボタンを押して tech-design-doc.zip をダウンロード
2. ZIPファイルをダブルクリックで解凍 → tech-design-doc フォルダができる
3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
4. Claude Code を再起動

⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-18
取得日時: 2026-05-18
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Technical Design Document Skill

活用場面

新しい機能やシステムを設計する際
アーキテクチャに関する決定事項を文書化する際 (ADR/RFC)
リファクタリングや最適化作業を計画する際

実行フロー

1. 複雑さの評価

レベル	範囲	必要なセクション
小	単一コンポーネント、100 LOC 未満	TL;DR、Design、Implementation
中	複数コンポーネント、API の変更	+ Background、Solution Analysis
大	システムレベル、新規サービス	フルテンプレート

2. コンテキストの収集

記述する前に、コードベースを調査します。

影響を受けるコンポーネントを特定する (grep/glob で関連コードを検索)
既存の実装とパターンを読み込む
依存関係と潜在的な副作用をメモする
コードベースに同様のソリューションが既に存在するか確認する

3. ドキュメントの作成

以下のテンプレート構造に従い、複雑さのレベルに合わせて調整します。

4. 引き渡し前の確認

[ ] 問題が明確に定義されているか (何もしなければ何が問題になるか？)
[ ] 複数の選択肢がトレードオフとともに比較されているか (単一の解決策だけではないか)
[ ] 決定の根拠が文書化されているか
[ ] 図が主要なフローを示しているか
[ ] 実装手順が具体的で実行可能か
[ ] リスクが軽減策とともに特定されているか

ドキュメントテンプレート

# [Feature/System Name] Technical Design

## TL;DR
- 3〜5 個の箇条書き: 問題、解決策、主要な決定事項、期待される結果

## Background (Medium/Large)

### Current State
- 既存の動作と制限事項

### Problem Statement
- 何もしなければ何が問題になるか？
- 誰がどのように影響を受けるか？

### Goals / Non-Goals
- Goals: この設計で達成すること
- Non-Goals: 明示的に範囲外のこと

## Solution Analysis (Medium/Large)

### Option 1: [Name]
Pros: ...
Cons: ...

### Option 2: [Name]
Pros: ...
Cons: ...

### Comparison
| Criteria | Option 1 | Option 2 |
|----------|----------|----------|
| Performance | ... | ... |
| Complexity | ... | ... |

### Recommendation
Selected: Option X
Rationale: [why]

## Detailed Design

### Architecture
[Mermaid diagram - 以下の例を参照]

### Component Design
- 責任
- インターフェース
- 依存関係

### Data Model (該当する場合)
[スキーマまたは構造]

### API Design (該当する場合)
[エンドポイント、リクエスト/レスポンス]

## Implementation Plan

### Phase 1: [Name]
- [ ] Task 1
- [ ] Task 2

### Migration Strategy (該当する場合)

## Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| ... | High/Med/Low | High/Med/Low | ... |

## References
- 関連ドキュメント、外部リソース

Mermaid ダイアグラムの例

アーキテクチャ (フローチャート):

flowchart TD
    A[Client] --> B[API Gateway]
    B --> C[Service]
    C --> D[(Database)]

シーケンス:

sequenceDiagram
    Client->>Server: Request
    Server->>DB: Query
    DB-->>Server: Result
    Server-->>Client: Response

状態:

stateDiagram-v2
    [*] --> Pending
    Pending --> Processing: start
    Processing --> Done: complete
    Processing --> Failed: error

フィードバックの処理

ユーザーが変更を要求する場合:

どのセクションを修正する必要があるかを理解する
影響を受けるセクションのみを更新する
変更が他のセクションと矛盾しないことを確認する
変更に関連するチェックリスト項目を再確認する

出力場所

プロジェクトに docs/、ai_docs/、または design/ ディレクトリがあるか確認する
場所が不明確な場合は、ユーザーに確認する
説明的なファイル名を使用する: design-[feature-name].md

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Technical Design Document Skill

When to Use

Designing a new feature or system
Documenting architecture decisions (ADR/RFC)
Planning refactoring or optimization work

Execution Flow

1. Assess Complexity

Level	Scope	Sections Required
Small	Single component, <100 LOC	TL;DR, Design, Implementation
Medium	Cross-component, API changes	+ Background, Solution Analysis
Large	System-level, new service	Full template

2. Gather Context

Before writing, explore the codebase:

Identify affected components (grep/glob for related code)
Read existing implementations and patterns
Note dependencies and potential side effects
Check for similar solutions already in codebase

3. Write Document

Follow the template structure below, scaled to complexity level.

4. Verify Before Handoff

[ ] Problem clearly defined (what breaks if we do nothing?)
[ ] Options compared with trade-offs (not just one solution)
[ ] Decision rationale documented
[ ] Diagrams illustrate key flows
[ ] Implementation steps are concrete and actionable
[ ] Risks identified with mitigations

Document Template

# [Feature/System Name] Technical Design

## TL;DR
- 3-5 bullets: problem, solution, key decisions, expected outcome

## Background (Medium/Large)

### Current State
- Existing behavior and limitations

### Problem Statement
- What breaks if we do nothing?
- Who is affected and how?

### Goals / Non-Goals
- Goals: what this design achieves
- Non-Goals: explicitly out of scope

## Solution Analysis (Medium/Large)

### Option 1: [Name]
Pros: ...
Cons: ...

### Option 2: [Name]
Pros: ...
Cons: ...

### Comparison
| Criteria | Option 1 | Option 2 |
|----------|----------|----------|
| Performance | ... | ... |
| Complexity | ... | ... |

### Recommendation
Selected: Option X
Rationale: [why]

## Detailed Design

### Architecture
[Mermaid diagram - see examples below]

### Component Design
- Responsibilities
- Interfaces
- Dependencies

### Data Model (if applicable)
[Schema or structure]

### API Design (if applicable)
[Endpoints, request/response]

## Implementation Plan

### Phase 1: [Name]
- [ ] Task 1
- [ ] Task 2

### Migration Strategy (if applicable)

## Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| ... | High/Med/Low | High/Med/Low | ... |

## References
- Related docs, external resources

Mermaid Diagram Examples

Architecture (flowchart):

flowchart TD
    A[Client] --> B[API Gateway]
    B --> C[Service]
    C --> D[(Database)]

Sequence:

sequenceDiagram
    Client->>Server: Request
    Server->>DB: Query
    DB-->>Server: Result
    Server-->>Client: Response

State:

stateDiagram-v2
    [*] --> Pending
    Pending --> Processing: start
    Processing --> Done: complete
    Processing --> Failed: error

Handling Feedback

When user requests changes:

Understand which section needs revision
Update only affected sections
Ensure changes don't contradict other sections
Re-verify the checklist items related to changes

Output Location

Check if project has docs/, ai_docs/, or design/ directory
Ask user if location is unclear
Use descriptive filename: design-[feature-name].md