sync-pstack

pstack を同期する

1 つのスキルで、プロジェクトに pstack をセットアップし、セットアップ済みのすべてのプロジェクトを上流の pstack および共通のオーバーライド一式と同期させます。プロジェクト固有のルールは同期されません。

セットアップでは、プラグインの固定バージョン、オーバーライドブロック、そのヘルパー、廃止されたコントローラー用に維持される型付きエントリポイント、ルーティングテーブル、検証用スキルから成る共通レイヤーを導入します。ソースの権威、ドメインの法則、レビューシーンなど、プロジェクト独自のナレッジは導入しません。これらはプロジェクト側の作業として維持され、ドメインスキルはセットアップ時に変更されずに取り込まれます。

レイヤー

レイヤー	配置場所	変更方法
上流	各プロジェクトの .claude/settings.json、ユーザーの ~/.claude/settings.json、およびユーザーの Codex マーケットプレイスで、固定タグに指定された pstack@pstack-claude プラグイン	sync --tag と user-pin。pstack 自体は編集されません。
共通	assets/block.md。各プロジェクトの AGENTS.md にある pstack:begin と pstack:end マーカーの間に反映されます。また、assets/pstack/ のヘルパーは .agents/pstack/ にコピーされ、assets/pstack/rules/ のルールファイルはブロックと同じ形式で .agents/pstack/rules/ に反映されます。	dotai チェックアウト内のこのスキルのソースを編集し、その後同期します。
プロジェクト	インタビューの回答を格納する .agents/pstack.json、ブロックに一覧表示される .agents/playbooks/ 内のプロジェクト用プレイブック、およびブロック外にあるすべてのルール。ブロック外のルールが優先されます。	手動またはセットアップを通じて、プロジェクト側で変更します。

スクリプトを実行する

任意のディレクトリから node <skill>/scripts/sync-pstack.mjs <command> を実行します。

コマンド	効果
discover <project>	インタビューに必要な情報を JSON で出力します。読み取り専用です。
status [project...]	最新の上流タグ（およびそれより先行する上流の VERSION）、ユーザーのピン留め、各プロジェクトのピン留め、差分、ベンダーコピー、最後のソースリビジョンを表示します。プロジェクトのパスを指定しない場合は、~/.agents/config.json のリポジトリセット、その親ディレクトリ、および各 --root <dir> からローカルの pstack プロジェクトを検出します。リンクされた git worktree はスキップします。各 worktree は、チェックアウトしているブランチ経由で同期されるためです。プロジェクトのパスを指定しない sync も同じセットを対象にします。読み取り専用です。
apply <project>	プロジェクトの設定に基づいて、ブロック、ヘルパー、プロジェクトのピン留めを書き込みます。--tag はまずタグをピン留めし、オーバーライドまたはプロジェクトのプレイブックが参照する各ファイルについて、2 つのタグ間の pstack の差分を表示します。また、引用されているテキストが pstack に残っていない場合は、そのタグを拒否します。--dry-run はブロックの差分を表示し、その他の書き込み対象を一覧表示します。--force は編集済みのブロックやヘルパーを上書きするか、プロジェクトの最後の同期より古いソースから再生成します。アンカーをスキップすることはありません。クローンの pstack.delivery が設定された trunk プロジェクトのメインチェックアウトへの書き込みは拒否します。そのようなプロジェクトは worktree で同期して、結果を反映します。
check <project>	apply で変更が発生する場合、終了コード 1 を返します。読み取り専用です。
verify <project>	プロジェクトの履歴で入力されたコマンドまたは引数ヒントのモードが解決できなくなった場合（dropped に記載されている場合を除く）、プロジェクトのスキルにスキルツリー内への無効なリンクがある場合、ルールに廃止済みのスキルが指定されている場合、ドキュメントでインストールを案内しているスキルがこのプロジェクトのワークフローファイルに依存している場合、check で変更が発生する場合、またはピン留めしたタグの pstack にオーバーライドやプロジェクトのプレイブックが参照するテキストがない場合、終了コード 1 を返します。読み取り専用です。スキルまたはモードが HEAD 以降に削除された場合に限り、チャット履歴を読み取ります。この処理には数分かかるため、最後の apply の後に一度だけ、出力をファイルに保存してバックグラウンドで実行してください。
sync --tag <tag> [project...]	指定したプロジェクトに対して apply --tag を実行します。プロジェクトを指定しない場合は、管理対象のすべてのプロジェクトを対象とし、管理対象外のプロジェクトを一覧表示します。プロジェクトのブランチから外れたチェックアウト、または書き込み対象ファイルに未コミットの変更があるチェックアウトは、--allow-dirty を指定しない限り拒否します。また、いずれかのプロジェクトで失敗しても処理を続けます。
playbook <project> <name>	.agents/playbooks/<name>.md が拡張するすべての pstack プレイブックについて、プロジェクトのピン留め時点の番号付き手順を、変更を順に適用して出力します。Reply 行など、手順以外のテキストは除外されます。読み取り専用です。
smoke <project> <prompt>...	プロジェクトのルートから、Opus を使う読み取り専用の Claude Code セッションと、gpt-6.1-sol を使う読み取り専用の Codex セッションで各プロンプトを並列に実行し、それぞれのランタイムの最終回答を出力します。回答で確認できるのはルーティングだけです。セットアップの手順 6 に従って評価してください。Claude Code セッションはプランモードの CLI であり、デスクトップアプリのセッションツールは使用しません。
corpus [project...]	プロジェクトにインストールされた decisions-check.mjs と、このスキルのコピー（未コミットの編集を含む）を、プロジェクトの台帳および初回コミット以降に追加された決定ログの行（--all、chips、chips stale）に対して実行し、差分を出力します。2 つの chips 実行では、同じ台帳のコピーを読み取ります。各 --all 実行では、その時点のログを読み取ります。そのため、実行間に別のセッションがログを書き込んだ可能性がある場合は、差分を信頼する前に corpus を再実行してください。プロジェクトのパスを指定しない場合は、status が検出した管理対象のすべてのプロジェクトで実行します。--session <id> はこのセッションの ID を chips に渡し、--installed <dir> は保存されたプロジェクトのヘルパーのコピーから旧側を読み取り、--out <dir> は各側の完全な出力もそこに書き込みます。読み取り専用です。
user-pin --tag <tag>	ユーザースコープの Claude Code マーケットプレイスをピン留めし、更新コマンドを出力します。Codex のコマンドは毎回出力し、Claude Code のコマンドはユーザー設定で pstack マーケットプレイスが宣言されている場合にのみ出力します。
latest	最新の上流タグを出力します。
node <skill>/scripts/audit.mjs <project> [--json] [--min <score>] は、Audit モードが判定する情報を出力します。--min では文のペアに必要な重なりスコアを設定します。デフォルトは 0.5 です。読み取り専用です。

