raise-issue

スキル：raise-issue

概要

目的と背景

• 目的： 十分な背景情報を含む ISSUE をローカルの台帳（信頼できる情報源）とインデックスに記録し、担当者を割り当ててディスパッチします。利用可能な場合はリモートトラッカーにもミラーリングし、別のセッション／開発者が /fdk または /propose から取得して対応できるようにします。
• 使用するタイミング：
  • 質問や設計を行うセッションで、GAP や技術的負債を見つけたものの、まだ実装していない場合。別のセッション／開発者が対応できるよう、十分な背景情報を記録する必要があります。
  • 「raise issue」「issue を作成」「この件の issue を作る」「この gap を後で対応できるよう記録」「別の開発者が取得できる issue」。
  • 機能の不足、技術的負債、アーキテクチャに関する質問、プロセス改善、Plan-B／選択肢の確保。
• 対象外： 次の場合には使用しないでください。発生中のバグ／ランタイム障害／リグレッション → orca-issue を使用します（再現を最初に行うゲート）。セッション中にすぐ実行できる作業 → propose で計画してから実装します。プッシュは行いません（/ship の担当です）。

他のスキルとの境界（重複する場合は先に確認）

• orca-issue = 障害（バグ）対応のサイクルで、赤→緑の再現が必須です。raise-issue = 前進のための作業（gap／負債）を記録し、再現は行いません。
• propose = 今回のセッションですぐに実行するための計画です。raise-issue = 意図的に先送りする引き継ぎで、別のセッション／マシン／プロジェクトへ持ち越せます。
• raise-issue が行うのは記録と担当者の割り当てのみです。コード作成や別のブランチの変更は行いません。後任者は /fdk（フレームワークの場合）または /propose（プロジェクトの機能の場合）から作業を開始します。

基本モデル

分類（バグ → orca-issue）→ wiki を検索（R7-f）→ 台帳のドラフト（信頼できる情報源）→ 割り当て → ISSUES.md の行 → [issue-tracker.md の契約に従ってトラッカーへミラーリング] → 台帳をコミット → 確認して終了

入出力の契約

	フィールド	必須？	意味
入力	gap／負債の説明＋証拠	はい	セッションに参加していない人にも理解できるだけの情報
入力	担当者（ユーザー名）	いいえ	不明な場合はミラーリング時に確認
入力	契約 llmwiki/wiki/sources/issue-tracker.md	いいえ	なければ local-markdown のテンプレートから作成
出力	llmwiki/wiki/sources/draft/DDMMYY-<slug>.md	はい	テンプレートに準拠し、OKF frontmatter と ## Origin を含む
出力	llmwiki/wiki/sources/ISSUES.md の行	はい	ID · タイトル · ステータス · 担当者 · トラッカー
出力	リモート issue と tracker 列の URL	トラッカーがある場合	本文から台帳ファイルへのリンクを含む
出力	台帳をコミット（プッシュしない）	はい	issue が別の場所へ持ち越せるのは、リポジトリ経由の場合のみ

ルールと機能

• RULE-01（必須）：記録と割り当てのみ行います。コード作成や別のブランチ／プロジェクトの変更は厳禁です。issue はそのまま持ち越せる状態にします。
• RULE-02（必須）：セッションに参加していない人にも十分な背景情報を記載します。共通の記憶を前提とせず、証拠（レポート／評議会／ADR）を示します。
• RULE-03（必須）：既存 issue との重複を避けるため、先に wiki を検索します（R7-f）。
• RULE-04（必須）：issue ごとにファイルを 1 つ、インデックスに行を 1 つ作成します。複数の issue を 1 つのファイルにまとめてはいけません。
• RULE-05（必須）：ステータスは open／claimed より先に進めません。in-progress／done への変更は、引き継ぎ先のセッションが行います。
• RULE-06（必須）：タスクで必要なものだけを変更します。便乗した変更は行いません。
• 機能：wiki の読み取り、llmwiki/wiki/sources/ 内の台帳とインデックスへの書き込み、ローカルでのコミット、リポジトリの契約で宣言されたアダプターを介したリモートトラッカーへの issue の記録。

失敗時の境界

• バグ／障害の場合 → このスキルではキャンセルし、orca-issue に切り替えます。
• 既存 issue と重複する場合（R7-f で検索）→ issue を作成せず、既存 issue を伝えます。
• リモートトラッカー／CLI がない場合 → 台帳のみのモードで限定的に成功とします。
• メインブランチ上にいて直接コミットできない場合 → issue/<DDMMYY-slug> ブランチにコミットし、その旨を明記します。

