chips

チップ

チップとは、プロジェクトで推奨されるタスク、実行の対象外のサイド作業、または実行の1時間という予算に収まらない計測作業で、オーナーが新しいセッションで開始できます。プロジェクトごとに1つの台帳の行として記録され、提案ツール内のカードはその行を表示したものにすぎません。ルールは .agents/pstack/rules/chips.md で、sync-pstack がこれをすべてのプロジェクトに反映します。このセッションで台帳に初めて書き込む前に、必ず全文を読んでください。ただし、カードから開始したセッションでは、そのタスクの行に必要な情報はカードのブリーフに記載されています。このスキルは各モードを実行するもので、独自のルールを追加することはありません。

以下の各コマンドは node .agents/pstack/decisions-check.mjs <command> です。プロジェクトのチェックアウトから実行してください。カードのセッションが専用のワークツリーで開始されている場合は、ブリーフに出力されたパスがその場所を示します。このセッションの ID は、ランタイムのセッションツール（Claude Code デスクトップの get_session に self を指定する場合など）から取得し、すべてのボード読み取りに --session <id> を渡してください。セッションツールがないランタイムでは、これを付けずにボードを読み取ります。

モード	用途
一括確認、引数なしの /chips、/chips all、または /chips codex	このセッションで未完了のタスクを最新の状態にし、開始できるタスクをカードにしてボードを報告します。all は、稼働中のセッションに割り当てられていないタスクも対象とし、codex は提示する各カードで Codex への引き継ぎを強制します
提案	調査結果を追加します。新しい作業を台帳に登録する唯一の方法です
開始	カードで開かれたタスクを、そのカードのセッションで開始します
破棄	タスクを破棄するというオーナーの意向を記録します

pstack もこれらのモードを呼び出します。pstack のステップで追跡対象の issue、フォローアップ、または振り返り用の Backlog 項目を登録する場合や、範囲外の修正を独立した PR として提出する場合は、リードが代わりに Offer を実行します。引き継ぎのたび、コンパクションのたび、そして終了時に、リードは簡易的な一括確認を実行します。これはステップ 3 を省略します。「次は何？」のように、サイド作業の未完了チップについて尋ねられた場合は、ステップ 1 のクリーンアップを行わずにステップ 1 と 6 を実行し、何も書き込みません。

一括確認

1. chips --session <id> と chips stale を実行します。stale レポートには、未完了タスクごとに、経過期間、提案後に削除された、または存在しなくなった書き込み対象のパス、その提案以降に対象パスで行われたコミット、クローズ済み PR による待機状況、カードが表示されます。古い可能性が最も高いものから並びます。 その後、chips.md の Cleanup に従って、完了したタスクのカードセッションをクリーンアップします。アーカイブ済みのセッションも含むすべてのセッションをセッションツールで一覧表示し、Claude Code デスクトップの list_sessions で include_archived を指定し、セッション数を超える limit を設定するなどして、その一覧を実行ディレクトリに JSON 配列として保存します。その後、chips cleanup --sessions <file> --session <id> を実行します。Archive の下に一覧表示された各セッションをセッションツールでアーカイブし、一覧をもう一度保存して、chips cleanup を再実行し、表示された scan.mjs --remove コマンドを実行します。ステップ 6 用に、最初の実行の Report 行を保持します。chips.md の Owner に従い、/chips all で、最後に保存した一覧を使って chips all --session <id> --sessions <file> を実行し、ボードをもう一度読み込みます。以降はそのボードを使用します。セッションツールのないランタイムでは、この手順を省略します。
2. Do リストに示されたパスと、chips.md の Sweep に記載された今回の実行分の行をまとめて、1 回の append --from <file> バッチで適用します。
   • Withdrawal パス：指定された各カードで dismiss ツールを呼び出し、各項目の指示に従ってツールのレポートで決まった行を記録します。
   • Ledger パス：指定された各行を記録します。
   • Card パス：ステップ 5 で処理します。
   • 確認項目：セッションツールで各セッションを検索します。ツールがそのセッションをアーカイブ済みまたは存在しないと報告した場合は、カード項目の card: を指定して uncarded を記録します。開始済みタスクの行にセッションが指定されていない場合は、項目の指示に従ってセッションを見つけ、session: を指定して started を記録します。ツールが開始済みタスクのセッションをアーカイブ済みと報告した場合は、ツールで最後のレポートを読み、コミットに変更が含まれている場合、またはレポートにセッションが変更を反映したと記載されている場合は landed を記録し、レポートに指定があれば patch: を付けます。レポートでパッチが返されているものの適用されていない場合は、chips.md の Landing に従ってパッチを反映し、patch: を指定して landed を記録します。レポートでパッチが返されず、このチェックアウトにもセッション独自のワークツリーにも、タスクのパスに未コミットの編集がない場合に限り、dismissed stopped を記録します。それ以外の場合、またはツールでセッションが見つからない場合、タスクは started のままとし、ステップ 6 にその理由を記載します。 chips --session <id> を再実行し、Do リストにカードパスまたは適用できるものが何も表示されなくなるまで繰り返します。append がバッチを拒否した場合は、そのメッセージに従って拒否された行を修正または削除し、残りを append します。
