update-project

目的

既存のリポジトリでこのスキルを使用します。まず、リポジトリが Copier の更新を適用できる状態か、レガシーワークフローの移行が必要か、または明示的な自己採用が可能な dstack テンプレートソースかを判断します。通常の更新では、.copier-answers.yml の Git ソースに記録された stable または unstable チャネルを解決し、Copier の三者間更新を適用して、プロジェクト固有の変更をローカルに保持します。

<skill-dir> はこの SKILL.md を含むディレクトリ、<core-dir> はその兄弟ディレクトリである dstack-core スキルディレクトリとして解決します。共有ワークフローランナーを通じて更新ヘルパーを実行し、スクリプトのパスごとに環境を作成するのではなく、uv がワークフロー全体で同じ環境を再利用できるようにします。

共有信頼契約

このワークフローを実行する前に、../dstack-core/references/TRUST-AND-AUTHORITY.md を読み、その指示に従ってください。この契約はこのワークフローに対する規範です。このスキルと矛盾する場合は、より制限の厳しいルールに従い、矛盾を報告してください。

起動時のバージョン情報

更新または移行を適用する前に、update-project について ../dstack-core/references/SKILL-VERSION.md の指示に従ってください。読み取り専用の事前チェック後、変更を加える前に、出力された正確な1行を取得し、更新／移行の JSON または応答に含めてください。結果が stale の場合は npx skills update を案内します。unavailable の場合は、最新性を確認できなかったことを記録しますが、オフライン作業を妨げるものではありません。

更新固有の権限：

• 実行指示により、事前チェックのための検査が許可されます。ローカルの Copier 更新と専用の調整コミットは、リポジトリが移行ルーティングを通過した場合に限り許可されます。プッシュ、マージ、強制プッシュ、ブランチの削除、無関係なプロジェクト変更は許可されません。
• デフォルトのチャネルは stable で、PEP 440 に準拠した最新の安定版 vX.Y.Z リリースを選択します。unstable は、記録されたソースのデフォルトブランチの HEAD を選択します。既存のプロジェクトでは、記録されたチャネルを維持します。
• 選択したタグ、ブランチ、または明示的なリビジョンはすべて、到達可能なコミットに解決され、その正確な SHA が _commit に保存されます。インストール済みのスキルメタデータは、テンプレートの出所として使用されません。
• 明示的な開発用リビジョンは、変更を加える前に報告する必要があります。テンプレートソースの自己採用が暗黙に行われることはありません。

1. 更新前にレガシーリポジトリを振り分ける

まず、変更を加えない事前チェックを実行します。

uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --preflight --json

ヘルパーは次の項目を確認します。

• .copier-answers.yml が存在するかどうか。
• ツール、テンプレート、アーカイブ、移行、ベンダーディレクトリを除き、プロジェクト内のすべての場所にある有効な tasks.md ファイル。
• 数式がコピーされただけの状態を初期化済みデータベースとみなさずに、Beads の初期化状態。

recommended_workflow が migrate-workflow の場合は、Copier update を実行しないでください。検出されたタスクファイルと Beads の状態が未初期化であることを説明し、AskUserQuestion を使って次の質問を1つだけ尋ねます。Run /migrate-workflow now?

• ユーザーが同意した場合は、/migrate-workflow を実行し、そのワークフローで現在のタグ付きテンプレートを採用し、レンダリングされた新規プロジェクト構造を手動で調整し、Beads を初期化して、レガシーのタスク状態をインポートします。
• ユーザーが同意しない場合は、Copier を実行したりファイルを変更したりせずに終了します。
• 移行が完了してチェックポイントがコミットされた後、更新を検討する前に、この事前チェックを再実行します。

この振り分けは、Copier の状態がすでに存在するかどうかにかかわらず適用されます。レガシーの tasks.md ファイルがあり、Beads の状態が未初期化のリポジトリは、テンプレートの更新前に移行する必要があります。

Copier 管理下のプロジェクトで、回答にまだ language_profiles が含まれていない場合は、事前チェックで提示されるルート階層のみを対象とした suggested_language_profiles を使用します。これは、pyproject.toml を Python、tsconfig.json または package.json を TypeScript、Cargo.toml を Rust、go.mod を Go、mix.exs を Elixir、flake.nix を Nix に対応付けます。候補をユーザーに確認してもらい、自動的に適用してはいけません。見つかった候補も、ユーザーが承認した候補もない場合は、排他的な other プロファイルを提示します。再帰的なパッケージ検出はこのワークフローの対象外です。

