
Acomo
- 851 installs
- Updated July 6, 2026
- progress-all/acomo-skills
acomo is a Claude Code skill that teaches agents to read and reason about acomo getWorkflowModel JSON—nodes, edges, policies, and dataSchema—when implementing or debugging approval-style workflows.
About
acomo is a workflow-model reference skill for the acomo platform that documents the TypeScript shapes behind getWorkflowModel output, including ModelDefinition nodes and edges, Node actionPolicies with BinaryExpression allow rules, and branch conditions on exclusiveFork and parallelJoin paths. Developers reach for acomo when an agent must interpret Japanese-labeled workflow nodes, event start/end markers, or policy gates while implementing approval flows or tracing why a transition is blocked. The bundled reference excerpt walks through Node, NodeType, and condition expression fields so coding agents do not guess schema semantics. Use it whenever workflow JSON from acomo APIs needs accurate parsing, validation, or debugging during backend or agent-tooling work.
- 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
Acomo by the numbers
- 851 all-time installs (skills.sh)
- +26 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #324 of 2,715 Automation & Workflows skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/progress-all/acomo-skills --skill acomoAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 851 |
|---|---|
| Security audit | 2 / 3 scanners passed |
| Last updated | July 6, 2026 |
| Repository | progress-all/acomo-skills ↗ |
How do you parse acomo getWorkflowModel workflow JSON?
Read and reason about acomo getWorkflowModel JSON—nodes, edges, policies, and dataSchema—when implementing or debugging approval-style workflows.
Who is it for?
Backend or agent developers integrating acomo approval workflows who receive getWorkflowModel JSON and need precise schema and policy semantics.
Skip if: Teams not using the acomo workflow platform or developers who only need generic state-machine patterns without acomo-specific JSON.
When should I use this skill?
The user shares or asks about acomo getWorkflowModel JSON, workflow nodes, edges, actionPolicies, dataSchema, or approval-flow debugging.
What you get
Correctly interpreted workflow nodes, edges, policy expressions, and dataSchema fields ready for implementation or debugging.
- parsed workflow model interpretation
- policy and branch condition analysis
Files
acomo CLI / API 標準ガイド
acomo はワークフロー管理プラットフォームです。このスキルは acomo CLI と公開 API の標準的な使い方(モデル一覧・モデル定義取得・プロセス開始・保存・提出・承認・却下・差し戻しなど)を案内します。
前提・実行環境
- acomo CLI が実行できる環境(PATH に
acomoが存在すること)を前提とします。 - エージェントが CLI を実行する場合、リモートサンドボックス等ではローカルの
~/.acomo/config.jsonや環境変数が自動継承されないことがあります。CI・エージェント実行時は環境変数(ACOMO_ACCESS_TOKEN,ACOMO_TENANT_ID,ACOMO_BASE_URL)の設定を推奨します。 - 認証未設定時も API コマンドは存在し、実行時に終了コード 2 と stderr の
AUTH_REQUIREDで失敗します。その場合はユーザーに再ログイン(または環境変数設定)を促してください。
認証エラー時の扱い
認証エラー(認証未設定・401/403、終了コード 2)が出た場合は、試行錯誤で解決しようとしないこと。 速やかにユーザーにログインを促し、処理を中断する。
acomo loginの実行、または環境変数ACOMO_ACCESS_TOKEN,ACOMO_TENANT_IDの設定
認証
- ローカル利用:
acomo loginで~/.acomo/config.jsonに永続保存。 - CI・エージェント環境: 環境変数での認証を推奨。
アクセストークンはブラウザで acomo にログインした後に入手し、CLI で指定する。
# 環境変数で認証(非インタラクティブ向け)
export ACOMO_ACCESS_TOKEN="your-token"
export ACOMO_TENANT_ID="your-tenant-id"
# または login で保存
acomo login --tenant-id <tenantId> --access-token <accessToken>| 環境変数 | 説明 | 必須 |
|---|---|---|
ACOMO_ACCESS_TOKEN | アクセストークン | Yes |
ACOMO_TENANT_ID | テナント ID | Yes |
ACOMO_BASE_URL | API Base URL(省略時: https://acomo.app) | No |
CLI の出力は JSON です。パラメータは acomo <operationId> --help で確認する。
呼び出し形式
acomo <operationId> [--option value...] [body-json]- path/query パラメータ →
--name value形式の named option - リクエストボディ → 位置引数の JSON 文字列(または stdin)
# path param のみ(GET など)
acomo getWorkflowModel --modelId <ID>
# query params
acomo listWorkflowModels --take 10 --filter '{"name":{"contains":"申請"}}'
# body のみ(POST)
acomo createWorkflowModel '{"name":"経費申請","definition":{},"dataSchema":{},"policy":{}}'
# path param + body(PUT)
acomo saveWorkflowModel --modelId <ID> '{"name":"経費申請","definition":{},"dataSchema":{},"policy":{}}'
# stdin から body を渡す
echo '{"name":"経費申請","definition":{},"dataSchema":{},"policy":{}}' | acomo createWorkflowModel標準フロー
1. モデル一覧: acomo listWorkflowModels で対象モデルを特定する。フィルタ例: acomo listWorkflowModels --take 10 --filter '{"name":{"contains":"申請"}}' 2. モデル定義: acomo getWorkflowModel --modelId <ID> で definition / dataSchema / policy の JSON を取得する。 3. プロセス操作: 必要に応じて startWorkflowProcess / saveWorkflowProcess / submitWorkflowProcess / submitWorkflowProcessWithNodeId / approveWorkflowProcess / rejectWorkflowProcess / revertWorkflowProcess を使う。自分のプロセス一覧は listMyProcesses や listProcessWithNodeActions を検討する。
主要コマンド早見
| 用途 | コマンド |
|---|---|
| モデル一覧 | listWorkflowModels |
| モデル定義取得 | getWorkflowModel --modelId <ID> |
| 編集中モデル | getWorkflowModelWithLatestModelHistory --modelId <ID> |
| プロセス開始 | startWorkflowProcess --modelId <ID> |
| データ保存 | saveWorkflowProcess --processId <ID> '{"data":{...}}' |
| 提出 | submitWorkflowProcess --processId <ID> |
| 承認 | approveWorkflowProcess --processId <ID> |
| 却下 | rejectWorkflowProcess --processId <ID> |
| 差し戻し | revertWorkflowProcess --processId <ID> --nodeId <nodeId> |
| 自分のプロセス一覧 | listMyProcesses / listProcessWithNodeActions |
| 自分のプロセス取得 | getMyProcesses / getProcessWithNodeActions |
プロセス操作では、タスクノードでは dataSchema に沿ったデータを saveWorkflowProcess の body の data フィールドで送る。遷移は submit / approve / reject / revert で実行する。policy の write/read に従い、現在ノードで編集可能な項目だけを扱う。
補足
- データ構造(definition / dataSchema / policy / 条件式)の詳細は reference.md を参照する。
- 全コマンド一覧は
acomo --helpで確認する。
acomo データ構造リファレンス
acomo スキル(SKILL.md)の補助資料。getWorkflowModel で取得する JSON の definition / dataSchema / policy を読むときの型と用語をまとめる。
ModelDefinition(ワークフロー定義)
type ModelDefinition = {
nodes: Node[]; // ワークフローのノード(タスク、イベント、分岐など)
edges: Edge[]; // ノード間の接続
};Node(ノード)
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(エッジ)
type Edge = {
from: string; // 遷移元ノードID
to: string; // 遷移先ノードID
type: FlowType[]; // 遷移種別の配列
};FlowType(遷移種別)
| 種別 | 説明 |
|---|---|
normal | 通常の遷移(開始→最初のタスク等) |
submit | 提出による遷移 |
approve | 承認による遷移 |
reject | 却下による遷移 |
yes | 条件分岐でTrue |
no | 条件分岐でFalse |
ModelDataSchema(データスキーマ)
JSON Schema のサブセット。ワークフローで扱うデータの構造を定義する。
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(データアクセスポリシー)
各ノードで各データフィールドに対する読み書き権限を定義する。
type ModelPolicy = {
[nodeId: NodeId]: {
[propertyKey: string]: "write" | "read";
};
};write: そのノードでフィールドを編集可能read: そのノードでフィールドは読み取り専用
ノードIDに対応するエントリがない場合、そのノードではフィールドにアクセスできない。
BinaryExpression(条件式)
actionPolicies の allow や conditions の expression で使用される条件式。
type BinaryExpression = {
operator: "and" | "or" | "==" | "!=" | "has" | "in" | "belongsTo";
expression1: BinaryExpression | string;
expression2: BinaryExpression | string;
};主なオペレーター
| オペレーター | 説明 | 例 |
|---|---|---|
== | 等値比較 | $user.id == $executor(nodeId).id |
!= | 非等値比較 | $user.id != $executor(nodeId).id |
has | 配列に含む | $user.roles has "roleId" |
in | 値が配列に含まれる | $data.status in ["active","pending"] |
belongsTo | グループ所属 | $user belongsTo $executor(nodeId).groups |
and | 論理AND | 2つの条件を結合 |
or | 論理OR | 2つの条件を結合 |
式中の変数
| 変数 | 説明 |
|---|---|
$user.id | 操作ユーザーのID |
$user.roles | ユーザーのロール一覧 |
$user.groups | ユーザーのグループ一覧 |
$executor(nodeId).id | 指定ノードを実行したユーザーのID |
$executor(nodeId).groups | 指定ノードを実行したユーザーのグループ |
$data.{key} | プロセスデータの値 |
Related skills
FAQ
What JSON does acomo getWorkflowModel return?
acomo getWorkflowModel returns workflow JSON with a ModelDefinition containing nodes and edges, plus dataSchema and policy sections. Nodes carry ids, Japanese names, NodeType values, optional eventType start/end markers, actionPolicies with BinaryExpression allow rules, and branc
When should developers invoke the acomo skill?
Developers should invoke the acomo skill when implementing or debugging approval-style workflows backed by acomo. Use it whenever agents must interpret getWorkflowModel output, validate node transitions, or explain why actionPolicies block an operation.
Is Acomo safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.