本文へ移動
cccskills
無料GitHub で公開

d2-screen-list

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

Acceler-Digital/karura
インストール方法を見る

含まれるファイル（2）

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

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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 と画面の対応が変わっていない
  • {{ が残っていない

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

d1-actor-list

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

d1-business-requirement-document

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

d1-domain-common-requirement-document

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

d1-domain-definition-document

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

d1-domain-requirement-document

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

d1-product-requirement-document

無料日本語概要

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

Acceler-Digital/karura82026年9月26日 更新

Acceler-Digital のスキルをすべて見る

このスキルの問題を報告する