원클릭으로 Manus에서 모든 스킬 실행

design-to-spec

스타0

포크0

업데이트2026년 4월 6일 08:43

設計ドキュメント（Design Doc）を実装可能な仕様書（Spec）に変換するスキル。「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。「スペックにまとめて」「仕様書にして」「実装仕様を書いて」「specに変換して」でトリガーすること。 dig で曖昧さを解消してから使用すると最も効果的。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

whywaita

whywaita/dotfiles

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

design-to-spec

Design Doc を実装可能な Spec に変換する。「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。

引数

第1引数（必須）: 設計ドキュメントのパス（例: docs/design.md）
第2引数（任意）: Decisions ファイルのパス（dig の出力）。省略時は <doc-basename>-decisions.md を自動検出
第3引数（任意）: 出力先パス。省略時は <doc-basename>-spec.md

Workflow

Step 1: 入力読み込み

指定されたパスの Design Doc を読み込む
Decisions ファイルの検出:
- 第2引数が指定されていればそのパスを読み込む
- 省略時は <doc-basename>-decisions.md を検索し、存在すれば読み込む
- Decisions ファイルがない場合はその旨を伝え、dig の利用を提案する（必須ではない）
ユーザーの使用言語を判定し、以降のやり取りはその言語で行う

Step 2: Gap 分析

Spec に必要だが Design Doc（+ Decisions）に欠けている情報を特定する。

分類:

Blocking: この情報がないと Spec が書けない（例: 認証方式が未定義）
Non-blocking: Open Questions として記載できる（例: 将来の拡張計画）

対応:

Blocking な項目のみ AskUserQuestion で質問する
- 各選択肢に pros/cons を付記する
- 「未定」も受容し、Open Questions に記録する
Non-blocking な項目は Open Questions セクションに記載する

Step 3: Spec 生成

以下の構造で仕様書を生成する。ドキュメントの内容に応じて不要なセクションは省略してよい。

# Spec: <タイトル>

## Overview
<!-- 1-2段落で何を作るかを説明 -->

## Scope
<!-- In Scope / Out of Scope を明確に -->

### In Scope
- ...

### Out of Scope
- ...

## Terminology
<!-- プロジェクト固有の用語定義 -->

| 用語 | 定義 |
|------|------|
| ...  | ...  |

## Functional Requirements

### FR-1: <機能名>
- **説明**: ...
- **成功時**: ...
- **失敗時**: ...

## Non-Functional Requirements

### NFR-1: <要件名>
- **説明**: ...
- **基準**: ...

## API / Interface
<!-- エンドポイント、メソッド、入出力の定義 -->

## Data Model
<!-- エンティティ、リレーション、スキーマ -->

## State Transitions
<!-- 状態遷移図や状態の説明 -->

## Security
<!-- 認証・認可・データ保護 -->

## Decision Records
<!-- ADR 形式で設計判断を記録 -->

### DR-1: <決定事項>
- **Status**: Accepted
- **Context**: ...
- **Decision**: ...
- **Consequences**: ...

## Open Questions
- [ ] ...

## References
- [Design Doc](<元ドキュメントへのパス>)
- [Decisions](<decisions ファイルへのパス>)

言語ルール:

断定形で記述する（「〜とする」「〜である」）
曖昧な表現は禁止（Open Questions 以外）
- 禁止例: 「〜を検討する」「必要に応じて〜」「〜など」
- 許容例: 「〜とする」「〜を使用する」「〜は行わない」
各 Functional Requirement には成功時と失敗時の両方を定義する

Step 4: 出力

デフォルト出力先: <doc-basename>-spec.md（第3引数で上書き可能）
元のドキュメントは絶対に上書きしない
書き込み前に出力先をユーザーに確認する

Step 5: レビュー

サマリーを簡潔に伝える:
- 抽出した Functional Requirements の数
- Non-Functional Requirements の数
- Decision Records の数
- Open Questions の数
Open Questions が多い場合は dig の利用を提案する
修正要望があれば対応する

이 저장소의 다른 Skills

같은 저장소

poker-hand-review

whywaita/dotfiles

ポーカーのハンドレビューと座学を統合的に行うスキル。ユーザのハンドをGTO Wizardのソルバーデータとブログ記事を根拠に多角的にレビューし、同時に集合分析ベースの体系的な座学を実施する。数学的根拠（ポットオッズ、エクイティ、EV計算）とexploit観点を含む。「ハンドレビューして」「このハンドどう思う？」「レビューお願い」「hand review」「この判断正しかった？」「座学したい」「このスポットを勉強したい」「集合分析を見たい」「深掘りして勉強」「このスポットの全体像を知りたい」

