setup-template

masseater/typescript-template から作ったリポジトリを、テンプレートに揃える。GitHub 側の設定は gh で揃え、中身の移行が完了しているかは、テンプレートの骨格と突き合わせて確かめる。対象リポジトリを REPO=<owner>/<name> とする。

• 設定はすべて gh で行う
• どの手順も、同じ値で何度実行しても結果が変わらない
• それ以外のリポジトリで使うときは、作業を始める前に、どの手順を適用するかをユーザーに確認する
• 基準にするのは、テンプレートが持ち続けている骨格である。テンプレートの新しいリリースで増えた要素は、欠けとして扱わない
• 各要素は、入っているか、効いているか、古い形や重複が残っていないかの 3 点で見る
• 判定には、コマンドの出力やファイルの実物を根拠として添える
• 対象外の要素には、リポジトリの現実から言える理由を書く
• 検査では直さない。欠けは一覧として渡す。直しながら検査すると、判定が直しの結果に塗り替わる
• 検査や lint を緩めて緑にした形跡は、欠けとして扱う

この skill が必要な理由と達成したい状態

この skill が必要な理由は、テンプレートから作ったリポジトリに、コードとワークフローは引き継がれても、GitHub 側の設定とアプリ名が引き継がれないことにある。secrets、Actions の権限、ルールセットがそれにあたる。ワークフローのファイルは揃っているので、設定が抜けていてもファイルを見ただけでは分からない。抜けたまま動く自動化は、失敗するか、何もしないまま終わる。どちらにせよ、誰も気づかない。

中身も同じである。移行の欠けは失敗として現れない。hook が 1 つ足りなくても、古い設定が隣に残っても、入っている検査の範囲では、ビルドもテストも verify も通る。欠けは気づかれずに残り、取り残しは効かないまま残る。報告には「移行しました」しか出てこない。テンプレートは動くアプリの土台も持っているので、移行の目標は「アプリが動く」ことに寄る。そのぶん、動かすのに要らない骨格から先に抜け落ちる。リポジトリは欠けを教えてくれないので、テンプレートの骨格から逆向きに突き合わせないと、未完了は見つからない。