アンカーチェックでは、初回使用時にスクリプトが ~/.cache/sync-pstack/ に作成する bare clone から pstack を読み込みます。SYNC_PSTACK_UPSTREAM を指定すると、別のクローンまたは URL を参照できます。dotai のチェックアウトが存在する場合は、origin が udecode/dotai のそのチェックアウト内でコピーを実行してください。assets/ が信頼できる唯一の情報源です。apply と sync はレンダリング元のソースを出力し、レンダリングに使った共有コミットを synced.source に記録します。この記録があると、拒否の際にプロジェクトが編集した内容を正確に示し、コピーがプロジェクトの最後の同期より古い場合は上書きを拒否します。この実行で書き込まなかった編集が含まれていても、dotai のチェックアウトから check を実行してください。dotai の AGENTS.md が、それらの編集をこの実行自体の一部としてコミットするためです。

モードを選ぶ

依頼	モード
プロジェクトで pstack をセットアップする、またはここに pstack をインストールする	Setup
ここまたはすべての場所で pstack を同期、更新、またはアップグレードする	Sync
セットアップを比較する、または pstack を使用しているプロジェクトや差分があるプロジェクトを一覧表示する	Compare、読み取り専用
プロジェクトのスキルにある pstack との差分、または削除すべきスキルを監査する	Audit、オーナーが選ぶまで読み取り専用
「今後、で<architect、panelまたはarena>を実行する」、または実行を停止する	Reviews
共有ルールを変更する教訓や修正	Lesson
プロジェクト独自のプレイブックを追加または変更する	Project playbooks

共有ソースを変更すると、管理対象のすべてのプロジェクトが同期され、新規または変更された dotai スキルがそれぞれにインストールされます。これには各プロジェクトの .claude/skills/<name> リンクも含まれます（オーナーの発言、2026-10-09）。Setup、ピンの更新、または Reviews で変更されるのは、依頼で指定されたプロジェクトだけです。ただし、すべてのプロジェクトが対象と明示された場合は、管理対象のすべてのプロジェクトが変更されます。~/.agents/config.json のリポジトリセットは候補を示すものであり、許可を与えるものではありません。

Setup

1. 検出。 discover <project> を実行し、AGENTS.md と、そこから案内されるワークフロールールをすべて読みます。この時点ではまだ何も書き込みません。
2. ヒアリング。 これはユーザーが最初に目にするステップです。ヒアリングに従います。根拠をもとに準備し、必ずデリバリーについて尋ね、プロジェクトの根拠に反する理由がない限り推奨される回答を提案し、すでに確定した回答を再度尋ねてはいけません。
3. 回答を、latest の tag とともに .agents/pstack.json に記録します。
4. adaptに従ってプロジェクトを適応させます。ベンダーとして取り込まれた pstack のコピーを削除し、孤立したスキルとルールのフォークを整理し、同期対象ファイルにフォーマッターを適用しないようにし、このブロックと重複または矛盾するプロジェクトルールを書き換え、削除したスキルへの参照を付け替え、確認済みのルーティングテーブルを書き込み、存在しない場合は proof スキルを作成し、ルールからスキルを再生成します。
5. 適用。 apply <project> --dry-run を実行して差分を読み、その後 apply <project> を実行します。
6. 検証。
   • discover でベンダーとして取り込まれたコピーがないことを確認し、status <project> でユーザーピンがタグに設定されていることを確認します。そうでない場合は user-pin とそのコマンドを実行します。
   • 各ランタイムのモデルシートが存在することを確認します。~/.claude/pstack-models.md と ~/.codex/pstack-models.md に、ブロックの Panel レビュールールが使う担当モデルが記載されている必要があります。そうでない場合は、スモークテストの前に /pstack:setup-pstack を実行します。シートのないセッションでは、pstack のデフォルトモデルが使われるためです。
   • smoke <project> "<prompt>" を使って両方のランタイムをスモークテストします。実在する機能を指定した、平易な依頼を使います。「架空のタスクです。編集や、書き込みを行うコマンドの実行はしないでください。 は の後にリセットされます。どのように進めるか、順番に10行以内の短い行で説明してください。最初に開く todo 項目、その後、完了した作業をどのように反映するかを書いてください。」各ランタイムがどのプレイブックの名前を挙げるかだけでなく、実際にどう動くかを評価します。判定者が回答を採点する際は、判定者に回答を見せる前に、変更した指示文をもとに各ランタイムが意図する動作を書き出し、その各部分を必須とする行を引用します。変更したスキルのスモークテストが合格とみなされるのは、そのスキルがセッションで読み込まれたことが示されている場合に限ります。また、読み取り専用のスモークテストで証明できるのはルーティングであり、動作そのものではありません。まず、フィクスチャがプロンプトの前提どおりの状態かを確認します。たとえば、承認済みとした計画が Done ではないことを確認します。poteto-mode の Bug fix プレイブック（およびそれを拡張するプロジェクトのプレイブック）、worktree を使わないこと、デリバリーの回答を期待します。各プロンプトの末尾で、ランタイムに気づいたルールの衝突を番号付きリストで挙げるよう求めます。回答全体を読み、番号ごとに分類を1つ記録します。今回の変更で触れるルール同士の衝突は失敗です。修正し、失敗したランタイムを再度スモークテストします。ハーネスによるアーティファクトとは、読み取り専用モードのスモークテストに固有の制限で、実際のセッションにはないものを指します。たとえば、プランモードでスクラッチファイルへの書き込みがブロックされることや、ヘッドレスセッションでは使えないコネクターなどです。該当する場合はその旨を記録し、それに依存する主張はスモークテストのハーネス上で成り立つと限定して表現します。この記録をもって対応済みとします。Claude Code のスモークテストはプランモードの CLI を使うため、「何も編集しない」という条件下でプランモードを使うことは、常にそのようなアーティファクトに当たります。また CLI には、get_session、list_events、search_session_transcripts、start_session など、デスクトップアプリのセッションツールはありません。そのいずれかを必要とするルールは、リードがデスクトップセッションで実際に1回使用して検証し、そのセッション ID とともに記録します。スモークテストでの検証は認められません。デスクトップセッションがなければ、Needs you に gap と記録します。今回の変更より前から存在するものも含め、それ以外の番号付きの衝突はすべて、次の3つのいずれかで決着させます。今回の変更で修正する、プロジェクトの Suggested tasks ルールまたはトラッカーを通じてタスクを提示する、理由を明記して却下する、のいずれかです。衝突を記録するだけでは決着しません。ランタイム間の動作の違いは、変更したルール自体がその違いを定めている場合（たとえば、下書きの送信を一方のランタイムが拒否する場合）、またはプロジェクトルールでは変えられない理由でランタイムが、変更で約束された動作を拒否する場合を除き、失敗です。その場合は、動作するランタイムに合わせてルールとコミット本文の対象を限定するか、両方のランタイムが従うフォールバックをルールに設けます。テスト対象ファイルの読み取りが拒否されたと回答された場合、そのファイルに関する手順の判定は不確定です。partial と記録します。2つ目のプロンプトでは、サブエージェントがどのモデルで実行されるかを尋ねます。プロンプトでプレイブック、停止、ステップの名前を挙げてはいけません。また、ルール内のトリガーを、そのルール自身の文言で指定してはいけません。そうすると、実行で証明できるのは検索であり、ルーティングではありません。レビューなど、新規または変更したゲートをテストするには、そのゲートが起動する程度に十分な規模の平易な依頼を送り、todo リストと、作業を差し戻す応答だけを求めます。ゲートが促されずに現れた場合に限り、スモークテストを合格とします。実行時にはプロジェクトのフックが動作するため、ファイルをステージングする Stop フックは、セットアップで変更したファイルもステージングします。
   • 変更したコードファイルに対してプロジェクトの lintFix を実行してから、最後に verify <project> を実行します。これにより、入力ミスのあるコマンド、リンク切れ、廃止された名前、依存関係のある公開スキル、同期対象ファイルへのフォーマッター適用による書き換えが、ここで見つかります。納品前に、一覧にある問題をすべて修正します。
