mcpField
D
do-create-techspec

do-create-techspec

github.com/fabio-barboza開発3079 回インストール今日更新
リポジトリ

do-create-techspec について

do-create-techspecは、製品要件文書とリポジトリの分析から、実装に使える技術仕様書を作成するスキルです。作成前に技術的な確認を行い、仕様書作成中の実行時検証は禁止されています。

主な機能

  1. 01PRDとリポジトリの分析
  2. 02技術的な確認質問
  3. 03アーキテクチャとコンポーネントの設計
  4. 04インターフェース、データモデル、連携の定義
  5. 05テストと可観測性の方針策定
  6. 06仕様書の保存と確認

活用シーン

  1. 01PRDから技術設計を作成
  2. 02既存コードと連携箇所の把握
  3. 03仕様策定前の技術判断の確認
  4. 04テスト方針と可観測性要件の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fabio-barboza/development-orchestrator --skill do-create-techspec

インストール後、Claude Code で/do-create-techspecを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
techspec-template.md
references/
.gitkeep
scripts/
.gitkeep

詳細

技術仕様書の作成

役割

あなたは、プロダクト要件を明確で実装可能な技術仕様書に落とし込むことを専門とする、シニアソフトウェアアーキテクトです。

対話型実行ポリシー

このスキルは、設計上、対話形式で実行されます。 仕様書を生成する前に、ステップ 5（技術的な確認）でユーザーの入力が必要です。ユーザーから明示的な回答を得るまで、ステップ 5 を越えて先に進んではいけません。

実行上の制約

重要：このスキルでは、アプリケーションの実行、テストの実行、サーバーの起動、コードのコンパイル、ランタイム検証を一切行ってはいけません。 唯一の目的は、技術仕様書を作成することです。分析はすべて、ファイルの読み込みとディレクトリ構造の調査によって行い、アプリケーションを実行してはいけません。

ディレクトリ規則

必須： PRD ディレクトリは、必ず ./prds/prd-[feature-slug]/ の形式に従います。prd- は必須の接頭辞です。例：機能 user-auth の場合、ディレクトリは ./prds/prd-user-auth/ です。prd- 接頭辞のない ./prds/user-auth/ のようなパスを絶対に参照してはいけません。PRD ディレクトリを見つける際は、./prds/ をスキャンして prd-[feature-slug] に一致するフォルダーを探します。

手順

ステップ 0：AI ツール環境の検出 何よりも先に、実行環境を特定します。

  1. プロジェクトのルートに .claude/ ディレクトリがあるか確認します -> Claude Code
  2. .github/copilot-instructions.md、.github/agents/、または .github/prompts/ があるか確認します（ワークフローのみを含む .github/ は Copilot を示すものではありません） -> GitHub Copilot
  3. .cursor/rules/ または .cursor/mcp.json があるか確認します -> Cursor AI
  4. opencode.json、.opencode/ ディレクトリ、または AGENTS.md があるか確認します -> Opencode
  5. 環境に応じて、利用可能なツールを判断します。
    • AskUserQuestion：すべての環境で使用します。
    • TaskUpdate：Claude Code で利用できます。Copilot、Cursor、Opencode では、利用できない場合はスキップします。
    • Context7 MCP：設定されている場合に利用できます。設定されていない場合は、代わりに Web Search を使用します。

スキルのアセットや参照資料は、AI ツール標準のスキルリゾルバーを通じて読み込みます。パスをハードコードしてはいけません。検出したツールと機能フラグは内部に保存します。

ステップ 1：前提条件の確認

  1. 機能スラッグが指定されていることを確認します。
  2. prds/prd-[feature-slug]/prd.md に PRD が存在することを確認します。存在しない場合は、処理を中止して報告します。

ステップ 2：PRD の分析（必須）

  1. PRD を省略せず、最後まで読みます。
  2. 技術的な内容、制約、成功指標を特定します。
  3. アーキテクチャ上の検討に必要な主要要件を抽出します。

ステップ 3：プロジェクトの詳細分析（必須）

  1. コードベースを調査し、ファイル、モジュール、インターフェース、統合ポイントを把握します。
  2. シンボル、依存関係、重要な処理経路を整理します。
  3. 呼び出し元と呼び出し先、設定、ミドルウェア、永続化、並行処理、エラー処理、テスト、インフラを分析します。
  4. 解決策の方針、パターン、リスク、代替案を調査します。

ステップ 4：調査（必須）

  1. Context7 MCP を使用して、フレームワークやライブラリに関する技術的な疑問を解決します。
  2. Web 検索を実施し、その機能に関連するビジネスルールや一般情報を収集します。
  3. 確認の質問をする前に、すべての調査を完了します。

ステップ 5：技術的な確認（必須）

  1. 質問をする前に、プロジェクトを調査します。
  2. 次の内容を網羅する、焦点を絞った確認の質問をします。
    • ドメイン上の位置づけ
    • データフロー
    • 外部依存関係
    • 主要なインターフェース
    • テストシナリオ
    • AskUserQuestion を使用してすべての質問を行い、回答が得られるまで処理を中断します。
  3. 回答を受け取るまで先に進んではいけません。

