Skip to content
cccskills
FreePublished on GitHub

d2-screen-list

画面一覧の新規作成・更新を支援する。機能一覧・ユースケース一覧をもとに、本システムが提供する画面を SCR-* で台帳化する D2 成果物。機能一覧の策定後、Figma で画面遷移図・ワイヤーフレームを起こす前に呼び出す。

The English summary is being prepared. Showing the original description.

Works withFigma
See how to install

Files included (2)

  • SKILL.md5.3 KB
  • template.md1020 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

D2: 画面一覧

遵守すべき重要ルール

  1. ID を振り直さない: SCR-* は Figma のフレームと本書を結ぶキーになる。採番済みの ID は変えず、欠番も再利用しない。追加時は全体の最大値の次を採番する。
  2. 機能一覧に無い画面を作らない: すべての画面は 1 つ以上の FUNC-* に裏付けられる。必要な機能が機能一覧に無ければ、画面を作らずユーザーに報告する。

インプットする成果物

成果物のパス内容
docs/D2.system-requirements/function-list.md機能一覧。画面を起こす起点
docs/D1.business-requirements/use-case-list.mdユースケース一覧。操作の流れと画面の並び順の根拠
docs/D1.business-requirements/user-story-list.mdユーザーストーリー一覧。画面に表示すべき情報の補助
docs/D1.business-requirements/domain-requirements/*.mdドメイン要求仕様書群。画面を分けるかの根拠(§データアクセス要求・§UI/UX 方針)
docs/D1.business-requirements/product-requirement-document.mdPRD。対象デバイスの根拠(§利用形態)

アウトプットする成果物

成果物のパス内容
docs/D2.system-requirements/screen-list.md画面一覧

アウトプットに使用するテンプレート

テンプレートのパス内容
.claude/skills/d2-screen-list/template.md画面一覧テンプレート

処理

1. 分岐する

  • もし機能一覧またはユースケース一覧が存在しないなら、先に作成が必要な旨を伝えて終了する。
  • そうでなく、docs/D2.system-requirements/screen-list.md が存在しないなら、§2(新規作成)に進む。
  • それ以外なら、§3(更新)に進む。

2. 新規作成

2.1 画面の要否を判定する

機能一覧の各 FUNC-* について、利用者が入力・選択・閲覧する機能であれば画面を起こす。システムが自動で実行する機能、外部サービスの画面で操作する機能、帳票・メールそのものであれば画面を起こさない。

2.2 画面候補を出す

UC ごとに操作の流れをたどり、画面候補を出す。同じアクターがその場で処理するイレギュラーは別の画面にせず、元の画面の画面概要に含める。単純な確認ダイアログやトーストは候補にしない。

2.3 まとめる・分ける

1 画面はワイヤーフレーム 1 枚の単位とする。アクターや UC が違っても、同じ業務情報を表示する候補は 1 画面にまとめる。アクターによる一部の表示・操作の違いは、画面を分けずに画面概要に書く。

以下のいずれかに当たる場合だけ画面を分ける。

  • UI/UX 方針が利用者種別ごとの体験の分離を求めている
  • データアクセス要求により、アクターごとに見せる情報のまとまりが異なる
  • 表示・操作が大きく異なり、ワイヤーフレーム 1 枚で描けない

デバイスの違いや、空状態・エラー表示などの状態違いでは分けない。

2.4 各列を埋める

列埋め方
IDSCR-<連番>。並び順どおりに 1 から振る
画面分類関連 UC の「ドメイン / 区分」。複数ドメインにまたがる場合は 横断
画面名〜画面 の体言止め。本書内で一意にする
画面種別一覧 / 詳細 / 入力 / 確認 / 完了 / ダッシュボード / ダイアログ / 案内(エラー・次行動提示など表示専用)のいずれか
画面概要画面の目的と主な表示情報・操作を 1〜2 文。遷移先・レイアウトや、画面の外で行うことは書かない
利用アクター画面を実際に操作・閲覧するアクター
対象デバイス利用アクターの PRD §利用形態 の端末(PC / タブレット / スマートフォン)
関連 UC / 関連 FUNC画面が関わる UC-* / FUNC-*

2.5 並び順・ラベル・サイドバー

  • ユースケース一覧のドメイン順・UC 順・操作の流れの順に並べ、横断 を最後に置く。
  • 関連 FUNC がすべて [フェーズ2] の画面は、画面名に [フェーズ2] を付ける。
  • sidebars.ts の機能一覧の直後に登録する。

3. 更新

  • 上流で変わった FUNC-* / UC-* に関わる行だけを §2 の手順で見直す。
  • 不要になった画面は行を削除し、ID を欠番にする。
  • 削除・統合・改名した画面があれば、最後に SCR-* と画面名をユーザーへ伝える(Figma 側の整理に使う)。

完成時のセルフチェック

  • 関連 FUNC が空の画面が無い
  • SCR-* に重複が無く、更新時は既存の ID と画面の対応が変わっていない
  • {{ が残っていない

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。

The English summary is being prepared. Showing the original description.

Acceler-Digital/karura8Updated Sep 26, 2026

See all skills by Acceler-Digital

Report a problem with this skill