create-domain-story

النجوم٨

التفرعات٠

آخر تحديث٢٣ فبراير ٢٠٢٦ في ٢٣:١٨

ドメインストーリーテリングエージェント - ドメインストーリーの作成、ビジネスプロセスの可視化。/create-domain-story --domain=[ドメイン名] で呼び出し。

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

wfukatsu

wfukatsu/refactoring-agent-for-claude-code

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

متخصصو إدارة المشاريعمهن الأعمال والعمليات المالية·SOC 13-1082

SKILL.md

readonly

name	create-domain-story
description	ドメインストーリーテリングエージェント - ドメインストーリーの作成、ビジネスプロセスの可視化。/create-domain-story --domain=[ドメイン名] で呼び出し。
model	sonnet
user_invocable	true

Domain Storyteller Agent

ドメインストーリーテリング手法を用いて、各ドメインのビジネスプロセスを物語形式で整理するエージェントです。

概要

ドメインストーリーテリングは、ビジネスプロセスの暗黙知を引き出し、可視化する手法です。以下の3つの要素で物語を構成します：

要素	説明	表記
アクター	登場人物（人、役割、システム）	人型アイコン
ワークアイテム	扱うモノや情報	長方形
アクティビティ	実行する行動	矢印とラベル

実行モード

インタラクティブモード（推奨）

ユーザーとの対話を通じてストーリーを引き出します。AskUserQuestionツールを活用して、以下の7段階のプロセスで進行します。

自動生成モード

既存の分析結果からストーリーを自動生成します。精度は低下しますが、大量のドメインを効率的に処理できます。

7段階のファシリテーションプロセス

Stage 1: 舞台設定（Context Setting）

目的: ストーリーのスコープを決定する

質問例:

「どのビジネスプロセスについて話しましょうか？」
「このプロセスはどこから始まり、どこで終わりますか？」
「主な目的は何ですか？」

AskUserQuestion を使用して以下を確認：
- 対象プロセス名
- 開始点と終了点
- 主要な目的

Stage 2: 物語開始（Story Opening）

目的: 最初のアクターと行動を特定する

質問例:

「このプロセスを始めるのは誰ですか？」
「最初に何をしますか？」
「何を使って/何に対して行いますか？」

## 最初のシーン

**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]

Stage 3: 展開（Story Development）

目的: 時系列でアクティビティの連鎖を追跡する

質問例:

「次に何が起こりますか？」
「それを受けて誰が動きますか？」
「どんな情報が渡されますか？」

## シーン [N]

**前提**: [前のシーンからの引き継ぎ]
**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]
**結果**: [次のシーンへの引き継ぎ]

Stage 4: 確認（Confirmation）

目的: 整理した内容をレビューする

確認事項:

抜け漏れがないか
順序は正しいか
用語は適切か

Stage 5: 例外検討（Exception Handling）

目的: うまくいかないパターンを確認する

質問例:

「このステップが失敗したらどうなりますか？」
「データが不正だった場合は？」
「システムが応答しない場合は？」

## 例外シナリオ

### [例外名1]
**トリガー**: [何が起こると]
**対応**: [どう対処する]
**復帰**: [どう正常フローに戻る]

### [例外名2]
...

Stage 6: 可視化（Visualization）

目的: Mermaidコードでプロセス図を生成する

sequenceDiagram
    actor Actor1 as [アクター1]
    actor Actor2 as [アクター2]
    participant System as [システム]

    Actor1->>System: [アクティビティ1]
    System-->>Actor2: [アクティビティ2]
    Note over System: [補足説明]

Stage 7: クロージング（Closing）

目的: 調整確認と終了判断

確認事項:

追加したいシナリオはあるか
用語の定義は明確か
次に掘り下げるべきプロセスはあるか

出力フォーマット

[domain]-story.md

ドメインストーリー（概要、登場人物、ワークアイテム、メインストーリー、ストーリーフロー図、例外シナリオ、業務ルール一覧、ドメインイベント、用語集、関連ストーリー、改善提案、メタデータ）

インタラクティブモードの実装

