scaffold-repository

リポジトリをセットアップする

ファイル内容のソースとして、以下に記載する利用者向けプルリクエストテンプレートを除き、patinaproject/skills の現在のルートを使用してください。必要なファイルの一覧は core-baseline.txt で、すべての必須チェックは audit-checklist.md で確認してください。

patinaproject/skills の外部で実行する場合、単一のソースファイルは次の方法で取得します。

gh api repos/patinaproject/skills/contents/<path> --jq .content | base64 -d

複数のファイルを取得する場合は、一時的な浅いクローンを使用します。

git clone --depth 1 https://github.com/patinaproject/skills.git /tmp/patinaproject-skills-reference

ネットワークもローカルのチェックアウトも利用できない場合は、参照リポジトリのコピーをユーザーに依頼してください。記憶を頼りにファイルを再作成しないでください。

作業の種類を選択する

対象が Git リポジトリで、AGENTS.md、commitlint.config.js、package.json 内の標準スクリプトなど、Patina のファイルが存在しない場合は、新規リポジトリのセットアップを行います。

これらのファイルがすでに存在する場合は、既存リポジトリの更新を行います。

新規リポジトリ

1. core-baseline.txt を読み、必須ファイルをすべて現在の Patina リポジトリからコピーします。
2. 以下の入力値を使って、リポジトリ固有の値を設定します。
3. マーケットプレイス専用のテストファイルとメンテナンスファイルは除外します。マニフェストではすでに除外されています。
4. pnpm install を実行して pnpm-lock.yaml を作成し、Husky を設定します。
5. 作成したファイルをステージしますが、コミットはせず、最初のコミットはユーザーに委ねます。

既存リポジトリ

1. audit-checklist.md を最後まで読み、該当するチェックをすべて実行します。
2. レポートを必須の出力形式に合わせるため、audit-checklist.md に記載された差分名と定義を使用します。
3. 各差分について、推奨する変更を説明し、現在の Patina ファイルとのユニファイド diff を示します。
4. 既存ファイルを変更する前に、各推奨事項を受け入れるか、スキップするか、保留するかをユーザーに確認します。非対話型の上書きモードはありません。
5. audit-checklist.md で指定された順序で変更を提示します。コミットとプルリクエストのルール、パッケージとスキルのツール、リポジトリのドキュメント、GitHub ワークフロー、最後に廃止されたセットアップの削除の順です。
6. 受け入れられた変更によって空でない skills-lock.json が変更された場合は、pnpm skills:install を実行し、プロジェクトローカルのスキルが npx --yes skills@latest list --json に表示されることを確認します。また、更新された .agents/skills/ ディレクトリと .claude/skills/ リンクも含めます。

対象リポジトリが patinaproject/skills の場合も、同じ監査チェックを適用します。

リポジトリの入力値

可能な場合は、origin からリポジトリの所有者と名前を読み取ります。作成者の名前とメールアドレスは git config user.name と git config user.email から読み取ります。メールアドレスは公開用のセキュリティ連絡先として使用します。設定された名前またはメールアドレスがない場合は、処理を中止します。

gh api user --jq .login で作成者の GitHub ハンドルを解決します。失敗した場合は、デフォルト値を設定せずに Author GitHub handle for the package author URL? と質問します。

特定できない値があれば、ユーザーに尋ねます。

値	デフォルト
リポジトリの所有者	origin の所有者
リポジトリ名	origin の名前
1 行の説明	なし
公開範囲	public
コードオーナー	@<owner>
セキュリティ連絡先	設定済みの Git メールアドレス
作成者名	設定済みの Git 名
作成者のメールアドレス	設定済みの Git メールアドレス
作成者の GitHub ハンドル	現在認証済みの GitHub ユーザー

package.json の author フィールドに、作成者名、メールアドレス、https://github.com/<author-handle> を記載します。リポジトリ URL では引き続きリポジトリの所有者と名前を使用します。

必須ファイルの動作

core-baseline.txt は、scripts/verify-baseline.sh で使用するファイル一覧です。このスキルに別の一覧をコピーする代わりに、これを使用してください。

4 つの項目には特別な対応が必要です。

• pr-body-template.md を .github/pull_request_template.md にコピーします。そこに指定されている GitHub と Linear の両方のクローズ参照を必須にします。対象リポジトリのトラッカーアダプターとリンク済みの課題データを使って対応する ID を取得し、参照形式が対象の連携機能およびクローズ参照チェックに適合することを確認します。
• 対象に opening-a-pr プレイブックがない場合は、コピーした AGENTS.md と CONTRIBUTING.md を調整し、対象で有効なワークフローを本文の契約として明記します。本文の契約が存在しない場合は、本文の構成を作成者に委ねます。テンプレートが担うのは、クローズ参照についての注意喚起のみです。
• SECURITY.md を作成するのは、公開リポジトリの場合のみです。
• トラッカーの実際の手順は docs/agents/issue-tracker.md に保持します。docs/issue-tracker.md は、相対リンク agents/issue-tracker.md として作成します。

