idea-to-implementation-doc

アイデアから実装ドキュメントへのワークフロー

ユーザーが 特定のアイデアメモを1つ 技術的な実装ドキュメントにまとめたい場合に、このスキルを使用します。

これは、アイデアのトップレベルのインデックスを扱うワークフローではありません。単一のアイデアファイルを対象とし、別途実装計画を作成します。

目標

特定のアイデア／設計ドキュメントを基に、次の内容を含む詳細な実装ドキュメントを作成します。

• アイデアを慎重に検討する
• 類似製品や既存アプリを調査する
• 既存のソリューションとの不足点や重複を特定する
• 具体的な構築方法を提案する
• システム設計、主要コンポーネント、開発フェーズの概要を示す
• 計画を、Hermes、Claude Code、Codex、OpenClaw、その他のコーディングエージェント向けの実行可能なタスクおよび／またはプロンプトに変換する
• 「完了」とは、プログラムが動作し、すぐに使える状態であることを意味するよう、テスト、検証、受け入れ基準を含める
• エージェントにビルドの唯一の信頼できる情報源として渡せる、単一の Markdown ファイルを作成する

重要な制約

• プロダクトのアイデア出しだけでなく、実装戦略に焦点を当てます。
• 明らかなものを一から作り直さないために必要な範囲でのみ、既存アプリを調査します。
• スタックを過剰に設計しません。実現可能な最もシンプルな方法を選びます。
• 実用的で、実行に移せる内容にします。
• ユーザーがドキュメントを非技術的な内容にするよう求めた場合は、プロダクトレベルのアーキテクチャと計画までにとどめます。
• ユーザーがコードレベルの詳細を求めた場合は、プロダクトの説明に混ぜず、独立したセクションに含めます。

入力

主な入力：

• 特定のアイデアメモ1つ（例：ideas/my-app.md）

任意の入力：

• 別ファイルとして存在する場合は、関連する設計ドキュメント
• スタック、ホスティング、プラットフォームに関するユーザーの制約
• デプロイ先／データ保存場所の希望：ローカルのみ、セルフホスト、Cloudflare、AWS、その他のクラウド、または未定
• 対象プラットフォーム：ブラウザー／Web のみ、Windows デスクトップ、Mac デスクトップ、クロスプラットフォームデスクトップ、モバイル Web、iOS、Android、またはモバイル対応なしを明示
• データベース、バックエンド／ランタイム、フロントエンド、認証、ファイル／オブジェクトストレージ、キュー／ジョブ、リアルタイム／同期、検索、オブザーバビリティ／ログ、テスト、デプロイ／CI に関する、受け入れ済みの技術的なデフォルト設定や上書き設定

ワークフロー

1) ソースメモを読む

対象のアイデア／設計ドキュメントを確認し、次の内容を抽出します。

• 中心となる課題
• 想定ユーザー
• 必須の動作
• 対象外の事項
• 未解決の質問

2) 類似製品を調査する

目標やワークフローが類似するアプリ／製品を探します。

次の点を特定します。

• 類似製品
• 共通する機能や動作
• ユーザーのアイデアとの違い
• このアイデアで模倣や重複を避けるべきもの

これは軽量な製品調査として扱い、網羅的な市場分析は行いません。

3) 実装戦略に落とし込む

アイデアを、次の内容を含む実装計画に変換します。

• プロダクトのスコープ
• 主なユーザーフロー
• データモデル／データベースの要件
• 推奨するデータベース／ストレージのデフォルト設定、およびその採用・変更の判断
• ホスティング／デプロイ先とデータの保存場所
• フロントエンドの構成
• バックエンド／サービスの要件
• プラットフォーム対象の判断：Web のみ、デスクトップアプリ、モバイルアプリ、レスポンシブ Web、および MVP 対応と後続対応の区別
• フロントエンド、バックエンド／ランタイム、認証、ストレージ、キュー／ジョブ、リアルタイム／同期、検索、オブザーバビリティ／ログ、テスト、デプロイ／CI に関する推奨する技術的なデフォルト設定
• 統合ポイント
• ファイル／モジュールの構成
• 開発フェーズ
• 実行可能なタスクの内訳
• エージェント向けのプロンプトまたは引き継ぎ手順
• テストと検証の戦略
• 受け入れ基準と「完了」のチェックリスト
• リスクと未解決の質問

4) 実装仕様書と最終引き継ぎドキュメントを作成する

必要に応じて、段階的なアイデアワークフローの構成を使い、実装作業の成果物をソースノートの近くに保存します。

