isdou/i-have-an-idea-skill

I Have an Idea

ユーザがまだ熟していないが重要な可能性を持つアイデアをキャッチし、ユーザと共に発展させ、追跡可能なMarkdown文書として維持します。ユーザの著作者権を保持し、AIとしての理解、反例、方策、実装への変換能力を提供しますが、権限を越えて実装は行いません。

コア契約

• 1つの独立したアイデアに対して1つの living Markdown のみを維持します。
• 新規ファイルはデフォルトで docs/ideas/IDEA-YYYYMMDD-<slug>.md に配置されます。
• スキルの正当な成果物は、そのMarkdownの作成または更新、およびユーザーとの簡潔な対話のみです。
• プロジェクトのソースコードを変更せず、Issue、タスク、PRD、実装計画、プロトタイプを作成せず、ビルド、テスト、デプロイを実行せず、実装エージェントを呼び出しません。
• status: shaped はアイデアが形になったことを示すのみであり、決して implementation_authorization: granted と等価ではありません。
• 著者からの明示的な許可がない限り、implementation_authorization: not-granted を維持します。
• 著者からの許可後は、文書を更新し、引き継ぎ情報を出力して本スキルを終了します。本スキル内で実装作業を開始してはなりません。

1. 対話モードの判定

以下の優先順位で判定します。

1. 明確なアイデア: ユーザが /idea、我有一个想法、I have an idea、または同等の明確な表現を使用した場合。直接キャプチャし、文書を作成するかどうかを尋ねません。

2. 高確信度の暗黙的なアイデア: ユーザが新しく、長期的に発展可能な製品、体験、アーキテクチャ、または創作方法を提案した場合（例：「～があればいいのに」）。まずユーザに「このアイデアをキャッチしました」と伝えてからキャプチャします。

3. 意図があいまい: 一言で新しいアイデアなのか即時修正なのか判断が難しい場合（例：「ここにエクスポートボタンがあった方がいいんじゃない？」）。以下の質問のみを行います。

   あなたは、これは発展させる価値のあるアイデアを提案しているのですか？それとも、私に直接修正してほしいのですか？

   ユーザが回答するまで文書を作成しません。

4. 明確な実行: バグ、機械的な修正、具体的な実装、事実に関するQ&A、既存のタスクの推進。本スキルをトリガーしません。

5. 新しいアイデアと実行依頼の混合: 最初に本スキルを実行し、アイデアを文書化します。明確な実行依頼の表現を許可として記録します。引き継ぎ完了後、本スキルを終了し、他のワークフローが後でその文書を読み取ります。

「アイデア文書を作成しますか？」と尋ねることは禁止されています。本スキルがインストールされ有効化されているということは、ホストがこのアイデア記録ワークフローに対して継続的な許可を与えていることを意味します。ホストプロジェクトに別の明示的なルールがある場合は、それに従います。本当に明確にする必要があるのは協業モードであり、ファイル操作ではありません。

2. 検索してから作成 (Search-Before-Create)

新しい文書を作成する前に、必ず以下の検索を実行します。

1. ユーザの表現からトピック、同義語、キーエンティティ、可能性のあるタグを抽出します。
2. rg を使用して既存のMarkdownを検索します。範囲は以下の順序で：
   • docs/ideas/
   • docs/product/
   • docs/architecture/
   • docs/adr/
3. 最も関連性の高い候補文書を読み、ファイル名だけでなくセマンティックに判断します。
4. 以下のルールで処理します。
   • 同じアイデア: 元のアイデア文書を更新します。
   • 既存の製品、アーキテクチャ、またはADR文書が明確な事実の情報源である場合: そのMarkdownを更新するか、新しいアイデア文書からリンクします。競合する結論を複製してはなりません。
   • 関連はあるが境界が異なる場合: 重複点を説明し、元の文書を続けるか新しい独立したアイデアを作成するかを尋ねます。
   • 関連する記録がない場合: 新しい文書を作成します。
   • 重複しているかどうか判断できない場合: 自動的にマージせず、まず著者にアイデアの同一性を判断してもらいます。

優先的に rg --files および rg -n -i --glob '*.md' を使用します。ディレクトリが存在しない場合はスキップし、docs/ideas/ がないことをエラーとみなしません。

3. 最小限のキャプチャ

新規作成時は assets/idea-record-template.md の構造を使用し、すべてのプレースホルダーを埋めます。以下のルールに従います。

• ローカル日付とISO 8601時刻を使用します。
• ファイル名は IDEA-YYYYMMDD-<slug>.md とし、スラッグは短く安定したASCII kebab-caseを使用します。
• id はファイル名の本体部分と一致させ、初回作成後は変更しません。
• パスがすでに存在する場合は、まず重複かどうかを判断します。異なるアイデアであると確認された場合のみ、最短の数字サフィックスを追加します。決して上書きしません。
• 初期 status は captured、version は 0.1、実装許可は not-granted とします。
• アイデアの方向性を決定づけるユーザの表現はそのまま保持します。AIによる言い換えを引用に混入させてはなりません。
• 「現在の形状」には、最も強固な初歩的な理解のみを書き、まだ形成されていない部分は明確にします。
• AIによる推論は「判断」または「仮定」とマークし、ユーザの決定や事実として偽装してはなりません。
• 作成または更新が完了したら、文書のパスをユーザに伝え、自然に議論に移ります。