手順

主なワークフロー

Step	Type	Inputs	Action	Outputs/exit	Failure/next
W01	judgment	説明	foundation/feature-gap/tech-debt/architecture/process に分類	kind	bug → 停止し、orca-issue
W02	deterministic	kind + キーワード	記述前に wiki を検索（R7-f）	コンテキストのリンク [[...]]	重複 → 停止し、既存 issue を報告
W03	judgment	コンテキスト	テンプレートに沿って draft を作成	ledger ファイル	—
W04	judgment	draft	assignee + dispatch + entry を割り当て、理由を記載	frontmatter が揃う	—
W05	effect	draft	ISSUES.md に行を追加	index	ファイルがない → 作成
W06	effect	tracker の契約	可能であればリモート tracker にミラーリング（B01）	tracker 列の URL	ない → ledger のみ
W07	effect	ledger + index	ledger をコミット（push しない）	commit	メインブランチで禁止 → B02
W08	deterministic	結果	ID + パス + リンク + assignee を確認して停止	報告	—

各ステップの詳細（W01–W08 の真実の情報源）：

1. issue を分類します：foundation | feature-gap | tech-debt | architecture | process。bug の場合は停止し、orca-issue に引き継ぎます。
2. 記述前に wiki を検索します（R7-f）：関連する ADR/concept/draft を探し、重複を避けて正確なコンテキストを記載します。リンク [[...]] を「コンテキスト」セクションに記録します。
3. draft を作成します。下記のテンプレートに沿って llmwiki/wiki/sources/draft/DDMMYY-<slug>.md に作成します。コンテキストは、このセッションに参加していない人が pull してすぐに理解できるだけの十分な情報（issue が存在する理由、根拠、範囲、完了基準）を含めます。
4. 割り当て：assignee（担当する人/agent）+ dispatch（Claude/opencode/human の提案）+ entry（/fdk または /propose から開始）を記入します。選択理由も記載します。
5. index に登録：llmwiki/wiki/sources/ISSUES.md に行を追加します（ファイルがない場合は作成し、ヘッダーは # Issues — ledger local とします）。
6. リモート tracker にミラーリング（可能な場合）：ホスト + CLI を検出します（上の表）。利用可能な場合は → リモート issue を作成（本文に ledger ファイルへの逆リンクを記載）し、URL を tracker 列に記録します。利用できない場合は → スキップし、ledger のみとします。assignee（ユーザー名）が不明な場合は確認します。
7. ledger をコミットします（GH#99）：git add llmwiki/wiki/sources/draft/<DDMMYY-slug>.md llmwiki/wiki/sources/ISSUES.md && git commit -m "issue: <DDMMYY-slug> — <タイトル>"。ledger が真実の情報源となるのは、リポジトリとともに移動する場合のみです。ファイルが untracked のままでは、pull した人には見えず、git log --all も空になります。つまり、issue はまだ存在しません。このステップでは push しません（それは /ship の作業です）。メインブランチにいて直接コミットできない場合は、ブランチ issue/<DDMMYY-slug> を作成してそこにコミットし、その旨を明記します。
8. 確認するだけで、実行はしません：issue ID + ledger のパス + tracker のリンク + assignee を報告します。ここで停止します。実行は引き継ぎ先のセッションが行います。

ブランチ

ID	Kind	Guard	Behavior	Skip / failure	Rejoin
B01	capability_optional	git remote get-url origin + 利用可能な tracker CLI（契約に従う）	リモート issue を作成し、本文に ledger への逆リンクを記載して、URL を tracker 列に記録	利用不可 → ledger のみ；assignee が不明 → 確認	W07
B02	conditional_required	メインブランチにいて直接コミットできない	ブランチ issue/<DDMMYY-slug> を作成し、そこにコミットして、その旨を明記	—	W08
B03	conditional_required	llmwiki/wiki/sources/issue-tracker.md がない	local-markdown のテンプレートから作成；リモート GitHub がある場合は gh によるミラーリングを提案	—	W06

検証と停止

wiki フックは書き込み時に R9（frontmatter OKF）、R2（## Origin）、R5（有効なフォルダー）を確認します。W07 の後、ledger が git log に含まれていることを確認します。W08 で停止します。issue は実行しません。