マーケットプレイスの保守テスト、生成されたスキルリンク、リリースワークフローを通常のリポジトリにコピーしないでください。コピーしたワークフローは、対象リポジトリが実際に受け取るファイルに合わせて調整します。

デフォルトの .claude/settings.json では、enabledPlugins オブジェクトは空です。それでも、SessionStart の起動フックとして bash scripts/worktree-setup.sh が登録されています。Codex 環境では、同じスクリプトを [setup] ブロックから実行します。プロジェクトでは、後からプラグインを有効にできます。

コミット形式、プルリクエスト形式、Markdown の lint、パッケージスクリプト、コミット済みのローカルスキル、エージェントへの指示、課題追跡、リリース、アクションのピン留め、ラベル、ワークフローの権限については、最新のファイルと audit-checklist.md のチェック項目を使用してください。変更されるこれらの詳細を記憶に頼って書き直さないでください。

GitHub のマージ設定

利用可能な場合は、gh で現在の設定を確認します。

gh api "repos/<owner>/<repo>" --jq '{allow_squash_merge, allow_merge_commit, allow_rebase_merge, squash_merge_commit_title, squash_merge_commit_message, delete_branch_on_merge, allow_update_branch}'

公開リポジトリで gh が使えない場合は、curl を使って公開 API を利用します。リポジトリが非公開で、認証済みツールを利用できない場合は、想定される値をユーザーに示し、GitHub の設定を確認するよう依頼します。

想定される値：

設定	値
スカッシュマージ	On
マージコミット	Off
リベースマージ	Off
スカッシュタイトル	PR_TITLE
スカッシュメッセージ	COMMIT_MESSAGES
マージ後にブランチを削除	On
ブランチの更新を提案	On
リリースの不変性	On

設定をどのように確認したか、および相違点をすべて報告します。設定を変更する前に確認を求めます。確認を得たら、対応している値を次のように更新します。

gh api -X PATCH "repos/<owner>/<repo>" \
  -F allow_squash_merge=true \
  -F allow_merge_commit=false \
  -F allow_rebase_merge=false \
  -F squash_merge_commit_title=PR_TITLE \
  -F squash_merge_commit_message=COMMIT_MESSAGES \
  -F delete_branch_on_merge=true \
  -F allow_update_branch=true

リリースの不変性は、GitHub の Settings、General、Releases で有効にする必要があります。通常のリポジトリ API では、この設定を公開していません。

ワークフローの書き込み権限、リリースタグのタグ署名ルール、予約済みの autorelease: pending ラベルを含め、audit-checklist.md にあるリポジトリ設定のチェック項目も適用してください。通常の課題作業やプルリクエスト作業の一環として、Release Please のラベルを追加または削除しないでください。

結果を検証する

まず、ファイルの存在チェックを実行します。必要なファイルが 1 つもコピーされていなくても、ほかのツールが成功する場合があります。

bash <skill-directory>/scripts/verify-baseline.sh --public
# Use --private for a private repository.
pnpm install
pnpm exec commitlint --help
pnpm lint:md
echo "feat: bad" | pnpm exec commitlint
echo "feat: #1 ok" | pnpm exec commitlint

不正なコミットメッセージは失敗しなければなりません。#1 を使った公開リポジトリの例は成功しなければなりません。非公開リポジトリでは、そのリポジトリの非公開課題形式を使用します。

<skill-directory> を、このスキルがインストールされているディレクトリに解決します。対象リポジトリから検証スクリプトを実行するか、最後の引数として対象リポジトリのルートを渡します。パスが 1 つでも見つからない場合は、セットアップ失敗として扱います。

Markdown の変更をコミットする前に、次を実行します。

pnpm exec markdownlint-cli2 --fix "**/*.md"

非公開リポジトリを公開リポジトリに変更する

ユーザーが非公開リポジトリを公開するよう求めた場合は、公開範囲の移行手順を読みます。課題追跡や Git 履歴の変更は通常のリポジトリ更新とは別の作業であり、個別にレビュー済みの計画が必要です。

最終レポート

新しいリポジトリの場合は、ステージング済みのファイルと、ユーザーがまだ入力する必要のある値を列挙します。既存のリポジトリの場合は、バッチごとに適用済み、スキップ、保留中の変更を列挙します。失敗したチェック、GitHub の設定の差異、未完了の項目についてユーザーが行う必要のある操作を正確に記載します。