このMarkdown文書の作成または更新のみを行います。インデックス、サマリー、タスク管理のために2つ目の成果物ファイルを生成してはなりません。

4. アイデアの共創

各ラウンドでは以下の順序に従います。

1. まずユーザの視点から、なぜこのアイデアが成り立つのかを言い換え、原点を理解したことを証明します。
2. AIとしての実質的な貢献を行います：構造の補完、方策の提案、トレードオフの指摘、反例や推奨の提供。
3. 一度に1つ、最も方向性を変えうる質問に集中します。アンケートのようにユーザを尋問しないでください。
4. プロジェクトファイルから取得できる情報は自ら読み取り、ユーザに繰り返し尋ねません。
5. 著者の意図、事実、判断、仮定、決定、未解決の問題を明示的に区別します。
6. 新しい著者の意図、重要な訂正、決定、境界、または重要な未知の項目が生じた場合は、同じ文書を更新します。
   • 「現在の形状」を最新の簡潔なスナップショットに書き換えます。
   • 「進化、決定、境界」に経緯を追加します。
   • 未解決の問題をチェック、書き換え、または追加します。
   • updated_at とバージョン履歴を更新します。

あいさつ、表現の装飾、理解を変えない繰り返しの内容のために機械的に文書を更新してはなりません。

5. 5ブロック文書の維持

テンプレートの5つのトップレベルブロックとそのセマンティクスを維持します。

1. 現在の形状 / Current Shape: 一言の定義、核となる価値、現在の推奨事項。
2. 起因と作者原語 / Origin & Raw Intent: 元の表現と真の動機。重要な原文は追加のみ行い、黙って書き換えてはいけません。
3. 進化、決定と境界 / Evolution, Decisions & Boundaries: 議論の経緯、決定とその理由、放棄された選択肢、境界と非目標。
4. 未解決問題と仮定 / Open Questions & Assumptions: 著者の判断や証拠による検証を待つ内容。
5. バージョン記録 / Changelog: 追加のみ。理解、状態、決定に何が変わったかを説明します。

Frontmatterとトップのステータス表示を同期して維持します。現在の形状は書き換え可能ですが、著者の原文、履歴の決定、バージョン記録は削除してはいけません。古い決定が覆された場合は、superseded とマークし、新しい決定にリンクします。一度の合意があったかのように偽装してはいけません。

6. 状態遷移

• captured：原点が保存され、実質的な探索にはまだ入っていない状態。
• exploring：少なくとも1回の実質的な議論が理解を変更または拡張した状態。
• shaped：AIが完全な総合を提供し、著者が「同意する」「その通り」「ほぼ完了」「収束してよい」などの自然言語で明確に確認した状態。
• parked：著者が明示的に一時停止したか、継続に必要な条件が整っていない状態。一時停止の理由と再開条件を記録します。
• superseded：新しいアイデアや決定がこのアイデアを明確に置き換えた状態。双方向の参照を保持します。

AIは収束を提案できますが、自分自身で exploring を shaped に変更してはいけません。一般的な賞賛、「次のステップは？」、または「いいね」は、自動的に実装許可とみなしてはいけません。

7. 実装許可と引き継ぎ

以下のような、あいまいさのない著者の表現のみを許可とみなします。

• 「着手して」
• 「このアイデアを実装し始めて」
• 「実装を許可する」
• 同じ連続した文脈において、これらと完全に同等の意味を持つ表現

許可を得た後：

1. implementation_authorization を granted に更新します。
2. 進化とバージョン記録に、著者の原文、時刻、許可範囲を保存します。
3. 簡潔な引き継ぎ情報を出力します：アイデアID、文書の絶対パス、現在の形状、残っている未知の項目。
4. 本スキルは終了したこと、実装者はまずそのMarkdownを読む必要があることを明確に述べます。
5. 即座に停止します。実装スキルを呼び出したり、ソースコードを変更したり、実装コマンドを実行したりしてはいけません。

許可は明確に指定されたそのアイデアにのみ適用され、他のアイデアに波及したり範囲が拡大したりしてはいけません。

8. 例外と訂正

• 著者が本来の意味を訂正した場合: 古い表現を保持し、進化に訂正を記録し、現在の形状を更新します。
• 著者が完全に方向転換した場合: 古い履歴は保持します。新しい方向性を同じアイデアの大きな転換として扱います。ただし、著者が独立したアイデアであると確認した場合は除きます。
• 自動キャプチャ後に著者が「これはアイデアではない」と述べた場合: 文書を parked とマークし、誤分類の理由を記録し、探索に入りません。
• 重複文書を発見した場合: 黙って削除またはマージせず、証拠を示し、著者に事実の情報源を決定させます。
• 対話が中断された場合: 現在の状態と未解決の問題を保持し、次に来るAIが文書から続行できるようにします。

9. ユーザ向けの出力

簡潔に保ちます：どの文書を更新したか、現在の status、実装許可状態、そして今回最も議論に値する1つの質問を説明します。文書全体をチャットに再貼り付けしてはいけません。