2026-04-190

commit-push-pr

whywaita/dotfiles

Create a git commit, push a branch, and open a Pull Request with gh. Use when asked to commit changes, push to origin, or create PRs, especially when conventional commits and PR templates are required.

既存の設計ドキュメント・RFC・計画書を読み込み、AskUserQuestion による構造化された質問を通じて、曖昧さ・矛盾・未定義事項を洗い出し、決定事項と残課題を整理するスキル。「深掘りして」「曖昧な点を洗い出して」「設計の穴を突いて」「challenge my assumptions」「ドキュメントを読んで質問して」のような依頼でトリガーすること。仕様書（spec）の生成が目的の場合は design-to-spec を使うこと。

Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.

2026-02-040

name	design-to-spec
description	設計ドキュメント（Design Doc）を実装可能な仕様書（Spec）に変換するスキル。「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。「スペックにまとめて」「仕様書にして」「実装仕様を書いて」「specに変換して」でトリガーすること。 dig で曖昧さを解消してから使用すると最も効果的。
argument-hint	<design-doc-path> [decisions-path] [output-path]

design-to-spec

Design Doc を実装可能な Spec に変換する。「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。

引数

第1引数（必須）: 設計ドキュメントのパス（例: docs/design.md）
第2引数（任意）: Decisions ファイルのパス（dig の出力）。省略時は <doc-basename>-decisions.md を自動検出
第3引数（任意）: 出力先パス。省略時は <doc-basename>-spec.md

Workflow

Step 1: 入力読み込み

指定されたパスの Design Doc を読み込む
Decisions ファイルの検出:
- 第2引数が指定されていればそのパスを読み込む
- 省略時は <doc-basename>-decisions.md を検索し、存在すれば読み込む
- Decisions ファイルがない場合はその旨を伝え、dig の利用を提案する（必須ではない）
ユーザーの使用言語を判定し、以降のやり取りはその言語で行う

Step 2: Gap 分析

Spec に必要だが Design Doc（+ Decisions）に欠けている情報を特定する。

分類:

Blocking: この情報がないと Spec が書けない（例: 認証方式が未定義）
Non-blocking: Open Questions として記載できる（例: 将来の拡張計画）

対応:

Blocking な項目のみ AskUserQuestion で質問する
- 各選択肢に pros/cons を付記する
- 「未定」も受容し、Open Questions に記録する
Non-blocking な項目は Open Questions セクションに記載する

Step 3: Spec 生成

以下の構造で仕様書を生成する。ドキュメントの内容に応じて不要なセクションは省略してよい。

# Spec: <タイトル>

## Overview
<!-- 1-2段落で何を作るかを説明 -->

## Scope
<!-- In Scope / Out of Scope を明確に -->

### In Scope
- ...

### Out of Scope
- ...

## Terminology
<!-- プロジェクト固有の用語定義 -->

| 用語 | 定義 |
|------|------|
| ...  | ...  |

## Functional Requirements

### FR-1: <機能名>
- **説明**: ...
- **成功時**: ...
- **失敗時**: ...

## Non-Functional Requirements

### NFR-1: <要件名>
- **説明**: ...
- **基準**: ...

## API / Interface
<!-- エンドポイント、メソッド、入出力の定義 -->

## Data Model
<!-- エンティティ、リレーション、スキーマ -->

## State Transitions
<!-- 状態遷移図や状態の説明 -->

## Security
<!-- 認証・認可・データ保護 -->

## Decision Records
<!-- ADR 形式で設計判断を記録 -->

### DR-1: <決定事項>
- **Status**: Accepted
- **Context**: ...
- **Decision**: ...
- **Consequences**: ...

## Open Questions
- [ ] ...

## References
- [Design Doc](<元ドキュメントへのパス>)
- [Decisions](<decisions ファイルへのパス>)

言語ルール:

断定形で記述する（「〜とする」「〜である」）
曖昧な表現は禁止（Open Questions 以外）
- 禁止例: 「〜を検討する」「必要に応じて〜」「〜など」
- 許容例: 「〜とする」「〜を使用する」「〜は行わない」
各 Functional Requirement には成功時と失敗時の両方を定義する

Step 4: 出力

デフォルト出力先: <doc-basename>-spec.md（第3引数で上書き可能）
元のドキュメントは絶対に上書きしない
書き込み前に出力先をユーザーに確認する

Step 5: レビュー

サマリーを簡潔に伝える:
- 抽出した Functional Requirements の数
- Non-Functional Requirements の数
- Decision Records の数
- Open Questions の数
Open Questions が多い場合は dig の利用を提案する
修正要望があれば対応する