古い回答ファイルでは、パッケージのない single-package がデフォルトです。ユーザーが明示的に変換を依頼しない限り、この状態を維持します。変換する場合は --repository-layout monorepo と、完全なパッケージごとに1つの --monorepo-package '<JSON object>' のみを使用してください。パッケージを推測してはいけません。事前チェックでは、リビジョンの検索やレンダリングの前に正確な配置先と使用中のパスを一覧表示し、無効、予約済み、重複、大小文字の衝突があるパスやシンボリックリンクのパスを拒否します。パッケージオブジェクトに含めるのは display_name、slug、path、language_profiles のみです。表示名と頭字語は正確に維持してください。

2. 更新の前提条件

事前チェックで update-project が推奨され、かつ次の条件を満たす場合にのみ、通常の更新に進みます。

• .copier-answers.yml に Git 管理の _src_path と _commit が記録されている。
• 初期のひな形、または完了した移行チェックポイントがコミットされている。
• ユーザーが変更のある状態での更新を明示的に承認していない限り、ワークツリーがクリーンである。
• 記録された Git ソースから、選択したチャネルまたは明示的なリビジョンを解決できる。

3. テンプレートの更新を適用する

記録されたチャネルを通じて更新するか、明示的に上書きします。

uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --stable
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --unstable

プレビューする場合、プレリリースを含める場合、または別のリビジョンを明示的に選択する場合：

uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --pretend
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --prereleases --pretend
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --vcs-ref <release-tag>
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --vcs-ref <reviewed-tag-branch-or-commit>
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --add-profile typescript
uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --remove-profile python --add-profile other

プロファイルフラグを省略すると、記録された選択が維持されます。追加・削除フラグは繰り返し指定でき、冪等な集合操作として機能します。同じプロファイルを両方の集合に含めることはできません。other は排他的であり、認識済みプロファイルを最後の1つまで削除する場合は、同じ呼び出しで other を追加する必要があります。

更新では、Copier にすでに記録されている構造化されたプロジェクト概要の値を再利用します。古いプロジェクトで、目的、ユーザー、範囲、境界、プロジェクト種別のいずれかが不足している場合は、1回に1つずつ質問し、対応する --purpose、--users、--scope、--boundaries、--project-kind フラグを渡します。不足している値をレガシーの説明から導き出してはいけません。

ブランチ、コミット、または HEAD の明示的な指定は、1回限りの上書きです。ヘルパーは正確に解決されたコミットを保存し、次回の更新に向けて選択された安定版／不安定版チャネルをデフォルトのまま維持します。

dstack の自己採用

preflight が update-project-adopt を報告した場合は、ユーザーの明示的な承認を得て、作業ツリーがクリーンなときにのみ実行します。

uv run <core-dir>/scripts/run-workflow.py <skill-dir>/scripts/update-project.py --adopt --unstable \
  --project-name dstack --project-slug dstack \
  --purpose "<purpose>" --users "<users>" --scope "<scope>" --boundaries "<boundaries>" \
  --project-kind other --language-profile python --json

自己採用では、到達可能なリモートのデフォルトブランチのコミットを分離環境でレンダリングし、不足している生成パスをコピーし、既存の dstack 所有パスを保持します。生成されたバージョンに差異がある場合は migration/copier-adoption-candidates/ に書き込み、正確な不安定な Copier 状態を記録します。検証またはコミットの前に、すべての候補を調整し、このディレクトリを削除してください。ローカルにしかないコミットを採用することはなく、調整前に生成コードを実行することもありません。

ヘルパーの契約

ヘルパーは次の処理を行います。

