kaji

設計書（draft/design/）に基づき、TDD（テスト駆動開発）アプローチを用いて機能を実装する。

実装完了後の成果物に対し、設計整合性とコード品質の観点から厳格なレビューを実施する

Issue 作成後・workflow 起動前に人間が明示起動する要件 interview。one-way door を含みうる重要な Issue で、未決の decision tree を 1 問ずつ推奨案付きで確認し、決定事項と provenance を Issue に固定するときだけ使用する。軽微な Issue や workflow 実行中には自動起動しない。

第2層のインシデント調査レビュー収束サイクルを 1 コマンドで手動起動する slash command wrapper。kaji run .kaji/wf/official/incident.yaml <incident_issue_id> を Bash 経由で起動し、exit code を verdict に縮約する。

Issue要件に基づき、draft/design/に設計書を作成する。worktree内での作業が前提。

ワークフローを手動実行して検証し、失敗時は継続せず原因を調査して Issue に記録する。成功時も気づきや詰まりどころを Issue に記録する。

dev.yaml を --from review-poll --before close で起動し、終了後に /issue-close 案内を含む verdict を出力する slash command wrapper。

Create a validated sequential Issue series plan from an explicitly ordered GitHub Issue list. Use when a maintainer wants to generate or update an ID-named YAML file under .kaji/series, select standard workflows from Issue type metadata and workflow descriptions, or preview a series without starting it.

実装前 pytest baseline を deterministic に測定・構造化し、workflow verdict を返す。

dev workflow 向けの最終チェック。PR 前に品質ゲート、docs 整合、設計書昇格、Issue 更新をまとめて確認する。

レビュー指摘事項に対し、技術的妥当性を検討した上で修正対応（または反論）を行う

コード修正が適切に行われたかを確認する。新規指摘は行わない（レビュー収束のため）。

独立 review 済み starter candidate を承認 gate 後に atomic push し、検証済み snapshot として公開する。

kaji の release 作業（version bump / CHANGELOG / tag / GitHub Release ページ）を進め、PyPI publish workflow へ引き継ぐ。

starter 追随 candidate を別 session で独立検証し、過不足と検証証跡を判定する。

公開済み kaji Release に managed starter を追随させ、独立 review 用の未 push candidate を作成する。

Issue作成とラベル付与を行う。開発ワークフローの起点。review-ready の共通・type別観点を満たす本文生成を誘導する。

設計ドキュメントに対し、汎用的なソフトウェア設計原則に基づいてレビューを行う。

Issue本文の着手レディネスレビュー。作業着手に足る記述品質があるかを検証する全 workflow 共通ゲート。

イシュー完了時に使用。PRマージ・worktree削除・ブランチ安全削除を一括実行

docs-only workflow 向けの最終チェック。docs 整合と Issue 状態を確認し、PR に進めるか判定する。

review-ready の RETRY 指摘に基づき Issue 本文を修正する。

workflow 共通の PR 作成スキル。worktree 解決、未コミット確認、push、kaji pr create のみを担当する。

第2層。査読で挙がった既出指摘が解消されたかのみを確認する。新規指摘は行わない（レビュー収束のため）。全指摘解消なら PASS（report へ）、未解消ありなら RETRY（fix へ）。

第2層。査読 RETRY の指摘に対し、追加調査・再実験・artifact 修正、または技術的根拠を示した反論で対応する。調査セッションを継続（resume）し、指摘ごとの対応表をコメント投稿する。scope 拡大はしない。

第2層。インシデントイシューとローカル run artifact を読み、#301 の調査手順①〜⑥に沿って原因調査 artifact を作成し、全文をインシデントイシューへコメント投稿する。結論を断定できない場合は INCONCLUSIVE で PASS 可。

第2層。収束した調査 artifact を正本に、インシデントイシューへ最終提案コメント（可読サマリ・調査結論・対応策・意味的類似の指摘・統合提案・処遇メニュー・モデルメタデータ）を投稿する。ラベル操作・クローズ・起票は行わない（実行は人間）。

第2層。調査 artifact に対する実行型査読。使い捨て検証環境を準備し kaji-incident-reviewer subagent を起動、反証義務・独立検証・受理基準（実証）で判定して査読結果コメントと verdict を発行する。査読結論とレビュー verdict は別軸。

docs review の指摘に対応し、ドキュメントのみを修正する。コードやテストは変更しない。

docs-only の変更をレビューし、事実整合性・実装整合性・運用整合性の観点から判定する。

docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。

docs review の指摘が適切に修正されたかを確認する。新規指摘は行わない。

PR 上のレビューコメントに基づきコード修正・コミット・レビュー返信を行う。

codex auto-review (chatgpt-codex-connector[bot]) の reactions / reviews を polling して PASS / RETRY / BACK_FALLBACK を判定する。GitHub 限定。

PR に対し初回コードレビューを実施し、Approve / Changes Requested を投稿する。新規レビュー専用（修正確認は /pr-verify）。`dev` / `dev-thorough` / `docs` workflow では `review-poll` の `BACK_FALLBACK` を受けた fallback step として呼び出される。

イシュー着手時に使用。worktreeで分離された開発環境を構築し、Issue本文にメタ情報を追記する

fixture for exec_script dispatch tests

PR レビュー修正が適切に行われたかを確認する。新規指摘は行わない（レビュー収束のため）。

設計レビューの指摘事項に基づき、設計ドキュメントを修正または議論する。

設計修正が適切に行われたかを確認する。新規指摘は行わない（レビュー収束のため）。