adopt-keelson

Adopt keelson

規律あるイシュードリブンフロー — frame → plan → implement → open-change → gate → close、戦術的自律性（エージェントが機械的な動きを行う）と戦略的ヒューマンループ（元の設計、計画、戦略に触れる動きがあった瞬間にエスカレーションする）を備えたフロー — を この リポジトリに、その トラッカーとSDLCに合わせて移植します。

ターゲットリポジトリには以下の2つを生成します：

1. AGENTS.md — スキル群が参照する、質問形式で構成された基盤。
2. ライフサイクルスキルパック — 採用されたアイデアを、リポジトリ独自のスキルとして平易な言葉で記述（アクションを命名し、AGENTS.md からトラッカーバインディングを読み取る。ハードコードはしない）。

必要なものはすべてこのスキルフォルダにあります：templates/AGENTS.client.md、templates/lifecycle/*.md、references/tracker-notes.md。埋めるだけで、発明は不要です。

1 · インタビューの進め方

これは設定セッションであり、単なる yes/no ではありません。 想定ラウンド数は 約8～20回 — シンプルなリポジトリでは少なく、複雑なものでは多くなります。フローが曖昧でなくなるまで必要なだけラウンドを使ってください。急がないでください。その報酬は、ユーザーが実際に同意した AGENTS.md です。

• 1ラウンド1トピック。 参照フローが何をするかを説明し、そのリポジトリでのユーザーに決定させます。重要な判断を黙ってデフォルト化して先に進まず、選択肢を表面化させ、明確な承認を得てから進めてください。
• ユーザーがフローを所有します。 keelson のデフォルトは出発点であり、答えではありません。ユーザーが迷っている場合は、保守的な選択肢を提示し、再検討するフラグを立てて、埋もれさせないでください。
• 提案する前に発見します。 まず発見ラウンドを実施し、何を持っているか、何が不足しているか、何を望んでいるかを学び、そのギャップに合うアイデアだけを提案してください。
• 記録しながら進め、最後に確認します。 最終ラウンドでは、すべての決定を再現し、1回の承認を得てから書き込みます。

2 · ラウンド

最初に発見、次に各ピラーごとのラウンド、発見で明らかになったオプショナルファミリー、その後標準と納品、最後に確認。各ラウンドは設定するスキルと埋めるプレースホルダー（§3）を指定します。シンプルなリポジトリではラウンドを統合し、複雑なものでは分割してください。

発見

• D1 · SDLCマップ — 現在どのような納品段階/ピラーが存在するか（インテーク→トリアージ→設計→実装→レビュー→QA→リリース→運用）？どの部分が堅牢で、アドホックまたは欠落しており、keelson に確立または強化させたいか？この情報が後に提案するアイデアを左右します — 処方する前に聞いてください。
• D2 · トラッカーと用語 — トラッカー、作業項目/変更/ボードの呼称、{{status_field}} の列と各々が対応するライフサイクルの瞬間。
• D3 · リポジトリとブランチ — {{default_branch}}、{{branch_pattern}}、{{isolation}}（worktree またはブランチのみ）、{{merge_style}}、モノレポ vs ポリレポ。

ピラー — 各々の動作を決定する（スキルを採用し、その規約をキャプチャする）

• P1 · インテーク/フレーミング（frame-the-change） — すべての変更はトラッキングされた {{issue}} として開始されるか？含むべき内容（コンテキスト/スコープ外/受け入れ条件）は？
• P2 · 計画と計画の保存場所（plan-the-work） — 計画はいつ必要か？またどこにファイリングされるか：{{issue}} のコメント、リポジトリ内の設計ドキュメント、Wikiページ、または {{change}} の本文？→ {{plan_location}}。
• P3 · ドキュメントと決定記録 — ドキュメントの保存先：リポジトリ内 {{docs_root}}、外部Wiki（例：Confluence/Notion）、または混合 → {{docs_system}}；ADR の使用有無と保存場所（{{adr_dir}}）？ドキュメント更新ルール（どの変更がどのドキュメントを、同じ {{change}} 内で更新すべきか）。
• P4 · 実装の規律（implement-the-change） — コード＋ドキュメント＋テストを一緒に行う？ハードコード禁止（設定に出す）？スコープを {{issue}} に限定？
• P5 · 変更の公開（open-the-change） — {{change_title_format}}、本文に {{issue}} をリンク、{{size_cap}} ＋ {{oversize_label}}、セルフレビュー。
• P6 · CI品質ゲート（tune-gates G1を介して） — {{quality_gates}}；CIが所有（公開前に事前実行しない）、Red-CIデバッグ中はローカル検証の例外あり。
• P7 · ステータスフロー（track-status） — ステータスがいつ誰によって移動されるか？ボード vs ラベルのどちらを信頼情報源とするか？証拠を添えてクローズのみ。
• P8 · ピックアップルール（pick-next-work） — 次の {{issue}} を主張するためのバックログ/優先順位付け順序。

オプショナルファミリー — D1で明らかになったもののみ提案；ユーザーとともに採用またはスキップ

• O1 · マイルストーン/リリース（close-a-milestone） — 出口基準のある段階/マイルストーン/エピック/スプリント？リリースモデル？→ {{milestone}}。
• O2 · 検証ゲート（tune-gates G2を介して） — レビュー可能な成果物 → review-gate；正規の {{source_of_truth}} → source-change-gate と source-sync-gate のペア；複数の {{targets}} → parity-gate。tune-gates がゲートラウンド、選択ルール、テンプレートを所有 — このピラーでそれを実行し、統一言語で採用されたセットを返す（§4）。
• O3 · ドキュメントの一貫性とソース更新 — sync-docs（バッチ後の調整）と update-source-of-truth（信頼情報源の変更をループに流す）。

規律 — ヒューマンループ

• H1 · 戦術的 vs 戦略的境界 — 核心。 ユーザーに線を引かせる：エージェントが自律的に行う動作と、承認を得るためにエスカレーションが必要な動作。
• H2 · 不確実性と優先順位（respond-to-uncertainty） — 曖昧さとドキュメントの競合の解決；質問 vs 保守的に進む。
• H3 · フォローアップ、先行事例、運用（carve-out-followup、check-prior-art、automate-or-runbook） — それぞれ採用するか？

標準と納品

• S1 · エンジニアリング標準 — templates/AGENTS.client.md → Engineering standards に埋め込まれた InnoVestrum 標準を提示；そのまま採用、トリミング、または拡張。
• S2 · スキルの配置場所 — Claude の .claude/skills/、Codex の .agents/skills/、または両方；既存の AGENTS.md がある場合は上書きせずマージ。

確認

• C1 · 再生と確認 — すべての決定、採用 vs スキップしたアイデア、ユーザーが開いたままにしたギャップを要約。最後の承認を得てから、埋めて書き込む。

3 · プレースホルダー（埋めるものだけ）

リポジトリ規約のみがプレースホルダーであり、アクション動詞はそのまま残します。すべてを解決し、未記入のままにしないでください。

• 用語 — {{tracker}}、{{issue}} / {{issues}}、{{change}}
• ボード — {{board}}、{{status_field}}、使用列：{{status.planning}} · {{status.in_progress}} · {{status.in_review}} · {{status.done}} · {{status.blocked}} · {{status.deferred}}（未使用は省略）
• ブランチ/変更 — {{default_branch}}、{{branch_pattern}}、{{change_title_format}}、{{merge_style}}、{{isolation}}
• ドキュメント/決定 — {{docs_system}}（リポジトリ内 / Wiki / 混合）、{{docs_root}}、{{plan_location}}、{{adr_dir}}（いずれも none 可）
• スコープ/ゲート — {{size_cap}} + {{oversize_label}}、{{milestone}}、{{source_of_truth}}、{{target}} / {{targets}}、{{quality_gates}}（いずれも none 可）

4 · 埋めて書き込む

1. クライアント AGENTS.md — templates/AGENTS.client.md をレンダリング：すべてのプレースホルダーを置換し、採用されたセクションのみ残し、S1の標準を埋め込み、references/tracker-notes.md から選択されたトラッカーのセクションを ## Tracker notes の下に折り畳む。リポジトリルートに書き込む（または既存ファイルにマージ）。
2. ライフサイクルスキル — 採用された各アイデアについて、templates/lifecycle/<name>.md（プレースホルダー + frontmatter 説明）をレンダリングし、各クライアントスキルディレクトリに <dir>/<name>/SKILL.md として書き込む。ゲートスキル + §8/§3 基盤は tune-gates §4 に従う — その選択（P6/O2）がどのゲートを採用するかを決定し、それらのみをレンダリング。
3. スキップされたアイデア → スキルを書き込まず、その AGENTS.md セクションも残さない。

5 · 検証して引き渡す

• 書き込まれたファイルから {{ をgrep — ゼロの未解決プレースホルダー。
• 採用された各アイデアに AGENTS.md セクションと書き込まれたスキルの両方が存在すること；各書き込まれたスキルの {{status.*}} / {{change}} / {{plan_location}} などがインタビューと一致すること。
• 要約：トラッカー、採用されたSDLCピラー vs ユーザーに委ねたもの、書き込まれたファイル、再検討のフラグが立っている決定があればその旨。新しい AGENTS.md を最初に読むよう指示。

注意点

• ユーザーに決定させよ；重要な判断を黙ってデフォルト化するな。 用語、ステータス列、計画やドキュメントの保存場所、戦術的/戦略的境界 — これらはユーザーが設定するもの。黙ってデフォルト化された AGENTS.md は誰も同意していないもの。
• パックは選択可能、特にゲート。 採用されたアイデアのみ書き込め；正規のソースがなくターゲットが1つのバックエンドリポジトリは、ソースゲートとパリティゲートを完全にスキップする。ゲートの選択ルール — および「nullバインディングのゲートを決して書くな」という罠（{{source_of_truth}} が none の場合は source-change/source-sync-gate なし；1つの {{target}} ではパリティなし） — は tune-gates に存在する；それを適用し、ここで再導出しない。
• トラッカーのコマンドをスキルに書き写さない。 アクションを命名せよ；バインディングは AGENTS.md → Tracker notes に一度だけ存在する。gh/glab をスキルに書き込みそうになったら？止めて — それをトラッカーノートに押し込め。
• 標準は基盤であり、飾りではない — パックはコード品質のために標準を参照する；スキル内でそれを再記述しない。
• 書かれたすべての行を黄金律に従わせよ（keelson AGENTS.md）：ギャップ、注意点、ポインタのみ。PRの開き方を一般的に説明するスキルは誤り；ステップを命名し、後は委ねよ。