Monomi: Command for Claude Code

/refine-requirements — 要件壁打ちフェーズ

リリース(release-N)単位で要件をユーザーと壁打ちし、確定要件を .claude/workflow.config.json の requirementsPath({release} をリリース識別子で置換したパス)に書き出す。 後続の run-release / implement-feature ワークフローはこのファイルを入力として受け取るため、実装可能な粒度まで具体化してから確定させること。

引数: $ARGUMENTS(対象リリース番号や要件の種。例: release-1 ログイン機能。省略時はユーザーに確認)

進め方

1. config の読込: .claude/workflow.config.json を Read する。以降のパス・ブランチ・自動化設定はすべてこの config から取る(requirementsPath・baseBranch・conventionsDoc・knownIssues.path・automation.pipeline)。ファイルが無い・読めない場合は「.claude/workflow.config.json がありません。作成してから再実行してください」と明示して中断する(書き出し先やベースブランチを推測で補完しない)
2. 現状把握: プロジェクトの README / 要件書(あれば)と、対象リリースの既存ドラフト(あれば requirementsPath の該当パス)を読む。関連する実装の現状は conventionsDoc から探索する。あわせて knownIssues.path のバックログを確認し、今回のリリースで対応する既存課題があればその ID を控える
3. 壁打ち(対話): AskUserQuestion を使い、以下を1テーマずつ詰める。一度に全部聞かない:
   • 解決したい課題と成功基準(誰が・何に困っていて・どうなれば成功か)
   • スコープ(今回やること / 明示的にやらないこと)。割れた論点と最終決定はスコープ確定表の材料として論点・決定のペアで記録する
   • 優先度(必須 / 推奨 / 将来)
   • 受け入れ基準(検証可能な形で。各 AC が自動検証可能か手動検証必須かも判定する。記法は後述)
   • 非機能要件(性能・セキュリティ・互換性)で関係するもの
4. 調査(必要時): 技術的な実現性・代替案の比較が必要なら、サブエージェント(Explore / general-purpose)や WebSearch で調査してから提案する。推測で断定しない
5. リリースブランチの作成: リリース識別子(release-N-slug)が確定した時点で、baseBranch を最新化してから同名のブランチを作成しチェックアウトする(git checkout <baseBranch> && git pull && git checkout -b release-N-slug)。以降のステップ(実装・レビュー・doc同期・コミット)はこのブランチ上で行う。既に対象ブランチで作業を再開している場合は作成をスキップする
6. 確定要件の書き出し: requirementsPath の該当パスに、後述の「requirements.md の構成(実運用フォーマット)」に従って書く
7. 確定要件のコミット: 書き出した requirements.md を単独の docs コミットにする(例: docs: release-N-slug の確定要件を追加)。run-release の Gate 0 は作業ツリーがクリーンであることを要求するため、未コミットのまま次のステップへ進まない
8. run-release の起動: config.automation.pipeline の値で分岐する:
   • "auto": 起動確認を挟まず、そのまま次を起動する:

     Workflow({scriptPath: ".claude/workflows/run-release.js", args: {release: "release-N-slug", config: <手順1で読み込んだ config>}})
     

   • "ask": AskUserQuestion で起動可否を確認し、承認された場合のみ上記を起動する。見送られた場合は、上記の起動スニペットと従来の個別実行(implement-feature 以降の各工程)を案内して終了する
   • 起動は常に scriptPath 指定とする(新規ワークフローが同一セッションで name 解決されない既知の罠の構造的回避)