acomo ワークフローモデリング スキル

業務の説明から acomo のワークフローモデル（definition + dataSchema + policy）を設計・生成・改善する。

---

動作フロー

1. ユーザーの依頼を受け取る
2. 必要情報チェックリストと照合し、情報の充足度を把握する
3. 不足がある場合 → 本質的な質問に絞ってヒアリングする
4. 情報が揃った場合 → philosophy.md の原則に従ってモデルを設計する
5. 設計したモデルをユーザーに説明し、合意を得る
6. `acomo schema show` でスキーマ定義（`additionalProperties` の有無・型制約）を確認し、設計したモデルが準拠していることをセルフレビューする
7. acomo スキルの CLI で createWorkflowModel を使い登録する
8. フィードバックがあれば 2 に戻る

---

必要情報チェックリスト

ワークフローモデルを生成するには以下が揃っている必要がある。 各項目について「明確 / 不明確 / 不足」を判定してから設計に進む。

#	必要な情報	不足した場合の影響
1	業務の目的・概要	モデル全体の方向性が定まらない
2	申請者（誰が起票するか）	最初のタスクノードが決まらない
3	承認者・確認者（誰が判断するか、何段階か）	タスクノードの数と順序が決まらない
4	各ステップの作業内容	ノード名と役割が決まらない
5	却下・差し戻し方針（フロー終了 or 申請者へ差し戻し）	reject 終了か revert 差し戻しかが決まらない
6	並列承認の有無（複数承認者が同時に判断するか）	parallelFork/Join が必要か決まらない
7	データ項目（何の情報を入力・参照・更新するか）	dataSchema が定義できない
8	各データ項目の型（文字 / 数値 / 日付 / ファイル / 選択肢）	dataSchema のプロパティ型が決まらない
9	enum の選択肢（選択肢型の場合、何を選べるか）	dataSchema の enum 値が決まらない
10	タスクごとのデータ権限（各タスクで項目を編集するか参照のみか）	policy（read/write）が定義できない
11	段階限定の入力項目（例: 承認者コメントのみ承認タスクで記入）	dataSchema のキーと policy の対応が決まらない

---

ヒアリングの指針

情報が多数不足している場合: 最も本質的な1〜2問に絞る。全項目を一度に聞かない。

例:「申請者と承認者は誰ですか？何段階の承認が必要ですか？」

ほぼ揃っているが一部不明の場合: 不明点だけ確認するか、妥当な仮定を置いて提案する。

例:「却下後は申請者への差し戻し（修正・再提出）で考えてよいですか？それともフロー終了ですか？」

依頼が明確な場合: ヒアリングせずに設計に進み、仮定した内容をユーザーに明示する。

例:「以下の前提でモデルを設計しました。[仮定の一覧] 修正があれば教えてください。」

---

設計の手順（情報が揃った後）

1. ノードを列挙する

   • 開始イベント（必ず1つ）
   • 各アクターのタスクノード（1アクター × 1作業 = 1ノード）
   • 終了イベント（結末の数だけ）

2. エッジを設定する

   • 開始 → 最初のタスク: normal
   • タスク → 次のタスク（提出）: submit
   • 承認ノード → 承認先: approve
   • 承認ノード → 却下先（終了）: reject
   • 承認ノード → 差し戻し先（申請ノード）: revert

3. dataSchema を設計する

   • 論理型は string / number / date / file / enum の5種。API への JSON では 日付（date）は type: "string" + format: "date" + _acomoType: "date" とする（JSON Schema の type: "date" は使えない）。詳細は patterns.md と schemas/ の dataSchema.json を参照。
   • 各型の正確な JSON Schema 表現は acomo schema show で確認すること（acomo config show と同じ系譜の組み込みコマンド。バックエンドの AJV バリデーション定義を CLI に静的組み込みしたもの）。モデルを構築する前に必ず参照すること。
   • status は含めない
   • _order は 10, 20, 30... の10刻み

4. policy（データアクセスポリシー）を設計する

   • definition の各タスクノード ID と、dataSchema の各プロパティキーを対応づけ、write（編集可）か read（参照のみ）かを割り当てる
   • 多段承認・並列タスクでは、タスクノードごとにマトリクスを増やす
   • 詳細・よくあるミスは philosophy.md。型・「ノードにエントリがない場合」の意味は acomo の reference.md の ModelPolicy 節を参照

5. philosophy.md でセルフレビューする

   • よくある設計ミスに引っかかっていないか確認する

6. ユーザーへ説明・確認する

   • フローを自然言語で説明する（JSON をいきなり渡さない）
   • 「この内容でよいですか？」と合意を取る

7. CLI で登録する（patterns.md の CLI 手順を参照）

---

設計原則・制約の詳細

→ philosophy.md を参照

典型パターンのサンプル定義

→ patterns.md を参照

CLI / API の操作方法

→ acomo スキル（SKILL.md）を参照

データ構造の型定義・用語（policy / definition / actionPolicies との違いなど）は reference.md を参照する。