hasegama/pstack-claude

architect

型・関数シグネチャ・モジュール構成を設計し、独立した複数案を比較してから実装する。/architect や、構造の判断を伴う実装に使う。

arena

同じ課題に独立した複数候補を作り、評価して基準案に優れた部分を統合する。/arena や、設計・実装案の比較に使う。

blast-radius

変更が差分の外に及ぼす影響を調べ、成立条件を実コードの実行で確認する。影響範囲や小さな差分の安全性をレビューするときに使う。

bro

直前の説明を専門用語に頼らない平易な言葉で言い直す。/bro や、説明をわかりやすくしてほしいという依頼に使う。

control-cli

既存のハーネスや PTY・tmux で CLI・TUI を操作し、表示と挙動を検証する。端末 UI の不具合再現や操作確認に使う。

control-ui

既存のブラウザー・Playwright・CDP ハーネスで UI を操作し、表示と挙動を検証する。Web・Electron の不具合再現や操作確認に使う。

create-verification-skill

アプリを利用者と同じ経路で検証するプロジェクト用スキルと機能マップを作る。/create-verification-skill や、検証手順をスキルにしたい依頼に使う。

deslop

差分から不要なコメント、防御的なコード、型の回避などを見つけ、既存の書き方に合わせる。コミット前のコード整理に使う。

figure-it-out

既存の手順で扱いきれない大きな変更について、検証できる単位と仮説検証の手順を組み立てる。/figure-it-out や、大規模な移行の設計・実装に使う。

how

実コードから仕組み・処理の流れ・配置先・責務を説明する。どう動くか、どの層に置くか、変更前の構造理解を求める依頼に使う。設計意図の履歴調査は why を使う。

interrogate

独立した複数の Claude レビュアーで同じ対象を批判的に検証し、盲点や反証をまとめる。/interrogate や、設計・コードを厳しくレビューする依頼に使う。

maintain-verification-skill

既存の検証スキルと機能マップを実装・実動作と照合し、確認できた不整合を直す。/maintain-verification-skill や、検証手順の棚卸しに使う。

no-comments

Comment Sicko にコメントの妥当性を調べさせ、採用した指摘を反映する。/no-comments や、コメントで補っている設計を見直す依頼に使う。

poteto-mode

pstack の設計原則と作業手順を使い、調査・設計・実装・検証を進める。/poteto-mode、poteto の流儀で作業してほしいという依頼に使う。

principle-boundary-discipline

検証やエラー処理を CLI・設定・ネットワークなどの境界へ集め、内部の型と純粋な処理を活かす。境界の設計時に使う。

principle-build-the-lever

繰り返せるツール・スクリプトで変更や検証を実行する。手作業の反復が発生する編集・移行・分析に使う。

principle-encode-lessons-in-structure

繰り返す注意事項を lint・型・メタデータ・実行時検査に落とし込む。同じ修正や指示が再発したときに使う。

principle-exhaust-the-design-space

前例のない UI・設計判断で複数の試作を比べる。単一案に決める前に設計空間を探索するときに使う。

principle-experience-first

機能の範囲や UX の判断を利用者の体験から決める。実装都合と体験の品質が競合するときに使う。

principle-fix-root-causes

症状を再現して原因までたどり、根本を直す。不具合調査・修正で使う。

principle-foundational-thinking

ロジックを書く前に型・データ構造・共有状態を決める。実装の土台や作業順を設計するときに使う。

principle-guard-the-context-window

大量の出力やファイルを扱う作業で、主会話に残す要点と分担する調査を整理する。コンテキストの消費が大きいときに使う。

principle-laziness-protocol

削除と必要最小限の変更で問題を解く。リファクタリングや抽象化・層の追加を判断するときに使う。

principle-make-operations-idempotent

中断や再試行の後も同じ状態へ収束する処理を設計する。コマンド・初期化・処理ループを作るときに使う。

principle-migrate-callers-then-delete-legacy-apis

新しい内部 API へ呼び出し側を移し、旧 API を同じ作業で取り除く。内部 API の移行に使う。

principle-minimize-reader-load

処理を読むために追う層と覚える状態を減らす。追跡しにくいコードの設計・レビューに使う。

principle-model-the-domain

分岐や状態の前提をデータ構造・状態機械・型で表現する。状態を持つ処理や重複した条件を設計するときに使う。

principle-never-block-on-the-human

可逆的な作業を進めて具体的な結果を示す。作業を進めるか確認するかの判断に使い、ユーザーの依頼範囲に従う。

principle-outcome-oriented-execution

移行の最終形へ収束する作業順を組み立てる。段階的な書き換えや移行で中間実装の要否を判断するときに使う。

principle-prove-it-works

実物・実値・実行結果を確認して作業の完了を示す。完了報告前の検証に使う。

principle-redesign-from-first-principles

新しい要件を最初から前提にした構造を考える。既存設計へ要件を統合するときに使う。

principle-separate-before-serializing-shared-state

並列処理の共有書き込みを分離し、共有が本当に必要な部分だけ直列化する。同じファイル・ブランチ・状態への競合を設計するときに使う。

principle-sequence-verifiable-units

各段階で結果を確かめられる単位に分割して順に進める。多段階の変更や移行を計画するときに使う。

principle-subtract-before-you-add

不要なコードや参照を除去してから変更を加える。追加・リファクタリング・書き換えの作業順を決めるときに使う。

principle-type-system-discipline

不正な状態を表しにくい型、境界のパース、網羅的な分岐を設計する。型付き言語の実装・シグネチャのレビューに使う。

show-me-your-work

判断・理由・根拠・結果を追跡できる TSV の意思決定ログを残す。/show-me-your-work や、長い作業の判断を後からレビューしたい場合に使う。

swarm

複数の Claude ワーカーで調査範囲を分担、または同じ課題を独立して試し、結果を集約する。/swarm や、並列調査・候補比較に使う。

tdd

失敗するテストから修正を進める。TDD・失敗テスト・回帰テストを明示的に依頼された場合、または不具合に安価で明確なローカルテストがある場合に使う。

teach

how と why の調査をつなぎ、変更や仕組みを理解できる説明にまとめる。/teach や、変更・サブシステムをきちんと理解したい依頼に使う。

technical-writing

技術文書の構造と文章を整える。文書、RFC、README、PR 説明、コミットメッセージの作成・レビューに使う。