7. 納品。 プロジェクトのデリバリー回答に従います。trunk の場合は、ヒアリングで直接プッシュするという回答が「はい」だった場合に限り、オーナーのクローンで git config pstack.delivery push を実行します。この設定はリポジトリには書き込まれず、その他すべてのクローンは PR を作成します。コミットする場合、コミット本文には、どのランタイムとプロジェクトのどのコミッターが、何を得るか、または失うかを記載します。各ランタイムの主張は、そのランタイム自身のスモークテストの回答を根拠にします。user モードの場合は、オーナーのコミットについて、その旨を応答に記載します。最後に、回答、適用した確定済みのデフォルト、削除および維持したスキル、検証結果を記載します。

Sync

1. status を実行し、管理対象プロジェクト、それぞれのピン留めタグ、差分、最後に取得したソース、最新タグを確認します。ピン留めするのは latest が表示するタグだけです。VERSION の変更がマージされても、タグがプッシュされるまではリリースではありません。また、上流の VERSION が最新タグより先行している場合は、status に表示されます。
2. 新しいタグがある場合は、ピン留めされているタグから新しいタグまでの pstack-claude の CHANGES.md を読みます（gh api 'repos/michael-denyer/pstack-claude/contents/CHANGES.md?ref=<tag>' -H 'Accept: application/vnd.github.raw'）。各変更をブロックと照合します。ここでいうブロックとは、オーバーライドが参照するプレイブックの手順、スキル、原則、またはフックです。上流がオーバーライドの内容を実行するようになった場合は、そのオーバーライドの削除を提案します。オーバーライドと矛盾する文言が変更された場合は、書き換えを提案します。次に、CHANGES.md で追加または変更された各スキル、エージェント、プレイブックの手順について、対象範囲内の各プロジェクトで導入すべきか判断します。プロジェクトのプレイブックと、ブロック以外のルールを読み、スキルの名前を git grep で検索してから、未接続と判断します。プロジェクトごとに次のいずれかの判定を付けます。「すでに接続済み」なら該当する行を明記します。「接続する」なら、追加先または置き換え先の手順やルールと、そこで埋めるギャップ（たとえば、他のゲートがレビューしないパス）を明記します。「手動のみ」なら、自動化が抵触するルールを明記します。「不要」なら、すでに同等の役割をより適切に果たしているものを明記します。スキル自体の説明ではなく、プロジェクトの既存のゲートとエスカレーションを踏まえて判断します。同期の引き継ぎにはこの表を含めます。プロジェクトのルールがプランページを経由して引き継がれる場合は、プランページに記載します。接続する提案も含め、各提案をユーザーに提示し、ユーザーの了承を得た場合にのみ適用します。ブロックの変更はLessonを通じて行い、プロジェクトのプレイブックの変更はProject playbooksを通じて行います。
3. 対象範囲内のプロジェクトを指定して sync --tag <tag> --dry-run を実行し、ブロックまたはプロジェクトのプレイブックが参照するすべてのファイルについて、出力された pstack の差分を読みます。引用されたテキストが残っていても手順が変わることがあるためです。その後、--dry-run を外して実行します。リクエストがすべての管理対象プロジェクトを対象としている場合に限り、プロジェクト一覧を省略します。一覧にある未管理プロジェクトごとに Setup を提案します。
4. 各拒否の理由を解消します。
   • ブロックまたはヘルパーの編集。 拒否メッセージにプロジェクト側の編集内容が表示されます。汎用的な編集は Lesson を通じてテンプレートに移し、プロジェクト固有の編集はブロックの外に移します。これで変更は失われないため、--force を付けて再実行します。移さない場合は、オーナーが編集を破棄してよいと言ったときに限り --force を使用します。
   • 別のブランチまたは未コミットの編集。 プロジェクトのブランチに切り替えるか、オーナーのコミットを待ちます。未コミットの編集がこの実行で加えたもの、または別のセッションによる未コミットの作業の周囲にあるこの実行の差分だけをプロジェクトのルールがコミットする場合に限り、--allow-dirty を使用します。
   • 古いソース。 dotai のチェックアウトを更新し、そこから再実行します。未コミットの編集がある場合は、Lessonのステップ 2 に従います。この実行でプロジェクトがすでに同期済みのコミットを修正またはリベースした場合は、apply --dry-run のブロック内の差分全体が、コミット済みテンプレートの行だけで構成されていることを確認してから、--force を付けて再実行します。
   • 未コミットの共有編集。 プロジェクトは、誰もコミットしていない共有編集をソースとして最後に同期されており、クリーンなソースから同期するとその編集が失われます。dotai のチェックに合格したら、dotai の AGENTS.md の指示どおりにコミットしてプッシュし、その後再実行します。オーナーが編集を破棄してよいと言った場合に限り、--force を使用します。この実行で加えた編集が、後から修正版として反映されている場合も、拒否は引き続き発生します。apply --dry-run を実行し、ブロック内の差分にコミット済みテンプレートの行だけが含まれていることを確認します。それに反する診断があれば説明し、その後 --force を付けて再実行します。
   • pstack のアンカー。 新しいタグの pstack に、ブロックまたはプロジェクトのプレイブックが依存するテキストがなくなっています。拒否メッセージには pstack の差分が表示されます。新しいテキストに合わせて、ブロックのオーバーライドは Lesson を通じて、プレイブックの変更は該当プロジェクト内で書き直してから、再実行します。上流がすでに同じ役割を果たしている場合は、その変更を削除します。
   • エラー。 テンプレートでレンダリングできない設定があります。設定を修正し、そのプロジェクトで再実行します。
