prd-grade-fe

prd-grade-fe

$SKILL はこのスキルの ベースディレクトリ を指します（スキル読み込み時の「Base directory for this skill」の行。framework リポジトリでは skills/prd-grade-fe）。すべてのスクリプトとリファレンスはスキルディレクトリに含まれており、リポジトリには依存しません。

薄いハブです。設計ルールは所有しません。美的ルールは hallmark（skills/hallmark/SKILL.md）、決定論的ルールは impeccable（npx -y [email protected] detect、バージョンを固定）に委ねます。ハブが所有するのは順序とフェーズ間の契約、そして --self-test を備えた2つのスクリプトです。

ファイル	役割
scripts/design-sync.py	design.md を唯一の信頼できる情報源とします。css :root{} ブロックから YAML frontmatter（impeccable が読み込みます）と tokens.css を生成します。drift がある場合、--check は rc 1 を返します。
scripts/fe-gate.sh	納品前のゲートです。ターゲットの存在を確認 → detect --json → 意味に沿った rc 0/1/2 → viewport-check.mjs 320/375/414/768。終了コード 0 は合格、1 は impeccable のエラー、2 は finding／viewport の不合格、3 はスキップ（node／ネットワークが不足）、4 はターゲット不足です。
scripts/badge-consistency.py	impeccable に存在しない決定論的ルール（GH#164）です。1つのファイル内で、ステータスバッジ（render*Badge／*Status*／*Pill*／pill span）は、アイコンかドットか・rounded-*・トークン定数（STATUS_GLASS）のシグネチャを統一する必要があります。多数派（≥2）と異なるバッジを file:line で報告し、fe-gate はこれを finding として rc 2 に含めます。
references/presets/macos-glass.design.md	detect rc 0 を通過したデフォルトプリセットです。証拠は macos-glass.evidence.md にあります。
references/intake.md	Route A/B/C → design.md。
references/impeccable-audit.md	監査ルーブリック（5軸／20点）・強化・磨き込み、出典付きの要点整理。

WHAT

目的とコンテキスト

• 目的： 本番品質のフロントエンドページ／画面を、ゲートキーパー付きで制作します。テーマは1つの design.md に固定し、hallmark に従ってトークンのみで構築します。fe-gate.sh が合格し、P0 が 0 になるまで納品しません。
• トリガー（使用するタイミング） — 旧 ## When to use の内容：
  • ユーザーが、手早いモックアップではなく本番投入するフロントエンドページ／画面を求めている場合（手早いモックアップ → /br または hallmark のみ）。
  • ユーザーがテーマを「デフォルトで進めて」「これがデザイン資料です」、または「このページと同じように作って：」のように提示する場合。
  • プロジェクトに design.md がすでにあり、チェックゲート付きで同じデザインシステムの画面を追加する場合。
• 対象外： 手早いモックアップではありません（→ /br または hallmark のみ）。設計ルールは所有しません（美的ルール = hallmark、決定論的ルール = impeccable）。BR→frame のパイプラインは扱いません。

メンタルモデル

テーマのソース（A プリセット · B 資料 · C URL）→ design.md（唯一の信頼できる情報源）→ design-sync.py → tokens.css + frontmatter → トークンのみで構築（hallmark）→ fe-gate.sh（impeccable detect + badge-consistency + 4 viewport）→ 監査／強化／磨き込み → レポート。ハブが所有するのは順序とフェーズ間の契約です。ルールは hallmark／impeccable にあります。

入力と出力の契約

	フィールド	必須？	意味
In	ページ／画面の brief	はい	制作するもの
In	テーマのソース A/B/C、対象ユーザー、ユースケース、トーン	いいえ	「go ahead」／空欄の場合 → A + brief から2～4語で推測し、1文で明示します
In	既存の design.md	いいえ	存在し、--check が rc 0 の場合 → 再利用し、フェーズ3へ進みます
Out	同期済みの design.md + tokens.css	はい	design-sync.py --check が rc 0
Out	design の stamp と critique を含む、トークンのみの HTML 出力	はい	ライト／ダークの切り替え、相対パスのフッター
Out	fe-gate.report.json + 8項目のレポート（フェーズ5）	はい	「本番投入可能」とするのは、fe-gate の終了コードが 0 で、P0 = 0 の場合のみです

