repo-prep

リポジトリの準備

公開前にリポジトリで必要となる法務、メタデータ、コミュニティ、コンプライアンス関連のファイルを、中央の作者プロフィールに基づいて一貫して対話形式で作成します。リポジトリごとの作者の選択も尊重します。

使用する場面

• GitHub への公開やオープンソース化に向けて、新規または既存のリポジトリを準備するとき。
• LICENSE、NOTICE、AUTHORSHIP、README のセクション、パッケージのメタデータなど、不足している項目を追加するとき。
• AI を活用した作業について、根拠を示せる AUTHORSHIP 記録を作成するとき（ウィザード）。
• コミュニティ向けドキュメントや .github/ テンプレートを追加するとき。
• リポジトリに適用される EU／ドイツのコンプライアンス上の義務を確認するとき。

運用の原則

• 決めつけず、対話する。 ユーザーに選択肢を確認します（以下の質問の仕方を参照）。作者プロフィールの defaults を尊重しつつ、リポジトリごとに確認します。テンプレートをただ無条件に書き出してはいけません。
• 冪等性を保つ。 既存のファイルを検出し、スキップするか更新します。黙って上書きしてはいけません。書き込み前に実行計画を提示します。
• 主張より根拠を重視します（特に著作者情報について）。リポジトリを調べて事実を集めます。
• 外部に影響する操作（gh 経由の操作やプッシュなど）を実行する前に確認します。
• ユーザーの git の慣習に従います。依頼された場合に限りコミットします。

質問の仕方（インタビューの手段）

インストールされている場合は cenno を優先します。見やすいパネル、進捗ドット、音声入力を利用できます（考察を引き出す著作者情報の回答に最適です）。

1. 実行ごとに cenno を一度検出します： ToolSearch で mcp__cenno__ask_sequence を検索します。ツールが解決できた場合は cenno を使い、それ以外の場合は AskUserQuestion（選択肢）または通常の会話形式のプロンプト（自由記述）に切り替えます。
2. cenno を使う場合：
   • 複数の質問をするフロー（著作者情報のウィザード、範囲の選択など）には、flow: "question" を指定して mcp__cenno__ask_sequence を使います。進捗ドットは自動入力されます。
   • 単一の質問には mcp__cenno__ask_user を使います。
   • 選択肢から一つ選ぶ場合は input.kind: "choice" と choices、はい／いいえで答える場合は "confirm"、考察を促す自由記述（判断、見解、方向性、アートディレクション）には "voice_text"、評価には "scale" を使います。
   • 返された JSON（{answers: [...]}／{answer, ...}）を解析します。{answered: false}（タイムアウト）の場合は、再試行するか別の方法に切り替えます。
3. cenno が必要とされていてもインストールされていない場合は、cenno スキルからセットアップできることを伝えます。処理は中断せず、適切に別の方法へ切り替えます。

中央の作者プロフィール（信頼できる唯一の情報源）

本人情報、プロモーションリンク（「広告」）、デフォルト設定は ~/.config/personal-os/repo-prep/profile.toml に保存されます（REPO_PREP_PROFILE で変更できます）。

1. 初回実行時にファイルが存在しない場合は、assets/templates/profile.example.toml をそこにコピーし、ユーザーが入力できるよう案内します（名前、メールアドレス、github、url、プロモーション対象のプロジェクト、デフォルト設定）。このファイルには、この作者向けの初期値が設定されています。
2. {{author}}、{{email}}、{{github}}、プロモーション用ブロック、デフォルトの選択肢を解決するため、毎回の実行開始時にプロフィールを読み込みます。

ワークフロー

1. 検出 — リポジトリを調べます。マニフェスト／エコシステム（pyproject.toml、 package.json、Cargo.toml、go.mod）、既存ファイル、git remote、デフォルト ブランチ、GitHub 上にすでに存在するかどうかを確認します。作成者のプロフィールを読みます。
2. 範囲の確認 — AskUserQuestion で対象コンポーネント（core / community / .github / promo / compliance / gh remote）を確認します。プロフィールの defaults をもとに初期値を設定します。
3. プレースホルダーの解決 — references/checklist.md に従って、一度だけ実行します。
4. 生成 — 選択した各コンポーネントについて、assets/templates/ と assets/github/ からファイルを作成し、プレースホルダーを埋めます。LICENSE には scripts/fetch_license.py を使います。パッケージのメタデータはインラインで編集します。
5. 著作者の確認 — AUTHORSHIP.md を作成する場合は、テンプレートを埋めるだけでなく、以下のウィザードを実行します。
6. コンプライアンス — 要望があった場合、または作成者が EU 圏在住の場合は、references/eu-germany-compliance.md の確認質問を実施し、該当する項目のみ追加します。
7. gh remote（任意）— 確認してから、リポジトリを作成／設定します。
8. 検証 — テストスイートを実行します（メタデータの編集でビルドが失敗することがあります）。差分を表示し、依頼された場合にのみコミットします。

項目ごとの詳細、プレースホルダー一覧、エコシステムの検出方法については、 references/checklist.md を参照してください（生成前に読んでください）。

著作者確認ウィザード

主要な機能です。AI 支援を受けた作業について、根拠のある AUTHORSHIP.md を作成するには、references/authorship-wizard.md を読み、手順に従ってください。このウィザードでは、次のことを行います。

• まず外部の根拠資料（ADR、git log、変更履歴、AI セッションログ、 CLAUDE.md／AGENTS.md、デザイントークン）を収集し、編集可能な草案を提示します。
• まず法域を尋ね、その後、5 つのセクションに沿って聞き取りを行います — 意思決定、判断の行使、目標設定と方向性、アートディレクション、AI による実装。
• 法域に応じた枠組み（米国の人間による著作権要件、EU／ドイツの「独自の知的創作物」、英国の CGW）に基づく 法務・著作権セクションを作成します。
• 常に法的助言ではないことを明記します。

出力テンプレート：assets/templates/AUTHORSHIP.md。

EU／ドイツのコンプライアンス

references/eu-germany-compliance.md では、CRA（SBOM、脆弱性報告）、AI Act 第 50 条の透明性、 ドイツの Impressum（DDG）、GDPR、製造物責任指令、EAA を扱います。義務は条件付きです — 確認質問を行い、該当する項目のみ追加してください。法的助言ではありません。

リソース

• assets/licenses/ — MIT、BSD-3-Clause（オフラインで利用可能）を同梱。それ以外は取得します。
• assets/templates/ — AUTHORSHIP、CODE_OF_CONDUCT、CONTRIBUTING、SECURITY、 NOTICE、CHANGELOG、profile.example.toml。
• assets/github/ — PR と issue のテンプレート、dependabot、CI ワークフロー（python/node）。
• scripts/fetch_license.py — 任意の SPDX ID について、記入済みの LICENSE を作成します。
• references/ — checklist.md、licenses.md、authorship-wizard.md、 eu-germany-compliance.md。