3. 古いレポートにある各タスクについて、概要、記載された事実、コードを照らし合わせて判断し、行を一括で append します：
   • ツリーにすでに修正が含まれている場合は、コミットを示して dismissed done を記録します。
   • 提示されてから対象が削除されている場合は、dismissed superseded を記録します。パスが移動しただけの場合は、新しい writes: を指定して updated を記録します。
   • 存在しないパスとは、提示された名前が間違っているパス、またはタスクが作成するパスです。git ls-files で実際のパスを見つけて、それを指定して updated を記録するか、タスクが作成するパスはそのままにします。カード化されたタスクの updated で削除できるのはパスだけなので、セッションでは started 行に実際のパスを記載します。
   • 待機中の PR がマージされずにクローズされている場合は、現在の waits を指定して updated を記録します。
   • 2 つのオープンタスクが同じ問いに答える場合は、トピックの移動を記録し、chips.md の Sweep が示す dismissed dup を記録します。優先するタスクにカードがあるか、開始済みの場合は、もう一方に waits: task:<keeper> を指定します。
   • 開始済みのタスクについては、その変更を含むコミットがある場合に landed を記録します。残りはステップ 2 のチェック項目がセッションから確定するため、そのセッションがまだ実行中かどうかを担当者に尋ねないでください。
   • レポートでタスクが薄い可能性があるとされている場合は、プラン内でその指摘を見つけ、提示されている名前を記録または実行し、folded 行として記録します。このセッションがそのタスクのカードを持っている場合は、先に取り下げます。別のセッションが持っている場合は、そのカードがキューから外れた後に指摘を折りたたみます。指摘を保持しているソースがない場合は、タスクをそのままにします。薄いままにするタスクはステップ 6 で示します。
   • カードを持ち、Ready 行に別のオープンタスクとパスを共有すると記載されている各タスクについて、依存関係をステップ 5 と同様に判断します。依存関係が必要な場合は、カード化されたタスクが取り込む、待機先と task:<その ID> を指定した updated を記録します。
   • カードを持つ各タスクについて、ステップ 5 と同様に chips.md の Title ルールに照らして工数を確認し、異なる場合は正しい effort: を指定した updated を記録します。カード化されたタスクはこれを取り込みます。
4. ステップ 3 で変更した内容について、ステップ 2 を繰り返します。
5. カードパス：各カードの前に、そのタスクが別のオープンタスクの成果を必要とするかどうかを判断します。まず Ready 行にパスを共有すると記載された各タスクを確認し、次に、その作業が前提としているオープンな設計上の問いを確認します。成果が必要な場合は、カードを出す代わりに、待機先と task:<その ID> を指定して updated を記録します。また、概要に記載された工数を chips.md の Title ルールに照らして確認し、原因とその所在が指摘に記載された (xhigh) の修正には effort: high、原因が特定されていないバグや遅延には effort: xhigh を指定して updated を記録します。その後、suggest ツールの直近の結果に保留中のカードが 20 件未満表示されている間に、同じターン内で各カードに Do リストの名前を提示します。プロンプトには chips brief <id> の出力をそのまま使い、工数には概要に記載された値を使います。その後、card: と session:、さらに /chips codex では codex: always を指定して carded を記録します。suggest ツールがないランタイムでは、chips.md の Limits に従って、プランの ## Open work にある各 Ready タスクを代わりに提示します。各カードの前に、タスクの writes: がアクティブなプランに触れるかどうか確認します。Status: が status.mjs で始まる語、たとえば building で始まるプランはアクティブです。そのプランのファイルは、プラン自体、意思決定ログ、および対象ファイル <plans>/topics/<topic>.md です。トピックは Topic: 行、または .agents/pstack.json で pageTopic.field が指定するフロントマターリストの最初の項目です。そのセッションはこれらのファイルを書き換えており、chips が認識するのは台帳のタスクだけなので、カードの代わりに、そのタスクの待機先と run:<そのプラン> を指定した updated を記録します。
6. まず、クリーンアップの Report 行、Sweep がクリーンアップした各タスクとそのコミットへのリンク、scan.mjs --remove が残した各 worktree とその理由を報告します。次に、この Sweep が記録した各行を平易な言葉で 1 行ずつ報告し、続いて、開始可能なタスクとカードの有無を報告します。20 件のカード制限によりカード化されなかった各 Ready タスクの横には start <id> を記載します。開始済みのタスク、オープンのままである理由、およびそのタスクを閉じる drop <id> も報告します。何を待っているか、その待機先ごとにまとめて報告し、レビューが必要な迅速な作業も報告します。タスクが、担当者がまだコミットしていない完了済み作業を待っている場合は、開始可能なタスクの一覧の前に、そのコミットを促す報告をします。該当する各完了済みタスクの名前と、そのコミットによって解放される待機中タスクの数を記載します。次の作業の波はその後に始まります。各タスクは ID とタイトルで示します。記載する各コミットは、そのコミットへの GitHub リンク https://github.com/<owner>/<repo>/commit/<sha> として記載し、owner と repository はチェックアウトの origin リモートから読み取ります。レポートで担当者に何も尋ねません。セッションのレポートまたはプランに担当者への問いがある場合は、リードが解決します。その問いを規定するルールに基づいて回答し、そのプランに決定行とセッションへのメッセージを添えた look Defaults 行として記録します。該当するルールがない場合は、リードが decide タスクとして提示します。担当者が異議を申し立てた場合は、リードがタスクを再度提示します。
7. タスクが開始済みまたはカード化されている間、またバックグラウンドコマンドの終了時にランタイムがリードを再呼び出しする場合は、chips.md の Waves に従って、バックグラウンドで chips wait --session <id> を実行します。開始済みセッションを示して終了したら、session ツールでそのセッションを調べます。カードの工数のまま、または suggest ツールが工数を取得しなかった場合に chips.md が示すあなたの工数のまま実行中であれば、chips wait が出力する、その概要の工数まで下げます。工数の引き下げが適用されるのは次のターンからなので、タスクを続けるよう指示するメッセージをキューに入れ、現在のターンを停止します。その後、この Sweep を再実行します。