例

• 成功例：「skill-search にキャッシュがないため issue を起票」→ kind を tech-debt に分類し、重複がないことを検索で確認 → llmwiki/wiki/sources/draft/190926-skill-search-cache.md + ISSUES.md の行 + gh issue create（本文に ledger へのリンク）→ issue: 190926-skill-search-cache — … をコミット → ID + リンクを報告して停止。
• 境界/失敗例：「prod で approve が止まっているため issue を作成」→ 発生中の bug と分類 → 停止し、orca-issue に引き継ぎます（再現を優先）。ledger には記録しません。

参照 — 保存場所 — ローカル台帳が真実のソース、リモートトラッカーはミラー

• Issue = 1つのドラフトファイル：llmwiki/wiki/sources/draft/DDMMYY-<slug>.md（propose と同じ場所にあり、clone するとリポジトリと一緒に移動します。外部トラッカーに依存しません）。これが常に真実のソースです。
• 集中インデックス：llmwiki/wiki/sources/ISSUES.md — issue ごとに1行（id · タイトル · status · assignee · tracker）。MEMORY.md と同様です。（wiki/ ルートではなく sources/ に保存します — R5 のフォルダー構成ルールにより、ルートへの配置は禁止されています。）
• リモートトラッカーがあればミラーリングします（Issues タブへの表示、実際の担当者の割り当て、通知の送信が可能です）：git remote get-url origin と利用可能な CLI から自動検出し、ミラーリングした後、リンクを tracker 列に記録します。台帳が引き続き真実のソースであり、トラッカーは連携用のコピーにすぎません。

参照 — トラッカー — CLI をここにハードコードせず、リポジトリの契約を読む

このリポジトリでの publish/fetch/label/close/claim の方法は、リポジトリごとの契約ファイル llmwiki/wiki/sources/issue-tracker.md（アダプター境界）に記載されています。このスキルが説明するのは意図だけで、契約が方法を定めます。トラッカーを変更する場合（Jira の追加、GitLab への切り替えなど）は、このスキルではなく、その契約を変更してください。[[issue-tracker]] を参照してください。

• 契約ファイルがまだない場合は、テンプレートから作成します（デフォルトは local-markdown：台帳を正本とし、ネットワークは不要です）。リモートの GitHub がある場合は、gh のミラーを追加することを提案します。
• リモート issue の本文には、台帳ファイル（真実のソース）へのリンクを必ず記載してください。URL は tracker 列に記録してください。
• 標準ラベルは5つ（labels 列、デフォルトは needs-triage）：needs-triage · needs-info · ready-for-agent · ready-for-human · wontfix。ヘッドレス CLI にディスパッチできるのは ready-for-agent だけです。ready-for-human は人が対応する作業です。

参照 — wiki フックの検証に最初から対応する（やり直しを3回防ぐ）

llmwiki/wiki/ 内のすべてのファイルには、(R9) 先頭に OKF YAML frontmatter（type/title/status/tags/timestamp/id） · (R2) 出典を追跡する ## Origin セクション · (R5) 有効なフォルダー内への配置（issue は sources/draft/、インデックスは sources/）が必要です。以下のテンプレートには、これら3つすべてが含まれています。

参照 — issue テンプレート（frontmatter + 本文）

---
type: issue
kind: foundation | feature-gap | tech-debt | architecture | process
title: "<một câu>"
status: open            # open | claimed | in-progress | done | wontfix
assignee: <tên/agent>   # ai chịu trách nhiệm
dispatch: <Claude | opencode:<model> | human>
entry: /fdk | /propose  # người nhận mở bằng skill nào
priority: P1 | P2 | P3
tags: [issue, <...>]    # R9 OKF
timestamp: <YYYY-MM-DD>
id: <DDMMYY-slug>
source_session: <mô tả ngắn phiên phát hiện>
---

# Issue: <tiêu đề>

## Vấn đề (một câu)
## Bối cảnh & bằng chứng   (vì sao issue tồn tại; link [[ADR]]/[[concept]]/report/council)
## Phạm vi                 (đụng file/module/dự án nào; universal hay local)
## Không thuộc phạm vi     (chống scope-creep)
## Hướng gợi ý (không bắt buộc)
## Tiêu chí HOÀN THÀNH     (kiểm chứng được)
## Assign & lý do
## Origin                  (R2 — raise bởi ai/phiên nào, nguồn bằng chứng)