1. Git ルートを解決し、リビジョンの検索や変更を行う前に、移行／自己採用の振り分けを実行します。
2. .copier-answers.yml から Copier のソースと以前のリビジョンを読み取ります。
3. 維持されている、または明示的に指定されたチャネルを解決します。stable では PEP 440 の順序付けに従って条件を満たすタグのうち最大のものを使用し、unstable ではソースのデフォルトブランチの HEAD を使用します。
4. デフォルトではプレリリースを除外し、--prereleases が指定された場合にのみ含めます。
5. 選択したすべてのリビジョンが到達可能であることを確認し、成功を報告する前に正確なコミット SHA を永続化します。
6. デフォルトで作業ツリーがクリーンであることを要求します。
7. Copier の更新を適用します。
8. Git から認識される変更済みファイルと未追跡ファイルのみを対象に、一貫性のある競合マーカー、Git の未マージパス、新たに生成された .rej ファイルを確認します。
9. 依存関係の環境や .venv などの、Git で無視されるコンテンツは無視します。
10. 競合がない場合は、python3 scripts/setup-tooling.py --json を実行して mise.lock を更新し、--locked でインストールし、hk フックを調整します。
11. ツールのセットアップ成功後に bd hooks install を実行し、bd hooks list --json が報告するすべてのフックがインストール済みで最新であることを確認します。個別の beads_hooks 結果では、ステータスと復旧コマンドを報告します。
12. 競合がある場合は、生成されたプロジェクトコードをすべてスキップし、ツールのセットアップと Beads フックをスキップとして報告し、復旧コマンドを提示します。
13. scripts/check-docs.py が存在する場合は実行します。
14. bd info --json と bd ready --json --limit 1 を使用して、ストレージモードに依存しない Beads のスモークテストを実行します。
15. プロジェクトの機能式が存在する場合は検証します。
16. 正規の言語プロファイルを維持するか、明示的に追加／削除します。レガシーなルートマニフェストの提案は preflight で報告しますが、暗黙に適用することはありません。
17. 古いレイアウトの回答ではデフォルトで単一パッケージを使用し、明示的なパッケージ変換はレンダリング前に検証します。
18. 選択されたリリース、解決された Copier コミット、変更ファイル、ツールと Beads フックの個別の段階、検証、警告、競合、準備状況を報告します。

Beads のすべてのストレージモードでサポートされているわけではないため、bd doctor は使用しません。

4. 変更されたすべてのパスを調整する

ヘルパーの変更ファイル出力に加え、git status --short と git diff --name-status からパス管理台帳を作成します。変更された各パスは、以下のいずれか1つに分類して、必ず1回だけ記載します。

• template change accepted；
• project change preserved；
• conflict resolved。

各パスについて、上流の変更、維持すべきローカルの動作、解決方法、検証の証拠を記録します。

パス	分類	上流／ローカルの意図	解決方法	検証
…	template change accepted	…	…	…

プロジェクト所有のアーキテクチャ、運用、開発、リファレンス、ロードマップ、機能の履歴を維持します。パスの判断が曖昧な場合は中断してください。テキスト上の競合がないことは、変更を受け入れたことを意味しません。変更されたパスが台帳から漏れている場合、または unknown のみで分類されている場合、調整は未完了です。

すべてのパスを記録したら、最終ファイルに対してプロジェクト固有の検証を再実行し、機能作業を再開する前にテンプレートの更新を独立した区切りとしてコミットします。ツールのセットアップ結果が劣化している場合、未解決として扱います。報告された各復旧コマンドを実行し、最新かつ空ではない mise.lock を確認してから、更新を準備完了と分類してください。

結果

報告内容：

1. 事前確認ルート、旧タスクファイル、Beads の状態、および移行を提示した場合のユーザーの同意判断；
2. 移行先と Copier のソース；
3. 以前の Copier リビジョンとチャンネル；
4. 選択したチャンネル、わかりやすいタグ／ブランチ／参照、および正確に解決されたリビジョン；
5. 以前、提案、および適用後の言語プロファイル；
6. リポジトリのレイアウト、正確なパッケージの事前確認、生成されたパッケージパス、および未解決の候補すべて；
7. 変更されたファイルと完全なパス計上台帳；
8. 実際の更新競合と解決内容；
9. ツールの利用可否、ロック、インストール、フックの各状態と、正確な復旧コマンド；
10. ドキュメントと Beads の検証；
11. 警告と未分類のパス；
12. 機能開発を再開できる状態かどうか。移行が必要な間、競合または機能低下したツールが残っている間、候補が未解決のままである間、ロックが古いか存在しない間、または変更されたパスが未分類の間は、必ず「不可」とします。