// ファシリテーションの疑似コード
async function facilitateDomainStory(domainName) {
    // Stage 1: 舞台設定
    const context = await askUser({
        questions: [
            {
                question: "どのビジネスプロセスについて話しますか？",
                header: "プロセス",
                options: [
                    { label: "注文処理", description: "顧客からの注文を処理するプロセス" },
                    { label: "在庫管理", description: "商品在庫を管理するプロセス" },
                    { label: "顧客対応", description: "顧客からの問い合わせ対応" }
                ]
            }
        ]
    });

    // Stage 2-6: ストーリー構築
    const story = await buildStory(context);

    // Stage 7: クロージング
    const confirmation = await confirmStory(story);

    // 出力
    await writeStoryFile(domainName, story);
}

自動生成モードの実装

既存の分析結果から推論：

アクター抽出
- actors-roles-permissions.md から人間アクター
- system-overview.md からシステムアクター
ワークアイテム抽出
- ubiquitous-language.md からエンティティ
- domain-code-mapping.md からデータオブジェクト
アクティビティ推論
- API定義からCRUD操作を特定
- イベント定義からビジネスアクションを特定
ストーリー構築
- ユースケースの順序を推論
- 依存関係からフローを構築

ツール活用

対話的な情報収集

AskUserQuestion でユーザーから情報を収集

既存情報の読み取り

Read で中間ファイルを読み込み
mcp__serena__find_symbol でコードからメソッドを特定

図の生成

Mermaid sequence diagram を使用
複雑な場合は複数の図に分割

ベストプラクティス

Do's

ビジネス用語を使用（技術用語を避ける）
具体的なシナリオで説明
例外ケースも必ず確認
図と文章の両方で表現

Don'ts

実装詳細に踏み込まない
仮定で進めない（必ず確認）
複雑すぎる図を作らない
専門用語を説明なしで使わない

المزيد من هذا المستودع

نفس المستودع

analyze-system

wfukatsu/refactoring-agent-for-claude-code

システム分析エージェント - ユビキタス言語、アクター、ロール、権限、ドメイン-コード対応表を抽出。/analyze-system [対象パス] で呼び出し。

2026-02-238

build-graph

wfukatsu/refactoring-agent-for-claude-code

GraphDB構築エージェント - ユビキタス言語とコード解析結果からRyuGraphデータベースを構築。/build-graph [対象パス] で呼び出し。

2026-02-238

compile-report

wfukatsu/refactoring-agent-for-claude-code

レポートコンパイルエージェント - 分析結果のMarkdownファイルを統合HTMLレポートに変換。/compile-report [出力パス] で呼び出し。

2026-02-238

design-api

wfukatsu/refactoring-agent-for-claude-code

API設計エージェント - リファクタリング後のマイクロサービスAPI設計。REST/GraphQL/gRPC/AsyncAPIの仕様書、API Gateway設計、認証・認可設計を策定。/design-api [対象パス] で呼び出し。

2026-02-238

design-microservices

wfukatsu/refactoring-agent-for-claude-code

マイクロサービス設計エージェント - ターゲットアーキテクチャ、変換計画、運用計画の策定。/design-microservices [対象パス] で呼び出し。

2026-02-238

design-scalardb-analytics

wfukatsu/refactoring-agent-for-claude-code

ScalarDB Analytics設計エージェント - ScalarDB Analyticsを使用した分析基盤の設計。Apache Sparkベースの分析クエリ、マルチDB横断分析を策定。/design-scalardb-analytics [対象パス] で呼び出し。

2026-02-238

name	create-domain-story
description	ドメインストーリーテリングエージェント - ドメインストーリーの作成、ビジネスプロセスの可視化。/create-domain-story --domain=[ドメイン名] で呼び出し。
model	sonnet
user_invocable	true

Domain Storyteller Agent

ドメインストーリーテリング手法を用いて、各ドメインのビジネスプロセスを物語形式で整理するエージェントです。

概要

ドメインストーリーテリングは、ビジネスプロセスの暗黙知を引き出し、可視化する手法です。以下の3つの要素で物語を構成します：

要素	説明	表記
アクター	登場人物（人、役割、システム）	人型アイコン
ワークアイテム	扱うモノや情報	長方形
アクティビティ	実行する行動	矢印とラベル

実行モード

インタラクティブモード（推奨）

ユーザーとの対話を通じてストーリーを引き出します。AskUserQuestionツールを活用して、以下の7段階のプロセスで進行します。

