open-spec-propose

新しい変更を提案し、任意の作業用アーティファクトを作成します。

次のアーティファクトを作成して変更を進めます：

• proposal.md（何を、なぜ行うか）
• design.md（どのように行うか）
• tasks.md（実装手順）

実装の準備ができたら、open-spec-apply スキルを使用してください

---

入力：ユーザーのリクエストには、変更名（kebab-case）または作成したいものの説明を含めてください。

手順

1. 明確な入力がない場合は、作成したいものを尋ねます

   AskUserQuestion tool（自由回答形式、選択肢なし）を使用して、次のように尋ねます：

   "どのような変更に取り組みたいですか？作成または修正したいものを説明してください。"

   説明から kebab-case の名前を導き出します（例：「ユーザー認証を追加」→ add-user-auth）。

   重要：ユーザーが何を作成したいのかを理解するまで、先に進まないでください。

2. 変更ディレクトリを作成します

   specs/changes/<name>/ を作成します。

   specs/changes/ は Git の無視対象です。これは任意のワークフロー用の足場であり、正式な仕様として管理されるのは specs/features/ のみです。

3. 作業用アーティファクトを作成します

   TodoWrite tool を使用して進捗を管理します。

   次を作成します：

   • proposal.md：問題、目標、対象外事項、スコープ
   • design.md：アーキテクチャ、意思決定、トレードオフ、境界
   • tasks.md：チェックボックス付きの具体的な実装手順

   アーティファクトのルール：

   • 実施に役立つ場合は、使用技術を踏まえた内容にします。
   • AGENTS.md および有効な機能ドキュメントに沿った内容にします。
   • 正式な動作の基準として specs/features/ を使用します。
   • 変更によって既存の動作が変わる場合は、影響を受ける正式な仕様を参照します。
   • ユーザーがすでに十分な詳細を提示している場合は、追加の質問をせずにアーティファクトを直接作成します。

4. 変更を実装可能な状態にします

   完了する前に、次の点を確認します：

   • proposal.md で変更が必要な理由が説明されている。
   • design.md で意図するアプローチと境界が説明されている。
   • tasks.md に順序立てた実行計画が記載されている。
   • 変更名とアーティファクトが、open-spec-apply スキルで実行できるほど具体的である。

出力

すべてのアーティファクトを作成した後、次の内容を要約します：

• 変更名と保存場所
• 作成したアーティファクトの一覧と簡単な説明
• 準備状況：「すべてのアーティファクトを作成しました！実装の準備ができています。」
• プロンプト：「実装には open-spec-apply スキルを使用してください。完了したら、specs/features/ を同期し、これらの一時的なアーティファクトを整理するために open-spec-complete スキルを使用してください。」

ガードレール

• ユーザーが明示的に省略を求めない限り、3つの主要なアーティファクトをすべて作成します。
• 文脈が重大な点で不明確な場合はユーザーに尋ねます。ただし、作業を進めるために妥当な判断を優先します。
• 同じ名前の変更がすでに存在する場合は、続行するか新しいものを作成するか、ユーザーに確認します。
• 次に進む前に、各アーティファクトのファイルが存在することを確認します。
• 作業用アーティファクトを正式な仕様として扱わないでください。