Skill.md検索

段階的対話で要件を明確化: 最大5ラウンド、1ラウンド3問以内の構造化質問で、ユーザーの頭の中にある暗黙的な要件を言語化。 思考汚染を防いで自由回答を引き出す: AIが選択肢を先に提示せず、ユーザーの自発的な意見を最優先で収集。 矛盾を自動検出して論理を堅牢化: 新しい決定との過去の矛盾をリアルタイム検出し、一貫性のある仕様案に調整。 決定の出自を追跡・透明化: 全ての決定事項に「ユーザー発案」「対話的到達」「AI提案」などの記号を付け、誰の判断かを明確化。 仕様書へのスムーズな引き継ぎ: トレードオフ表・前提レジスター・確信度付き決定サマリーを /spec に自動連携。 新しいプロダクトやシステムの要件定義を、チーム全体で納得できる形で進めたいPM・プロダクトオーナー ユーザーの「何となくこうしたい」という曖昧な要望を、実装可能な仕様に言語化したい開発リーダー 要件定義フェーズで決定の根拠を記録し、後々の議論の蒸し返しを防ぎたいステークホルダー 仕様策定前に、決定事項間の矛盾や前提条件の脆弱性を発見・改善したいアーキテクト 仕様駆動開発（SDD）の最上流工程。ユーザーの暗黙知を対話的に引き出し、/spec に引き継ぎます。基本原則は段階的対話（最大5ラウンド、1ラウンド最大3問）、自由回答ファースト（AIが選択肢を先に出さない）、弁証法的三層構造（テーゼ→アンチテーゼ→ジンテーゼの質問構成、第2層は省略禁止）、追従禁止（安易な肯定をしない）、前提探索、矛盾検出（Continuous Elenchus）、Decision Provenance（決定出自追跡）、所有権維持（人間が著者）。Anti-Sycophancy Protocol では安易な肯定や権威的提案を避け、懸念があれば率直に指摘。ワークフロー：説明責任フレーミング→Round 1～5（定義・戦略→トレードオフ→技術制約→Devil's Advocate→最終確認）。中間リフレクション（メタ認知的介入2問）と弁証法的CTOチェックポイント（前提脆弱性検証+反対立場検討）を挿入。Decision Provenance 記号：🧑（ユーザー発案）、🔄（対話的到達）、🤖（AI提案採用）、✅（CTO検証済み）。出力：トレードオフ表・Assumption Register・決定事項サマリー（確信度付き）・/spec 引き継ぎ情報。

仕様策定用ブランチの作成: spec/{action-id}-{short-description} 形式で、仕様検討フェーズ専用のブランチを自動生成できます。 実装用ブランチの作成: impl/{action-id}-{short-description} 形式で、実装フェーズ用のブランチを自動生成できます。 他スキルからの自動統合: /spec スキルや spec-workflow スキルから自動呼び出しでき、ワークフロー全体をシームレスに連携できます。 ブランチ名の自動検証: 重複確認やアクション ID の妥当性チェックを行い、命名規則の統一を保証できます。 SDD（Specification-Driven Development）ワークフローを採用しているチーム Git ブランチ管理を体系化して自動化したい開発チーム 仕様策定と実装フェーズを明確に分離したプロジェクト ブランチ名規則を統一・強制したい技術リーダー SDD ワークフローにおけるブランチ作成を担当。仕様策定フェーズでは spec/{action-id}-{short-description} (例: spec/001-01-01-user-auth)、実装フェーズでは impl/{action-id}-{short-description} (例: impl/001-01-01-user-auth) の命名規則に従ってブランチを生成します。発動条件は /branch コマンド直接呼び出し、/spec スキル内部での自動呼び出し、spec-workflow スキル内部での自動呼び出しの3つ。パラメータは type（spec or impl）・action-id（必須）・description（省略時は自動生成）。ユーザー確認後に git checkout -b で実行し、完了を通知します。ブランチ既存時にはエラーハンドリングで既存ブランチへの切り替えまたは別名での作成を提案。