lggarrison/agent-skills

リポジトリセットアップ

新しいリポジトリには毎回同じベースラインが必要です：ライセンス、セキュリティ問題の報告方法、README、PRとIssueを有用にするテンプレート、そしてコントリビューターがローカルで実行するのと同じチェックを実行するCI。このスキルはそのベースラインのためのチェックリストであり、それを実行するための方法です。

最初にリポジトリのルールを確認

何かを追加する前にリポジトリに既にあるものを読んでください：AGENTS.md / CLAUDE.md、CONTRIBUTING.md、既存の.github/ファイル、パッケージマニフェストとそのスクリプト、およびCI設定。これらが規約（デフォルトブランチ、ライセンス、ツール、ファイルの場所）を設定している場合は、それに従ってください。ここにあるテンプレートに合わせるために既存のファイルを上書きしないでください。拡張するか、そのままにしてギャップを指摘してください。

ワークフロー

1. 依頼を明確にする

• ブートストラップ： 新しい、またはほぼ空のリポジトリ。チェックリスト全体を実行します。
• ギャップを埋める： 既存のリポジトリに一部のファイルが欠けている。不足しているものだけを追加します。
• 監査： 何が欠けているか、または弱いかを報告し、何も変更しません。

2. 棚卸しをする

どのチェックリストファイルが存在するかをリストアップし、マニフェスト（package.json、pyproject.toml、go.mod、Cargo.tomlなど）を読んで言語、スクリプト、プロジェクトが公開されているかどうかを確認します。git remote show origin または gh repo view --json defaultBranchRef でデフォルトブランチを見つけてください。この方法で学習できることをユーザーに尋ねないでください。

3. 判断を要する事項について尋ねる

これらはユーザーの決定事項です。1回の短いラウンドで一度尋ね、証拠がそれを支持する場合は推奨してください：

• ライセンス、および著作権者の名前。
• セキュリティ連絡先： GitHubのプライベート脆弱性報告、メールアドレス、またはその両方。
• 行動規範の連絡先（追加する場合）。
• PRのベースブランチ（デフォルトブランチでない場合）。
• 公開するかどうか： パッケージレジストリ、またはリリースアーティファクトとして。
• CIマトリックス： サポートするオペレーティングシステムとランタイムバージョン。

4. ファイルを作成する

チェックリストを上から下へ実行し、該当しないセクションはスキップします。

• 正規のテキストを取得し、記憶から書き出さないこと。 gh api licenses/<spdx-id> --jq .body（例：mit や apache-2.0）でライセンステキストを取得し、年と権利者を記入します。行動規範は公式ソース（Contributor Covenantなど）から取得します。
• テンプレートを適応させる。 templates/ から開始します。すべての <placeholder> を置き換え、コマンドをこのリポジトリに存在するものに変更します。リポジトリにないスクリプトをリストするテンプレートは、テンプレートがないより悪いです。
• チェックのリストを統一する。 PRテンプレートのチェックリスト、CONTRIBUTING.md、pre-commitフック、およびCIはすべて同じコマンドを名指しする必要があります。1つが変更されたら、他も変更します。
• 設定を変更する前に尋ねる。 ブランチ保護、ルールセット、プライベート脆弱性報告はリポジトリ設定であり、ファイルではありません。それらを提案し、ユーザーが同意した場合にのみ適用します。

5. 確認する

• テンプレート、フック、またはCIジョブで指定されたすべてのコマンドがローカルで実行され、成功すること。
• どのファイルにも <placeholder> が残っていないこと。
• Issueフォームとワークフローが有効なYAMLであること。Issueフォームはデフォルトブランチにのみ表示されるため、マージ後にそこで確認します。
• リンク（セキュリティポリシーのURLを含む）が解決すること。
• リポジトリ独自のフォーマットとlintチェックが新しいファイルに合格すること。

6. 報告する

何を追加したか、何をそのままにしてその理由、提案したリポジトリ設定、およびまだ未解決の判断事項を述べてください。

チェックリスト

R は必須、rec は推奨、opt は任意です。

ツール

• R git、および言語ランタイムとパッケージマネージャー。
• rec 固定されたバージョンファイルに一致するランタイムバージョンマネージャー（nvm、fnm、pyenvなど）。
• rec メンテナー向けに gh auth login で認証された gh。

法務とコミュニティ

• R LICENSE。
• R SECURITY.md：サポート対象バージョン、非公開での報告方法、報告後に報告者が期待できること。
• rec CONTRIBUTING.md：セットアップ、実行するチェック、ブランチとコミットの規約、PRのレビュー方法。
• rec CODE_OF_CONDUCT.md（実際の執行連絡先付き）。
• rec Keep a Changelog 形式の CHANGELOG.md。

ドキュメント

• R README.md：それが何か、インストール方法、最小限の使用例、および CONTRIBUTING.md、SECURITY.md、ライセンスへのリンク。
• opt AGENTS.md：コーディングエージェント向けのベンダーニュートラルなエントリポイント。実行するコマンドと従うべきルールを示し、繰り返すのではなく他のドキュメントにリンクします。
• opt RELEASING.md（公開プロジェクト向け）。公開を参照。

エディタとGitの衛生

• R 言語、ビルド出力、ローカル環境ファイル用の .gitignore。
• rec * text=auto eol=lf を含む .gitattributes。これにより、オペレーティングシステム間で改行コードが変わらなくなります。
• rec 文字セット、最終改行、インデント用の .editorconfig。

GitHubテンプレートと自動化

リポジトリがGitHub上にない場合は、ホストの同等のものを使用します。

• rec .github/PULL_REQUEST_TEMPLATE.md。テンプレートを参照。
• rec .github/ISSUE_TEMPLATE/ 内のIssueフォーム：bug_report.yml、feature_request.yml、および空のIssueを無効にしセキュリティ報告をプライベートチャネルに誘導する config.yml。テンプレートを参照。
• rec .github/dependabot.yml。リポジトリが使用する各パッケージエコシステムに1エントリ、さらに github-actions 用に1エントリ。
• R .github/workflows/ci.yml。すべてのPRとデフォルトブランチへのすべてのプッシュで、PRテンプレートと同じチェックを実行します。
• opt .github/release.yml。生成されたリリースノートをラベルでグループ化します。
• opt .github/workflows/release.yml（公開プロジェクトのみ）。
• rec デフォルトブランチ上のブランチ保護またはCIを要求するルールセット。これは設定なので、先に尋ねます。

Node.jsとTypeScript

他の言語の場合はこのセクションをスキップし、そのエコシステムのツールで同じ考え方を適用します：固定されたランタイムバージョン、フォーマッター、リンター、テストランナー、単一の「すべてをチェック」コマンド、CIマトリックス。

ランタイムとメタデータ

• rec .nvmrc、および package.json の engines.node。これらは互いに一致している必要があります。
• R package.json の repository、homepage、bugs、license、author。
• rec ネイティブESMのための `