ワンクリックで
incident-report
第2層。収束した調査 artifact を正本に、インシデントイシューへ最終提案コメント(可読サマリ・調査結論・対応策・意味的類似の指摘・統合提案・処遇メニュー・モデルメタデータ)を投稿する。ラベル操作・クローズ・起票は行わない(実行は人間)。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
第2層。収束した調査 artifact を正本に、インシデントイシューへ最終提案コメント(可読サマリ・調査結論・対応策・意味的類似の指摘・統合提案・処遇メニュー・モデルメタデータ)を投稿する。ラベル操作・クローズ・起票は行わない(実行は人間)。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| description | 第2層。収束した調査 artifact を正本に、インシデントイシューへ最終提案コメント(可読サマリ・調査結論・対応策・意味的類似の指摘・統合提案・処遇メニュー・モデルメタデータ)を投稿する。ラベル操作・クローズ・起票は行わない(実行は人間)。 |
| name | incident-report |
収束した調査 artifact を正本として、インシデントイシューへ最終提案コメントを投稿する。 review PASS(初回受理)と verify PASS(修正後受理)の 2 経路がここに合流する。
全終端は「提案」(#303 決定 D): ラベル付与・除去、クローズ / reopen、バグイシュー化、統合の実行は 一切行わない。それらは人間の処遇判断。
ワークフロー内の位置: review/verify(PASS)→ report → end
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 対象インシデントイシュー ID |
issue_ref | str | 人間可読の Issue 参照 |
step_id | str | 現在のステップ ID |
手動実行時は $ARGUMENTS 第 1 トークンを issue_id とする。
.claude/skills/incident-investigate/SKILL.md § 全 incident-* skill 共通ルールに従う。
artifact root を解決する(共通ルール参照):
ART="$(kaji config artifacts-dir)"
$ART/[issue_id]/investigation/report.md(収束済み)を正本として読み込む。
以下を含む最終提案コメントを構成する(Issue 完了条件の「可読サマリ・意味的類似の指摘・統合提案」に対応)。
duplicate の場合、統合先イシューと根拠(実行は人間)。docs/dev/incident-labels.md の対応表と整合させる)。処遇メニューの対応表(conclusion → 推奨ラベル・後続アクション。実行は人間):
| conclusion | 推奨 status ラベル | 推奨 classification ラベル | 後続アクション(人間が実行) |
|---|---|---|---|
internal-bug | incident:mitigated 等 | incident:cause:internal | バグイシュー化ドラフトを起票、緩和/恒久対策の判断 |
upstream | incident:mitigated 等 | incident:cause:upstream | 上流 issue への報告 / watch、回避策の適用 |
environment | incident:mitigated 等 | incident:cause:environment | 環境修正、運用手順の更新 |
transient | (第1層が自動付与済みの場合あり) | incident:cause:transient | 頻度を監視。頻発なら昇格判断 |
duplicate | (統合先に集約) | 統合先に準ずる | 統合先への集約(実行は人間) |
INCONCLUSIVE | incident:investigating 維持 | 付与しない | 不足証拠の収集後に再調査 |
risk-acceptedは人間専用語彙であり、本コメントの出力語彙に含めない。
verdict マーカーを無条件付与する。auto-close hazard 回避規約に従う(提案文面で「バグイシュー化」等の 名詞表現を使い、ハザードパターンと issue 番号の連接を避ける)。
kaji issue comment [issue_id] --commit \
--verdict-step report --verdict-status <STATUS> \
--body-file <最終提案 markdown>
ラベル操作・クローズ・イシュー起票は一切行わない。 PASS: end。
---VERDICT--- status: PASS reason: | 最終提案コメントを投稿した(可読サマリ・調査結論・対応策・類似・統合提案・処遇メニュー) evidence: | conclusion=<値>、処遇メニュー・モデルメタデータを含む最終提案を投稿 suggestion: | 人間がラベル遷移・クローズ・バグイシュー化・統合の実行を判断する ---END_VERDICT---
| status | 条件 |
|---|---|
| PASS | 最終提案コメントを投稿した |
| ABORT | 前提崩壊(対象が非インシデント / artifact 不在等) |
設計書(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 に記録する。