page-builder

ページビルダー

汎用テンプレートを生成するのではなく、対象製品にふさわしいページを構築します。

まず製品を把握する

対象ルート、周辺ページ、製品と対象ユーザー、ソースコンテンツ、デザインシステム、再利用可能なコンポーネント、データコントラクト、フレームワーク、レンダリングモデル、レスポンシブ対応の規約、メタデータ、テストを確認します。

以下を特定します。

• ページの種類と、ユーザーが完了すべきタスク
• ユーザーがどのようにページにたどり着き、何を理解または実行する必要があり、その後どこに進むのか
• 実際に存在する主張、データ、アセット、状態
• 再利用すべき既存のコンポーネントとプロジェクトの規約
• このページとサイト全体に関する判断との境界

不足情報によってページの役割、コンテンツ、データ、主要なアクションが大きく変わる場合は、簡潔な質問を1つしてください。影響を受けるセクションを削除したり、不足している事実を汎用的な文言で置き換えたりしないでください。

関連するガイダンスのみを読み込む

構築に関するガイダンスはreferences/workflow.md、最終確認の前にreferences/quality-gates.mdを読んでください。ルート、デプロイ、ロケール、市場、またはサポート対象のデータ機能がページに影響する場合は、references/delivery-localization.mdを読んでください。プロジェクトのコンテキストを利用する場合、またはタスクで得た長期的に有用な事実を返す場合は、references/contextus.mdを読んでください。

../../catalog/pages.jsonに該当するページリファレンスがある場合は、そのリファレンスのみを読み込んでください。ページの種類が定義されていない場合は、共通のワークフローを使用し、リポジトリの保守がタスクに含まれていない限り、恒久的なカタログ項目を作成しないでください。

ページの製品コンテキストを参考に優先事項を調整しますが、新たなページの位置づけを作り出さないでください。コンポーネントの推奨事項では、Bricksにある安定したIDを参照します。まず対象プロジェクトにすでに存在するコンポーネントを再利用してください。新しいコンポーネントが必要な場合に限り、Bricksのガイダンスを使用してください。Bricksがインストールされていなくても、Paginaは引き続き使用できます。

構築

1. ページコントラクトを定義します。目的、対象ユーザー、主要なタスク、必要な事実、入力、出力、対象外事項を明確にします。
2. ビジュアル構成を選ぶ前に、情報の階層とコンテンツを確立します。
3. 対象プロジェクトのコンポーネント、トークン、レイアウト、アイコン、コンテンツモデル、ルーティング規約を再利用します。
4. 実際の状態、レスポンシブな動作、アクセシビリティ、メタデータ、エラー処理を実装します。
5. Contextusが利用できる場合は、ユーザーが確認した長期的に有用な事実と、エージェントが発見した候補を返します。利用できない場合は、別のコンテキスト管理システムを作成せずに報告します。
6. 実際のルートと製品のコンテキストでページを検証します。

境界

• Paginaが担当するのは一度に1ページで、コンテンツ構造とコンポーネント構成も含みます。
• 新しいページのみを構築します。このスキルを使って既存ページを監査、最適化、修正、再構築しないでください。
• ページリファレンスは、長期的に有効な判断基準と受け入れ基準を示すものであり、固定されたビジュアルテンプレートではありません。
• 再利用可能なコンポーネントの動作は、対象のデザインシステム、またはBricksのようなコンポーネントリファレンスで定義します。
• サイトマップ、グローバルナビゲーション、URLアーキテクチャ、ページ間のユーザージャーニー、ウェブサイト全体の計画は、このスキルの対象外です。
• 製品に関する主張、顧客の証拠、価格、法的条件、運用機能を作り出さないでください。
• 具体的な要件がない限り、確立された技術スタックやデザインシステムを置き換えないでください。

完了

作成したページ、再利用した既存の規約とコンポーネント、検証したルートと状態、長期的に有用なコンテキストの更新または候補、未解決の重要な依存関係や製品上の判断を報告します。