ルールと機能

• RULE-01 (MUST): hallmark の rubric をここにコピーしないでください。ルールを変更する場合は、hallmark または references/impeccable-audit.md（出典 + sha）を修正してください。
• RULE-02 (MUST): 絶対に npx impeccable install を呼び出さないでください（3.6.1 では install に --help がなく、実際に $HOME にインストールされます）。--scope は必ずスペースを入れずに記述してください（--scope=type）。stdout の JSON を信頼し、stderr は信頼しないでください（npx はストリームを結合します）。
• RULE-03 (MUST): 修正を3回繰り返しても finding が残る場合は、残存分の表を添えて引き渡し、その旨を明記してください。または、.impeccable/config.json の {"ignores":[...]} に理由付きの waiver を記載し、レポートで明示してください。こっそり ignore しないでください。
• RULE-04 (MUST): node またはネットワークが不足している場合は、レポートに skipped: <理由> と記載し、exit gate は ≠ 0 としてください。「たぶん問題ない」という例外はありません。
• RULE-05 (MUST): design.md がすでに存在する場合は、上書きしないでください。システムを変更する場合は、hallmark design-md の no-overwrite policy に従い、## Variants を AMEND してください。
• RULE-06 (MUST): skill の修正時にセルフチェックを行ってください。python3 $SKILL/scripts/design-sync.py --self-test && python3 $SKILL/scripts/badge-consistency.py --self-test && bash $SKILL/scripts/fe-gate.sh --self-test を実行してから、bash fdk/tools/sync-skill.sh prd-grade-fe を実行します。
• Capabilities: プロジェクト内の design ファイルと出力の読み書き、トークン同期スクリプトおよび決定論的なアンチパターン検出ゲート（バージョン固定）の実行、ヘッドレスブラウザーによる4つのビューポートの測定、テーマのソースとしての URL／デザインドキュメントの読み取り。

失敗時の境界

• node またはネットワークが不足している場合は、skipped: <理由> とし、gate exit ≠ 0 にします。レポートで問題なしと述べてはいけません（partial）。
• fe-gate の rc が 1 / 3 / 4 の場合は blocked とし、停止して原因を記録します。1/3/4 から「問題なし」へ進む経路はありません。
• 修正を3回行った後の rc 2 は partial です。残存 finding の表を添えるか、理由付きの waiver をレポートに記載して引き渡してください。
• design-sync.py --check の rc 1（drift）の場合は、フェーズ3に進めません。
• design.md がすでにある状態でユーザーがテーマの変更を求めた場合は、上書きせず ## Variants を AMEND してください。

HOW

メインワークフロー

Step	Type	Inputs	Action	Outputs/exit	Failure/next
W01	deterministic	project	フェーズ0の事前確認：ls design.md …、command -v node、design-sync.py --check	システムが固定済みか、node があるか	固定済み → B01；node なし → B02
W02	judgment	brief	フェーズ1のインタビューを1メッセージで実施（テーマのソース · オーディエンス · ユースケース · トーン）	回答または推論の明示	—
W03	effect	テーマのソース	フェーズ2で変数 A/B/C を固定 → design.md → design-sync.py && --check	rc 0	rc 1 → drift を修正
W04	effect	design.md	hallmark に従って構築。token-only、ファイル先頭に stamp	HTML 出力	軸ごとの critique が < 3 → W05 の前に修正
W05	deterministic	出力	フェーズ4の gate：fe-gate.sh（≤ 3回）→ /20 で監査 → harden/polish → slop-test → 最後に fe-gate	exit 0 + P0 = 0	rc 1/3/4 → blocked；3回修正後に rc 2 → partial
W06	judgment	結果	フェーズ5の納品 + 8項目のレポート	レポート	—