提案

1. まず chips --session <id> を実行し、トピックまたはタイトルが調査結果に関連する各オープンタスクについて、chips brief <id> で概要を確認します。
2. chips.md の「Offer」に従って行を選びます。
   • 調査結果が、提案済みタスクの質問に該当し、そのタスクがカードを持っていない場合、そのタスクに folded 行を記録し、調査結果が追加する内容を記載します。
   • 開始済みタスク、またはカードを持つタスクの質問に該当する場合、そのトピックに新しいタスクを提案し、waits: task:<id> を指定します。カードが取り下げられると、chips はそのタスクをカード付きのタスクに統合します。
   • それ以外の場合は、chips id で取得した ID、簡潔な命令形のタイトル、chips.md の「Title」の規則に該当する場合のみ (xhigh)、および writes:、topic:、kind:、waits:、owns:、session: を指定して新しいタスクを提案します。session: にはこのセッションの ID を指定し、このセッションのタスクであることを示します。chips.md の「Owner」の規則に従います。waits: には、Sweep の手順 5 で確認した、このタスクが書き込むファイルを対象とする各アクティブなプランの run:<plan> を含めます。調査結果が既存の質問への回答になる場合は、ボードに記載されたトピックを再利用します。新しいトピックには、領域ではなく、1 人のオーナーの質問を指定します。
3. append <plans>/suggested-tasks.decisions.tsv chip "<id> <title>" "<finding>" "<tokens>" <result> で追記します。append が行を拒否した場合、メッセージに記載されたルートに従います。
4. 次の Sweep までカードには手を付けないでください。

開始

カードから開始したセッション、またはオーナーの「start 」でリードが開始したセッションは、何かを書き込む前に、chips.md の「Sweep」に従って次の手順を実行します。

1. chips brief <id> を実行し、カードのプロンプトではなく、その出力に基づいて作業します。
2. chips を実行します。タスクが Ready でも Started でもない場合、何を待っているのかをオーナーに伝えて終了します。
3. 追加のパスがあれば writes: に記載し、このセッションの ID がランタイムのセッションツールから取得できる場合は session: に記載して、started を記録します。その後、chips brief <id> をもう一度実行します。この行が記録されるまでにタスクが変わる可能性があるためです。セッションツールが、このセッションを概要の Effort: より上位として示す場合は、最初の返信でその旨をオーナーに伝えます。セッション自身の Effort は引き下げられないためです。
4. タスクに記載されていないパスへ書き込む前に、そのパスを含めた別の started 行を記録します。別の開始済みタスクがチェックアウトの外でそのパスを書き込んでいるために append がその行を拒否した場合、そのパスには手を加えず、オーナーに伝えます。
5. 作業が完了したら、概要の「Landing」の段落と chips.md の「Landing」に従って反映し、patch: を指定して landed を記録します。上書きせずに実行ディレクトリをチェックアウトにマージし、クリーンアップスキャンの --landed チェックが通った後、最後のコマンドとしてワークツリーを削除します。レビュータスクのセッションは、レビューした各タスクに対して、まず reviewed を記録します。

取り下げ

1. タスクが開始済みの場合は、dismissed stopped を記録します。
2. このセッションが提案したカードをタスクが持っている場合、そのカードで dismiss ツールを呼び出します。ツールがオーナーがタスクを開始したと報告した場合は、started を記録してオーナーに伝えます。それ以外の場合は、uncarded の代わりに、その card: を指定して dismissed declined を記録し、2 つの間にマージが反映されないようにします。
3. 別のセッションがカードを保持している場合は、その card: を指定して dismissed declined を記録します。
4. タスクがカードを持っていない場合は、dismissed declined を記録します。