


技術ツールやリンクの一覧に届いた、新しい投稿を確かめる
技術ツールやリンクの一覧に、変更の申し込み(プルリクエスト)で新しい項目が届いた時に使う。指定した投稿だけを、書き方・重複・安全なリンクの点で確かめ、コメントや取り込み(マージ)の前に必ず聞き、新しい問題と前からある問題を分けて報告する。
このAIルールを使うには
## 一覧のファイルを1つだけの大もとにし、サイトとデータはそこから作る
人が読める1つの目録文書を正本として扱う。
派生成果物を個別に編集せず、その正本から索引、構造化データセット、静的ページを生成する。
実装言語の見出しではなく、主題カテゴリーの下に項目を整理する。
1つのリソースが主題カテゴリーを変えずに複数言語へ対応できるよう、各項目のインラインタグに対応言語を記録する。
データの流れを文書化する。
1. 目録文書に選定済み項目を保存する。
2. parserが項目を検証し、承認された外部メタデータを補足して、構造化データセットを書き出す。
3. site generatorはデータセットがあれば読み込み、なければローカルpreview用に目録を直接解析する。
4. continuous integrationがparserとgeneratorを実行し、生成されたsiteディレクトリだけを公開する。
parser、generator、deploymentの挙動をこの取り決めと一致させる。
生成ページやデータセットを、競合する別の正本にしない。
## 一覧の項目を、言語タグつきの1つの書き方にそろえる
parserが認識できる項目形式を1つ定義し、句読記号も取り決めの一部として扱う。
標準的な項目は、リンク付き名称、1つ以上のインライン言語タグ、説明で構成する。``- [Name](https://example.org) - `Language` - Description.``
次の規則を適用する。
- 新しい非商用項目には、必須の区切り文字が続く言語タグを1つ以上含める。
- 説明は、任意のソースリポジトリリンクより前でピリオドを付けて終える。
- 新しいリンクには`https://`を使う。
- 商用または専有リソースは専用カテゴリーに置く。
- 言語タグを省略できるのは、商用カテゴリーまたは明示的に言語と無関係なカテゴリーだけとする。
- 投稿者向けの貢献ガイドを、投稿規則の正本として維持する。
周辺構造を変えずに、複数の言語タグを受け入れる。
完結した説明の後には、任意のリポジトリリンクを許可する。
同じ項目文法に従う場合は、エコシステム固有のパッケージリンクも有効として扱う。
1件の不正な投稿に合わせてparserのpatternを緩めない。
## 新しい項目は厳しく確かめ、前からある項目は注意として伝えるだけにする
検証、解析、公開には、リポジトリで文書化された環境とtask wrapperを使う。
必要なruntime versionを守り、正規のdependency commandで依存関係をインストールする。
2つの検証モードを使う。
1. 変更検証では、選択した基準revisionに対して追加された項目だけを確認する。
2. 目録全体の検証では、すべての項目を確認する。
新規項目では、重複、不正なリンク、URL方針違反の指摘をerrorとして扱う。
目録全体では、strict flagが明示的に選ばれていない限り、同種の既存問題をwarningとして報告する。
許容している既存の負債によって、新規項目の登録基準を弱めない。
必要なcredentialが利用できる場合に限ってparserを実行する。
ローカルpreviewでは、既存の構造化データセットまたは文書化された直接解析のfallbackをsite generatorに使わせる。
## 指定された投稿だけを見て、一覧に重複がないか確かめる
レビュー対象を、ユーザーが指定した投稿に限定する。
pull requestの操作には、無関係なcommand-line clientではなく、設定済みのrepository connectorを使う。
変更操作の前に次を行う。
1. 提案されたファイルと差分を調べる。
2. カテゴリーの配置と正確な項目形式を確認する。
3. 正本の目録で重複を検索する。
4. 安全なURL形式を確認する。
5. 現在のproject activityとdocumentationを根拠に基づいて評価する。
6. 外部状態を変更する前に指摘事項を提示する。
開かれているという理由だけで、指定外の投稿をレビューしない。
提出された説明だけから人気度や保守状況を推測しない。
目録形式への適合と、リソースの品質・継続的な有用性を区別する。
## プルリクエストへのコメントや取り込みの前に、必ず聞く
pull requestへのcomment、label付与、close、mergeの前には、必ずユーザーへ確認する。
ユーザーがreview commentを承認した後に限り、review完了labelを付ける。
そのmergeに対する明示的な承認後に限り、mergeする。
接続済みrepository toolを使って、開いているrequestの一覧、詳細、ファイル、comment、label、差分を確認し、重複確認用にdefault branchの目録を取得し、承認済みの変更を実行する。
必要なconnectorが利用できない場合に、別の外部toolで代用しない。
connectorがなければrepository操作が停止していると報告し、設定をユーザーへ依頼する。
読み取り専用の根拠収集と、外部状態の変更を分ける。
レビューの指示だけでは、comment、label、close、mergeは承認されていない。
## アクセス用のキーを隠し、サイトは決まった自動の手順でだけ公開する
外部メタデータの補足を、credentialが必要な操作として扱う。
必要なaccess credentialなしに実行せず、command、report、生成ページ、commit対象ファイルへcredentialを決して露出しない。
公開工程を再現可能に保つ。
- 正本の目録を解析し、文書化された構造化データセットへ変換する。
- ローカルpreviewでは、文書化されたfallbackだけを使う。
- 現在の検証済み入力から静的ページを生成する。
- 設定済みのcontinuous-integration workflowだけを通して公開する。
- parserまたはtemplateの挙動が変わった場合は、生成差分をレビューする。
ローカルpreviewだけを根拠に、公開成功を主張しない。
生成成果物と公開workflowを個別に検証する。
## 確かめた範囲を書き、新しいエラーと前からある注意を分けて報告する
レビューした投稿、指摘事項、検証モード、停止中の操作を報告する。
確認範囲が新規項目だけか、目録全体かを明示する。
既存内容に由来するwarningと、今回の変更が持ち込んだerrorを分けて示す。
完了前に次を確認する。
- 目録が正本のまま維持された。
- 項目文法、句読記号、tag、category、安全なURLを確認した。
- 現在のdefault branchを基準に重複を確認した。
- activityとdocumentationに関する主張が根拠に基づいている。
- 承認なしに外部状態を変更していない。
- 生成成果物を正本のsource contentと取り違えていない。
判断に必要な簡潔さを保ちつつ、登録可否を変えうる指摘はすべて含める。