5. user-pin --tag <tag> を実行し、続けて表示されたコマンドをホームディレクトリから実行します。pstack フックのファイルが変更された場合、Codex は再度そのフックを信頼するよう求めます。
6. verify で同期済みの各プロジェクトを検証し、Setup のステップ 6 と同じ基準で、使用中のデリバリーモードごとに 1 つのプロジェクトをスモークテストします。when または手順が変更された各プレイブックについて通常のプロンプトを 1 つ、各カットエントリーポイントについて 1 つ、新規または変更された各ゲートについて 1 つをテストします。固定のテストセットはありません。CHANGES.md でスキルまたは原則が追加または変更された場合は、同期済みの各プロジェクトでAuditも実行します。Audit は新しいピン留めタグの pstack を読み取ります。まず、そのスキルが対象とする役割を担う、プロジェクトおよびユーザースコープのスキルを評価します。
7. 各プロジェクトをそのブランチ上で、各プロジェクト固有のデリバリー方式に従って提供します。コミットするのは同期で書き込まれたファイルだけです。push プロジェクトでは同期内容をコミットしてプッシュします。user プロジェクトでは変更をオーナーに委ねます。pr プロジェクトでは同期内容をコミットし、PR は作成せず <branch> に直接プッシュします（オーナーの指示、2026-10-20）。trunk プロジェクトでは origin/<branch> から切り出したワークツリーで同期を実行し、land.mjs で反映します。push または pr プロジェクトをプッシュする前に、そのブランチで実行される各ワークフローの on: push フィルターを読みます。プッシュに含まれるパスが、これに一致する paths リスト、またはこれから除外されない paths-ignore リスト、あるいはフィルターがないことによってワークフローを起動する場合は、ワークフローの編集自体が CI を起動するため、そのパスで起動しないようにフィルターを変更し、ヘッドコミットのメッセージに [skip ci] を含めます。同期内容が以前の同期ブランチに積み重なっている場合は、それらの PR が GitHub 上でマージ済みと表示されるよう、リベースではなく --no-ff でプロジェクトのブランチをマージします。各コミット本文には、Setup のステップ 7 のとおり、何を得る、または失うランタイムとコミッターを記載します。

比較

status を実行します。pstack を使用している管理対象外の各プロジェクトについて、指示を読み、すべてのオーバーライドを、対象ブロックで網羅済み、プロジェクトへの適応、明示的なポリシーの違い、ドリフト、未解決のいずれかに分類します。ルールが失われたと判断するのは、ブロック外のプロジェクトの AGENTS.md とセットアップ計画の処置表を読んだうえで、表現を変えて複数の言い回しでも動作を検索した後に限ります。セットアップではルールの移動や言い換えが行われるためです。各違いについて、両方の動作、それぞれのソースパス、最小限の調整案を報告します。セットアップまたは同期を提案し、依頼がない限り何も適用しません。

監査

スキルが、pstack またはブロックですでに管理されている規則を複製したり、pstack が現在担っている作業を引き続き担ったりすると、pstack からドリフトします。このモードでは、オーナーが削除できるよう、そのドリフトを見つけます。

1. dotai チェックアウトがある場合はそこから、node <skill>/scripts/audit.mjs <project> を実行します。次の項目が出力されます。
   • プロジェクトスコープおよびユーザースコープの各スキルについて、そのソース、入力数、流入経路、古くなったインストール済みコピー。
   • overrides の注記も adds マーカーもないブロックのルール。
   • pstack、ブロック、またはプロジェクト内の別ファイルと内容が重複する文。 入力数に含まれるのは、人が書いたものだけです。エージェント、タスク通知、ヘッドレスの記録、および貼り付けたブロックは除外されます。また、2,000 文字を超えるリクエストでは、先頭 200 文字より後にある一致も無視されます。ユーザースコープのスキルの入力数は、すべてのプロジェクトのセッションを対象にします。
