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

d2-screen-flow-diagram

画面遷移図の新規作成・更新を支援する。画面一覧の SCR-* を利用者ごとの Mermaid 図でつなぎ、画面間の遷移を表す D2 成果物。画面一覧の策定後に呼び出す。

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

含まれるファイル（2）

  • SKILL.md6.6 KB
  • template.md1.2 KB

SKILL.md（原文）

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

D2: 画面遷移図

遵守すべき重要ルール

  1. 画面一覧に無い画面を描かない: 図に置く画面は画面一覧の SCR-* だけとし、画面名は画面一覧と一致させる。遷移に必要な画面が画面一覧に無ければ、画面を足さずユーザーに報告する。
  2. 業務の進め方を作らない: 業務状態を進める・戻す遷移は、ドメイン要求仕様書の §業務状態遷移 と §業務運用(イレギュラー対応)にあるものだけを描く。

インプットする成果物

成果物のパス内容
docs/D2.system-requirements/screen-list.md画面一覧。図に置く画面と、その利用アクター・並び順・画面概要
docs/D1.business-requirements/product-requirement-document.mdPRD。図の分け方の根拠(§システム利用ユーザーと体験設計)と、利用者ごとの利用経路(§利用形態)
docs/D1.business-requirements/domain-requirements/*.mdドメイン要求仕様書群。進む・戻る遷移の根拠(§業務状態遷移)、例外時の遷移の根拠(§業務運用(イレギュラー対応)・ドメイン共通要求仕様書 §UI/UX 方針)

アウトプットする成果物

成果物のパス内容
docs/D2.system-requirements/screen-flow-diagrams/<ACT-N>_<アクター名>.md画面遷移図。1 図 1 ファイル

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

テンプレートのパス内容
.claude/skills/d2-screen-flow-diagram/template.md画面遷移図テンプレート

処理

1. 分岐する

  • もし画面一覧が存在しないなら、先に作成が必要な旨を伝えて終了する。
  • そうでなく、docs/D2.system-requirements/screen-flow-diagrams/ が存在しないなら、§2(新規作成)に進む。
  • それ以外なら、§3(更新)に進む。

2. 新規作成

2.1 図を分ける

PRD §システム利用ユーザーと体験設計 の表の行ごとに 1 図とする。表に無いアクターが画面一覧の利用アクターに現れるなら、そのアクターごとに 1 図とする。ただし、利用する画面がすべて他の 1 つの図に含まれるアクターは、その図にまとめる。

1 図を 1 ファイルとし、ファイル名は図のアクターの ID とアクター名をアンダースコアでつないだもの(例: ACT-15_ACT-16_コンプライアンス部・内部監査部.md)とする。アクターが複数なら、ID どうしはアンダースコア、アクター名どうしは中黒で連結する。

各図には、画面一覧で利用アクターに当該図のアクターを含む画面をすべて置く。複数の図のアクターが使う画面は、それぞれの図に置く。

2.2 遷移を出す

同じ利用者が続けて操作する画面の間にだけ線を引く。

  • 進む遷移: 画面一覧の並び順と画面種別(入力から確認、確認から完了 等)を、§業務状態遷移 の進む遷移に照らして引く。工程をまたいで同じ利用者が続けて操作するなら、工程間でも線を引く。
  • 戻る遷移: §業務状態遷移 の戻る遷移(修正・見直し 等)だけを引く。単に前の画面へ戻る・キャンセルするだけの遷移は引かない。
  • 一覧から開く遷移: 一覧・ダッシュボードの画面から、そこで選んだ案件を扱う画面へ線を引く。
  • 例外時の遷移: §業務運用(イレギュラー対応)の事象のうち、利用者に次の行動を示す必要があるものは、§UI/UX 方針 の例外時の体験に従って案内の画面への線を引く。入力エラーの表示のように、その画面の中で完結するものは引かない。
  • 入口: 認証の画面から、利用者が最初に使う画面へ線を引く。

もし図の中の多くの画面から同じ画面へ遷移するなら、個々の画面から線を引かず、遷移元の subgraph から 1 本で引く。

もし通知から起動する、別の利用者から端末を引き渡される、別の利用者の作業へ引き継ぐといった図の外との出入りがあるなら、出入口のノードを置いて線を引く。PRD §利用形態 で他の利用者の端末を介して使う利用者がいるなら、端末を引き渡す箇所を双方の図に出入口として描く。

2.3 図を埋める

  • 図は左から右へ流れるよう flowchart LR で描き、画面は画面一覧の画面分類ごとに subgraph で囲む。
  • 画面のノード ID は SCR<連番> とし、ラベルは画面名と SCR-* を改行して並べる。出入口のノードは角丸にする。
  • 線のラベルには、遷移の契機を業務上の操作・結果で短く書く。ボタン名・画面項目は書かない。一覧から開く遷移のように契機が自明な線にはラベルを付けない。
  • フェーズ2 以降でだけ成立する遷移は、線のラベルに [フェーズ2] を付ける。
  • 上流に根拠の無い遷移を引いたなら、図の直後のブロック要確認マーカーにまとめる。
  • タイトルは図のアクターを アクター名: ACT-N の形で書く。
  • sidebars.ts の画面一覧の直後に「画面遷移図」カテゴリを置き、各ファイルをタイトルと同じラベルで登録する。PRD の表の順に並べ、表に無いアクターの図は画面一覧で最初に現れる順に後ろへ並べる。

3. 更新

  • 画面一覧で追加・削除・改名・利用アクターの変更があった画面と、ドメイン要求仕様書で変わった業務状態遷移・イレギュラーに関わるノードと線だけを §2 の手順で見直す。
  • 削除された画面はノードと線を消し、前後の画面の線を §2.2 で引き直す。
  • もし利用アクターの変更で図の分け方が変わるなら、§2.1 に従ってファイルを追加・削除し、サイドバーも合わせる。

完成時のセルフチェック

  • 画面一覧の全 SCR-* が、利用アクターを含む図のすべてに現れ、それ以外の図には現れていない
  • ノードの画面名が画面一覧と一致している
  • どの線にもつながっていないノードが無い
  • {{ が残っていない

レビュー

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

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

同じリポジトリのスキル

概要と使いどころ

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 のスキルをすべて見る

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