各ステップの詳細（W01–W06 の信頼できる情報源）— 旧 ## Steps セクション、原文：

フェーズ0 — 事前確認（マシンが自動で確認できることは尋ねない）

ls design.md DESIGN.md tokens.css 2>/dev/null; command -v node && echo node-ok
python3 $SKILL/scripts/design-sync.py --check 2>/dev/null; echo sync-rc=$?

• design.md があり、--check の rc が 0 の場合は、「システムは固定済みです。再利用します」と伝え、フェーズ3に進みます（ただし、ユーザーがテーマの変更を求めた場合は references/intake.md §「プロジェクトに design.md がすでにある場合」に従います）。
• node がない場合もフェーズ1～3は実施しますが、フェーズ4では skipped と記載し、レポートで問題なしと述べてはいけません。

フェーズ1 — 1メッセージでインタビュー（hallmark の質問をまとめ、追加質問はしない）

構築を始める前に、4つの情報が必要です。答えられる項目だけ答えるか、**「go ahead」**と言ってください。

1. テーマのソース — [A] デフォルトの macOS glass · [B] デザインドキュメントのパス（ファイル／フォルダー） · [C] 対象ページの URL
2. オーディエンス — 誰が使い、どんな知識をすでに持っていますか？
3. ユースケース — このページで促したい行動は何ですか？
4. トーン — 両極から1つ選択：editorial · brutalist · soft · utilitarian · luxury · playful · technical · austere

「go ahead」と言うか、回答が空欄の場合は A を選び、brief から2～4を推論し、返信の冒頭で一文にして推論を明示してください（hallmark Step 1 のオプトアウトプロトコル）。「brief が十分明確」という例外はありません。必ず質問し、ユーザーが2秒でパスできるようにします。

フェーズ 2 — トークンのロック（references/intake.md）

• A：cp $SKILL/references/presets/macos-glass.design.md ./design.md を実行し、1 行目のプロジェクト名を変更します。
• B：資料を読み込み → ファイル名:行番号の出典付きスキーマ表 → 補足の質問を1つ → design.md + § Provenance に記録します。
• C：hallmark study <URL>（URL モード、拒否リスト + 宣誓）→「DNA をロック」→ § Provenance + § Notes（リズムの盲点、引き継がないアンチパターン）を含む design.md。
• 続いて、python3 $SKILL/scripts/design-sync.py && python3 $SKILL/scripts/design-sync.py --check を実行し、rc が 0 になってから次に進みます。
• Genre / Macrostructure / Theme を言葉で明示します（hallmark Step 2.5）。

フェーズ 3 — ロック済みのシステムに沿ってビルド

• ロック済みの design.md を使い、hallmark のデフォルトフロー（Step 2 macrostructure → 3 ruleset → 5 preview → 6 build）を実行します。diversification は逆転し、画面間でシステムを統一します。
• すべての色、フォント、角丸、モーションは tokens.css の var(--…) 経由で指定します（hallmark discipline 3）。インラインの hex/oklch は使いません。トークンが足りない場合は、design.md の :root ブロックに追加してから design-sync.py を再実行します。
• 閲覧者向け HTML 出力：ラベル付きトグルボタンによるライト／ダーク切り替え + html[data-theme] + localStorage + FOUC 対策；13″向けのコンパクトな文字サイズ；フッターに対象ファイルの相対パスを記載します。
• ファイル先頭にスタンプを記載します：`` および /* Hallmark · pre-emit critique: P? H? E? S? R? V? */（6 軸。3 未満の軸があれば、フェーズ 4 に進む前に修正します）。

フェーズ 4 — ゲート（機械が先、人が後）

