インストール
npx skills add tw93/Waza -a claude-code codex cursor -g -y誰向けか
機能計画と欠陥修正はすでにでき、臨機応変ではなく同じ習慣でエージェントを走らせたいなら、このスキルが合う。公式の書き方は、すでに身についているエンジニアリング習慣を、エージェントが実行できるスキルにする、である。
インストール後、スラッシュスキル一式が手に入る。ページが名指しするのは /think、/check、/hunt。Claude Code ではスラッシュコマンドを直接打つ。Codex ではインストール済みスキル名で呼び、同じ手順を踏む。ページは Cursor、Gemini CLI、Copilot、Amp、Kimi Code CLI にも触れ、同じ共有ディレクトリを読む他のエージェントもこの8スキルを拾えると書く。それはディレクトリ読み取りの関係であり、排他的な名簿ではない。
より向くのは、開ける対象リポジトリがあり、すぐに implement させるのではなく、先に読み取り専用の計画または検査をしたい人。公式説明：
https://github.com/tw93/waza
3分で最初の試行
公式インストール経路はこの1本だけ：
npx skills add tw93/Waza -a claude-code codex cursor -g -y
コマンドは共有スキルディレクトリ ~/.agents/skills にコピーを落とす。Claude Code はシンボリックリンクでつなぐ。Codex、Cursor、そのディレクトリを読む他のエージェントは、スキルを /check、/think などの名前として認識する。ページは別インストーラを主経路としては出していない。
前提：このマシンで上の npx コマンドが既に動き、~/.agents/skills を読むエージェントを少なくとも1つ開いていること。インストール先はこの共有ディレクトリ。手で別フォルダへコピーしない。
初回は可逆で分析寄りの作業を選ぶ。Claude Code で対象リポジトリを開いたあと /check を入力するか、先に /think で計画だけする。Codex では同じ検査または計画をスキル名で呼ぶ。初回に implement と言わない。成功の合図：スキルが /check、/think などの名前で現れ、/check がリポジトリの公開コンテキストから検査結果を出し、未インストールとは言わないこと。
使用例
例1：先に機能を計画し、実装するかを決める。
公式は機能計画を次のように書く。/think、計画を承認、implement X と言う、それから /check、最後に merge。初回は /think まで走らせて計画を読む。根拠に承認ボタンの見た目も、merge の具体コマンドもない。確認できるのはこの順序と、実装は計画が受け入れられたあとであるべきこと。
例2：先に根本原因を調べ、それからコードを直す。
公式は欠陥修正を次のように書く。/hunt、それから修復、それから /check、そのあとフォロー。ページはフォローを release/publish/push/issue follow-through と書くが、それらの手順は展開していない。初回は /hunt だけ走らせる。根本原因の説明が現象に合ってから手を入れる。/hunt は根本原因の確認用であり、すぐ直し始める用ではない。
どちらも同じインストール経路の上にある。/check は計画や修復のあとに続けられるが、初回は検査を単独で走らせ、公開コンテキストを読んだことを確認する。
利用の境界
Waza が提供するのは汎用のエンジニアリング習慣だけ。/check は実行時に対象リポジトリの公開コンテキストを読む。README、パッケージマニフェスト、Makefile、継続的インテグレーションのワークフロー、および今回の作業の制約。非公開パス、資格情報、トークンは読まない。ページは、非公開設定や秘密情報にアクセスできるとは書いていない。
インストールコマンドには claude-code、codex、cursor の3目標があり、コピーは ~/.agents/skills に落ちる。そのディレクトリを読む他のエージェントもスキルを拾えるが、ページは名前ごとに起動例を出していない。Claude Code のスラッシュと Codex の名前呼び以外で、他環境について確認できるのは「共有ディレクトリを読めばこの8スキルが現れる」だけ。
ページに言語範囲、枠、必須のリポジトリ種類はない。対象リポジトリの公開コンテキストが欠けているとき、/check がどこまでできるか、公式は別の失敗例を出していない。