2. 監査レポートを、意図と削除・統合・維持の評価基準を示す監査ブリーフに照らして判断します。ブロックのパネルレビュー規則で確認を求めずに実行できる場合、またはオーナーが「panel」と指示した場合に限り、/pstack:interrogate を実行します。それ以外の場合はリードが判断し、判定表でリードを判定者として明記します。各スキルには、1 つの判定を割り当てます。pstack またはブロックがすでにその役割を果たしている場合、あるいは利用されていない場合は「削除」、その領域の知識は残すものの手順の記述を削除する場合は「統合」、pstack では保持できない領域知識を含む場合は「維持」です。削除するものには、代わりに何がその役割を担うかを必ず記載します。
3. AskUserQuestion を使って判定表をオーナーに提示します。削除案はプロジェクトごとにまとめ、推奨案を先に示します。各削除案には、全履歴の入力数と、このセットアップで機能することを確認した代替策を記載します。ファイルを削除する案では、規則、教訓、数値、根拠をそれぞれ別に数え、各項目について、すでに別の場所にある数、引き続き保存先が必要な数、削除される数を示します。削除したファイルを読むワークフローはないため、git 履歴を安全策として提示することはありません。「一度も入力されていない」など、案に事実に関する主張を含める場合は、その根拠となる確認方法を明記します。ゲートを移動または削除する案では、ラベルに該当するゲートを記載します。入力済みコマンドのエントリポイントが失われるのは、オーナーがその削除案を選んだ場合に限ります。また、その削除案では、プロジェクトの設定の dropped に当該コマンドを記載します。
4. 選択された内容を、ブロックの Plans and trails および Panel review の規則に従い、計画として実行します。削除案が依拠する利用数は、実際に削除する直前に再確認します。計画の実行中も、並行するセッションが対象を使い続けるためです。削除、統合、再構築の前に、旧テキスト内の各ルール、確認項目、今も有効な教訓をすべて列挙し、それぞれの新しい保存先を引用するか、記録された削除として示します。adapt の処置表に従ってください。最初に移行先を編集する前に、各行のソース引用と条件を確定します。移行先を編集していないレビュー担当者が、保存先がすでに存在していた各行、編集後に引用が変わった各行、スクリプトで生成された各行を確認します。表は計画とともにコミットします。プロジェクトの AGENTS.md が名前を挙げている各ワークフローガイドには、Lesson のステップ 1 に従って、更新用のゲートを設けます。dotai のスキルを削除した後は、管理対象のすべてのプロジェクトでそのパスを検索し、削除を完了する前に各プロジェクトのドキュメントチェックを実行します。ユーザースコープのスキルはホームディレクトリから npx --yes skills remove <names> -g -y を実行してアンインストールし、プロジェクトスキルはプロジェクト内で npx --yes skills remove <names> -y を実行してアンインストールします。

レビュー

各プロジェクトの.agents/pstack.jsonにあるレビューリストには、パネル、architect、またはアリーナを実行する作業が記載されています。すでにそれを要求する各pstackステップで、毎回確認せずに実行するものです。ユーザーの「panel」「arena」または「full」は、それ以外の場所で実行するものです。

1. ツールのスキルをすべて読み、次に、Featureのarchitect向けデザインステップなど、プロジェクトの固定バージョンでそのツールをデフォルトで呼び出すpstackプレイブックのステップとスキルをすべて列挙します。ビルド前に、呼び出し箇所ごとに計画の「Defaults」に行を設け、そこで何が起きるかと、それを取り消すキーワードを記載します。
2. ユーザーの文を、対象となるプロジェクトごとに1行にします。kebab-caseのidと、作業、ツール、ステージを明記した1文のruleを記載します。例：{ "id": "api-design", "rule": "A best-api design gets architect before its target is picked." }。すでにその作業を対象とする行がある場合は、追加せずにその行を書き換え、ユーザーが取り下げる行は削除します。
3. プロジェクトのプレイブックがその作業でツールを実行する場合は、その箇所で(reviews: <id>)として行を参照し、どの行にも該当しないプレイブックのステップからはツールを外します。
4. applyを実行してからverifyを実行します。verifyは、有効な参照がその行にないのにpstack:interrogate、pstack:arena、pstack:architectを記載しているプレイブックの行と、bigWork、risk、reviewPrを設定したままの構成を検出します。
5. 対象の行に該当する通常のリクエストを1つ、該当しない、プロジェクトで最も一般的な作業からのリクエストを1つ使ってスモークテストします。判定は「Setup」のステップ6に従います。対象外のリクエストが結局対象の行に該当する場合、その行がユーザーの依頼よりも広い作業を対象としているため、そのことをユーザーに伝えます。その後、各プロジェクトの回答形式に従って引き渡します。

教訓

/pstack:reflectから得た教訓、または1つのプロジェクトでの修正が共有レイヤーを変えるのは、すべてのプロジェクトに当てはまる場合に限ります。1つのプロジェクトに関する教訓は、そのプロジェクトのブロックの外に記載します。計画ページの形式を変更する場合は、これらのステップを実行し、「plan-page」スキルの「Change」モードでは、ステップ2、3、4にレンダラー固有の詳細を追加します。1つのプロジェクトだけが記述するセクションは、レンダラーではなく、そのプロジェクトのプレイブックのフロントマターに記載します。