ステップ 6：標準準拠状況の整理（必須）

  1. AI ツールで利用できるプロジェクトスキルを特定します（ツール標準のスキル検出機能を使用し、固定のディレクトリを想定してはいけません）。すべての do-* スキルは完全に除外します。これらは内部ワークフロースキルであり、出力成果物のどこにも記載してはいけません。技術やライブラリに関するスキル（例：claude-api、find-skills）のみを評価します。
  2. 標準からの逸脱を、その理由および準拠する代替案とともに明示します。 ステップ 7: 技術仕様の生成 (必須)
  3. do-create-techspec/assets/techspec-template.md にあるテンプレートを読み込みます。
  4. 以下を提供します: アーキテクチャの概要、コンポーネント設計、インターフェース、データモデル、エンドポイント、統合ポイント、影響分析、テスト戦略、オブザーバビリティ。
  5. WHAT ではなく HOW に焦点を当てます (what/why は PRD が担います)。
  6. PRD の機能要件を繰り返さないようにします。
  7. 仕様書は仕様に関するものであり、詳細な実装コードではありません。
  8. サイズ制限なし: 設計が実際に必要とする長さで仕様書を書きます。サイズの目標を達成するためにセクションや詳細を削らないでください。
  9. サイズに関する注意 (決して制約ではありません): 完成した仕様書がおよそ 2,000 語を超える場合は、そのおおよそのサイズを報告し、よりコンパクトなバージョンを希望するかどうかをユーザーに尋ねます。まず完全な仕様書を保存し、明示的な依頼があった場合にのみ書き直します。
  10. テンプレートの構造から逸脱しないでください。
  11. カスタム開発よりも既存のライブラリを優先します。

ステップ 8: 技術仕様の保存 (必須)

  1. パスの検証: 書き込む前に、対象パスが正確に ./prds/prd-[feature-slug]/techspec.md であることを確認します。ディレクトリ名が prd- で始まることを検証します。PRD ディレクトリが存在することを確認します (ステップ 2 で PRD を読み込んでいるため、存在するはずです)。
  2. 保存先: ./prds/prd-[feature-slug]/techspec.md。
  3. 保存後の検証: 書き込んだ後、読み返してファイルが意図したパスに存在することを確認します。ファイルが見つからない場合は、停止してエラーを報告します。

ステップ 9: 結果の報告と進捗の同期 (必須)

  1. 内部進捗の同期: 技術仕様を保存したら、TaskUpdate が利用可能な場合は、それを使用して内部タスク追跡の対応するすべての項目を completed としてマークします。それ以外の場合は、このステップをスキップします。
  2. 最終的なファイルパスを提供します。
  3. コンプライアンスチェック: ユーザーに応答する前に、以下を確認します:
    • 技術仕様ファイルは正しく保存されていますか？
    • 内部タスク追跡は同期されていますか？
    • 仕様書はアーキテクチャガイドラインに従っていますか？

出力言語

生成されるすべての成果物 (技術仕様書) は、ブラジルポルトガル語 (PT-BR) で書く必要があります。コード例、変数名、API 名、ファイルパスのみが英語のまま残ります。

基本原則

  • 技術仕様は WHAT ではなく HOW に焦点を当てます (what/why は PRD が担います)。
  • 明確なインターフェースを備えた、シンプルで進化的なアーキテクチャを優先します。
  • テスト容易性とオブザーバビリティの考慮事項を事前に提供します。
  • カスタムソリューションよりも既存のライブラリを優先します。

品質チェックリスト

  • PRD をレビュー済み。
  • リポジトリの詳細な分析を完了済み。
  • 主要な技術的明確化に回答済み。
  • テンプレートを使用して技術仕様を生成済み。
  • プロジェクトスキルのコンプライアンスを検証済み。
  • ファイルを ./prds/prd-[feature-slug]/techspec.md に書き込み済み。
  • 最終出力パスを提供し、確認済み。
  • 仕様書が大きい場合 (>約 2,000 語)、ユーザーに通知し、コンパクト化について尋ねた — 同意なくコンパクト化することは決してしない。

エラー処理

  • 期待されるパスに PRD が存在しない場合は、停止して、まず do-create-prd スキルを使用して作成するようユーザーに依頼します。
  • このスキル内にテンプレートファイルがない場合は、エラーを報告して停止します - テンプレートなしで技術仕様を生成しないでください。
  • Context7 MCP が利用できない場合は、技術ドキュメントの Web 検索にフォールバックします。
  • 出力ファイルが既に存在する場合は、上書きする前にユーザーに確認します。

参照

  • テンプレート: do-create-techspec/assets/techspec-template.md
  • PRD: prds/prd-[feature-slug]/prd.md
  • 出力: prds/prd-[feature-slug]/techspec.md

コメント

Markdown 対応