mcpField
D
dev-frontend

dev-frontend

github.com/idaibin開発640 回インストール1 日前に更新
リポジトリ

dev-frontend について

dev-frontendは、既存のコードベースで承認済みのフロントエンド変更を実装するスキルです。再利用を優先し、必要な設計・スタック指針に従い、変更箇所に即した根拠で検証します。

主な機能

  1. 01適用される指針に沿った変更
  2. 02保守対象のコンポーネントと所有者の再利用
  3. 03必要に応じたフレームワーク・スタック資料の選択
  4. 04低コストな根拠による重点検証
  5. 05範囲・確認・対象外・不足事項の報告

活用シーン

  1. 01既存スタックでのフロントエンド変更
  2. 02所有者と契約に基づく変更なしの確認
  3. 03フレームワーク・ルーティング・スタイルの変更

インストール

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

$npx skills add https://github.com/idaibin/skills --skill dev-frontend

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
assets/
frontend-visual-evidence.example.json
frontend-visual-evidence.schema.json
references/
behavior-first.md
checklist.md
code-quality.md
codebase-design.md
decomposition.md
eval-cases.md
framework-profiles.md
frontend-css-governance.md
frontend-layout-governance.md
frontend-visual-evidence.md
frontend-visual-gate-example.md
interaction-motion-quality.md
openapi-contract-governance.md
project-grounding.md
protocol-contracts.md
specification-authorities.md
stack-guidelines.md
styling-systems.md
ui-components-and-tokens.md
usage.md
visual-direction-and-anti-slop.md
scripts/
validate-frontend-visual-evidence.py

詳細

フロントエンドの実装

開始条件

既存のスタックで、許可された最小限のフロントエンド部分を実装します。有効なガイダンス、現在の Worktree、対象のルート/コンポーネント、および適用される Product/UI/DESIGN の権威ある仕様のみを確認します。決定的な動作契約またはビジュアル契約が未解決の場合は停止します。

ルートマップ

リクエスト条件確認するもの結果
フロントエンドのソースを変更する場合チェックリストの該当セクション既存のものを優先して実装
ツールチェーン、依存関係、ルーティング、スタックの移行、またはレンダリング/エフェクトのセマンティクスを変更する場合スタックガイドラインの該当セクションスタック固有の制約
フレームワークの状態、ライフサイクル、ルーティング、またはコンポーネント API のセマンティクスを変更する場合選択したフレームワークプロファイルフレームワークに準拠した変更
変更なし、または承認済みベースラインの確認を行う場合チェックリスト正確なオーナーシンボルとベースラインチェックの証拠
動作/公開シーム、オーナーシップ、または品質に関する懸念が該当する場合動作を優先、コードベース設計、および/またはコード品質対象を絞った設計/検証
変更対象のファイル、コンポーネント、または関数に、独立した UI、状態、データ、副作用、またはビジネス上の責務が混在している場合分解責務に一貫性のあるオーナーと、読みやすいオーケストレーション
スタイリングシステムまたは CSS のオーナーシップを変更する場合変更対象に応じて、スタイリングシステムまたはCSS ガバナンス対象を絞ったスタイリング
共有コンポーネント/トークン、またはレイアウトのオーナーシップを変更する場合コンポーネント/トークンまたはレイアウト該当するビジュアル契約
アニメーションまたはビジュアルの方向性を変更する場合モーションまたはビジュアルの方向性該当するインタラクション/ビジュアル契約
選択したソースのビジュアル検証が該当する場合仕様の権威ある定義およびビジュアルエビデンス実行時の比較境界
API/プロトコル、または境界をまたぐシグナルが該当する場合OpenAPI ガバナンス、プロトコル契約、および/またはプロジェクトの根拠資料条件を確認したインテグレーション作業

不変条件

  • 新規作成する前に、最も近い保守対象のオーナーを再利用し、ルーティング、状態/データ、コンポーネント、スタイリングのオーナーシップを維持します。
  • サイズはレビューの目安として扱い、行数のルールにはしません。安定したオーナーシップ、動作、ライフサイクル、副作用、または検証の境界でのみ分割します。
  • 変更なしの確認でも、現行ベースラインの対象を絞ったチェックを実行する前に、正確なオーナーパスとシンボル、およびそれに対応する契約を確認して報告します。
  • 変更した動作に最も近い、最も低コストの証拠を使用します。ソース/差分のチェック、ホットリロードが利用できる稼働中の開発環境、対象を絞ったテストの順に確認し、その境界または提供段階で必要な場合にのみ、本番向けの完全なビルドを行います。
  • Product の動作と UI のビジュアル面での準備状況は、独立したものとして扱います。ソース/ビルドの証拠だけでは、ブラウザー/クライアント/実行時の受け入れを証明できません。
  • ビジュアルアセットの生成、ブラウザー/クライアントの状態操作、レビュー、Git の変更は行いません。
  • このフェーズの証拠をコーディネーターに返し、コーディネーターがすでに許可されている実行時の受け入れ、修正、提供をそれぞれのオーナーを通じて続行します。オーナーを切り替えただけでは、新たなタスク/サブエージェントも、承認の再取得も必要ありません。

出力マップ

適用される場合は、対象範囲、権威ある仕様、再利用の判断、選択したプロファイル、変更したファイル/契約、対象を絞った検証、開発環境で得た証拠、本番ビルドの状況、対象外の事項、および不足事項を個別に報告します。

リファレンスマップ

  • 基本的な実装については、該当するチェックリストのセクションのみを読み、技術スタックとフレームワークの詳細についてはルートマップを参照してください。
  • ルートマップに記載された条件別のリファレンスは、その条件に該当する場合にのみ読み込んでください。
  • 視覚的なエビデンスを作成する場合にのみ、フロントエンドの視覚的ゲートの例を読んでください。
  • トリガーと適用範囲については、使用方法を読んでください。
  • メンテナーのみ:評価ケースを読んでください。通常の実行時には読み込まないでください。

コメント