• README.md — アイデアパッケージ全体のステータス／インデックスページ。
• 02-implementation-spec.md — 詳細な実装戦略。
• 03-agent-build-handoff.md — コーディングエージェントまたはSuperpowers向けの最終的な単一ファイルの引き継ぎドキュメント。
• 04-spec-review.md — 実行前の準備状況レビュー。

小規模なアイデアの場合は、単一の <idea-name>.implementation.md ファイルでも構いませんが、アプリ全体のビルドでは段階的な構成を使用してください。

推奨される命名規則：

• ideas/<idea-slug>/README.md
• ideas/<idea-slug>/02-implementation-spec.md
• ideas/<idea-slug>/03-agent-build-handoff.md
• ideas/<idea-slug>/04-spec-review.md

推奨される出力構成

# <Idea Title> Implementation Plan

## Summary

## Source Idea Review

## Similar Products / Market Check

## Product Scope

## System Overview

## Data Model

## Database / Storage Recommendation

## Hosting / Data Location / Deployment

## Technical Stack Recommendation

## Frontend Plan

## Platform Targets

## Backend / Services Plan

## Key Workflows

## Milestones / Phases

## Build Tasks

## Agent Build Prompt

## Testing and Verification Plan

## Acceptance Criteria / Done Means

## Risks and Tradeoffs

## Open Questions

## Next Build Prompt

最終エージェント引き継ぎフォーマット

実装仕様書の草案を作成したら、次の必須構成に従って 03-agent-build-handoff.md を作成します。

# <Project Name> Agent Build Handoff

## Mission

## Product Vision

## User Experience Goals

## Non-Negotiable Requirements

## Out of Scope

## Technical Architecture

## Data Model

## Database / Storage Recommendation

State the recommended database/storage approach, why it fits the product, and whether the user accepted it or overrode it. Mention relevant alternatives considered when helpful.

## Hosting / Data Location / Deployment

Specify whether data stays local, is self-hosted, uses Cloudflare, AWS, another cloud, or remains undecided. If undecided, list the assumptions used for the MVP and what would change later.

## Platform Targets

Specify whether the MVP is browser/web-only, Windows desktop, Mac desktop, cross-platform desktop, mobile web, iOS, Android, or a combination. Explicitly separate MVP platforms from future platforms.

## Technical Stack Recommendation

List recommended defaults and user overrides for frontend, backend/runtime, auth, database, file/object storage, queues/jobs, realtime/sync, search, observability/logging, testing, and deployment/CI. The handoff should not require the build agent to guess these choices unless the spec explicitly marks them as flexible.

## Integrations

## Implementation Phases

## Build Tasks

## Testing Requirements

## Verification Commands / Checks

## Acceptance Criteria

## Done Means

## Known Risks

## Open Questions

## Prompt for Build Agent
Use a prompt that asks the build agent to inspect the project, preserve scope, create or follow an implementation plan, run tests, and verify evidence before claiming done. Do not duplicate Superpowers' detailed planning protocol; hand off to it.

## Superpowers Build Handoff
Use the `superpowers-gpt` workflow on this document.

Start with:
1. `superpowers-using-superpowers` to route the work.
2. `superpowers-writing-plans` to inspect the target repo and turn this handoff into exact implementation tasks, files, commands, tests, and expected results.
3. `superpowers-executing-plans` or `superpowers-subagent-driven-development` to implement the approved plan without scope drift.
4. `superpowers-requesting-code-review` to review the implementation.
5. `superpowers-verification-before-completion` to prove the work satisfies the acceptance criteria before claiming completion.

The goal is to convert this spec into an executable implementation plan, build it with tests, review the result, and verify before claiming completion.

仕様書レビューのゲート

引き継ぎの準備が整ったと判断する前に、次の判定構成で 04-spec-review.md を作成します。

# <Project Name> Spec Review

Verdict: PASS | PASS WITH CHANGES | FAIL

## Summary

## Readiness Checklist
- [ ] Product goal is clear
- [ ] Requirements are testable
- [ ] Product decisions are resolved or explicitly listed
- [ ] Technical decisions are resolved or explicitly listed
- [ ] Database/storage recommendation is present or explicitly unnecessary
- [ ] Recommended technical defaults are documented, with user overrides if any
- [ ] Acceptance criteria are concrete
- [ ] Done Means is specific
- [ ] A fresh agent could build from the handoff without obvious missing context
- [ ] Testing requirements are included
- [ ] Verification commands/checks are included
- [ ] Non-goals prevent likely scope creep

