メニュー
作業パターンを skill 化すべきか判定する共通スキル。org-retro と org-curate から呼ばれ、 「skill 化推奨 / 候補止まり / curated ノートのまま」の 3 値と根拠を返す。 自動 skill 化はせず、推奨は machine-local な knowledge/skill-candidates.local.md に追記し、 窓口が候補キューが溜まった時点でバッチで人間に問い合わせる二段構え。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
ワーカーClaudeを派遣して作業を委譲する。窓口は司令塔であり、 手を動かす実作業は原則としてワーカーに任せる。 ユーザーから作業の依頼を受けたとき、ファイル編集・実装・調査等の 実作業が発生する場合に発動する。
組織の全ロール（窓口・ディスパッチャー・キュレーター・ワーカー）に必要な Claude Code の許可設定・環境変数を一括で配置・更新するスキル。 「設定して」「許可設定を更新して」「セットアップして」 「permissions設定」「org-setup」等で発動する。
open Issue を triage して「次の仕事候補（N 件 + 推奨 1 件）」を窓口が人間へ提示する。 決定的ツール tools/work_discovery_scan.py を 1 回実行し、その候補 JSON を 設計書 §5.2 の人間可読フォーマットでレンダリングするところで停止する（propose-only）。 起動主体は窓口に限定。手動 / イベント起動のみ（常駐 /loop なし）。 「次の仕事候補出して」「triage して」「次なにやる？」や PR マージ後の proactive next-dispatch で窓口が手動起動する。
蓄積された生の学び（knowledge/raw/）を整理・統合する。 ディスパッチャーが worker クローズ時の閾値チェック (tools/check_curate_threshold.py) 超過でオンデマンド起動した キュレーターから 1 回だけ呼び出される（常駐 /loop は廃止）。 手動で「知見を整理して」と言われたときにも使う。
委譲プロセスの振り返り。ワーカーへの作業委譲が完了したとき、 委譲の進め方自体を振り返り、プロセス改善の知見を記録する。 さらに、完了タスクの作業パターンをwork-skillとして蓄積すべきか判断する。 実作業の技術的な振り返りはワーカーが自動的に行うため、ここでは扱わない。
skill の棚卸し（廃止候補 / 重複統合 / owner 明記チェック）。 状態ベースで発火する: 候補キュー knowledge/skill-candidates.md の pending が 5 件以上、 または .claude/skills/ 配下の work-skill 数（org-* を除く）が 20 以上になった場合のみ実行。 時間ベースの /loop では起動しない（変化の無い日に raw ログを汚す副作用を避けるため）。
| name | skill-eligibility-check |
| description | 作業パターンを skill 化すべきか判定する共通スキル。org-retro と org-curate から呼ばれ、 「skill 化推奨 / 候補止まり / curated ノートのまま」の 3 値と根拠を返す。 自動 skill 化はせず、推奨は machine-local な knowledge/skill-candidates.local.md に追記し、 窓口が候補キューが溜まった時点でバッチで人間に問い合わせる二段構え。 |
| effort | low |
| allowed-tools | ["Read","Edit","Write"] |
作業パターンが新規 work-skill として切り出す価値があるかを 5 シグナルで採点し、 3 値（skill_recommend / candidate_queue / curated_only）で返す。 このスキル自体は skill 生成も人間問い合わせもしない — 判定専用。
判定基準が org-retro と org-curate の 2 箇所に分散すると必ず乖離するため。 このスキルを single source of truth として双方から呼ぶ。
呼び出し元は以下の構造を渡す:
context: post_retro | curation
pattern_name: <kebab-case の候補 skill 名>
summary: <何を再利用できるかの 1-2 文>
task_ids: [<関連タスク ID>, ...] # optional。post_retro は通常 1 件、curation は空配列可
raw_files: [<knowledge/raw/ のファイルパス>, ...]
steps_outline: # 主要手順の箇条書き
- <step 1>
- <step 2>
- ...
trigger_description: <このパターンが適用される状況を言語化できるか / できないなら空>
decision_criteria: <判断基準や閾値があるか / できないなら空>
output_format: <成果物の再利用可能フォーマット / なければ空>
必須は context / pattern_name / summary / raw_files / steps_outline のみ。
task_ids は raw ノートの標準スキーマに含まれないため curation 文脈では空配列でよい。
trigger_description / decision_criteria / output_format は採点対象そのもので、
空のまま渡すと該当シグナルが 0 点になる。
references/signals.md の定義に従い、各シグナル 0 点 / 1 点で採点する。
| シグナル | 1 点の条件 |
|---|---|
| raw_reappearance | 同パターンの raw 記録が 3 件以上ある |
| steps_complexity | steps_outline が 3 項目以上かつ非自明な判断を含む |
| trigger_articulable | trigger_description が具体的かつ検索可能な語彙で書ける |
| criteria_articulable | decision_criteria に定量閾値または分類ルールがある |
| reusable_output | output_format が他タスクで転用可能な構造を持つ |
詳細な判定手順は references/signals.md を参照。
| 合計点 | 判定 | 意味 |
|---|---|---|
| 3 点以上 | skill_recommend | skill 化推奨。候補キューに追加 |
| 2 点 | candidate_queue | 候補止まり。raw に追記し次回の raw_reappearance を待つ |
| 1 点以下 | curated_only | curated ノートのままで十分 |
閾値を 3 点に置いた根拠: org-retro 旧版の「2 つ以上で推奨」よりやや保守的にし、 候補止まり層を明示的に作ることで、「skill 検索面のノイズ」を予防する。
以下の構造を呼び出し元に返す:
decision: skill_recommend | candidate_queue | curated_only
score: 0-5
matched_signals: [<1 点が付いたシグナル名>, ...]
rationale: <1-2 行の根拠文>
proposed_skill_name: <pattern_name> # skill_recommend / candidate_queue のみ
knowledge/skill-candidates.local.md（machine-local な実エントリ用ファイル。Issue #755）に
以下のエントリを追記する。candidate_queue / curated_only の場合は書き込まない。
追記先は必ず
.local.md（公開ファイルではない）: 公開のknowledge/skill-candidates.mdは エントリフォーマット定義のみを保持し、エントリ一覧は常に空に保つ（operator-private な 候補が OSS リポジトリに載らないため。knowledge/skill-candidates.local.mdは .gitignore 済み）。 フォーマット定義・status 語彙・運用ルールは公開ファイル冒頭が一次参照で、実エントリだけが.local.mdに入る。.local.mdが未作成なら見出し## エントリ一覧を持つ最小ファイルを新規作成して追記する。 閾値カウント（tools/check_curate_threshold.py//skill-audit）は両ファイルを合算して読む。
### {YYYY-MM-DD} {pattern-name}
- **判定スコア**: {score}/5
- **該当シグナル**: {matched_signals}
- **根拠**: {rationale}
- **関連タスク**: {task_ids、curation 文脈では空 "[]" 可}
- **関連 raw ファイル**: {raw_files}
- **呼び出し元**: {context}
- **提案 skill 名**: {proposed_skill_name}
- **status**: pending
- **決定日**: 未定
- **却下理由**: （status が rejected に遷移したとき記入、それ以外は省略）
- **統合先**: （status が merged-into-* のとき記入、それ以外は省略）
書き込み後も呼び出し元には出力 YAML を返す（キュー追記は副作用として完了）。
このスキルは判定とキュー追記だけを行う。以降のアクションは呼び出し元の責務:
org-retro（post_retro）:
skill_recommend → キュー追記のみ（Step 4 で実施済み）。人間への即時提案はしない。
バッチ問い合わせは窓口が pending ≥5 で実施する
（一次参照: knowledge/skill-candidates.md 冒頭、Issue #68 方針。/skill-audit 発火時も同様）candidate_queue → raw/ に技術的知見のみ記録curated_only → raw/ への記録で十分（報告不要）org-curate（curation）: decision 値に関わらず通常の Step 3 で curated/ 統合 + Step 4 で <!-- curated --> 付与を行う（skill 化と curated ノート化は両立）。
skill_recommend → 候補キュー追記のみ（skill 側で自動書き込み済み）。
人間への問い合わせは窓口の役目で、キュー閾値 N=5 に達したら窓口が行うcandidate_queue → 追加アクションなし（次回の raw_reappearance を待つのはシグナル上の話であり、raw を未整理のまま残すことではない）curated_only → 追加アクションなし同一 pattern_name が既に knowledge/skill-candidates.local.md に status: pending で
存在する場合、Step 4 では新規エントリを追加せず既存エントリの 関連タスク・関連 raw ファイル を
追記マージする（重複チェックの読み先も実エントリを持つ .local.md。公開ファイルは常に空）。
status が approved / rejected / merged-into-* になっているエントリは
履歴として保持し、新しいエントリを別日付で追加する（過去の却下理由を失わない）。
status が deferred（人間が提示を受けて見送った候補）になっているエントリは、Step 4 では
再追加も pending への差し戻しもしない（見送りは確定として扱い、同じ候補を蒸し返さない。Issue #753）。
deferred は閾値カウント対象外・再問い合わせ対象外である。人間が明示的に再検討したいときのみ
新しい日付で別エントリを起こす。
knowledge/raw/ の記録で十分で、
本スキルの入力 5 項目（特に steps_outline と trigger_description）が埋まらない