with one click
i-doc-update
docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| description | docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。 |
| name | i-doc-update |
ドキュメント修正専用のスキル。 このスキルの目的は ドキュメントのみを更新すること である。コード、設定、テストは変更しない。 ただし、docs の記述が現行実装や運用方針と矛盾していないかは厳格に確認する。
| タイミング | このスキルを使用 |
|---|---|
| docs-only Issue の主作業 | ✅ 必須 |
| コード変更を伴う Issue | ❌ issue-implement / i-dev-final-check を使用 |
ワークフロー内の位置: review-ready → start → update-doc → review-doc → (fix-doc → verify-doc) → i-doc-final-check → i-pr → close
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 正規化済み Issue ID(GitHub 数値または local ID) |
issue_ref | str | 人間可読の Issue 参照(GitHub では #<issue_id>、local では bare ID) |
step_id | str | 現在のステップ ID |
$ARGUMENTS = <issue_id>
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される(prompt.py 側で provider 別に整形)。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID(# を付けない)。
docs/README.mdREADME.mdmake verify-docs による全体確認は許可ABORT_shared/worktree-resolve.md の手順に従い、 Worktree の絶対パスを取得すること。以降のステップではこのパスを使用する。
# 設計書が存在する場合のみ表示。マッチが無くても失敗しない
shopt -s nullglob
files=([worktree_dir]/draft/design/issue-[issue_id]-*.md)
if (( ${#files[@]} > 0 )); then
cat "${files[@]}"
else
echo "[i-doc-update] no draft design file for issue [issue_id] (skipping)"
fi
docs/dev/documentation_update_criteria.md の 3 観点(事実整合性・実装整合性・運用整合性)に沿って、最低限以下を確認する。
docs/ の記述が現行コードと矛盾していないかAGENTS.md / CLAUDE.md のコマンド、禁止事項、運用ルールと矛盾しないかdocs/dev/development_workflow.md と workflow/skill 構成が一致しているか必要なドキュメントだけを更新する。
初回に以下を実行し、既存 docs 全体の状態を確認する。
cd [worktree_dir] && source .venv/bin/activate && make verify-docs
cd [worktree_dir] && git add docs/ README.md .kaji/wf/ .claude/skills/ .agents/skills/ && git commit -m "docs: update for [issue_ref]"
必要に応じて変更対象パスを絞ってよい。
kaji issue comment [issue_id] --commit --body-file - <<'EOF'
## docs-only 更新完了
### 更新内容
- (更新したドキュメント)
- (関連 workflow / skill)
### 整合確認
- 実装 / workflow / 既存 docs / AGENTS.md / CLAUDE.md との整合を確認
- `make verify-docs` による初回全体リンクチェックを実施
### 次のステップ
`/i-doc-review [issue_id]` でレビューを実施してください。
EOF
---VERDICT---
status: PASS
reason: |
docs-only の更新を完了した
evidence: |
対象ドキュメントと関連 workflow/skills を更新し、現行実装・CLI・運用方針との整合を確認した
suggestion: |
---END_VERDICT---
| status | 条件 |
|---|---|
| PASS | docs 更新完了 |
| ABORT | docs だけでは安全に対処できない |
設計書(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 に記録する。