## Required Changes Before Build

## Optional Improvements

## Superpowers Handoff Recommendation

ビルドの引き継ぎを、重大な確認事項なしでSuperpowersに渡せる状態になった場合にのみ、PASS を使用してください。

ライトモードとフルモード、および進行ルール

このスキルを小規模なアイデアに使用する場合は、単一の <idea-name>.implementation.md で十分なことがあります。ユーザーがビルド準備の完了を求めていない限り、完全な引き継ぎパッケージを無理に作成しないでください。

フルモードでは、次のルールに従ってください。

• アーキテクチャやMVPの範囲を変えるような未解決のプロダクトに関する質問がある場合は、実装に進まないでください。
• テスト要件、検証項目、受け入れ基準、Done Meansが具体的になるまで、03-agent-build-handoff.md を作成しないでください。
• 主要なプロダクト上または技術上の選択がまだ明記されていない場合は、04-spec-review.md を PASS としないでください。

ユーザーは、完全性に関するゲートを正確なフレーズ GREENLIGHT NEXT STAGE で上書きできます。その場合は次の成果物に進み、未解決の項目を前提または未解決の質問として記録したうえで、作業を続けてください。

調査の指針

類似製品を調査する際は、次の質問に答えてください。

• すでにこの問題を解決しているアプリは何ですか？
• どの機能が一般的なものですか？
• どの部分が独自または差別化要因ですか？
• このアイデアは、実際にはよく知られた製品カテゴリの一種ですか？
• 既存のツールではなく、この製品をユーザーが選ぶ理由は何ですか？

既存アプリに非常によく似たアイデアに見える場合は、その点を明確に記し、ポジショニングの見直しまたはスコープの絞り込みを提案してください。

レビューの指針

アイデアのドキュメントをレビューする際は、次の項目を明示的に確認してください。

• 曖昧さ
• スコープの肥大化
• ユーザーフローの不足
• データの所有権が不明確
• ホスティング先／データの保存場所の選択が欠けていないか
• Web、デスクトップ、モバイルの対象プラットフォームの決定が欠けていないか
• データベース／ストレージの推奨が欠けていないか
• 技術的なデフォルトの推奨またはユーザーによる上書きが欠けていないか
• 成功基準が曖昧でないか
• 隠れた前提がないか
• すでに別の場所にある機能と重複していないか

実装計画の指針

技術計画では、次の点に従ってください。

• 想定されるコンポーネントを具体的に示してください。
• まずはシンプルなアーキテクチャを優先してください。
• データベースが必要かどうか、およびその理由を説明してください。
• まず推奨するデフォルトの技術スタックを提示し、ユーザーが承認または変更できるようにしてください。技術コンポーネントをすべてゼロから選ばせないでください。
• 該当する場合は、データベース／ストレージ、バックエンド／ランタイム、フロントエンド／UI、認証、ファイル／オブジェクトストレージ、キュー／ジョブ、リアルタイム／同期、検索、可観測性／ログ、テスト、デプロイ／CIを扱ってください。
• 承認されたデフォルトは決定事項として記録し、ユーザーによる変更は明示的な上書きとして記録してください。
• アプリが小規模な場合は、エンタープライズ向けの完全なスタックではなく、最小限の実用的なアーキテクチャに触れてください。
• アプリに認証、永続化、検索、同期、またはリアルタイム機能が必要な場合は、その点を明示してください。

停止条件

ユーザーが停止を指示した場合、または高レベルのレビューのみを希望した場合は、得られた内容を提示し、残っている不確実性を明確にしてください。

呼び出されたときの動作

このスキルは、アイデアドキュメントがすでに存在する場合に、タスクとして実行するか、明示的なリクエストによって実行することを想定しています。

一般的な応答スタイル：

• アイデアの簡潔な概要
• 見つかった類似製品
• 実装戦略
• 新しい実装ドキュメントのファイルパス

品質基準

優れた実装ドキュメントを読めば、開発者やAI コーディングエージェントがすぐに次のことを理解できます：

• 何を構築するのか
• なぜこのアプローチが妥当なのか
• システムを構成する主要な要素は何か
• 推測に頼らずに構築を始める方法
• 比較対象となる既存製品
• どのタスクをどの順序で完了するか
• どのテストを実行するか
• アプリが実際に動作することを検証する方法
• エージェントが「完了した」と正直に言う前に、何が満たされている必要があるか