cmate-verify

cmate-verify

「このリポジトリで何が通れば合格か」を .commandmate/verify.yaml に宣言し、 実 exit code で 判定するランナー。CommandMate 本体の検証ゲート （commandmate verify <worktree-id> / commandmate wait <worktree-id> --verify）の 代替ではなく、verify.yaml の起案（手順 1）と、CommandMate が無い環境でも bash と git だけで同じ判定を出すスタンドアロンランナー（手順 2）の 2 役である。

正準仕様は CommandMate リポジトリの docs/design/verification-config.md。 本体のローダ（src/lib/verification/verify-config.ts）は同じ仕様を一般的な YAML パーサで 実装するので、この Skill で書いた verify.yaml はそのまま引き継げる。

なぜ exit code か: cmd | grep ... は $? を grep に渡して非ゼロ終了を隠す。vitest は 全テスト緑でも Unhandled Rejection で exit 1 を出しうるので、出力を grep した要約は それを PASS と報告してしまう。ゲートは必ず sh -c "$cmd" > log 2>&1 で走らせ $? を直接読む。

構成

cmate-verify/
├── SKILL.md
└── scripts/
    ├── verify-run.sh        # ゲート実行ランナー（bash 3.2 互換）
    └── tests/
        ├── run-tests.sh     # fixture ベーステスト（bash + git だけで動く）
        └── fixtures/*.yaml

scripts/tests/run-tests.sh は vitest に依存しない。Node の無い導入先でも bash scripts/tests/run-tests.sh だけで検証できる（CommandMate 本体では tests/unit/skills/cmate-verify/ の薄いラッパが npm run test:unit から同じ suite を回す）。

install 先は .claude/skills/cmate-verify/ と .agents/skills/cmate-verify/ の両方で、 中身は byte-identical である（Claude は前者、Codex は後者を読む）。以下のコマンド例は .claude/... で書いてあるが、.agents/... に読み替えても同じものが走る。

手順 1: init（.commandmate/verify.yaml が無い場合）

コードを書かず、リポジトリをスキャンしてゲートを起案し、ユーザーの確認を得てから書き出す。 検出優先順位は次のとおり。上位が見つかったら下位は補助として扱う。

1. .github/workflows/*.yml の CI ジョブ — そのリポジトリにおける「何が通れば合格か」の 既存の定義。run: の各ステップが第一候補。
2. package.json の scripts — lint / test / test:unit / typecheck / build 系。
3. Makefile のターゲット — make lint / make test 等。
4. 言語マニフェスト — Cargo.toml（cargo clippy / cargo test）、pyproject.toml （ruff / pytest / mypy）、go.mod（go vet / go test ./...）等。

起案時の注意:

• 実行時間の長いゲートには timeoutSec を明示する（既定は 600 秒）。
• ゲートの並び順がそのまま実行順になる。速いゲートを先に置くと失敗が早く読める （途中で失敗しても残りは実行されるので、順序は打ち切りではなく可読性のための選択）。
• デプロイ・publish・リリース・外形変更を伴うコマンドはゲートにしない。 ゲートは 何度でも安全に再実行できるものに限る。
• 起案結果は「どこから拾ったか」（CI ジョブ名 / npm script 名）とセットで提示し、 ユーザーの確認を得てから .commandmate/verify.yaml を書き出す。