mcpField
K
kineti-fe-gdk-update

kineti-fe-gdk-update

github.com/sztadii開発014 回インストール今日更新
リポジトリ

kineti-fe-gdk-update について

Kinetiのフロントエンド利用側チェックアウトで `@geodome/gdk` を更新するスキルです。バージョン選定、APIと翻訳の適応、検証を扱い、変更は未コミットのままにしてGDKソースは編集しません。

主な機能

  1. 01安定版または指定バージョンの選択
  2. 02依存関係とロックファイルのみ更新
  3. 03API、テンプレート、モックの適応
  4. 04対応ロケールの翻訳を完了
  5. 05必要な非E2Eチェックの実行

活用シーン

  1. 01フロントエンドチェックアウトでGDKを更新
  2. 02変更されたGDK APIへの適応
  3. 03依存関係の更新後に翻訳を整備
  4. 04E2Eテストを実行せずアップグレードを検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sztadii/agent-skills --skill kineti-fe-gdk-update

インストール後、Claude Code で/kineti-fe-gdk-updateを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

Kineti フロントエンドで GDK を更新する

対象範囲

@geodome/gdk を最新の安定版または指定されたバージョンに更新し、コードと翻訳を調整して結果を検証します。選択されたフロントエンドのコンシューマーのチェックアウト内だけで作業し、変更はコミットしないでください。プッシュ、PR の公開、スケジュールの変更、GDK ソースの変更は行わないでください。通知スケジューラーは更新を許可するものではありません。このスキルを編集しても、通知スケジューラーは起動しません。

依存関係

スキルの依存関係はありません

ワークフロー

対象を確定する

  • リモートと package.json からチェックアウトの識別情報とコンシューマーの依存関係を確認します。自己依存を避けるため、対象が GDK 自体の場合は拒否します。対象が曖昧な場合に限り、質問してください。リポジトリやネストされたディレクトリの指示、および翻訳ガイダンスを確認します。
  • リモートのデフォルトブランチを取得し、SHA と依存関係/ロックファイルのベースラインを記録します。タスクによる変更を調べ、リセット、破棄、または通知せずにスタッシュすることなく、最新のベースを使用してください。ユーザーの作業を保持できない場合は、ブロッカーとして報告します。
  • 設定済みのレジストリから、指定バージョンがない場合は、プレリリースを除外して、SemVer 上で最も高い安定版を一度だけ特定します。タグに依存したり、バージョン比較のためにインストールしたり、暗黙にダウングレードしたり、アクセス失敗を「最新です」と表現したりしないでください。インストール済みまたはロック済みの対象であっても、未完了の翻訳、調整、検証は必要です。

更新する

AWS/CodeArtifact の認証および依存関係のインストール/更新に関するコマンドは、リトライも含め、毎回 AWS_PROFILE=kineti を設定してください。インストール/更新の前に AWS_PROFILE=kineti pnpm run preinstall を実行します。プロジェクトの pnpm、レジストリ、フックを使用し、トークンを公開したりグローバル認証情報を変更したりしないでください。認証失敗の診断には AWS_PROFILE=kineti aws sts get-caller-identity を使用します。

  • package.json と pnpm-lock.yaml で GDK だけを更新し、バージョン表記のスタイルを維持し、無関係な更新やロックファイルの不要な変更を避けます。
  • リリースノート、公開 API/型、コンシューマーでの使用箇所を調べます。リポジトリ内のパターンに従って、破壊的な API 変更、テンプレート、ランタイムの動作、モックを調整します。型を弱めたり、エラーを抑制したり、テストやチェックを無効にしたり、有用なアサーションを削除したりしないでください。
  • 既存の抽出、同期、翻訳、整形、検証のパイプラインを通じて、サポート対象のすべてのロケールの翻訳を完了します。更新したパッケージ/アプリケーションから抽出し、生成された ID、プレースホルダー、翻訳を維持してください。キーの同期だけでは不十分です。

検証する

インストール、調整、翻訳生成がすべて完了した後、独立したチェックを並行して実行します。前提条件と、可変リソースを共有するチェックは順番に実行し、失敗を修正する前にすべての結果を収集してください。

CI のワークフロー/スクリプトを確認します。完全な型チェックと、watch モードではない CI ユニットテスト一式を実行します。その他の E2E 以外のチェックは、PR の CI で必要な場合にのみ実行してください。影響するスコープには未コミットの変更も含めます。集約スクリプトや Nx ターゲットを確認してから実行してください。リポジトリの指示に記載されていても、Playwright/Cypress を含むローカルまたはリモートの E2E/ブラウザーのテストスイートは絶対に実行しないでください。E2E 以外のターゲットを選択し、E2E は合格ともブロッカーともせず、意図的に未実行として報告します。CI チェックは変更しないでください。

プロジェクトのコマンドを確認してください。drones-frontend の例: lint、typecheck、format-check-all、test-ci。翻訳では drone-fe:extract-i18n、sync-locales、prettify-locales、verify-locales を使用します。 翻訳パイプラインを再実行し、追加のロケール変更がないことを確認します。PR の CI で必要な場合に限り、本番環境/サポート対象ロケール向けのビルドを行います。イメージの公開やデプロイは絶対に行わないでください。

Nx のチェックには NX_SKIP_NX_CACHE=true NX_NO_CLOUD=true を使用します。前段のステージでブロックされた場合は、後段の型チェックを個別に実行します。アップグレードによる失敗を修正し、最終変更に対して失敗したチェックや無効化されたチェックを再実行して、差分を確認します。検証を緩和することなく、意図した動作に合わせてテストを更新してください。

修正可能な失敗があっても作業を続けてください。既存の問題、GDK ソースの修正が必要な場合、または認証情報/サービス/インフラストラクチャを利用できない場合は、証拠を添えて未完了の結果とします。無関係な修正は行わず、連携のために他者のブランチ、PR、会話、Slack、Jira を調べたりしないでください。対応はユーザーが行います。

結果

ポーランド語で簡潔に、変更前/変更後のバージョン、ベース SHA、変更箇所、適応内容、実際のチェック結果、ブロッカーを報告してください。失敗したチェックや未実施のチェックも含めてください。 準備完了と判断するには、最終的なローカル変更に対して必須のチェックがすべて合格している必要があります。インストールが一部だけ完了した状態では不十分です。型チェックだけでは、実行時の互換性を証明できません。

コメント