what-now

What Now

これは what-now オリエンテーションスキルです。ユーザーのアクティブな変更の現在の状態を読み取り、次に何をすべきかを明確に伝えます。推測や曖昧さはありません。

ヘルパースクリプトの実行

このスキルには、専用の scripts/ ディレクトリにヘルパースクリプトが含まれています（この SKILL.md と同じ場所にインストールされています）。このスキルの絶対パス（このファイルの末尾に このスキルのベースディレクトリ として表示されています）を SKILL_DIR に設定し、プロジェクトのルートディレクトリからスクリプトを実行します（プロジェクトの .changes/ ファイルと CONTEXT.md ファイルを操作します）。

SKILL_DIR="<absolute path to this skill's directory>"

以下のすべての node "$SKILL_DIR/scripts/..." コマンドは、この設定に依存します。packages/build/ は参照しないでください。このパスはツールキットの開発リポジトリにのみ存在し、インストール済みのスキルにはありません。

ステップ 1：受付

マニフェストを読む前に、目標と観察可能な成果、影響を受ける領域、制約とアンチゴール、要件が確定済み、一部確定、または未確定のいずれであるかを確認します。依頼が状況確認のみの場合は、変更の成果が提示されていないことを記録して続行します。

ステップ 2：現在の状態を取得

node "$SKILL_DIR/scripts/change-status.mjs"

JSON 出力を解析します。アクティブな変更がない場合は、以下の「アクティブな変更がない場合」セクションに進みます。

ステップ 3：各アクティブな変更を解釈して助言

機能変更（クラス：feature）

次の判断ツリーを使用します。

フェーズ	承認状態	ユーザーへの案内
architect	architect pending	「architect を実行して、アーキテクチャ設計セッションを開始または続行してください。」
architect	architect approved	「specify を実行して、実装の詳細とインターフェースを確定してください。」
specify	specify pending	「specify を実行して、仕様作成セッションを続行または再開してください。」
specify	specify approved	「plan を実行して、決定事項を実装チェックリストに分解してください。」
plan	plan pending	「plan を実行して、計画セッションを続行または再開してください。」
plan	plan approved	「implement を実行して、タスクのチェックリストに取り組んでください。」
implement	implement pending	「implement を実行して、実装に着手または続行してください。」
implement	implement approved, docs pending	「implement を実行してください。現在はドキュメントの調整フェーズです。CONTEXT.md ファイルを更新し、ドキュメントの承認を行ってください。」
archive-ready	docs approved	「検証済みアーカイブを作成してください。これが最後のアクティブな状態です。」

差し戻しが記録されている場合：

• マニフェストから差し戻しの項目を読み取ります。
• 最新の差し戻しの resolution が空の場合、未解決です。ユーザーに次のように伝えます。「[phase] に未解決の差し戻しがあります：[missed]。[restart_phase] から再開し、続行する前に [invalidated_approvals] のみ再承認してください。」

トリアージ変更（クラス：bug | small）

フェーズ	承認状態	ユーザーへの案内
implement	implement pending	「triage を実行して、直接修正を実施または続行してください。」
implement	implement approved, docs pending	「triage を実行して CONTEXT.md を調整・検証し、ドキュメントを承認してください。」
archive-ready	docs approved	「検証済みアーカイブを作成してください。」

リファクタリング変更（クラス：refactor）

フェーズ	承認状態	ユーザーへの案内
refactor	refactor pending	「refactor を実行して監査を完了し、リファクタリングの承認を取得してください。」
implement	implement pending	「refactor を実行して、選択したクリーンアップに取り組んでください。」
implement	implement approved, docs pending	「refactor を実行してドキュメントを調整・検証し、ドキュメントを承認してください。」
archive-ready	—	「検証済みアーカイブを作成してください。監査のみの場合は、承認済みの監査レポートが含まれます。」

エピックの変更（クラス：epic）

状態	ユーザーへの案内
アーキテクトの承認待ち	「エピックに対して architect を実行し、全体像を設計して子変更を特定してください。」
アーキテクト承認済み、仕様策定待ち	「エピックに対して specify を実行してください。このセッションでは、子変更間の横断的な契約（共有インターフェース、データ形式、順序の制約）を確定します。」
仕様策定承認済み、子変更なし	「エピックに対して specify を実行してください。仕様策定セッションが終了すると、子変更のマニフェストが作成され、エピックが decomposed に移行します。」
分解済み、すべての子変更がアーカイブ可能な状態ではない	子変更の進捗表を表示します。深さ優先で作業します：次に archive-ready まで進める子変更を1つだけ特定し、一括では選びません。子変更がスパインの途中にある場合は、まずその子変更の次のフェーズに進むよう案内してください。
すべての子変更がアーカイブ可能な状態	「エピックのコンテキストを調整して検証し、ドキュメントを承認し、エピックを archive-ready に移行してから、親と子の変更をまとめた検証済みアーカイブを1つ作成してください。」

実行モデル — 深さ優先。 子変更は依存関係の順に、1つずつ archive-ready まで進めます（architect → specify → plan → implement → archive-ready）。子変更を個別にアーカイブしてはいけません。すべての子変更の準備が整ったら、エピックで調整して検証済みアーカイブを作成します。

子変更の順序： ブロックされていない子変更（未完了の兄弟変更に依存しないもの）が複数ある場合は、並行して作業してもかまいません。ただし、それぞれのスパインを最初から最後まで進める必要があります。そのことを明確に伝えてください。

複数の変更が同時進行している場合

進行中の変更をすべて、現在のフェーズと次のアクションを含む表に一覧表示します。どの変更に取り組みたいかユーザーに尋ねるか、最も進捗している（切り替えコストが最も低い）変更を提案してください。

ステップ 4：問題があるように見える場合

承認済みなのにフェーズが進んでいない： マニフェストが手動で編集された可能性があります。フェーズを強制的に進めてはいけません。該当する承認をリセットして再承認し、状態機械を進めてください。

子変更の parent フィールドが存在しないエピックを指している： 親がアーカイブ済みの可能性があります。ユーザーに確認してから、子変更を個別に進めてください。

キャンセル： manifest.archive.reason が具体的であることを確認してから、検証済みキャンセルアーカイブの作成を案内してください。進行中のワークスペースを、決して黙って削除しないでください。

進行中の変更がない場合

.changes/active/ に変更がない場合：

ユーザーに尋ねます： > 「進行中の変更はありません。何に取り組んでいますか？以下を教えてください：」 > - 目標／成果、影響を受ける領域、制約または避けたいこと、要件がまとまっているかどうか > - 「まずリポジトリのコンテキストを把握したい」→ map は任意です。その後、適切なエントリースキルを使用します > - 「きちんと作り直したい PoC がある」→ reforge を使用します > - 「まだ初期段階のアイデアがある、または解決策を比較している」→ brainstorm を使用します > - 「新機能または重要な変更がある」→ architect を使用します > - 「バグまたは小さな修正がある」→ triage を使用します

参考ファイル

• references/manifest-schema.md — フェーズの状態機械、承認の意味、エピックモデル
• references/change-lifecycle.md — パイプライン全体