Menu
workflow 共通の PR 作成スキル。worktree 解決、未コミット確認、push、kaji pr create のみを担当する。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| description | workflow 共通の PR 作成スキル。worktree 解決、未コミット確認、push、kaji pr create のみを担当する。 |
| name | i-pr |
workflow 共通の PR 作成スキル。 workflow 固有の完了判定は持たず、PR 作成そのものに責務を限定する。
| タイミング | このスキルを使用 |
|---|---|
i-dev-final-check 完了後 | ✅ 必須 |
i-doc-final-check 完了後 | ✅ 必須 |
provider.type='github' 配下 | ✅ 受理（gh CLI 経由） |
provider.type='local' 配下 | ❌ Step 0 で ABORT。代替は /issue-close（local merge） |
make check）の実行 → i-dev-final-check / i-doc-final-check の責務i-dev-final-check の責務i-dev-final-check / i-doc-final-check の責務issue-close の責務常に注入される変数:
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 正規化済み Issue ID（GitHub 数値または local ID） |
issue_ref | str | 人間可読の Issue 参照（GitHub では #<issue_id>、local では bare ID） |
step_id | str | 現在のステップ ID |
provider_type | str | github / local のいずれか。Step 0 のガード判定に使用 |
git_remote | str | git remote 名（provider.<type>.git_remote config から解決。未指定時のフォールバックは kaji_harness/config.py 定義）。Step 4 の git push -u 引数に使用 |
$ARGUMENTS = <issue_id>
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される（prompt.py 側で provider 別に整形）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。
pr_id / pr_ref / pr_url は本 Skill の Step 4 で kaji pr create の出力から確定する。プロンプトへの自動注入は現時点では行わない（forge 採用先確定時に再評価、draft/design/local-mode/design.md §残課題 参照）。
docs/guides/git-commit-flow.md（kaji の Conventional Commits 運用、--no-ff merge 規約）/issue-start が実行済みであることgit absorb がインストール済みであること（任意）本 Skill は forge provider 専用。最初に provider_type を解決し、
github 以外なら 以降のステップに進まず ABORT verdict を出力して終了 する。
手順:
provider_type の解決（ハーネス注入 → 手動 fallback の優先順）:
PROVIDER_TYPE="${provider_type:-$(kaji config provider-type 2>/dev/null || true)}"
|| true は手動実行で [provider] 不在時に kaji config provider-type が
exit 2 を返しても shell 全体を落とさないため。空文字に縮退する。
判定と verdict 出力:
PROVIDER_TYPE が github → Step 1 に進む
PROVIDER_TYPE が local → 以下の ABORT verdict を そのまま stdout に
出力して以降のステップは実行しない:
---VERDICT---
status: ABORT
reason: |
i-pr is forge-only and cannot run under provider.type='local'.
evidence: |
Pull request concept does not exist in local mode (bare provider).
suggestion: |
Use /issue-close for local merge instead.
---END_VERDICT---
PROVIDER_TYPE がそれ以外（空文字 / 不明値）→ 以下の ABORT verdict を
出力して終了:
---VERDICT---
status: ABORT
reason: |
i-pr could not resolve provider_type.
evidence: |
provider_type was not injected and `kaji config provider-type` failed
(likely missing `[provider]` section in .kaji/config.toml).
suggestion: |
Add `[provider]` to .kaji/config.toml. See docs/cli-guides/local-mode.md.
---END_VERDICT---
重要: ABORT verdict は shell の
exitに任せず agent 自身が stdout に 出力すること。workflow runner はその verdict を読み取ってon: ABORT: endで workflow を終わらせる。補足: workflow 経由で起動された場合は、
kaji runのrequires_provider検証（Phase 4 commit 4）で先に止まるはずだが、user がprovider=local配下で/i-prを直接呼ぶケースに備えて Skill 層でも止める（3 層ガードの冗長性）。
_shared/worktree-resolve.md の手順に従い、 Worktree の絶対パスを取得すること。以降のステップではこのパスを使用する。
また、Issue 本文から > **Branch**: \[prefix]/[issue_id]`` を抽出して prefix を取得する。
cd [worktree_dir] && git status
未コミットの変更がある場合は先にコミットしてください。
workflow 固有の docs 同梱判定は i-dev-final-check / i-doc-final-check 側の責務とする。
cd [worktree_dir] && git absorb --and-rebase
fixup対象がない場合は何も起きません（正常）。
git absorb がインストールされていない場合はスキップ。
cd [worktree_dir] && git push -u [git_remote] HEAD
# stderr は捨てず stdout と分離して取得する（失敗を握りつぶさないため）。
# ``2>&1 | tail -1`` 形式は pipeline exit status が tail 側で 0 になるため使わない。
pr_output=$(cd [worktree_dir] && kaji pr create --base main --title "[prefix]: タイトル ([issue_ref])" --body "$(cat <<'EOF'
## Summary
(Issueの概要を1-2文で)
Closes [issue_ref]
## Changes
- (主な変更点)
## Documentation
- (ドキュメントの更新内容。設計書昇格 / 既存 docs 更新 / なし)
## Test Plan
- [x] 既存テストがパス
- [ ] 新規テストを追加（該当する場合）
- [ ] 手動検証: (必要な場合)
EOF
)")
pr_create_rc=$?
# 成功時のみ最終行を取り出す（失敗時の stdout を URL として誤認しないため）。
pr_url=""
if [ "$pr_create_rc" -eq 0 ]; then
pr_url=$(printf '%s\n' "$pr_output" | tail -n1)
fi
# 失敗 / 形式不一致のいずれかなら abort_reason に診断を入れて分岐する。
# pr_id / pr_ref は abort_reason が空のときだけ確定する（壊れた値を作らない）。
abort_reason=""
if [ "$pr_create_rc" -ne 0 ]; then
abort_reason="kaji pr create exited with rc=$pr_create_rc"
elif ! printf '%s' "$pr_url" | grep -Eq '^https://github\.com/[^/]+/[^/]+/pull/[1-9][0-9]*$'; then
abort_reason="kaji pr create last line is not a PR URL: '$pr_url'"
fi
if [ -n "$abort_reason" ]; then
# 失敗時: 診断を stderr に出し、Step 5 / Step 6 には進まない。
# 後述「失敗時の処理」の ABORT verdict をそのまま stdout に出力して終了する。
printf 'ERROR: %s\n' "$abort_reason" >&2
printf '%s\n' "$pr_output" >&2
# ここから先（pr_id 確定 / Step 5 / Step 6）には進まないこと。
else
# 成功時のみ pr_id / pr_ref を確定する。
pr_id="${pr_url##*/}" # "42"
pr_ref="gh:${pr_id}"
fi
失敗時の処理:
abort_reasonが非空（=pr_create_rc非 0、またはpr_urlがhttps://github.com/.../pull/<N>形式に一致しない）の場合、 以降のステップ（Step 5: Issue 本文への PR 番号追記、Step 6: 完了報告）には 進まないこと。pr_id/pr_refは確定しておらず、未確定値で Issue 本文を 上書きすると壊れた**PR**:行を残す事故になる。その場合は以下の ABORT verdict を そのまま stdout に出力して 終了する:
---VERDICT--- status: ABORT reason: | kaji pr create failed or returned an unexpected output. evidence: | abort_reason="$abort_reason" pr_create_rc=$pr_create_rc (full output captured in pr_output / stderr above) suggestion: | Re-run after addressing the underlying error (auth / rate limit / pre-existing PR for the branch). Check the forge CLI auth status (`gh auth status`) and `kaji pr list --head <branch>`. ---END_VERDICT---
重要: PR body に
Closes [issue_ref]を必ず含めること。これにより GitHub の Development sidebar に正式リンクが作成される。既存 PR を Issue に手動リンクする public API は存在せず、closing keyword が紐付けを自動化できる唯一の手段である。前提条件（repo 設定への依存）: この live closing keyword は、リポジトリ設定 Auto-close issues with merged linked pull requests（Settings → General → Features → Issues）が 無効化されている ことを前提とする。本リポジトリ （apokamo/kaji）では無効化済みのため、PR を merge しても Issue は自動 close されず、 close は
/issue-closeの明示操作で行われる。この設定値は REST / GraphQL から 参照できず API では検証不能 なため、設定を有効化しないこと。skill を他リポジトリ で流用する場合も同設定の無効化が前提となる。 規約の正本:docs/dev/shared_skill_rules.md§ auto close keyword 回避なお当該設定が抑止するのは linked PR 経由の auto-close のみ。commit message 経由（commit が default branch に到達した時点で close される別経路）はカバー対象 と保証されないため、commit body / merge commit message 側の closing keyword 回避規約は維持 される。
Closes+#+ 番号を書いてよいのは PR description の この 1 行のみ。
マージ規約: kaji の merge 規約は
--no-ffonly（squash merge 禁止）。マージ自体は/issue-closeの責務だが、PR タイトルとコミットは Conventional Commits に従うこと（docs/guides/git-commit-flow.md参照）。
PR 作成後、Issue 本文のメタ情報（NOTE ブロック）に PR 番号を追加:
CURRENT_BODY=$(kaji issue view [issue_id] --json body -q '.body')
# **Branch** 行の後に **PR**: [pr_ref] を追加した本文を作成して更新
kaji issue edit [issue_id] --commit --body "..."
以下の形式で報告してください:
## PR作成完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| PR | [pr_ref] |
| URL | [pr_url] |
| コミット整理 | git absorb 実行済み / スキップ |
### 次のステップ
PRのマージ準備ができたら `/issue-close [issue_id]` を実行してください。
/issue-close の責務）---VERDICT---
status: PASS
reason: |
PR 作成を完了した
evidence: |
push と kaji pr create が成功した
suggestion: |
---END_VERDICT---
| status | 条件 |
|---|---|
| PASS | PR 作成成功 |
| RETRY | 再試行で解決可能な失敗 |
| ABORT | 継続不能な失敗 / Step 0 で provider mismatch |
設計書（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 に記録する。