
Acomo
Read and reason about acomo getWorkflowModel JSON—nodes, edges, policies, and dataSchema—when implementing or debugging approval-style workflows.
Overview
acomo is an agent skill most often used in Build (also Ship review, Operate iterate) that documents acomo workflow JSON types—nodes, edges, policies—for getWorkflowModel responses.
Install
npx skills add https://github.com/progress-all/acomo-skills --skill acomoWhat is this skill?
- Documents ModelDefinition shape with nodes and edges for workflow graphs
- Lists five NodeType values: event, task, exclusiveFork, parallelFork, parallelJoin
- Explains actionPolicies with NodeActionType plus BinaryExpression allow conditions
- Covers exclusiveFork and parallelJoin condition expressions and destinations
- Companion to acomo SKILL.md when parsing definition, dataSchema, and policy payloads
- 5 NodeType values documented: event, task, exclusiveFork, parallelFork, parallelJoin
Adoption & trust: 1 installs on skills.sh; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You fetched an acomo workflow model JSON and cannot tell which node types auto-advance, how forks join, or what an action policy expression means.
Who is it for?
Developers integrating acomo-backed approval or operations workflows who need a typed glossary while coding parsers, simulators, or agent tools.
Skip if: Builders who only need high-level marketing copy about workflows without reading getWorkflowModel JSON structures.
When should I use this skill?
When interpreting acomo workflow model JSON from getWorkflowModel or aligning agent code with definition, dataSchema, and policy structures.
What do I get? / Deliverables
You can map definition fields to correct handling per NodeType, evaluate branch destinations, and align agent-generated code with dataSchema and policy rules.
- Correct mental model of nodes, edges, and policies
- Agent or code that handles each NodeType and branch condition appropriately
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build backend because the reference explains workflow definition types agents use while coding integrations against acomo models. Content maps directly to ModelDefinition, Node types, action policies, and fork/join semantics consumed from backend APIs and agents.
Where it fits
Generate TypeScript types and validators that match acomo Node and Edge definitions before calling transition APIs.
Implement a simulator that respects task nodes waiting for external input versus auto-processing fork nodes.
Walk policy allow expressions on each NodeActionType before releasing a workflow change to production tenants.
Trace why parallelJoin has not fired by checking whether all child branches reached the join node per the reference semantics.
How it compares
Reference lexicon for acomo workflow graphs, not a generic BPMN tutorial or a one-shot deployment skill.
Common Questions / FAQ
Who is acomo for?
Backend-focused solo builders and indie teams using acomo skills who must interpret workflow definition, schema, and policy JSON accurately in code or agents.
When should I use acomo?
While building acomo integrations, before shipping workflow changes you need to review for fork/join logic, and when operating production cases stuck on task or parallelJoin nodes.
Is acomo safe to install?
Check the Security Audits panel on this Prism page; the skill is documentation-only but still verify provenance before agents act on workflow APIs with your credentials.
SKILL.md
READMESKILL.md - Acomo
# acomo データ構造リファレンス acomo スキル(SKILL.md)の補助資料。`getWorkflowModel` で取得する JSON の definition / dataSchema / policy を読むときの型と用語をまとめる。 ## ModelDefinition(ワークフロー定義) ```typescript type ModelDefinition = { nodes: Node[]; // ワークフローのノード(タスク、イベント、分岐など) edges: Edge[]; // ノード間の接続 }; ``` ### Node(ノード) ```typescript type Node = { id: NodeId; // ノード固有ID(文字列) name: string; // ノード名(日本語) type: NodeType; // ノード種別 eventType?: "start" | "end"; // イベントノードの場合の種別 actionPolicies?: { // 操作権限ポリシー type: NodeActionType; // アクション種別 allow: BinaryExpression; // 許可条件式 description?: string; // 説明 }[]; conditions?: { // 分岐条件(exclusiveFork, parallelJoin) expression: BinaryExpression; type?: FlowType; destination: NodeId; }[]; position?: { x: number; y: number }; // エディタ上の座標(表示用。業務ロジックでは不要なら無視してよい) canRevert?: boolean; // 差し戻し可能か }; ``` ### NodeType(ノード種別) | 種別 | 説明 | 自動処理 | | --------------- | ------------------------------------------------------ | ------------------- | | `event` | 開始/終了イベント。eventType で判別 | 開始: Yes, 終了: No | | `task` | ユーザーの操作が必要なタスク | No(外部入力待ち) | | `exclusiveFork` | 排他的条件分岐。conditions を評価して1つのルートに進む | Yes | | `parallelFork` | 並列処理の開始。複数の子プロセスに分岐 | Yes | | `parallelJoin` | 並列処理の合流。全子プロセスが到達すると次に進む | Yes(条件充足時) | ### NodeActionType(アクション種別) | 種別 | 説明 | | --------- | ------------------------ | | `manage` | 全操作が可能 | | `read` | 読み取りのみ | | `start` | プロセス開始 | | `submit` | 提出(次のノードへ進む) | | `approve` | 承認 | | `reject` | 却下 | | `revert` | 差し戻し | | `update` | データ更新 | ### Edge(エッジ) ```typescript type Edge = { from: string; // 遷移元ノードID to: string; // 遷移先ノードID type: FlowType[]; // 遷移種別の配列 }; ``` ### FlowType(遷移種別) | 種別 | 説明 | | --------- | --------------------------------- | | `normal` | 通常の遷移(開始→最初のタスク等) | | `submit` | 提出による遷移 | | `approve` | 承認による遷移 | | `reject` | 却下による遷移 | | `yes` | 条件分岐でTrue | | `no` | 条件分岐でFalse | ## ModelDataSchema(データスキーマ) JSON Schema のサブセット。ワークフローで扱うデータの構造を定義する。 ```typescript type ModelDataSchema = { type: "object"; properties: { [key: string]: ModelDataSchemaProperty; }; required?: string[]; additionalProperties: false; }; type ModelDataSchemaProperty = { type: "string" | "number" | "date" | "object" | "array"; title: string; // 日本語ラベル description?: string; // 説明 enum?: string[]; // 列挙値(type が 'string' の場合) items?: any; // 配列要素のスキーマ(type が 'array' の場合) _order?: number; // 表示順序(10, 20, 30...) _acomoType?: string; // acomo 独自拡張型 _recordKey?: string; // レコード型のキー }; ``` ### \_acomoType(独自拡張型) | 型 | 説明 | | -------- | ---------------------------------- | | `string` | テキスト入力 | | `number` | 数値入力 | | `date` | 日付選択 | | `enum` | 選択肢(enum 配列から選択) | | `file` | ファイルアップロード | | `record` | レコード型(テーブル形式のデータ) | | `object` | オブジェクト型 | | `array` | 配列型 | ## ModelPolicy(データアクセスポリシー) 各ノードで各データフィールドに対する読み書き権限を定義する。 ```typescript type ModelPolicy = { [nodeId: NodeId]: { [propertyKey: string]: "write" | "read"; }; }; ``` - `write`: そのノードでフィールドを編集可能 - `read`: そのノードでフィールドは読み取り専用 ノードIDに対応するエントリがない場合、そのノードではフィールドにアクセスできない。 ## BinaryExpression(条件式) actionPolicies の `allow` や conditions の `expression` で使用される条件式。 ```typescript type BinaryExpression = { operator: "and" | "or" | "==" | "!=" | "has" | "in" | "belongsTo"; expression1: BinaryExpression | string; expression2: BinaryExpression | s