statuskit

statuskit

プロジェクトに戻ってきたとき、「これは今どうなっていて、次に何をするのが一番いいだろう？」と考えるなら、まず開くのが statuskit です。プロジェクト全体を読み取り専用で調査し、Git の作業ツリー、GitHub のイシュー、オープン中の PR、未登録の計画を確認して、1 画面に収まるステータスダッシュボードを表示します。さらに、独自の判断を加えます。まず完了させるルールに沿って、考えられる次のアクションに順位を付け、実行すべきアクションを必ず 1 つだけ選び、それを実行するキット（または通常のコマンド）へ案内します。

これは読み取りと助言を行うツールです。コミット、プッシュ、イシューのクローズ、PR の編集やマージ、ラベルの変更、コードの書き込みは一切行いません。変更を伴う操作はすべて、案内先のキット内で、そのキット独自の保護のもとで行われます。statuskit の操作がリモート、ブランチ、トラッカーに届くことはありません。だからこそ、いつでも、何度でも、安全に実行して状況を把握できます。書き込みルールに記載されたローカルファイルだけに書き込みます。

どんなときに実行するか

行動を起こす前に状況を把握したいときです。「次に何をすればいい？」「プロジェクトのステータスを確認して」「このプロジェクトは今どうなっている？」「次は何？」「プロジェクトのステータス」「状況を把握したい」「/statuskit」、またはしばらく離れていたあとに「これ、今どういう状態？」とだけ尋ねる場合などです。

次の境界は重要です。

• トラッカーの信頼性を判定するツールではありません。 それは issuekit の役割です。statuskit は、推奨事項を判断するためにイシューの件数と状態を読み取り、簡易的な古さのシグナルを 1 つ計算します。トラッカーの詳しい健全性は issuekit に任せてください。issuekit は「トラッカーは正確か？」に答え、statuskit は「このプロジェクトは今どうなっていて、次に何をすればいい？」に答えます。

順位付けの原則：まず完了させる

statuskit が選ぶアクションはすべて、「新しく始めるのをやめ、完了させることに集中する」（作業中のタスクを最小限にする）という 1 つのルールに基づいています。選ばれるアクションは常に、何か新しいことを始める前に、最小限の労力で進行中の作業を最も多く片付けられるものです。

同じ段階内で順位が並んだ場合は、まず明示された優先度で決め、次に、その段階で求められる作業に応じて 2 つのシグナルのいずれかを使います。

• 再開または完了の段階。 候補のうち、最も最近アクティブだったものを選びます（イシュー／PR の updatedAt、またはブランチの最終コミット時刻）。最近のアクティビティはコンテキスト切り替えコストの目安であり、途中まで進めた作業に戻る際に最小限に抑えたいのがこのコストです。例外は、完了済みだがレビュー待ちの PR です。戻るべき作業がないため、開始段階と同様に、効果の大きさで順位を決めます。
• 新しい作業を始める段階。 ブロック解除の効果（以下を参照）が最も高いものを選び、同じ場合は最近のアクティビティで決めます。新しく始める作業には保持すべきコンテキストがないため、最近のアクティビティが示すコストはゼロです。代わりに最大化すべきなのはスループット、つまり、それが完了したあとにリポジトリで並行して進められる作業の量です。

残りの候補は次点になります。優先度も効果の大きさも、段階をまたいで候補の順位を上げることはありません。まず完了させるという原則が土台であり、これらはその中でのみ順位を決めるものだからです。例外は 1 つだけです。critical イシューです。 詳しくは以下を参照してください。

優先度

優先度とは、「何が重要か」に対する人間の明示的な判断であり、issuekit のラベルセットから読み取ります。値は critical、high、medium、low です。 statuskit が順位付けに使うその他の情報は、すべてリポジトリの仕組みから推定したものです。これは誰かが実際に示した唯一のシグナルであり、そのため、すでに挙げたシグナルと競合するのではなく、あらゆる同順位の判定で最初に使われます。

優先度の基準

label	意味	順位への反映
critical	すべてを止めて対応します。進行中の作業より優先されます	段を越えて繰り上げます
high	対応可能なほかの課題より先に対応します	同じ段の中で順位を決めます
medium	通常の優先度です。評価後のデフォルトです	同じ段の中で順位を決めます
low	いずれ対応する価値はありますが、何も優先しません	同じ段の中で順位を決めます
(none)	未評価です。誰も順位を付けていません	low より下になります

優先度は独立した2つのラベル名前空間の1つであり、statuskit は両方を読み取ります。 ライフサイクル（ready、blocked、in-progress、…）は課題に取り組めるかどうかを示し、優先度は次に取り組むべきかどうかを示します。一方から他方を決めつけてはいけません。blocked の critical 課題は依然としてブロック中であり、それを最上位にすると、ユーザーが着手できないものを勧めることになります。

未評価の課題は low より下になりますが、それは作業への評価ではありません。 トラッカーへの評価です。誰も順位を付けていない課題には、優先すべきという主張がありません。statuskit の役割は、根拠を示せる次の一手を選ぶことです。ラベルのない課題をラベル付きの課題より上にするのは、ユーザーに代わって主張をでっち上げることになります。未評価の課題が多いなら、それこそが発見事項です。誰も順序を付けていないバックログを黙って並べ替えるのではなく、その状態を示して issuekit triage を案内してください。

critical だけは、完了優先を上回ります

ここでのほかのシグナルはすべて同じ段の中で順位を決めます。これは意図的な抑制です。巧妙な数値によって、ユーザーが始めた作業を完了するのを思いとどまらせないためです。critical は例外であり、その理由は一行で述べられるほど明確です。完了優先は、何が重要か誰も示していないときに何をすべきかを決めるヒューリスティックであり、critical は誰かが重要だと示したものです。

進行中の作業を最小限に抑えるのが適切なデフォルトなのは、まさに追加情報を必要としないからです。どのリポジトリでも、いつでも、誰にも尋ねずに機能します。critical ラベルはそのデフォルトよりも明らかに優れた情報であり、この調査において人が意図的に設定した唯一のシグナルです。それを無視すると、statuskit は、ユーザー自身が火急だと示した課題よりも、半分しかできていないリファクタリングを上位にすることになります。ダッシュボードを単に間違っているのではなく、信用できないものにしてしまうのは、これだけです。

3つのガードによって、例外が原則を飲み込まないようにします。

• 繰り上げられるのは、対応可能な critical だけです。 ブロックされておらず、オープンでなければなりません。blocked の critical は着手できないため、適切な場所であるブロック中の一覧に残ります。そのブロッカー自体が対応可能なら、それが最上位の次の一手になります。
• 繰り上げるのは critical だけです。それ以外は繰り上げません。 high は小さな critical ではありません。レバレッジと同じように同じ段の中で順位を決めます。先回りを望むリポジトリは critical と示す必要があり、その手間こそがこのレベルの意味を保ちます。
• 何を後回しにするかを伝えます。 critical によって、それがなければ選ばれていた段の項目を後回しにする場合は、同時に後回しになる次の一手を明示します。「#12 は critical なので最優先です。赤い PR #34 は次点になります」。ユーザーに見えない先回りは、順位付けのバグと見分けがつきません。この例外はまれなので、特別な出来事として伝えるべきです。

対応可能な critical が複数あるなら、それ自体が発見事項です。 2件ならタイブレーク（レバレッジ、次に最近のもの）で決めます。しかし、複数の課題がすべてを優先するトラッカーでは、このレベルの意味が失われています。どれについても何も後回しにならず、critical がいつの間にか新たな通常レベルになっているためです。最上位の次の一手にその旨を記し、古くなった critical ラベルをドリフトとして検出する issuekit triage を案内してください。

ブロック解除レバレッジ

unblocks(X) は、X が解決された時点で完全に対応可能になるオープンな課題の数です。 「次に、これらのうちどれが最も多くの独立した作業を解放するか」への答えであり、このファイルでは、すでに課題名を示している2つの表に、並べ替え可能な列として表示します。 そのルールを決めるのは「完全に」という言葉です。#19 が #12 と #23 の両方によってブロックされている場合、#12 を閉じただけでは #19 は着手可能になりません。ブロックが減るだけであり、取り掛かれるものを探している人にとっては何の価値もありません。#12 を取り除いたときに、その課題に残る未解決のブロッカーがゼロになる場合に限り、その課題を unblocks(#12) の数に含めます。これより緩い定義では数が水増しされ、誤った課題を指し示すことになります。優先順位をまったく付けないよりも悪い結果です。

