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

2026-07-2112

incident-cycle

apokamo/kaji

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

2026-07-2112

issue-design

apokamo/kaji

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

2026-07-2112

kaji-run-verify

apokamo/kaji

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

2026-07-2112

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

I Doc Fix

docs review の指摘事項に対応する。このスキルでも コード、設定、テストは変更しない。

いつ使うか

タイミング	このスキルを使用
`i-doc-review` または `i-doc-verify` が RETRY のとき	✅ 必須

ワークフロー内の位置: update-doc → review-doc → fix-doc → verify-doc

入力

ハーネス経由（コンテキスト変数）

変数	型	説明
`issue_id`	str	正規化済み Issue ID（GitHub 数値または local ID）
`issue_ref`	str	人間可読の Issue 参照（GitHub では `#<issue_id>`、local では bare ID）
`step_id`	str	現在のステップ ID
`previous_verdict`	str	前ステップの verdict

手動実行（スラッシュコマンド）

$ARGUMENTS = <issue_id>

解決ルール

コンテキスト変数 issue_id が存在すればそちらを使用。なければ $ARGUMENTS の第1引数を issue_id として使用。

issue_ref はハーネス経由ではプロンプトに自動注入される（prompt.py 側で provider 別に整形）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。

前提知識の読み込み

実行手順

previous_verdict または Issue コメントから最新レビュー結果を取得
Must Fix を 1 件ずつ検討
docs のみ修正
実装 / CLI / AGENTS.md / CLAUDE.md / 関連 docs との整合を再確認

修正対象ファイルに絞って以下を実行:

cd [worktree_dir] && python3 scripts/check_doc_links.py [changed-markdown-files...]

docs のみコミット
対応内容を Issue にコメント

Verdict 出力

---VERDICT---
status: PASS
reason: |
  docs review の指摘に対応した
evidence: |
  Must Fix 項目を修正し、関連する docs と実装の整合を再確認した
suggestion: |
---END_VERDICT---

status の選択基準

status	条件
PASS	修正完了
ABORT	docs 修正だけでは解決不能