1. ユーザーの依頼を一言一句そのまま引用した To-do リストを開き、最後の動作編集の後に、次のゲートをこの順で並べます。ヘルパーに対する deslop と no-comments、ブロックとスキルの文章に対する unslop、テストと corpus、ヘルパーパネル、未コミットの dotai ツリーからレンダリングした最終ブロックに対するプッシュ前レンダリングとスモーク一式。試行実行の前に、反転させた教訓ごとに名前付きプロンプトを1つずつ、Setup のステップ 6 で説明されている意図された動作のファイルに書き込みます。dotai のプッシュ、apply、verify、そして実施する場合は意思決定トレイルのレビューです。証拠とみなすものを再定義するルール変更では、そのルールが判断する意思決定のプロンプトを追加します。たとえば、結果を書き込む経路を試すプロンプトだけでなく、カットのルールならカットを対象とするプロンプトも追加します。この実行で、スモーク後にそのプロジェクトのスモークが読み取った指示ファイル（ブロック、プロジェクトルール、プレイブック、ワークフローガイドを含みます）を編集した場合、そのプロジェクトの一式を再実行し、プロジェクトの納品前に再実行を完了します。また、Close にはトレイルレビューの対象となったコミットを記載します。プロジェクトの AGENTS.md が指定する各ワークフローガイドには、更新ゲートを設けます。ユーザーに設計を言い返す場合、各状態またはトリガーにはユーザー自身の言葉を使います。オーナーが維持するよう指示したルールにも同じ扱いを適用します。リードはオーナーのトリガーとルールのトリガーを比較してから、そのルールと、該当する箇所でエージェントが読み込むすべての複製を書き換え、オーナーの適用範囲に合わせます。ゲートを変更する計画では、その計画を開始した時点で有効なゲートに従います。推奨事項とデフォルトは現行ルールを適用し、現行ルールが要求するゲートを省略する選択肢には、その旨を明記します。
2. 最初の編集の前と、ステップ 5 のスモークの前に、dotai のチェックアウトを取得して早送りし、dotai の AGENTS.md の指示どおり、その場で編集します。他のセッションにはブロックの Other sessions ルールを適用します。このルールは他のセッションを前提に計画せず、競合が作業を妨げる場合に限って対処します。この実行の未コミット編集が早送りを妨げる場合は、コミットされるまで早送りをスキップします。その後プッシュが拒否された場合は、git pull --rebase で取り込まれた変更にリベースし、この実行自身のハンクにある競合を解決してから、チェックを再実行し、再度プッシュします。同期したプロジェクトに取り込まれる各上流コミットの名前を記載します。リードは、この実行で書き込んでいない編集を決して復元しません。dotai のチェックが通った場合、dotai の AGENTS.md の指示どおり、他のセッションの dotai 編集やローカルコミットを自身の後にコミットしてプッシュします。その編集は、ステップ 5 の指示どおり、独立したコミットにします。生成された workflow-manifest.json の競合は、git checkout HEAD -- workflow-manifest.json と node scripts/build-workflow.mjs で解決します。作業ツリーのコピーが置き換えられたファイルに対しては、git apply -3 の前に HEAD をチェックアウトします。そうしないと apply -3 は拒否されます。
3. dotai のチェックアウトにある assets/block.md またはヘルパーを編集します。プロジェクト名、パス、コマンドは含めません。プロジェクトごとに異なる値は、設定フィールドとプレースホルダーにします。新しい必須フィールドがあると、インタビューで追加されるまで、そのフィールドのないすべての設定でレンダリングが失敗するため、`` の内部で使う任意フィールドを優先します。ヘルパーが何かを拒否すると記述するブロックの文章には、ヘルパーが確認する正確な述語と、スキップする内容を明記します。自由形式のコンテンツから遷移を推測する拒否ルールは、実装前に少なくとも2つの述語設計を比較します。そのラウンドの修正で、その述語に関する新たなクリティカルが出た場合、次の修正では推測を明示的な入力に置き換えます。たとえば、遷移が書き込むマーカーや記録済みのベースコミットなどです。古い設定形式を拒否し始めるヘルパーには、移行の前提条件を確認したうえで、同じ apply 書き込みに移行処理を含めます。オーナーが反復して改善すると述べた共有ルールは独立したスキルに移し、ブロックには権限ルールとそのスキルへのポインターだけを残します。ルールを廃止または縮小する変更、あるいは例外を追加する変更では、最初のスモーク前に adapt の廃止ポリシー検索を実行し、該当箇所をすべて修正します。上限や境界を追加する変更では、再実行、再度、〜まで、などのループを再開する指示がないか、すべてのセクションを検索し、それぞれに上限を設けます。共有ルールを編集する前に、変更対象の節に対して git log -S '<clause>' -- assets/block.md を実行します。その節が教訓によって追加された場合は、その教訓を覆す編集として記録します。反転の記録行には、新しい文章に対してその教訓のケースをスモークする、ステップ 1 のプロンプトを記載します。ブロックのルールが pstack のステップを抑制し始める場合は、Template grammar に従い、ステップごとに # overrides の注記を1つ追加します。
4. 管理対象の各プロジェクトで apply <project> --dry-run を使ってプレビューします。ヘルパーまたはチェックの変更では、管理対象の各プロジェクトで、その変更が判定するすべての成果物に対して旧版と新版を実行し、失敗内容を比較します。台帳ヘルパーの場合は corpus --session <id> --out <run directory> を実行し、レンダラーの場合はレンダリングされた本文も比較します。ランタイムのセッションツールがセッション ID を提供する場合は、このセッションの ID を渡します。chips はその ID がないと開始セッションのチェックを出力しないためです。比較で追加または削除された各行を、その行に対処するスキルまたはルールのステップ（たとえば、合格ヘッダーの下にある Do リストの行を処理するステップ）と照らして読みます。件数の変化だけでは何も証明されません。dotai のコミット前に、リードは管理対象プロジェクトごとに、実際にレンダリングされたページの変更箇所も開いて確認します。終了ステータスや表示されたパスだけでは内容が分からないためです。実際の成果物を指摘する指摘事項は、フィクスチャだけではなく、その成果物を確認して初めて解消します。作業の発端となった実際の成果物は、必ず拒否すべきケースとして維持し、修正ラウンドごとに再実行します。新規または範囲を拡張したチェックが判定するのは未解決の成果物だけとし、ニアミスには、そのチェックが果たしうる各役割について解決済みの成果物を1つずつ含めます。また、解決済みの成果物が参照するファイルの名前変更または削除も含めます。チェックは、ゲートの対象となる状態まで入力した各テンプレートに対して実行し、合格できるようにします。拒否する述語ごとに、合格すべきニアミス、拒否すべきニアミス、そして再開された計画などの逆遷移を実行します。失敗がある実行、または新しいチェックがゲートとする状態の事例がない実行は、verified ではなく partial または gap として記録します。他のセッションが未コミットで保持している新たな失敗ファイルは、失敗のままにし、ブロックの Delivery ルールに従って所有者を明記します。ファイルに関する主張を記録する直前に、そのファイルを再読します。コミット本文には、プロジェクトごとの新たな失敗数を記載します。ユーザーのグローバル設定に対してコマンドを表示または実行するヘルパーは、スクラッチの HOME にその設定のコピーを置き、対照実行と並べてエンドツーエンドで動作を確認してから出荷します。
5. dotai の最初のコミット前に、ヘルパーまたはチェックの変更について、差分を対象に /pstack:interrogate を1ラウンド実行します。スモークラウンドは時間がかかり、部分的なレビューにしかならないため、リードはパネルが受け入れた指摘を修正します。受け入れられた修正の後は、スモーク前に文章作成の各パス、テスト、corpus を再実行します。その後、apply は未コミットのツリーからレンダリングするため、そのツリーからスモークします。管理対象プロジェクトごとに、その .agents/pstack を実行ディレクトリにコピーして corpus --installed のベースラインとし、ライブチェックアウトでベースラインのスモークを実行します。次に、そのプロジェクトのピン留めされたタグを指定した sync --tag <its pinned tag> <project> で未コミットのツリーからレンダリングします。このコマンドの事前チェックは、チェックアウトがプロジェクトのブランチ以外にある場合、または書き込み対象ファイルに未コミットの編集がある場合に拒否します。新規または変更された dotai プロジェクトスキルは、それぞれのスキルディレクトリに直接コピーして再インストールの代わりとし、変更されたユーザースコープの各スキルはローカルチェックアウトから -g を使ってインストールします。そして、Setup のステップ 6 の判定方法に従って、対応するスモークを実行します。sync が拒否するプロジェクトは、エクスポートからスモークします。すべての Git チェックアウトの外に git archive HEAD を展開し、そこで git init とコミットを実行します。これにより Codex はリポジトリ内で動作し、親ディレクトリの AGENTS.md を読み込みません。apply --force で新しいブロックをレンダリングします。ベースライン実行では、変更前の状態を独自のエクスポートにコピーした指示ファイルから読み込み、対になる実行との差分が編集だけになるようにします。レンダリング結果には共有ソースを記録しません。また、ステップ 6 の apply は、出力を同一に保ったまま、assets/ を最後に変更したコミットを記録します。スモークで指摘された競合はツリー内で修正して再度スモークし、変更を1回のプッシュで dotai に反映します。dotai では node scripts/build-workflow.mjs、続いて node --test skills/sync-pstack/scripts/sync-pstack.test.mjs と scripts/validate-skills を実行します。後者は生成されたカタログをチェックします。いずれもフォアグラウンドコマンドの制限時間を超える可能性があるため、出力と終了ステータスをログに記録しながらバックグラウンドで実行します。この実行で作成した新規ファイルは git add -- <new paths> でステージし、この実行のパスは git commit --only -- <paths> でコミットします。このコミットでは git add -A を決して使いません。指定したパスに別セッションのハンクも含まれている場合は、それもコミットし、その旨を本文に記載します。dotai の AGENTS.md はすべての変更をコミットするよう求めているため、他のセッションの未コミット編集が残っている場合は、workflow-manifest.json とともに2つ目のコミットにし、残っていない場合はマニフェストを1つ目のコミットに含めたうえで、両方をプッシュします。オーナーがプッシュを保留している場合は、コミットもプッシュもしません。編集は dotai のチェックアウトに残し、git diff を実行して得た差分をパッチとして実行ディレクトリに保存します。計画の Open work 項目には、そのパッチ、反映後にのみ有効となるすべての主張、各プロジェクトでステップ 5 のレンダリングを記載します。変更が反映されるまで、次の apply は拒否されます。
6. プロジェクトがすでに同期済みのコミットを修正する場合は、amend や rebase ではなく新しいコミットを作成します。プロジェクトはそのコミットをソースとして記録しているためです。同期したコミットをすべての管理対象プロジェクトに反映します。セッションが実行中にファイルを追加するため、apply の直前に、プロジェクトのライブツリーごとに corpus <project> --installed <its step 5 baseline> --session <id> を再実行します。ステップ 5 でレンダリングしたプロジェクトの未コミットの共有編集による拒否は、Sync のステップ 4 に従って解決します。ブロックが指定する新規または変更された各スキル、および今回編集した各スキルをローカルチェックアウトからインストールし、続いて Sync のステップ 6 の verify を実行します。その後、実施する場合は意思決定トレイルのレビューを行います。ステップ 5 のスモークは、今回の apply が .agents/pstack.json 以外にも書き込む場合、またはスモーク以降のコミットや編集によって、そのスモークが読み取った指示ファイルのバイト列が変わった場合を除き、そのプロジェクトでは有効です。その場合、そのプロジェクトでは納品前に対応するスモークを再実行します。変更が触れるルールの間でスモークが指摘した競合は、いずれのプロジェクトも納品する前に、新しい dotai コミットとして反映します。新規または変更された各プロジェクトスキルは、npx --yes skills add udecode/dotai --skill <name> --agent codex claude-code -y を使って再インストールし、ロックファイルにリモートソースを記録します。変更されたユーザースコープのスキルは、ホームディレクトリから npx --yes skills add udecode/dotai --skill <name> --agent codex claude-code -g -y を使って更新し、インストール済みの SKILL.md と dotai のコピーを diff -q で比較します。その後、各プロジェクトで Sync のステップ 7 を実行します。

