Menu
作成手順「ringi」（self-evolving-agent から自動同期）: Procedure: ringi
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
全 Claude セッションをスキャンし、ユーザーが何をしているかを分析して、 スキル・MCP プラグイン・エージェント・CLAUDE.md のどれに最適化すべきかを分類し、 具体的な改善提案（優先度・実装難易度・推奨アクション付き）を生成する。 Use when the user wants to analyze their Claude usage patterns, or when asked to "scrape sessions", "what do I do with Claude", or "what should be a skill vs agent vs claude.md".
PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。
Claude Code のトークン使用量・コストの確認と分析を行う。日次・月次レポートの表示から 高コスト要因・キャッシュ効率の分析、削減提案まで（表示だけの軽量モードあり）。 Use when you need to check today's or this month's token usage and cost, or to analyze Claude Code costs and get reduction suggestions. Triggers on: "今日のコスト", "今月のコスト", "トークン使用量", "ccusage", "コスト分析", "コスト削減".
/compact の前に、圧縮の要約から抜け落ちやすい「判断構造」と「セッション状態」を tmp/compact-state/latest.md に固定フォーマットで保存する。 Use when you are about to run /compact, when the user says "compact する前に", "compact-prep", "コンテキストを圧縮したい", or when context usage is high and compaction is imminent. Do NOT use for cross-session handover documents (use handover) — compact-prep is for surviving in-session compaction, not for ending a session.
現在のセッションの作業内容を次のセッションへ引き継ぐための引き継ぎドキュメントを生成する。 Use when the user asks to summarize the session for handover, says "引き継ぎ", "次のセッションに渡して", "context をまとめて", or when a session is ending and you think it would help to create a handover document for continuity. Also use when you are about to run out of context and want to preserve progress.
作成手順「1on1-prep」（self-evolving-agent から自動同期）: 1on1 準備手順（ EM 版）
| name | ringi |
| description | 作成手順「ringi」（self-evolving-agent から自動同期）: Procedure: ringi |
用途: 予算・採用・外部委託・方針変更に関する上位決裁が必要なとき。
workspace/ringi-YYYYMMDD-[テーマ略称].md に作成し、決裁者へ直接送付できる状態で出力する。
タイプが変わると必須セクションの比重と読み手の関心が変わる。
| タイプ | 代表例 | 追加で比重が増すセクション |
|---|---|---|
| 予算稟議 | ツール導入・外部サービス契約 | §3 費用概算（変数式）・§6 代替案比較・コスト上限目安 |
| 採用稟議 | 正社員・業務委託の新規採用 | ポジション要件・採用コスト・組織への影響（FTE 変化） |
| 組織変更稟議 | チーム再編・役割変更 | 変更前後の権限関係・移行スケジュール・影響者一覧 |
| 方針変更稟議 | 技術方針・運用ルール変更 | 変更影響範囲・ロールバック条件 |
「誰に上げるか」によって深さ・補足の量が根本的に変わる。
| 確認項目 | 問い |
|---|---|
| 決裁者 | 誰が最終承認するか（本部長 / CTO / CEO） |
| 閲覧者に非技術者が含まれるか | YES → 技術用語に一文の平易な補足を付ける（Lesson D） |
| 決裁に必要な情報が揃っているか | 費用・期待効果・リスクの三点が揃っていれば着手可能 |
非技術の決裁者を含む場合（稟議ではほぼ常に該当）: 技術コンポーネントの説明欄に「非技術者向け補足」列を必ず追加する（Lesson D）。
補足の書き方: 「= [平易な一文で仕組みを説明]」 例: 「= PR を作成すると AI が差分を解析し、初期レビューコメントを数分以内に自動投稿する仕組み」
1 文テスト: 「何のために・いくらで・誰に承認を求めているか」を 1 文で言えなければ、本文を書き始めてはいけない。
合格例:
不合格例（着手禁止）:
1 文を書いてから §1〜§7 の本文に進む。
起案日 = 今日の日付（Lesson C：プレースホルダーにしない）
希望決裁日は「展開開始日 − バッファ日数（最低 3 営業日）」で逆算し、python3 で平日か確認する:
# 希望決裁日が平日か確認（暗算禁止）
python3 -c "
from datetime import date
d = date(YYYY, M, D)
weekday = d.weekday() # 0=月 ... 4=金 5=土 6=日
print(d, d.strftime('%A'), 'WEEKDAY ✅' if weekday < 5 else 'WEEKEND — 要移動')
"
土日に当たる場合は直前の金曜か翌週の月曜に移動し、インライン注記を添える（例: 「金 [YYYY-MM-DD] 中 — 土曜 [YYYY-MM-DD] からの繰り上げ」）。
メタデータ表テンプレート:
| 起案日 | 起案者 | 決裁者 | 希望決裁日 |
|---|---|---|---|
| [今日の日付（曜日）] | [氏名（メールアドレス）] | [決裁者氏名] 様 | **[YYYY-MM-DD（曜日）] 中** |
3 パートを順番に書く:
現状の課題（なぜ今これを上げるか・放置するとどうなるか）
↓
現状の取り組み（すでに検証・着手していることがあれば先に示す）
↓
目的（何を達成するためにこの稟議を上げるか）
「現状の取り組み」がある場合、決裁者の「新規リスク」への懸念を先に解消できる。 「パイロット検証済み」「技術検証済み」の事実があれば必ず明示する（承認速度に大きく影響する）。
| コンポーネント | 概要 | 非技術者向け補足 |
|---|---|---|
| [名称] | [1〜2 行の説明] | = [平易な一文で仕組みを説明] |
対象スコープ（誰が・どのリポジトリが・どの組織が）と展開スケジュール（フェーズ + 日付）も記載する。
絶対にやってはいけない: 費用欄を空欄や「要確認」にする。変数が未確定でも変数定義 + 計算式 + 参考レンジで表現し、決裁者が変数を代入するだけで全体コストを把握できる形にする。
> 変数: **N** = [変数の定義（例: 追加ライセンス数）] / **M** = [変数の定義（例: 月間 PR 件数）]
| 項目 | 算式 | 参考試算 |
|---|---|---|
| [費目 A] | ¥X/[単位] × N | N=10 → ¥Y / N=20 → ¥Z |
| **月額合計** | **¥X×N + M×¥Y + α** | N=10, M=500 → **¥XX,000** / N=20, M=1,000 → **¥YY,000** |
必須: コスト上限の目安を一文添える。例: 「API 費が月 ¥XX,000 超過時はフィルターを自動適用して規模を制御する」。決裁者が「青天井リスク」を感じると承認が遅れる。
定量目標は「指標 / 現状 / 目標 / 計測方法」の 4 列で書く（計測できない目標は定量に含めない）:
| 指標 | 現状 | 目標 | 計測方法 |
|---|---|---|---|
| [指標名] | ベースライン or 実測値 | [数値目標] | [誰が・どのツールで測るか] |
現状値が未計測の場合は「ベースライン」と書き、計測方法を目標の一部に含める。
| リスク | 深刻度 | 対策 |
|---|:---:|---|
| [リスク内容] | 🔴 高 / 🟡 中 / 🟢 低 | [具体的な対策] |
最低 3 件。決裁者が想像しやすい懸念（セキュリティ / 現場の反発 / コスト超過）を意識的に含める。「対策」は「モニタリングする」で終わらず、発動条件と初動アクションまで書く。
採用案の説明より却下した理由の方が価値が高い。決裁者が「他の手はなかったのか？」と聞かなくて済む形にする。
| 案 | 月額概算 | 採否 | 採否の根拠 |
|---|---|:---:|---|
| **A. 本提案** | [算式] | ✅ 採用 | [なぜ本提案を選んだか] |
| B. [代替案名] | [概算] | ❌ 却下 | [なぜ却下したか。今の制約で見送った場合はその制約を明記] |
| C. 現状維持 | ¥0 | ❌ 却下 | [なぜ何もしないではいけないか] |
再検討トリガーを必ず書く（Lesson K）: 「将来この条件が変わったら B を再検討する」を記録することで、同じ議論が再燃するコストをゼロにする。
**希望決裁日: [YYYY-MM-DD（曜日）中]**
理由: [展開開始日] から Phase 1 に着手するため。
**承認後の初動（承認翌週中）:**
1. [具体的な初動アクション 1]
2. [具体的な初動アクション 2]
3. [具体的な初動アクション 3]
| | 氏名 | 確認・決裁 | 日付 |
|---|---|---|---|
| 決裁者 | [決裁者氏名] 様 | | |
| 起案者 | [氏名] | ✍️ | [今日の日付（曜日）] |
成果物の冒頭（Subject 行の直後・本文の前）に、未確定値の一覧を番号付きで置く。
> **送信前に埋める項目（優先順）:**
> 1. `[決裁者氏名]` — ヘッダー表と §7 承認欄の 2 箇所
> 2. `[変数 N の実数値]` — [確認先（例: 情シス経由で現契約席数を確認）]
> 3. `[X% の実測値]` — [確認先（例: パイロットの実測データから記入）]
> 4. [その他の未確定項目]
> **Subject: 【決裁依頼】[テーマ] — [YYYY-MM-DD（曜日）] 中にご決裁をお願いします**
取り込み経緯: 2026-06-28 の auto-kaizen セッション。指定 10 ドメイン中、稟議だけが eval-ringi.md（eval）あり × procedures/ringi.md（手順）ゼロという唯一の構造的空白だった（前回 2026-06-27 の code-review-execution.md 追加で他の空白はすべて埋まった）。Lesson A・B・C・D・K のすべてが稟議文脈で発動するにもかかわらず未統合だった点を、稟議固有の実行フローとして体系化した。