القائمة
Issue作成とラベル付与を行う。開発ワークフローの起点。review-ready の共通・type別観点を満たす本文生成を誘導する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
設計書（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 に記録する。
| description | Issue作成とラベル付与を行う。開発ワークフローの起点。review-ready の共通・type別観点を満たす本文生成を誘導する。 |
| name | issue-create |
GitHub Issue を作成し、適切なラベルを付与する。
本スキルは issue-review-ready（.claude/skills/issue-review-ready/SKILL.md の共通・type 別チェック観点）で RETRY にならない水準の本文を生成することを目標とする。単なるテンプレ埋めではなく、「何を」「どこに」「なぜ」「何が満たされれば完了か」「その根拠」を明示できるまで対話で不足を補う。
| タイミング | このスキルを使用 |
|---|---|
| 新機能・バグ修正・リファクタの着手前 | ✅ 必須 |
| 既存Issueがある場合 | ❌ 不要 |
ワークフロー内の位置: create → (grill-me: 任意・明示起動) → review-ready → start → ...
$ARGUMENTS = <title> [type] [description]
title (必須): Issue タイトルtype (任意): feat / fix / refactor / docs / test / chore / perf / security（デフォルト: feat）description (任意): 詳細説明。省略時は対話で収集。参照:
docs/rfc/github-labels-standardization.md（GitHub Labels 標準化ドキュメント）
| type | ラベル | 用途 |
|---|---|---|
feat | type:feature | 新機能追加 |
fix | type:bug | バグ修正 |
refactor | type:refactor | リファクタリング |
docs | type:docs | ドキュメント |
test | type:test | テスト追加・改善 |
chore | type:chore | 雑務・依存の掃除 |
perf | type:perf | パフォーマンス改善 |
security | type:security | セキュリティ対応 |
$ARGUMENTS から title, type, description を取得する。
type が未指定なら feat をデフォルトとするdescription が未指定または情報不足なら、ユーザーに対話で詳細を確認する本文起草の前に、以下が揃っているかを確認する。不足している場合は 対話で補う、またはコマンド実行・ファイル閲覧で事実を確認する。推測で埋めない。
| # | 観点（review-ready） | 収集する情報 |
|---|---|---|
| 1 | 構造の完備 | 概要・目的・完了条件の3セクションを埋める材料 |
| 2 | 概要の具体性 | 「何を」「どこに」: 対象モジュール / ディレクトリ / ファイルパス、対象ドキュメントパス |
| 3 | 目的の根拠 | 背景・動機: 既存コード/ドキュメント/運用で困っている具体的事象 |
| 4 | 完了条件の検証可能性 | 客観的に判定可能な条件（CLI 実行結果、ファイル存在、テスト通過、docs 整合等） |
| 5 | 1次情報の明示 | 外部 URL、docs/ パス、関連 Issue/PR 番号、ログ、CLI 出力のいずれか |
| 6 | 記述間の整合性 | 概要・目的・完了条件が互いに矛盾しないこと |
| 7 | 作業スコープの推定可能性 | dev: 対象ファイル/ディレクトリ/技術スタック。docs-only: 対象ドキュメントパスまたは領域 |
| 14 | workflow 内判定可能性 | RETRY して環境非依存で同じ結果を得られる条件と、merge・実機適用・外部応答後の確認を分離する材料 |
| 15 | 重要判断の着手可能性 | 共通正本に従い、source of truth の指定、人間が決定済みの方針と出典、未決の重要判断と可逆性を収集する。one-way door は起票時に人間へ確認 |
補強のヒント:
make check 通過」）Step 1 で確定した type に応じて、以下のテンプレートファイルを Read ツールで読み込み、その本文構造に従って Issue 本文を組み立てる。
| type | テンプレートファイル |
|---|---|
feat | .claude/skills/issue-create/templates/issue-feat.md |
fix | .claude/skills/issue-create/templates/issue-bug.md |
refactor | .claude/skills/issue-create/templates/issue-refactor.md |
docs | .claude/skills/issue-create/templates/issue-docs.md |
canonical 外 type のフォールバック: test / chore / perf / security を受け取った場合は issue-feat.md を使用する（dispatch 方式の制約）。
dispatch 方式: パターン A（Read ツールによる静的選択読み）を採用。SKILL.md は薄く保ち、テンプレート本文は外部ファイルで管理する。
各テンプレートには「本文の雛形」に加えて、type 特有のチェックポイント（例: feat のユースケース、bug の OB/EB、refactor の測定指標、docs の対象パス）が記載されている。テンプレート末尾の「チェックポイント」を対話で必ず確認してから本文を確定する。
共通の追記ルール（全 type 共通）:
draft/design/issue-<issue_id>-<slug>.md を参考欄に予告してもよい### 重要判断 サブセクションを設けて本文へ必ず記録する。
記録しないと creation の対話にしか残らず、issue-review-ready は Issue 本文と人間コメントしか
検査しないため（issue-review-ready/SKILL.md Step 1）provenance が失われ、RETRY/ABORT か
provenance 欠落のまま進行する。記録形式は 判断 / 方針 / 出典（人間決定の参照）/ 未決事項 とし、
判断対象がなければ - 該当なし と確認根拠を書く。判断軸の正本は
_shared/critical-decision-checklist.md## 完了条件 の末尾に ### ワークフロー完了後の確認項目 を置く。workflow を RETRY して
環境非依存で同じ結果を得られない merge 後・実機適用後・外部応答後の確認だけをここへ分離する- なし とし、未チェックの placeholder を残さないdocs/dev/workflow_completion_criteria.md § workflow 内完了条件と事後確認の分離kaji issue create --title "[title]" --body "[body]" --label "[label]"
Issue 作成後に .claude/skills/grill-me/SKILL.md の「要否門番」と同じ基準で、
workflow 開始前の interview が必要かを判定する。one-way door を含みうる重要な Issue なら
/grill-me [issue_id] を推奨し、軽微で不要なら /issue-review-ready [issue_id] を案内する。
grill-me を自動起動せず、issue-create 内で interview を代行しない。
以下の形式で報告すること。
## Issue 作成完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| タイトル | [title] |
| Type | [type] |
| ラベル | [label] |
| URL | [issue-url] |
### 次のステップ
- grill-me 推奨: `/grill-me [issue_id]` を明示起動し、完了後に `/issue-review-ready [issue_id]`
- grill-me 不要: `/issue-review-ready [issue_id]`
実行完了後、以下の形式で verdict を出力すること。
---VERDICT---
status: PASS
reason: |
Issue 作成成功
evidence: |
Issue [issue_ref] を作成、ラベル付与済み
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | Issue 作成成功 |
| ABORT | 作成失敗、または review-ready の観点に必要な素材が対話でも揃わない |