プロジェクトのプレイブック

プロジェクトは、ユーザーだけが呼び出せるスキルだけでなく、pstack のプレイブックを土台としてライフサイクルを追加します。そのため、通常のリクエストも poteto-mode を通じてプロジェクトに届きます。各 .agents/playbooks/<name>.md は、poteto-mode の「Project playbooks」段落に従います。この段落では、extends と when のフロントマター、および pstack のステップ自体の文言を引用した箇所を基点とする変更を定義します。sync-pstack では、次の点が追加されます。

• 任意の page-lead、page-pairs、page-require 行。これらは、plan-page スキルで説明されている、計画が記述するレビューセクションを指定します。
• ブロックには各プレイブックとその when の文が一覧表示されます。そのため、プレイブックを追加または編集すると、apply でブロックを再生成するまで check は失敗します。
• pstack のプレイブックにはない箇所で停止する場合の停止ポイント。

**In** はステップ内に作業を追加し、**Replace** はプロジェクトで方針がすでに決まっているステップを置き換え、**Before** はそのステップより前に実行します。そのため、実装を行う変更は、設計ステップや固定ステップの Before ではなく、ベースの実装ステップの In に置きます。**In**、**Before**、**After** は行を追加し、ベースのステップの文言をすべて残します。そのため、ブロックやプロジェクトのルール（委任、コミット、スナップショット、追加の執筆作業）と矛盾する文言があるステップには、**Replace** が必要です。誰がコミット、プッシュ、返信できるかなど、後続のステップを制限するルールは、制限対象となる最初のステップの Before に置きます。エージェントは、生成されたステップを順番に todo リストへコピーするためです。アンカーのチェックでは、順序ではなくテキストが一致するかを確認します。編集のたびに playbook <project> <name> を実行してください。これは、変更を順番に適用した各ベースの全ステップを出力するので、その内容を確認します。2 つのベースを拡張するプレイブックでは、それぞれのベースに対する各変更を記述します。