1. bash $SKILL/scripts/fe-gate.sh <output.html …> を実行し、antipattern | file:line | snippet の表と fe-gate.report.json を確認します。
   • badge lệch pattern so với N badge anh em の行は badge-consistency を示します。他のバッジ（多数派）に合わせて不一致のバッジを修正し、逆に他のバッジを修正しないでください。
   • rc 2 → 該当する finding を修正します（design.md のトークンを変更して同期するか、マークアップを修正）。その後、再実行します。最大 3 ラウンド。 レポートに記載できるよう、各ラウンドの finding 数を記録します。
   • rc 1 / 3 / 4 → 停止し、原因を記録します。1/3/4 から「問題なし」に至る経路はありません。
2. references/impeccable-audit.md を読み込み、5 軸を 20 点満点で採点し、P0–P3 を列挙します。Harden、次に Polish のチェックリストを実施します。P0 は 0 でなければなりません。
3. 出力に hallmark slop-test（skills/hallmark/references/slop-test.md）を実行し、赤になったゲートを修正します。
4. すべての修正後に fe-gate.sh を最後にもう一度実行します（Harden／Polish の修正によって finding が再発する可能性があります）。

フェーズ 5 — 納品 + レポート

レポートには、次の項目をこの順序で含めます：（1）フェーズ 1 の推論／回答；（2）Genre/Macrostructure/Theme + Theme の出典；（3）6 項目の critique；（4）第 1 ラウンドから n ラウンドまでの finding 表と最終 rc；（5）監査スコア /20 + P0 件数；（6）4 つの viewport；（7）出力の相対パス；（8）該当する場合は skipped。「本番環境に対応しています」という文言は、fe-gate の exit が 0 かつ P0 = 0 の場合に限り記載できます。

分岐

ID	種類	条件	動作	スキップ／失敗	再合流
B01	conditional_required	design.md があり、--check の rc が 0	「システムはロック済みなので再利用します」と伝え、W02–W03 を省略	ユーザーがテーマの変更を求めた場合 → references/intake.md § 「プロジェクトに design.md がすでにある場合」	W04
B02	recovery	node / ネットワークがない	フェーズ 1–3 は実施し、フェーズ 4 では skipped と記録	レポートで問題なしと述べてはいけません	W06
B03	user_optional	テーマの出典 = B（資料）	ファイル名:行番号の出典付きスキーマ表 → 補足の質問を1つ → design.md + § Provenance	—	W03（同期）
B04	user_optional	テーマの出典 = C（URL）	hallmark study <URL> →「DNA をロック」→ design.md + § Provenance + § Notes	—	W03（同期）
B05	recovery	fe-gate rc 2	該当する finding を修正（design.md のトークンを変更して同期するか、マークアップを修正）→ 再実行。最大 3 ラウンド	3 ラウンドを超えた場合 → 残件の表または理由付きの waiver を添えて納品	W05

検証と停止条件

機械ゲート：fe-gate.sh の exit 0（impeccable detect rc 0 + badge-consistency + 4 つの viewport 320/375/414/768）および design-sync.py --check の rc 0。人によるゲート／ルーブリック：5 軸の監査で 20 点満点、P0 = 0、slop-test で赤なし。ゲートの修正は最大 3 ラウンドです。すべての修正後、fe-gate を最後にもう一度実行します。

例

• 成功例： /prd-grade-fe dựng trang danh sách đơn hàng cho app quản lý kho, mặc định theme → A を選択し、cp でプリセットの macos-glass を design.md にコピー、sync rc 0、token-only でビルド、fe-gate の1回目は rc 2（finding 2件）→ 修正 → 2回目は exit 0、P0 = 0 → 8項目のレポートに「本番環境への導入準備完了」と記載。
• 境界条件／失敗例： node がないマシン → フェーズ1～3は実行し、fe-gate は exit 3 → レポートに skipped: node がありません と記載し、「本番環境への導入準備完了」とは書きません。

呼び出し例

/prd-grade-fe dựng trang danh sách đơn hàng cho app quản lý kho, mặc định theme
/prd-grade-fe trang pricing, theme lấy từ docs/brand/ (folder)
/prd-grade-fe landing cho sản phẩm X, làm giống https://example.com