PR へのレバレッジは、その PR がクローズする課題を通じて生じます。unblocks(PR #34) は、その PR の closingIssuesReferences に含まれる課題のレバレッジです。これによって Closes 列は単なる事実の表示から優先順位へと変わります。CI の結果にかかわらず、3 件の課題を解放するレビューは、1 件も解放しないレビューより優先されます。

スタックのすべてのレイヤーで closingIssuesReferences は空です。これはリンク切れではなく、プラットフォームの仕様です。 GitHub がクローズキーワードを解決するのは、リポジトリのデフォルトブランチを対象とする PR に限られます。そのため、正しい Closes #123 を含むレイヤー PR でも、下のレイヤーがマージされ、GitHub がその PR のターゲットを trunk に変更するまで、クローズする課題は表示されません。同じフィールドを参照する 3 つの表示は、レイヤー上ではすべて同時に誤った結果になります。その PR は何もクローズせず、優先順位もレバレッジも表示されず、そのブランチはどの課題にも対応付けられません。そのため、baseRefName がデフォルトブランチでない PR では、本文から Closes #N を抽出して代わりに使ってください。見つかったものは、closingIssuesReferences が返す値とまったく同じように扱います。このファイルのほかの箇所と同様、抽出はあくまで簡易的な読み取りです。レイヤー上の PR で、かつフィールドが空だった場合に限って使ってください。

数値を正確に保つためのルールは 4 つです。

• 深さは 1 のみです。 連鎖的な依存は数えません。推移的な数値では、中間の課題が単にブロック解除されるだけでなく、完了すると仮定することになります。そのようなスケジュール予測を statuskit が行うべきではありません。また、深さ 1 なら自然に循環を避けられますが、推移的にたどるには A blocked by B blocked by A のような循環を防ぐ仕組みが必要です。
• まだオープンのブロッカーのみを数えます。 これは、ブロック中の課題の集合にすでに適用されているルールと同じです。
• ブロッカーは PR の場合もあります。 GitHub では課題番号と PR 番号で同じ名前空間を共有するため、blockedBy: #34 は「マージ待ち」を意味することがあり、オープン PR の読み取りに対して解決されます。
• 依存関係が宣言されていなければ、列も表示しません。 リポジトリのグラフにエッジが一つもなければ、すべての値は 0 になります。この列を表示すると、「依存関係が何も解除されない」と誤って伝えてしまいますが、実際には「誰も依存関係を記録していない」ということです。列を非表示にし、依存関係が宣言されていないため、レバレッジは利用できませんと一度だけ伝え、issuekitを案内してください。依存関係の宣言はトラッカーを適切に管理するためのものであり、サーベイの役割ではありません。

2 つの状態は表示しますが、最優先にはしません。対処には人の判断が必要であり、statuskit が後回しにせず完了させるべき作業とは見なせないためです。

• 承認済みで CI もグリーンの PR（「マージ可能」）。マージするかどうかはあなたが決めるためです。
• 他の人から実際に対応を求められているレビュー待ちの PR。これはあなたの手の届かないところにあるためです。

どちらもダッシュボードには事実として表示されますが、いずれも最優先の作業にはなりません。

「あなたの手の届かないところにある」とは、実在する人についての主張です。 この 2 つ目の状態に当てはまるのは、レビュー担当者が指定されている場合、または作成者以外の人がすでにレビューしている場合など、実際に誰かに対応が求められているときだけです。作成者であることから推測して（「あなたが PR を作成したのだから、誰かの対応を待っているはず」）、そう判断する方法では、個人で管理するリポジトリではダッシュボード全体が機能しなくなります。すべての PR があなたのものであり、誰にも依頼していないのに、すべての行がいつまでも相手待ちと表示され、優先順位付けでは別のものが最優先になります。したがって、待ち状態は author ではなく reviewRequests と latestReviews から判断してください。答えが誰もいないなら、その PR はあなたの手の届かないところにあるのではありません。あなた自身の対応で止まっているため、完全な優先順位付けに従って順位を付けます。 statuskit が認定するのはレビューまでで、マージは認定しません。 これにより、新しい段階がその上位ルールと矛盾しなくなります。未レビューの PR をレビューすることは、完了を確認できる実際の作業ですが、マージボタンを押すかどうかは判断が必要なため、statuskit は関与しません。認定されるアクションは reviewed で終わり、マージの判断はあなたに返されます。

トラッカーの解決

すべてのプロジェクトが GitHub Issues で作業を管理しているわけではなく、gh が動作することは、このプロジェクトが GitHub Issues を使っている証拠にはなりません。 リポジトリで gh の認証が済み、Issues が有効で、未解決のバグ報告が 40 件あっても、計画された変更はすべて Linear に記録されている場合があります。別のリポジトリは昨日作成されたため、Issue が 1 件もないかもしれません。この 2 つには正反対の案内が必要になるため、statuskit は API の応答の有無から推測せず、明示的に判断します。

答えが得られる最初の段階を採用します。

1. プロンプト。 ユーザーが明言しています（「GitHub Issues は使いません」「この内容をトラッカーに登録して」）。明示された内容が常に優先されます。
2. リポジトリのエージェントガイドファイル（CLAUDE.md または同等のファイル）に、作業の追跡先が記されています。このプロジェクトでは GitHub Issues ではなく Linear で作業を追跡します のような一文が、どちらの場合でも判断を確定させます。
3. 検出。 プランの調査ですでに実行している gh issue list --state all の呼び出しを使うため、追加コストはかかりません。空でない配列は あり を意味します。リポジトリで Issues が無効だと示すエラーは なし を意味します。
4. 不明。 空の配列、またはその他のエラー（ネットワーク、認証、レート制限）です。空の配列からは、作成初日のリポジトリなのか Jira を使う組織なのか判断できません。また、呼び出しの失敗はポリシーについて何も示しません。

判定結果は 4 つの状態のいずれかであり、このファイル内のトラッカーに依存するルールはすべてこれに基づきます。

判定	根拠	Issue の段階（†）と Issues パネル	未登録プランの確認
あり	プロンプト、ガイド、または空でない配列	実行	実行
なし	プロンプト、ガイド、または Issues が無効であること	スキップ	スキップ
不明	空の配列、またはその他のクエリエラー	スキップし、その旨を一度だけ伝える	スキップ
利用不可	gh が見つからない、認証されていない、または GitHub リモートがない	Git のみの段階に切り替える	スキップ

以下でいう トラッカーなし とは、「なし」または「不明」を意味します。クエリエラーは「なし」を意味しません。 失敗した呼び出しを Issues の行に一度だけ記載し、トラッカーなしの場合と同様に進めます。再試行によって確定するのであって、宣言によって確定するのではありません。プロンプトまたはガイドで「あり」と示されているのに Issue クエリが失敗した場合も同様です。ポリシーは分かっていますが、データが分からないため、Issue の段階はスキップし、失敗した呼び出しを記載します。

「不明」の場合は、トラッカーなしと同様に進め、その旨を伝えます。 プランが未登録だと断定したり、「Issue を登録する」というアクションを認定したりせず、両方の経路を 1 行で示します。空の配列による「不明」だけが、ポリシーが曖昧な状態です。ライフサイクルラベルを調べて曖昧さを解消しようとしてはいけません。テンプレートでラベルが用意されていても誰も使っていない場合があり、その調査で変わるのは文言だけで、アクションは変わりません。この状態になり、ユーザーが回答できる場合は、declaration.md を読んでから、その内容に従ってください。

これを解決するのは statuskit だけです。 ちょうど 1 つのアクションを認定するのは statuskit だからです。他のスキルは、一行の結論を引き継ぐ（issuekit、afkkit）か、解決せずに両方の候補を示すだけです（plankit、grillkit、implementkit）。判断の導出を一か所にまとめることで、4 つのスキルがそれぞれ少しずつ異なる答えにずれていくのを防ぎます。

手順

1. 事前確認。情報源ごとに段階的に機能を絞り、全体を失敗させない

statuskit はgitファーストです。常に git のシグナルを軸にし、利用可能な場合は GitHub のシグナルで補完します。処理を中断するのではなく、利用可能なものを検出して対応します。

• git リポジトリではない → その旨を伝え、git 由来の情報はすべてスキップします。まだリポジトリがない場合は、「まず plankit を使い始める」が次のステップです。
• gh がない／認証されていない／リモートがない → 以下のgit のみの手順に切り替えます。これは正式な動作モードであり、エラーではありません。実際の不足点（gh がインストールされていない、gh auth login を実行する必要がある、または GitHub リモートを追加する必要がある）を一度伝えてから、処理を続けます。
• gh は使えるが、プロジェクトで GitHub Issues を作業管理に使っていない → トラッカーの解決に従って、明示的に判断します。これは機能上の問題ではなくポリシー上の事実なので、失敗した呼び出しによって判明することはありません。また、Issue の各段階と Issues パネルはこの判断に従います。
• 計画ドキュメントがない → 計画の読み取り全体をスキップします。計画が存在する場合でも Plans パネルは条件付きです。計画の調査を参照してください。
• シェルがまったくない（例：ブラウザベースのエージェント） → 調査を実行できないため、以下のコマンドをユーザーに提示して実行してもらい、返された結果を基に判断します。

2. 調査。読み取り専用でシグナルを収集する

常に git の情報を収集し、gh が使える場合に限り GitHub の情報も収集します。すべて読み取り専用のコマンドです。

git（常に実行）：

• 作業ツリー：git status --porcelain、現在のブランチ、上流ブランチとの先行／遅れ、git log @{u}.. --oneline（未プッシュのコミット。ブランチに上流ブランチが設定されていない場合はスキップします。上流ブランチがないこと自体が「プッシュ／公開」のシグナルです）、git stash list --format='%h %gd %s'（SHA は stash の安定した識別子です）、およびマージされていないコミットを含むローカルブランチ。
• ベースブランチ。main だと決めつけず、gitkitから取得します。以下の「フィーチャーブランチか」「マージされていないか」の判断はすべて、このブランチを基準にします。デフォルトブランチが develop や trunk のリポジトリで main を前提にすると、ダッシュボード全体の読み取りを誤ります。
• ブランチから Issue への対応付け。 現在のブランチを、オープンな PR の closingIssuesReferences（信頼できるシグナルであり、以下の PR 読み取りですでに取得しています）から追跡対象の Issue に対応付けます。見つからない場合はブランチ名のヒューリスティックにフォールバックします。スタックのレイヤーではこのフィールドが空なので、ブランチ名にフォールバックする前にレイヤーのフォールバックを適用し、PR 本文から Closes #N を読み取ります。ブランチ名のパターンは、ブランチ名を付けた gitkit から取得します（issue-<n>-<slug>）。ここでパーサーを別途もう一つ維持するのではなく、gitkit から読み取ります。そうすれば、上流で名前が変更されても、こちらがひそかに何にも一致しなくなる事態を避けられます。より緩やかなフォールバックとして、単独の #N、または Issue タイトルに一致するスラッグを使います。対応付けできない場合、ベース以外のブランチに変更があるときは、commit ではなく continue と判断します。
• worktree。 ブランチのコードがどこにあるかを調査で確認する必要がある場合は、パスを読み取るのではなく gitkit に問い合わせます。statuskit は worktree を作成も削除もせず、報告のみを行います。 GitHub（gh が使用できる場合のみ）：
• イシュー：gh issue list --state open --json number,title,labels,updatedAt,blockedBy,blocking を使い、ライフサイクルラベル（in-progress／ready／stacked／needs-planning／blocked／in-review）ごとに分類します。この語彙を使っていないリポジトリ向けに、ラベルなし／その他のステータスのバケットも設けます。件数と対応可能な項目だけを示し、ドリフト検出はしません。最近更新されたラベルなしのイシューは、見えない作業として扱わず、分類または計画の候補として扱います。
• 同じ labels 配列から読み取る 優先度 は、追加の呼び出しが不要です。調査ではすでにすべてのオープンイシューの全ラベルを取得しており、優先度はその中に含まれる4つのラベルだからです。複数の優先度ラベルが付いている場合は、最も高いものを採用します（これは状態ではなくトラッカー上の不整合であり、issuekit triage で修正します）。どれも付いていない場合は none とします。優先度ラベルが付いたオープンイシューが1件もない場合は、空欄だらけになるのを避けるため列を省き、issuekit triage を示しながら、優先度は未設定です。影響度と更新の新しさで順位付けしています と一度だけ伝えます。これは、影響度の列がすべてゼロの場合と同じルールであり、理由も同じです。値がまったく変わらない列は、確認した結果が空だったという事実のように見えますが、実際にはまだ誰も入力していないからです。
• 依存関係グラフ。 同じ呼び出しで取得する blockedBy と blocking は、GitHub のネイティブなイシュー依存関係なので、グラフは解決済みの状態で取得できます。本文の解析も、イシューごとの取得も、2回目のリクエストも不要です。フィールドの形式を決めつけず、(.blockedBy // []) | length のように防御的に読み取ります。リポジトリがこの機能を使っていない場合は、本文中の Blocked by #N／Depends on #N／Blocks #N という行をシェル内で --jq により抽出するテキスト規約に切り替え、本文がコンテキストに入らないようにします。どちらの方向からも同じエッジが表現されるため、1つに正規化します。
• ブロックされていない項目：ブロックされておらず、かつ in-review でもないすべてのオープンイシューを、件数にまとめず、番号＋バケット＋優先度＋updatedAt＋unblocks の件数＋タイトルで保持します。これは今すぐ着手できる一覧で、ダッシュボードではテーブルとして表示します。そのため、2回目の gh 呼び出しなしで作業に取りかかれます。オープン中の blockedBy 項目がある場合、または blocked ラベルが付いている場合、そのイシューはブロックされています。コードがすでに書かれていて次の手順がレビューであり、そのレビューは下の「レビュー待ち」テーブルにすべて表示されるため、in-review ラベルが付いているイシューは in-review とします。ここにも重複して載せると、今すぐ着手できる一覧に、着手できない項目が混ざるからです。ブロッカーがオープン中の PR を持つ、まだオープンの blockedBy 項目は、ブロックとして数えません。 前提となる作業は実装され、プッシュ済みなので、依存する作業はブロッカーのブランチを土台にしたブランチで今すぐ進められます。そのため、ブロック中の項目ではなく、stacked マーカーを付けてこのテーブルに載せます。この判定には、ダッシュボードがすでに行うオープン PR の読み取りを使うため、追加コストはありません。誤判定が大きな問題になるのは一方向だけです。積み重ねて進められる作業を「ブロック中」に分類すると、読者に見る必要がないと言っている唯一のテーブルに隠れてしまい、この調査の目的と正反対になります。それ以外はすべてブロックされていません。ready、ラベルなし、または計画が必要な作業、そして再開できる in-progress の作業が該当します。優先度の降順、次に unblocks の降順、最後に更新日時の新しい順で並べます。 宣言された優先度は推定されたものより上位であり、誰も順位付けしていない場合は影響度で順序が決まり、更新の新しさは並び順ではなく独立した列に残るからです。
• ブロック中の項目は、同じ読み取り結果のもう半分です。番号＋優先度＋待っている対象＋タイトルで保持します。ここに含めるのは、まだ実装されていない前提条件を待っている、本当に待機中の項目だけです。ブロッカーにオープン PR があるものは、すでに上のブロックされていない一覧に移されています。このテーブルの項目には着手できないにもかかわらず、優先度を表示するのは、追いかけるべきブロッカーかどうかが分かるからです。未着手の前提条件にぶら下がっている critical は、その前提条件を始めるべきだと示す、ダッシュボード全体で最も強い根拠です。この列がなければ、ほかの待機項目と同じに見えてしまいます。ブロッカーは、blockedBy があればそこから、なければ Blocked by #N／Depends on #N の行から取得します。blocked ラベルしかない場合は名前を特定できません。名前のある場合もない場合も、3つの形式すべてを保持してください。ブロッカー名がなくても、表示する価値のある事実です。イシューが何を待っていると述べているかを報告するのは、読み取った事実を示すだけです。そのブロッカーが今も有効かどうかを判断し始めた時点で、issuekit の領域に踏み込んでいるため、issuekit を示す必要があります。
• オープン PR：gh pr list --json number,title,author,baseRefName,statusCheckRollup,reviewDecision,reviewRequests,latestReviews,isDraft,updatedAt,closingIssuesReferences を使い、自分が作成し、問題がある／変更を求められている PR（対応可能）、誰もレビューしていない PR（対応可能）、承認済み＋CI 成功（表示のみ）、本当に他の人の対応待ち（表示のみ）に分類します。大規模なリポジトリでは高速性を保つため一覧の件数に上限を設けます。JSON フィールドが拒否された場合は、値を指定せず gh pr list --json を実行して、gh が受け付けるフィールドの一覧を確認します。
• 各 PR がクローズするイシュー。 本文から Closes #N を検索するのではなく、同じ呼び出しで取得する closingIssuesReferences を使います。これは GitHub が解決済みリンクとして認識する情報なので、大文字・小文字を問わず Closes／Fixes／Resolves を網羅し、UI で手動リンクされたイシューも含みます。また、コードブロックや引用されたレビューコメントにその文言があっても誤認しません。例外はスタックのレイヤーです。 その場合、GitHub は仕様上フィールドを空のままにするため、レイヤーのフォールバックを適用します。baseRefName は上の呼び出しですでに取得しているので、デフォルトブランチと比較し、その判定に該当しない PR では gh pr view <n> --json body --jq を使って本文から Closes #N を抽出し、本文がコンテキストに入らないようにします。このような行では Closes セルにイシュー番号の後ろへ (stacked) と記載し、リンクが存在しないのではなく保留中であると読者に分かるようにします。優先度と影響度は、解決済みフィールドの場合と同じように引き継ぎます。
• レビュー待ちの項目：レビューが未完了（reviewDecision が空、または REVIEW_REQUIRED）である、オープン中の非ドラフト PR すべてを、番号＋クローズするイシュー＋優先度＋unblocks の件数＋CI の状態＋作成者＋次に対応する人＋updatedAt＋タイトルの順で保持します。ID と、その ID が片付ける作業は並べて示します。この2つを合わせて初めて、その行に注目すべき理由が分かるからです。ブロックされていない項目と同じく、優先度の降順、次に unblocks の降順、最後に更新日時の新しい順で並べます。
• PR の優先度は、クローズするイシューの中で最も高い優先度です。 closingIssuesReferences を通じて PR に影響度を引き継ぐのと同じで、理由も同じです。PR 自体に重要度はなく、クローズする作業の重要度だけが対象だからです。平均ではなく最も高い優先度を採用します。PR をマージすると、それらのイシューすべてが完了し、その中で最も緊急度の高いものが実際に待たれているからです。クローズするイシューがない PR には優先度がないため、ダッシュを表示し、影響度と更新の新しさで並べます。ダッシュボードではこれらをテーブルにします。「レビュー待ち 3 件」だけでは、どれを自分が催促すべきか、どれに他の人の回答が必要か分からないからです。
• 次に対応する人は、作成者ではなくレビュアーから判断します。 次の3つをこの順に確認します。reviewRequests に自分が含まれている → 自分。レビューしてください。reviewRequests に他の人が含まれている、または latestReviews に作成者以外の人が含まれている → 相手。名前を示し、本当に相手の対応待ちであることを明確にします。どちらにも該当しない → 誰もレビューしていない。これは、レビュー待ち PR の見た目をしている停滞中の PR です。この3番目のケースは、ソロのリポジトリではすべての PR、チームのリポジトリではよくある見落とし（自分で PR を作成したものの、誰にもレビューを依頼していない）に該当します。どちらも、何もしなければレビューが始まらないという点で同じなので、順位付けするのはこのケースだけです。
• ほかにレビューできる人がいるのか？ これは3番目のケースに該当した場合だけ、実行ごとに一度だけ確認します。gh api repos/{owner}/{repo}/collaborators --jq 'length' を使います。共同作業者がちょうど1人なら、ほかにレビューできる人がいないことが確定するため、次の対応は自分でレビューすることです。2人以上、403、エラー、または取得できなかった場合は、レビュアーがいる可能性を排除できません。そのため、次の対応には両方の案（「レビュアーを依頼するか、自分でレビューする」）を示します。確認が必要な PR がない場合は、この呼び出しをしないでください。また、確認に失敗しても行を省かないでください。次に対応する人の列は確認なしでも正しく、確認によって変わるのは推奨内容の表現を詳しくする部分だけです。
• トラッカーの古さを示すシグナルとして、安価な相互チェックを1つ行います。関連するイシューがまだオープンのままになっている、マージ済み PR の件数です。単一の件数のみを使い、「再調整」を上位にするかどうかの判断に限って使います。どのイシューか、なぜそうなっているかを項目ごとに列挙してはいけません。それは issuekit の役割です。 plans（ファイルシステム。リストは常に実行され、未登録の確認にはトラッカーが必要です）：
• 正規の docs/plans/NNNN-plan-<slug>-YYYY-MM-DD.md ファイルと、連番のない旧形式の plan-<slug>-YYYY-MM-DD.md ファイルを列挙します（ただし、リポジトリ内で別の場所にプランが置かれている場合はその場所を使います。rfcs/、specs/、またはドキュメントで指定された場所があれば、そちらを優先します）。リストの取得は無料で、常に実行されます。これをラダーのプランの段階で読み取ります。
• 未登録の項目は、リポジトリが実際に GitHub issue で作業を追跡している場合にのみ算出します。 各プランを issue リストと照合し、issue になっていないものを残します。照合には、調査のほかの部分で使うオープン issue の一覧ではなく、--state all を使います。プランドキュメントが存在する場合に限り、gh issue list --state all --json number,title --limit 200 を1回呼び出します。数か月前に完了したプランには クローズ済み の issue があるため、オープン issue のみと照合すると、完了したプランがすべて未対応として報告されます。まさにこれが、このパネルを表示しない価値がある失敗例です。
• 同じ呼び出しがトラッカー解決の rung 3にあたるため、追加コストはかかりません。 未登録の比較に意味があるのは、トラッカーの読み取り結果が存在する場合だけです。結果が absent、unknown、または unavailable の場合は確認を省略し、プランを未登録として報告してはいけません。クエリエラーは absent ではなく unknown です。多くのプロジェクトでは、Linear、Jira、TODO.md、あるいは誰かの頭の中で作業を追跡しています。そのようなプロジェクトに「未登録が18件あります」と告げる調査は、自らの見落としを結果として報告し、ユーザーが意図的に使っていないトラッカー向けに issuekit create を案内してしまいます。
• プランのスラッグとタイトルで照合し、判断がつかない場合は登録済みとして扱います。 issue のタイトルがプランのタイトルと一致する、本文からプランのパスへリンクしている、またはスラッグが一致する場合は、それだけで十分です。この非対称性は意図的です。このパネルが表示するのは不足分だけなので、偽陰性なら気づかれない行が1つ増えるだけですが、偽陽性では、すでに追跡されている作業の重複登録をユーザーに促してしまいます。
• 未構築の項目は、トラッカーがない場合にプランの rung が順位付けに使うものです。 Phase <n> で始まる見出しを探し、区切り記号は緩やかに照合します（### Phase 2: auth と ### Phase 2 — auth は同じ形式です。実際のプラン群には両方が含まれます）。見出しに (built YYYY-MM-DD) のスタンプがあるフェーズは構築済みです。これは implementkit が、issuekit の (#41) が使うのと同じ末尾の位置に書き込みます。両方を併記できるため、### Phase 2: auth (#41) (built 2026-08-20) は、追跡され、リリース済みのフェーズです。
• スタンプがどこにもないプランは、何も表明しません。 スタンプの規約はプランごとに任意であり、スタンプがないことは未スタンプを意味します。未構築と解釈すると、この規約ができる前に書かれたすべてのプランを未完了の作業として報告してしまいます。そのようなプランはひとまとまりの単位として扱い、git のみのラダーと同様に、プラン全体を最優先にします。プランにスタンプが1つでもあれば、その情報は確定的なものとして扱い、スタンプのないフェーズは実際に未構築です。すべてのフェーズにスタンプが付いたプランは完了済みなので、対象から外します。

3. 順位を付け、最初に完了すべきアクションを1つ選ぶ

シグナルを候補アクションに対応付け、それぞれに所有するキット／コマンドのタグを付けたうえで、該当する中で最も高い rung を選びます。同じ rung 内の同順位は、その rung の行に記載された方法で決めます。記載がなければ、直近でアクティブだったものを優先し、それ以外は次点にします。GitHub シグナルが利用可能かどうかでラダーを選びます。

Git のみのラダー（gh なし）：

#	状態	アクション →
1	フィーチャーブランチに未コミットの作業がある	続行する、または commitkit を実行する
2	プッシュされていないコミットがある	git push
3	stash がある	gitkit rescue で確認して復元する、または破棄する
4	マージされていないローカルのフィーチャーブランチがある	完了させる、または gitkit clean で整理する
5	ディスク上にプランのドキュメントがある。トラッカーを確認できないため、登録済みかどうかは不明	最新のプランを implementkit で実装する
6	ベースブランチにあり、変更はなく、保留中のものもない	新しい作業（最新のプラン）を始める、または plankit を実行する
完全なラダー（gh が利用可能な場合）。git のみで判定できる状態にも、それぞれ明確な配置先があります。(表には出しますが、次の一手には選びません：承認済みかつCI成功のPR、他の誰かが本当に対応する必要のあるPRです。)

#	状態	次のアクション →
0 †	オープンでブロックされておらず、次の一手に選ばれていない、実行可能な critical イシュー	今の作業を中断します。ready または開始可能な stacked なら issuekit start <N> を実行し、in-progress なら再開します
1	自分のPRがCI失敗、または変更を求められている	CIを修正するか、mergekit fix <N> でレビューに対応します
2	誰もレビューしていない自分のPR（優先度が最も高いもの、次に unblocks、次に最終更新日時が新しいもの）	mergekit start <N> でセルフレビューできる状態にするか、レビュアーを依頼します
3 †	作業中で、自分がそのブランチにいるイシュー (未コミットの作業も「続行」としてここに含まれます)	再開するか、implementkit を実行します
4	孤立した作業：ベースブランチ上または追跡されていないブランチ上の未コミットの作業、あるいは未プッシュのコミット	commitkit を実行するか、プッシュします
5	stash	gitkit rescue で復元して作業を完了するか、不要なら削除します
6	マージされていないローカルの機能ブランチ	完了させるか、gitkit clean でブランチとそのワークツリーをクリーンアップします
7 †	古いトラッカーのシグナルが発生した	issuekit sync で整合性を取り直します
8 †	開始する ready イシュー、または開始可能な stacked イシュー（優先度が最も高いもの、次に unblocks、次に最終更新日時が新しいもの）	issuekit start <N>（gitkit 経由でワークツリーを作成）を実行し、その後 implementkit を実行します
8b	トラッカーなし： 最新のプランにある、まだ構築されていない次のフェーズ	implementkit で構築します
8c †	needs-planning イシュー（優先度が最も高いもの、次に最終更新日時が新しいもの）	grillkit で詳細を詰め、その後 issuekit triage で昇格させます
9 †	ラベルのないイシュー、またはライフサイクルマップにないステータスで、分類が必要なイシュー	issuekit triage で分類します
10 †	評価されていないバックログ、つまり優先度ラベルのないオープンイシュー	issuekit triage で順位付けします
11	未登録のプラン (トラッカーを使用中の場合のみ)、またはプランがまったくない状態	issuekit create または plankit を実行します

† は、トラッカーを使用している場合にのみ該当する段を示します。 順位付けの前に、トラッカーの判定に従って使用の有無を確定してください。これらの段のうち7つはトラッカーの使用を条件とするためです。作業を別の場所で追跡しているプロジェクトでは、これらの段はすべて飛ばされます。まさにその穴を埋めるのが段8bです。これがなければラダーは行き詰まり、次の一手が選ばれません。ディスク上に未構築のプランがあるリポジトリで「次の一手なし」とするのは、発見事項ではなく調査の失敗です。PRとgitの段（1、2、4、5、6）はトラッカーに依存しません。ブランチとプルリクエストは、トラッカーが何であれ同じ事実だからです。

段8bは段8のトラッカーなし版であり、意図的に同じ高さに置かれています。 どちらも何かを開始する段であり、どちらも上の完了段に該当するものがなかったことを意味し、作業が選ばれた後の引き継ぎ方法も同じです。プラン独自の順序、つまり最新のプランで最も番号の小さい未構築フェーズに基づいて順位付けします。プランのフェーズは依存関係の順に記述されており、先に進みすぎると、まだ存在しない前提条件の上にフェーズを構築することになるからです。

stacked イシューは、前提条件となるPRがまだオープンで、1本のチェーンを構成している場合に開始可能です。 オープン中のPRを確認すればそれも分かるため、確認のための追加コールは不要です。前提条件のPRがマージまたはクローズされている場合は、トラッカーとの不整合です。「Issues」行に記載して issuekit sync に回してください。start では拒否されます。段8cは、開始可能なすべてのイシューより下に置かれます。 needs-planning イシューは、人間が判断事項を決めるまで誰も開始できず、分類はすでに済んでいるため、分類より上に置かれます。次のアクションは人間による詳細な検討セッションなので、上のどの段も該当しない場合にのみ選ばれます。 Rung 0 がゼロと番号付けされているのは、実際には段ではないからです。 これは finish-first の軸を上書きする唯一の例外として文書化されています。これを順序の中に番号付きで含めると、単に最初に並ぶ通常の状態に見えてしまいます。発動するのはまれで、何を押しのけたのかを明示する必要があります。これより下が実際の梯子です。ほとんどの実行で rung 0 が発動するなら、critical は意味を失っており、本当に行うべきことは issuekit triage です。

Rung 10 は、実行可能なすべての段より下、「何かを計画する」に勝ります。 優先順位のないバックログは、上位の項目が適切に順序付けできないため、実際の抜け漏れです。しかし、これは作業ではなくトラッカーの整理なので、ユーザーが実際に完了できる項目より優先されることはありません。それでも段として設けているのは、そうしなければ、誰も単一の優先順位さえ設定していないリポジトリでは、影響力だけで暗黙に順位が決まり続け、その理由が通知されないからです。

Rung 11 の前半が存在するのは、未登録の項目一覧を算出した場合だけです。 つまり、解決処理の結果が tracker in use だった場合です。別の場所で作業を追跡しているリポジトリでは、statuskit は登録済みの計画と未登録の計画を区別できないため、未登録だとは断定しません。そのため、この段は後半の 計画がまったくない → plankit だけになります。作業を別の場所に記録しているプロジェクトに「計画を登録してください」と勧めるのは、実際には確認していない内容に基づく自信過剰な提案なので、何も言わないよりも問題です。

Rung 1 と 2 は、同じことを二度述べています。自分の PR が自分のところで止まっています。 赤い PR は明らかに止まっており、レビューされていない PR は気付かれずに止まっています。気付かれないほうは何週間も放置されるため、途中まで作成した issue の再開より優先されます。コードはすでに書かれており、チェックも通っているため、最小限の労力で最も多くの作業を片付けられます。これこそが finish-first の考え方です。完了するよう促す段で、影響力を基準に同点を決めるのはこれだけです。再開するために以前の作業状況を思い出す必要はありません。完成した PR のレビューは、どれを選んでも同じ作業なので、同点なら最も多くの作業を解放するほうを選べばよいのです。

担当する kit がインストールされていない場合は、エコシステムを必要としないルーティングツールである statuskit に合わせて、「commitkit を実行する」ではなく「変更をコミットする」のように、具体的なアクションを示してください。

4. 出力：ダッシュボードと、最優先のアクションを 1 つ

レンダリング規則に従って、以下の形式でダッシュボードを出力し、その後に順位付けした次のアクションの一覧を出力します。1 位のアクションは太字にし、対応する kit／コマンドを正確に記載してください。表には、単なる件数では示せない詳細を載せます。トラッカーを使用している場合は、ブロックされていない issue、レビュー待ちの PR、ブロッカー付きのブロックされた issue を示します。トラッカーを使用していない場合は、2 つの issue 表には記載するものがなく、代わりに未構築のフェーズを表示します。1 画面に収めてください。

# Project status · <repo> · <branch> · YYYY-MM-DD

## Working tree  <clean | N uncommitted · M unpushed · stash K>

## Issues        in-progress N · ready N · in-review N · blocked N     (omit without gh, or without a tracker)

Unblocked (N) · highest priority first
| Issue | Priority | Unblocks | Status | Last active | Title |
|---|---|---|---|---|---|
| #12 | critical | 3 | ready | 2d | <title> |
| #31 | high | 1 | in-progress | 4h | <title> |
| #47 | none | 0 | unlabeled | 3w | <title> |

## Pull requests <open N: X awaiting review, Y CI-red, Z ready to merge>   (omit without gh)

Waiting for review (X) · highest priority first
| PR | Closes | Priority | Unblocks | CI | Author | Next move | Last active | Title |
|---|---|---|---|---|---|---|---|---|
| #34 | #12 | critical | 3 | ✓ | you | nobody reviewing → yours | 1d | <title> |
| #29 | #19, #23 | high | 0 | ✗ | @someone | yours | 6h | <title> |
| #38 | none | none | 0 | ✓ | you | theirs: @reviewer | 2w | <title> |

Blocked issues (N)
| Issue | Priority | Waiting on | Title |
|---|---|---|---|
| #19 | high | #12 | <title> |
| #23 | low | `blocked` label, no blocker named | <title> |

## Plans         <M unfiled: plan-debugkit, plan-testkit>   (omit entirely unless there is a finding)

Unbuilt phases (N) · plan order      (only when there is no tracker, and a plan carries stamps)
| Plan | Phase | Title |
|---|---|---|
| plan-sso-login | 3 | <phase title> |
| plan-sso-login | 4 | <phase title> |

## Next move
**→ <the #1 action>.** Run `<kit / command>`.

Then:
- <runner-up> · `<kit / command>`
- <runner-up> · `<kit / command>`
- <runner-up> · `<kit / command>`

各アクション行は、手順を示す文体で記述します。 最優先のアクション、次点のアクション、スナップショットのチェックボックス一覧は、次に何に取り組むかを決める人が一目で確認します。そのため、ASD-STE100 簡易テクニカル英語の規則に従ってください。1 行につき 1 つの指示、能動態、現在形、行為者を明記し、比喩や二重の意味を持つ語を使わないでください。「#34 をマージする」「バックログを登録する」と書き、「#34 をゴールまで進める」とは書かないでください。ダッシュボード全体で、同じ対象には同じ用語を使ってください。あるアクションでは plan doc と呼び、別のパネルでは unfiled plan と呼ぶと、別々の対象のように見えてしまいます。この規則は、出力するダッシュボードとスナップショットファイルの両方に適用されます。これにより、文章を読むのではなく、ブロック全体をざっと確認できます。

レンダリング規則

何を、どこに、どの順序で出力するかを定める規則は、すべてこの表に記載されています。スナップショットファイルにも同じ規則が適用されます。

要素	ルール	理由
状況パネル	Working tree、Issues、Pull requests、Plans はそれぞれ、見出しと件数を1行にまとめ、その後に表だけを続けます。移動の理由は移動行に記載します。	4行を読めば、読み始める前にプロジェクトの状況がわかります。2文目があるパネルはレポートになります。
パネルの表示	Working tree、Issues、Pull requests は、件数が0の場合も必ず表示します。パネルを省略できるのは、情報源を利用できない場合に限ります。具体的には、gh がない場合の Issues と Pull requests、トラッカーの読み取り結果がない場合の Issues です。理由は1回だけ記載します。	クリーンなツリーやPRがないことも確認する価値のある事実です。また、パネルの構成を固定すれば、2日分のスナップショットを比較できます。
Plans パネル	検出事項がある場合のみ表示します。トラッカーの読み取り結果がある場合は未登録のプラン、トラッカーがない場合はスタンプ付きプランの未構築フェーズが対象です。両方を同時に表示できます。検出事項がなければ、Plans 行も、ファイル内の ## Plans セクションも、その理由への言及もありません。	空のプラン件数（21 filed · 0 unfiled）にはアクションにつながる情報がありません。他のすべてのパネルは常に存在する状態を報告します。Plans だけが条件付きのパネルです。
追加パネル	標準のパネル構成では把握できない、第一級のキュー（IDEAS.md のバックログや RFC インデックスなど）について、最大1つまで追加できます。調査で読み取ったファイルから内容を取得します。ビルド、テスト、リンターの実行で内容を取得するパネルは追加しません。	statuskit は読み取り専用の調査を行います。また、パネルの構成を固定することで、2日分のファイルを比較できます。
表の順序	Unblocked、Waiting for review、Blocked issues (N) の順に並べ、同時に表示するのは最大3つです。Blocked issues は Pull requests パネルの下に置き、正式名称を維持します。Unbuilt phases は Plans の下に置きます。パネルの順序は変更しません。	読者が最初に対応できる行で手を止められるよう、対応可能な行を、対応できない行より前に置きます。パネル外で単独の Blocked (N) と表示すると、ブロックされたPRと誤読されます。
in-review の Issue	Waiting for review に1行で表示し、Unblocked には表示しません。件数は Issues 行に記載します。オープン中のPRがない場合は、Issues 行に注記します（in-review 7 · 1 with no open PR）。issuekit triage に振り分けます。	PR の行には担当者と CI の状態が示されます。Issue を Unblocked に戻すと、着手可能であると誤解されます。
行	条件に該当する行をすべて列挙します。10件を超える場合は10件までに制限し、残りを表示する gh コマンドと +N more を最後に付けます。	完全性が重要です。何も告げずに切り捨てると、全件表示されているように見えます。
空の表	表を省略し、件数行（Waiting for review (0)）は残します。	0件も調査で確認された事実であり、パネルの欠落ではありません。
並べ替え	Unblocked と Waiting for review は Priority、次に Unblocks、次に更新の新しさで並べ、件数行にその旨を記載します（· highest priority first。Priority 列を省略する場合は · highest leverage first）。Blocked issues は更新の新しさで並べ、Priority は表示しますが、Unblocks は表示しません。Last active は並べ替え基準ではなく列です（4h、2d、3w）。	次に着手する行は先頭にあるべきで、並べ替え基準が明示されていれば列と照合できます。ブロックされた行には着手できないため、レバレッジを示す場所はありませんが、優先度を見ればブロッカーへの対応を追求する価値がわかります。
列の順序	並べ替えキーは、Issue の表では ID の後に、PR の表では Closes の後に配置します。コンテキスト列は、利用頻度の高い順に続けます。	PR | Closes の組み合わせで、PR の行が理解しやすくなります。
Closes セル	PR が何もクローズしない場合は、空欄にせず none と表示します。スタックのレイヤーについては、スクレイピングしたリンクを #12 (stacked) と表示します。	none はマージ後も Issue がオープンのままであることを示します。空欄では「未確認」と受け取られます。
Next move セル	yours、theirs: @name、または nobody reviewing → yours とします。	レビュアーの名前を示すことで、その申告を確認できます。
省略ルール	すべての行で担当者が同じ場合は Author を省略し（件数行に all yours と記載）、すべての値が0の場合は Unblocks を省略し、値を持つ行がない場合は Priority を省略します。それでも表が収まらない場合は、Title を先頭の語句までに短縮します。並べ替えキーは省略しません。	値に変化がない列は、確認済みの事実のように見えます。列の省略により、9列のPR表を1画面に収められます。
移動行	次点候補ごとに1行とし、Issue または PR を1つだけ明示します。スナップショットのチェックボックスと同じ区分にします。	表示された一覧とファイルの内容が、項目ごとに一致します。

5. ステータススナップショットを書く。提案するのではなく、デフォルトで書く

毎回、ファイルを書き込みます。 ターミナルのダッシュボードは流れて消え、順位付けされたアクション項目にチェックを付けることもできません。同じ内容をディスクに保存すれば読みやすく、実行時のToDoリストとしても使えます。ですから、許可を求めず、書き込んだあとに保存先を1行で伝えます。

docs/status/NNNN-status-<repo-slug>-YYYY-MM-DD.md に保存しました · 作業用ファイルです。gitignore 対象で、コミットされていません。

書き込みルールによって .gitignore の行が追加されなかった場合は、gitignored の代わりに untracked と記します。

依頼された場合に限りスキップします。 「表示するだけ」「ファイルはいらない」「何も書き込まないで」「画面上だけ」「/statuskit --no-file」は、いずれもその実行では指示に従い、ダッシュボードだけを表示するという意味です。スキップはその実行に限ります。ユーザーがそう伝えた場合や、リポジトリのエージェントガイドファイル（CLAUDE.md または同等のファイル）に記載されている場合を除き、継続的な設定にはなりません。書き込み可能なファイルシステムがない場合（下記参照）も、何も言わずにスキップします。

保存先。 docs/status/NNNN-status-<repo-slug>-YYYY-MM-DD.md に、次のシリアル番号、短い小文字のケバブケースのスラッグ（通常はリポジトリ名。スナップショットがプロジェクトの一部を対象とする場合は、ブランチ名やイシュー名など、より限定的なものを使用）、ISO 形式の作成日を使います。シリアル番号 NNNN を取得するには、このワークツリー、git worktree list に表示されるすべての他のワークツリー、および origin/HEAD（git fetch origin の後に git ls-tree --name-only origin/HEAD docs/status/）を対象に、docs/status/ にある先頭4桁のシリアル番号の最大値を調べて1を加えます。該当するものがなければ 0001 から始めます。並行するワークツリーで同じシリアル番号を使わないよう、3つすべてを調べます。リモートがない場合など、取得できないソースはスキップします。git がない場合はディレクトリだけを一覧表示します。シリアル番号はディレクトリごとに管理し、再利用しません。docs/status/ が存在しない場合は作成します。

1日につき1ファイル。必ず更新し、新規追加はしません。 書き込む前に docs/status/ を一覧表示し、今日の日付のスナップショットがすでにあるか確認します。ある場合はそのファイルを更新し、この実行で別のスラッグを選ぶはずだったとしても、既存の名前を維持します。今日の日付のファイルがディレクトリ内にない場合に限り、新しいファイルを作成します。ステータスファイルはある時点の状況を示すものであり、午後だけで3つも作れば、作業用ディレクトリが考古学の対象になってしまいます。さらに悪いことに、ユーザーがチェックした項目が、どれも最新に見える複数のファイルに分散してしまいます。モノレポ内の別のプロジェクトを今日のスナップショットが本当に対象としている場合は、そのプロジェクトに固有のスラッグを付け、スラッグと日付の組み合わせで照合します。同じプロジェクトに同じ日に2つのファイルを作ることはないため、連番の接尾辞で代用することは決してありません。

更新は上書きではなく、マージです。 ファイルの記載内容を信用せず、git と GitHub から調査全体を再度行ったうえで、引き続き未完了の各アクション項目について、キー（下記参照）のみを照合し、チェック済みの状態を引き継ぎます。それ以外の文言はすべて、新しい調査内容で書き換えます。文言がまったく変わったアクション項目も、キーが一致すれば同じ項目です。逆に、文言が偶然同じでもキーが一致しなければ別の項目です。チェック済みで、現在は該当しなくなった項目は Done today に移します。未チェックで、現在は該当しなくなった項目は削除します。

記載内容。 印刷するダッシュボードに、ファイルならではの次の2項目を加えます。

• スナップショットを取得した日時、対象コミット、および当日の書き換え回数を記録する出典行（Snapshot: 2026-07-23 14:20 · <branch> @ <short-sha> · run 3 today (first 09:05)）。これがないと古いファイルが最新のように見え、書き換え回数がないと午後の更新と午前に作成した元のファイルを区別できないためです。
• ファイルをToDoリストとして使えるよう、順位付けしたアクション項目をチェックボックスリストにします。最優先の項目を先頭にし、それぞれに使用するツール一式またはコマンドを記載します。

## Next moves

- [ ] **<the #1 move> (critical, unblocks 3)** · `<kit / command>` 
- [ ] <runner-up> (high, unblocks 1) · `<kit / command>` 
- [ ] <runner-up> · `<kit / command>` 

## Done today

- [x] <move, as it read when it was ticked> 

## Surfaced, not queued

- #34 approved + CI-green · merge when you're ready (`mergekit close 34`)
- #29 awaiting @someone's review

すべてのアクションにはキーがあります。 末尾の `` コメントがマージ時の照合に使われます。これは、表示されるテキストでは照合できないためです。文言は実行のたびに再生成されるため、調査後も残ったアクションは別の表現で戻ってきて、チェックがひそかに失われます。課題番号や PR 番号があるアクションは簡単なほうです。一方、「ラベルを用意する」や「バックログに登録する」のように番号のないアクションは、テキスト照合が失敗するまさにそのケースであり、ユーザーのチェックを維持する必要性が最も高いものです。キーは、人が読むファイルに記載されていて、ファイルの外では意味をなさないため、表示時には見えません。

固定の語彙からキーを選び、場当たり的なスラッグを作らないでください。そうしないと、本文と同じようにキーも実行のたびに変わってしまいます。

アクションの対象	キー
課題	issue-12
PR	pr-34
計画ドキュメント	plan-<slug>、計画独自のスラッグ
計画の1フェーズ	plan-<slug>-phase-<n>
ローカルブランチ	branch-issue-12-retry-budget
stash エントリ	stash-<sha>、git stash list --format='%h' で取得する stash コミットの短い SHA。stash@{0} のようなインデックスは新しい stash を追加するたびに変わります
対象のない段階的な優先度の段	段ごとに固定のスラッグを1つ使用します：push、reconcile、triage、prioritize、repo-labels、declare-tracker

作業を解放するアクションにはそれを明記し、誰かが順位づけしたアクションでは順位を先に示します。 キューに入ったアクションの優先度が medium より高い場合、または unblocks の数が0より大きい場合は、両方をその行に記載します：**Start #12 (critical, unblocks 3)** · \issuekit start 12`。ユーザーが実際に選ぶのはチェックボックスのリストで、多くの場合、表が画面からスクロールして消えた何時間も後です。この2つの句こそが、この項目を次の項目より優先する理由のすべてです。意味のない句は省略してください。unblocks 0 や medium、空欄は記載しません。デフォルトと記載がない状態は、どちらも読者がすでに想定しているからです。両方ある場合は、並び順に合わせて優先度を先にします。

キーをファイルの外に持ち出してはいけません。コミットメッセージやブランチ名、課題の本文など、どこにも記載しないでください。このキーは、gitignore 対象の一時ファイルの2つのバージョンを結びつけるものです。永続的な履歴に出力すると、一時的なファイルを永続的な成果物が参照することになります。Git に記録すべき関連付けはすでに存在します。PR の Closes #12 です。これは調査でも読み取られます。

すべてのアクションには、完了を示すシグナルが必要です。 キューに入ったアクションは、次回の調査で完了を確認できます。たとえば、PR がマージされた、課題がクローズされた、ラベルが作成された、作業ツリーがクリーンになった、といった状態です。完了はそのように検出するもので、チェックによって判断するものではありません。チェックは人が日中に付ける注記にすぎないため、マージ時に保持する必要があり、完了の証拠には決してなりません。「このリポジトリは独自のワークフローをドッグフーディングするか決める」のように、観測可能なシグナルのないアクションは、自動的に消えることがありません。そのため毎回永遠に再ランク付けされ、今日のファイルが墓場行きになるチェックだけが、それを黙らせる唯一の手段になります。こうした項目は次のアクションではなく、決定事項です。plankit に回すか、issuekit create で登録し、作成された課題がここに表示されるようにしてください。アクションが消える条件を挙げられないなら、リストに含めるべきではありません。

チェック済みのアクションは、ごみ箱ではなく Done today に移します。 新しい調査で、ユーザーがチェックしたアクションが該当しなくなった場合、それはそのアクションの完了を意味します。古くなった段階的なリストと一緒に削除するのではなく、## Done today の下に記録してください。1日につき1ファイルにする価値があるのは、その日に完了した内容が蓄積される場合だけです。残っている内容だけが表示されたファイルは、午後6時でも午前9時と同じように見えます。ステータスファイルにその印象を与えてはいけません。その日に完了したことが何もなければ、このセクションは丸ごと省略してください。 チェックボックス1つにつきタスクは1つです。まとめないでください。 各項目は、ユーザーが単独で完了してチェックを付けられる作業1つだけにし、必ず1つの issue または PR を指定します。「issuekit start で #12、#19、#23 に着手する」は3項目であり、1項目ではありません。「ラベルのない4件の issue をトリアージする」も同様です。ラダーのある段階が複数の issue に当てはまる場合は、issue ごとに1項目に分け、それぞれに該当する issue の番号、タイトル、コマンドを記載し、段階内の順序を維持してください。スナップショットをチェックボックスリストにする理由は、作業が途中の項目は見えないからです。3件の issue をまとめたボックスは、3件すべてが完了するまでチェックできず、それまでは何も進んでいないのと同じように見えます。同じルールは Surfaced, not queued リストにも適用されます。PR ごとに1行とし、要約行にはしないでください。分割によってリストが長くなるなら、それが作業の実際の長さです。項目を再びまとめるのではなく、テーブルと同じように、最終更新日時の新しい順に並べて上限を設け、その後に +N more の行を追加してください。

3つのテーブル（ブロックされていない issue、レビュー待ち、ブロックされている issue）は、表示されたとおりの内容で、記載順にファイルへ含めてください。これらはスナップショットが作業リストへと変わる部分です。件数しか残さないファイルでは、置き換え前のターミナルよりも明らかに不便になります。ファイル自体に必要な追加情報を除き、ダッシュボードにない情報を加えてレポートに膨らませないでください。同じ調査結果、同じクローズ済みパネルのセット、永続的な形式を維持してください。

使い捨てです。 このファイルは一時的な作業用であり、追跡対象の成果物ではないため、コミットしないでください。ユーザーから明示的に依頼された場合に限りコミットしてください。その判断はユーザーに委ね、異議を唱えずに従ってください。

書き込みルール

statuskit が書き込むのはローカルファイルのみで、書き込み対象の全一覧がこの表です。ここに記載された操作で、リモート、ブランチ、トラッカーに変更が反映されることはありません。

書き込み対象	条件	必要条件
スナップショット、docs/status/NNNN-status-<slug>-YYYY-MM-DD.md（Write）	ユーザーからスキップの依頼があった場合、または書き込み可能なファイルシステムがない場合を除き、毎回作成します。docs/status/ がない場合は作成します。	なし。保存完了のメッセージに保存先を記載してください。
ルートの .gitignore に docs/status/ の行を1行追加（Edit）	最初のスナップショットの前に限ります。ルートに .gitignore があり、git check-ignore -q docs/status/x.md が失敗する場合にのみ追加します。ルートに .gitignore がなければ作成しません。スナップショットは未追跡のままになります。	なし。保存完了のメッセージにその旨を記載してください。
既存のエージェントガイドファイルに宣言文を1文追加（Edit）	宣言の提案から行う場合に限ります。不明な読み取り結果が空の配列の場合に限ります。	プレビューとユーザーの承認が必要です。

ファイルシステムがない場合は？ スナップショットをコードブロックで出力し、正式な docs/status/NNNN-status-<repo-slug>-YYYY-MM-DD.md のパスを示してください。ユーザーのスナップショットを一覧表示できない場合は、0001 を使用して、ユーザー自身で保存できるようにしてください。

注意事項

• 外部に見える状態は一切変更しません。 statuskit は状況を調査して助言しますが、git や GitHub の状態には手を加えません。推奨事項の実行にその種の変更が必要な場合は、それを担当するキットへ案内し、そのキットが独自にプレビューを表示して承認を得ます。書き込みルール には、statuskit が書き込むすべてのファイルを記載しています。毎回の実行時に作成するスナップショット、最初のスナップショットの前に追加する .gitignore の1行、承認時にのみ追加する宣言文です。いずれもリモート、ブランチ、トラッカーには到達しません。この性質により、statuskit はいつでも安全に実行できます。この境界は「変更ゼロ」ではなく、このように表現してください。スナップショットは常に書き込みだったため、スキルの内容と矛盾する見出しは、より限定的でも実態に合った見出しより悪いからです。
• 起動するのではなく、案内します。 案内とは、キット名と1行のコマンドを示すことです。statuskit がキットを代わりに呼び出すことはなく、起動するのはユーザーです。「issuekit sync を実行してください」と案内したあとに自分でキットを呼び出すと、「状況を把握したい」という依頼への対応と同時に変更を再開することになり、読み取り専用の方針に反します。
• 必須にはせず、案内します。 推奨事項はどれも、担当キットがインストールされていない場合、通常のコマンドだけで実行できます。git しかないリポジトリでも statuskit は役立ちます。
• issuekit の領分を守ります。 issue の件数、ブロックされていない ID の一覧、各 issue が何を待っていると示しているかを含むブロック中の一覧、対応可能／進行中の一覧、各 issue に宣言された優先度を表示し、「reconcile」の順位付けに使う鮮度の真偽値を1つ算出します。ID の一覧表示は領分を越えるものではありません。同じ読み取り結果を役立つ形で表示するだけであり、最優先の対応に着手する前に gh をもう一度実行する手間も省けます。issuekit の領分として残すのは、トラッカーに関する判断です。項目ごとの健全性評価を表示してはいけません。どの issue がなぜ古くなっているのかを説明し始めた時点で、それは issuekit の triage／sync の仕事です。statuskit はそれを行うのではなく、案内すべきです。
• statuskit は優先度を読み取りますが、割り当てはしません。 issue に付いているラベルを表示するのは他の事実と同様の読み取りであり、そのラベルに基づいて並べ替えるのはラベルの目的です。優先順位の付いていない issue の優先度を推測するのは別です。それは issuekit の triage が担うトラッカー上の判断であり、この状況調査が、報告していると主張するシグナルそのものをひそかに作り出しかねない唯一の場面です。評価されていない issue はダッシュボードでも未評価のままにし、low より下に並べ、推測するのではなく担当先へ案内します。
• git の事実は gitkit が管理します。 ベースブランチ、ブランチ名の規約、ワークツリーの場所はすべて gitkit が提供し、statuskit はそれらを読み取って報告します。ここにそのどれかを重複して保持すると、ダッシュボードが実態と合わなくなったリポジトリを、自信ありげに説明し始めることになります。
• Edit を使うのは2つの追記だけで、それ以外には使いません：.gitignore の docs/status/ 行と、エージェントガイドファイルの宣言文です。スナップショットには Write を使います。このフィールドを強制するホストでツールを削除しても、どちらも単独で問題なく動作します。スナップショットは未追跡のままになり、宣言の提案 はユーザーが配置するための行を出力します。
• Skill をツール一覧に含めるのは gitkit 用だけで、それ以外には使いません。 上記の「起動するのではなく、案内する」というルールを踏まえると削除できそうに見えるため、明記しておきます。statuskit はベース参照、ブランチ名のパターン、ワークツリーのパスを取得するため、状況調査中に gitkit を呼び出します。対応手順に記載するその他のキットは、すべて案内するだけで、呼び出すことはありません。このツールを削除すると、調査はベースブランチを main だと暗黙に推測し始めます。
• 必要に応じて実行し、状態は保持しません。 実行のたびに新たに読み取ります。statuskit はリポジトリのルートに STATUS.md を保持せず、前回実行時のキャッシュも持たず、状況調査を省略するためにスナップショットを読み返すこともありません。既存ファイルから取得するのは、すでにチェック済みの項目だけです。状況調査そのものは、毎回 git と GitHub から再導出します。docs/status/ のファイルは、人間（または次のエージェント）向けの出力であり、statuskit が信頼する記憶ではありません。