プロジェクトの知識はスキルとプロジェクトのルールに保管し、プレイブックは作業の順序だけを定めます。以前ライフサイクルを実行していた型付きコマンドは、そのプレイブックを指定するエントリーポイントとして残します。

テンプレートの文法

assets/block.md と assets/pstack/rules/ 内の各ルールファイルは、行ディレクティブを含む Markdown です。ブロックには、一般的なタスクで必要となるすべてのルールと、各ルールファイルへのポインター行を 1 行ずつ記載します。各ポインター行では、エージェントにそのルールを読むよう促すトリガーを指定します。テキストをルールファイルへ移したルールでは、ポインターの上に overrides の注記を残します。

• , , 、 は、プロジェクトの設定が条件を満たすときにレンダリングされる領域を開始します。
• `` は、設定で skip の下に id が記載されている場合に削除される領域を開始します。
• `` は、最も内側の領域を閉じます。領域は入れ子にできます。
• {{key}} は設定値を挿入します。値が欠けた行がレンダリングされるとレンダリングは失敗し、どのセクションも指定していない skip エントリーがある場合も失敗します。
• で始まる行は、次のオーバーライドが置き換える pstack のテキストを指定します。`<path>` は pstack の `plugins/pstack/skills/` からの相対パスです。そのテキストがなくなると、`apply --tag` と `verify` は失敗します。オーバーライドには、置き換える pstack のステップごとに注記を付けます。そのため、対象範囲を広げる場合は、新たに対象となる各ステップにも注記を追加します。pstack に追加するだけのルールには代わりに を付けます。どちらもないルールは verify によって警告されます。
• インデントされた行は上のリスト項目の続きとなるため、条件付きの文をルールに追加できます。その項目の行にレンダリングされますが、入れ子のリスト項目で始まる場合、またはその後に続く場合は除きます。

境界

• pstack 自体のファイルは編集しないでください。ブロックまたはプロジェクトルールを通じて、その動作を変更してください。
• 拒否されたブロックやヘルパーは、オーナーの承諾がない限り上書きしないでください。ただし、その編集がテンプレートまたはブロック外に移動している場合は除きます。
• セットアップと同期で実行するのは、プロジェクトの回答で指定された内容だけです。回答で指示されていない保護ブランチへのプッシュ、強制プッシュ、PR の作成は行いません。また、Sync のステップ 7 にあるとおり、同期では PR を一切作成しません。pr プロジェクトの同期でそのブランチにプッシュすることは、PR を求めるルールセットがあっても実行する唯一の保護対象へのプッシュです。これはオーナーが継続的な依頼として求めているためです（オーナーの承諾、2026-10-20）。これは、プロジェクトの main へのプッシュを禁じるルールが必要とするユーザーの依頼に該当します。
• インタビューで確定した回答はオーナーに帰属します。プロジェクトの証拠と矛盾する場合に限り、再度確認してください。
• セットアップと同期では、ドメインスキルの手法を決して削除、統合、書き換えしません。削除は独立した測定済みの工程です。削除する前にファイル間の重複を測定し、他に管理者がいないルールは残してください。

リソース

• インタビュー：質問、その根拠と推奨事項、設定フィールド。
• 適応：ベンダーコピー、孤立したスキル、ルールのフォーク、Codex シート、フォーマッター、ブロックを中心としたプロジェクトルールの書き換え。
• assets/block.md：共有ブロック。
• assets/pstack/：Plans ルールが実行する計画および意思決定ログのヘルパーと、指定したモデルおよび推論量で別のランタイム上でプロンプトを実行する cross.mjs。smoke では読み取り専用で、パネルの Codex シートでは --reach を付けて実行し、オーナーの設定とネットワークを読み込み、スクラッチフォルダーにのみ書き込みます。また、サンドボックスなしでオーナー自身の Codex 設定を使う Codex ワーカーとして --bypass を付けて実行できます。さらに、cross.mjs を通じてパネルラウンドのシートを1つのプロセスで実行する seats.mjs があり、ラウンド中にセッションを起動するのは一度だけです。
• scripts/sync-pstack.mjs と、そのテストである scripts/sync-pstack.test.mjs。