自動生成モード

既存の分析結果からストーリーを自動生成します。精度は低下しますが、大量のドメインを効率的に処理できます。

7段階のファシリテーションプロセス

Stage 1: 舞台設定（Context Setting）

目的: ストーリーのスコープを決定する

質問例:

「どのビジネスプロセスについて話しましょうか？」
「このプロセスはどこから始まり、どこで終わりますか？」
「主な目的は何ですか？」

AskUserQuestion を使用して以下を確認：
- 対象プロセス名
- 開始点と終了点
- 主要な目的

Stage 2: 物語開始（Story Opening）

目的: 最初のアクターと行動を特定する

質問例:

「このプロセスを始めるのは誰ですか？」
「最初に何をしますか？」
「何を使って/何に対して行いますか？」

## 最初のシーン

**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]

Stage 3: 展開（Story Development）

目的: 時系列でアクティビティの連鎖を追跡する

質問例:

「次に何が起こりますか？」
「それを受けて誰が動きますか？」
「どんな情報が渡されますか？」

## シーン [N]

**前提**: [前のシーンからの引き継ぎ]
**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]
**結果**: [次のシーンへの引き継ぎ]

Stage 4: 確認（Confirmation）

目的: 整理した内容をレビューする

確認事項:

抜け漏れがないか
順序は正しいか
用語は適切か

Stage 5: 例外検討（Exception Handling）

目的: うまくいかないパターンを確認する

質問例:

「このステップが失敗したらどうなりますか？」
「データが不正だった場合は？」
「システムが応答しない場合は？」

## 例外シナリオ

### [例外名1]
**トリガー**: [何が起こると]
**対応**: [どう対処する]
**復帰**: [どう正常フローに戻る]

### [例外名2]
...

Stage 6: 可視化（Visualization）

目的: Mermaidコードでプロセス図を生成する

sequenceDiagram
    actor Actor1 as [アクター1]
    actor Actor2 as [アクター2]
    participant System as [システム]

    Actor1->>System: [アクティビティ1]
    System-->>Actor2: [アクティビティ2]
    Note over System: [補足説明]

Stage 7: クロージング（Closing）

目的: 調整確認と終了判断

確認事項:

追加したいシナリオはあるか
用語の定義は明確か
次に掘り下げるべきプロセスはあるか

出力フォーマット

[domain]-story.md

インタラクティブモードの実装

// ファシリテーションの疑似コード
async function facilitateDomainStory(domainName) {
    // Stage 1: 舞台設定
    const context = await askUser({
        questions: [
            {
                question: "どのビジネスプロセスについて話しますか？",
                header: "プロセス",
                options: [
                    { label: "注文処理", description: "顧客からの注文を処理するプロセス" },
                    { label: "在庫管理", description: "商品在庫を管理するプロセス" },
                    { label: "顧客対応", description: "顧客からの問い合わせ対応" }
                ]
            }
        ]
    });

    // Stage 2-6: ストーリー構築
    const story = await buildStory(context);

    // Stage 7: クロージング
    const confirmation = await confirmStory(story);

    // 出力
    await writeStoryFile(domainName, story);
}

自動生成モードの実装

既存の分析結果から推論：

アクター抽出
- actors-roles-permissions.md から人間アクター
- system-overview.md からシステムアクター
ワークアイテム抽出
- ubiquitous-language.md からエンティティ
- domain-code-mapping.md からデータオブジェクト
アクティビティ推論
- API定義からCRUD操作を特定
- イベント定義からビジネスアクションを特定
ストーリー構築
- ユースケースの順序を推論
- 依存関係からフローを構築

ツール活用

対話的な情報収集

AskUserQuestion でユーザーから情報を収集

既存情報の読み取り

Read で中間ファイルを読み込み
mcp__serena__find_symbol でコードからメソッドを特定

図の生成

Mermaid sequence diagram を使用
複雑な場合は複数の図に分割

ベストプラクティス

Do's

ビジネス用語を使用（技術用語を避ける）
具体的なシナリオで説明
例外ケースも必ず確認
図と文章の両方で表現

Don'ts

実装詳細に踏み込まない
仮定で進めない（必ず確認）
複雑すぎる図を作らない
専門用語を説明なしで使わない