SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsacomo-workflow-modeling

acomo-workflow-modeling

Agents & models

View repository

Updated 10-15 21:54

About this skill

acomo workflow modeling skill

Design, generate, and improve acomo workflow models (definition + dataSchema + policy) from business descriptions.This document is the dialogue design document for the "Modeling Agent"(information organization, sufficiency assessment, questions, staged generation, improvement) as the source of truth.

acomo product chat (text visible to users): Do not paste the headings of this document, self-references to procedures, skill names, file paths, or fence language tag names directly into user-facing explanatory text. Judgments follow this document, andthe words should be only explanations of and requests about the business. Keep internal notes in the thinking channel provided by the environment.

Division of roles among documents

Document Role
SKILL.md (this document) Dialogue flow, judgment criteria, staged generation, model proposals (acomo-workflow-model-draft) machine-readable output, clarifying question policy (format depends on the environment)
philosophy.md Design principles, self-review, common mistakes
patterns.md Typical patterns, CLI procedures, sample definitions

Clarifying questions and machine-readable output per environment

  • IDEs such as Cursor / Claude Code When using this skill: if information is insufficient, the structured clarifying questionsprovided by the IDE (e.g., Cursor's AskQuestion, Claude Code's AskUserQuestion) may be actively used. Do not rely only on questions in the conversation text; make them easier to answer with options.
  • acomo product AI assistant screen(via Cursor SDK): since the IDE's standard tools are not available on this route, follow the internal protocol（acomo-agent-question fenced JSON) defined by the acomo-backend system prompt. This skill body does not specify that JSON shape.
  • Model proposal (draft): In all environments, follow acomo-workflow-model-draft fenced block(one at the end, containing only JSON). For explanatory purposes, ```json etc. acomo-workflow-model-draft Do not output fenced code blocks other than。
  • In this monorepo, .cursor/skills → .agents/skills the same content may be referenced via a symbolic link (the path Cursor etc. reads depends on the environment).

Information model necessary for business process design

From the user's explanation, mentally slot the information from the following perspectives (not for the purpose of asking the user for a list, but as a checklist for design decisions).

  1. Business context — Business name, purpose, completion conditions, exceptional termination conditions
  2. Actors — Requester, worker, approver, confirmer, department/role, whether proxy/multiple people are involved
  3. Flow structure — Start conditions, normal steps, number of approval stages, branching conditions, parallel confirmation, handling of send-back/rejection/withdrawal
  4. Data — Input at request creation, additions along the way, approval comments, attachments, options, required/optional, type
  5. Permissions/policy — Who edits/views which items per task, items you do not want viewed
  6. Operational assumptions — Conditional branching by amount, etc., deadlines/SLA, notifications/external integrations, scope not handled in the initial release

Sufficiency判定ルーブリック

Before proceeding to model generation (concrete proposals for definition / dataSchema / policy), evaluate the following as Required / Recommended / Can be deferred .

Perspective Required Recommended Can be deferred
Purpose of the business and image of completion ○
Requester (who starts it) ○
Image of main approvals/confirmations and number of stages ○
Rough flow of normal steps ○
Main data items (name level) ○
Policy for rejection/send-back ○ Tentative is acceptable if assumptions are made explicit
Presence of parallel confirmation ○ Tentative is acceptable if assumptions are made explicit
Item types and enum values ○ Refine after the draft
Detailed read/write matrix For the first version, required only for parts that are hard to infer

Approach (definition first):

  • When the first message is almost empty: If the rubric-required items (business purpose, requester, main approvals/confirmations, normal steps, main data items) cannot be read at all from the user's messagecompletely unreadableShort text (e.g., "I want to build a workflow" etc.only an expression of intent), thenin that first reply acomo-workflow-model-draft do not output,only clarifying questions(1–2 questions) it is acceptable to focus on. The user'snext messageafter receiving, even if there are gaps list the assumptions and promptly acomo-workflow-model-draft show the outline of the definition with .
  • Otherwise: Until all rubric-required items are complete continuing only with questions and not presenting a model proposalis prohibited. Even if there are gaps, list the assumptions and first acomo-workflow-model-draft show the outline of the definition with .. On that basis, 1–2 questionsupdate the skeleton with.Points that significantly change the model, such as business branching, approvers, confidentiality, and monetary thresholds, must not be finalized based on assumptions alone(either assumptions + confirmation, or ask explicitly via a clarifying question).

How to show progress (required every turn)

So that the user does not end up in a state of "not knowing how much longer this will continue,"at the beginning of each turn, in 1 linewrite the following.

  • The current phase(e.g., which part you are working on: definition draft → dataSchema → policy)
  • A rough estimate of what remains in this session(e.g., "once definition is settled in another 1–2 rounds, then dataSchema")

Back-and-forth discussion and clarifying questions (1–2 questions, for updating the draft)

  • Do not make it a questionnaire that merely lists what is missing. Summarize what is currently known in one sentencebefore proceeding.
  • As a rule, use clarifying questions only "to revise the model proposal".The only exception is the first turn, when it is almost empty, which is used for questions to obtain seeds. A flow in which hearing continues and definition is never seen at allis prohibited (except for that one exceptional turn).
  • Make it easier to answer by adding options and concrete examples. In environments where structured clarifying questions are available, use combinations of single/multiple choice and free input.

Bad example:

Please tell me everything: the applicant, approver, data items, permissions, branching conditions, and how rejections are handled.

Good example:

First, I want to decide the approval structure. Is there one approver, or is it multi-level approval such as manager → department head? When rejected, is it closer to "terminate" or "send back to the applicant"?

Conditions for proceeding by placing hypotheses

  • Assumptions that are not explicitly stated but are generally reasonable shouldnot be finalized arbitrarilyand you should declare, "I will make a first draft based on this assumption."
  • For points that significantly change the model structure or policy (branching, approvers, confidentiality, thresholds, etc.), assumption + confirmation should be paired together.

Staged generation protocol (definition first)

Do not suddenly return only complete JSON;first show the deliverable (draft), thenincrease precision.

machine-readable fenced blockは acomo-workflow-model-draft only(for explanatory purposes, ```json etc. are prohibited). For clarifying questions, the output formatfollows the above "Clarifying questions and machine-readable output per environment."

  1. 1-line progress — phase and remaining estimate (required every turn).
  2. definition draft — if the above "when the first turn is almost empty" applies,the first responseshould not output acomo-workflow-model-draft and only clarifying questions.Otherwiseshould immediately acomo-workflow-model-draft output.definition Include the path from the start event through the task sequence to the end. For anything undecided, list the assumptions in the body and the description.
  3. Clarifying questions (optional) — in order to update the skeleton, 1–2 questionsonly, in a format suited to the environment (on a turn where you output a draft, you may continue immediately after the draft within the same turn. If the first turn is almost empty, ask questions only without a draft).
  4. definition confirmation loop — after the user's reply,the updated acomo-workflow-model-draft at the end. If necessary, continue with clarifying questions.
  5. dataSchema — once the definition is readable,properties fill in. Items whose type is not yet determined may use placeholders or minimal types, butthe premise of fixing them latershould be indicated in the progress lines.
  6. policy — fill in read/write once the task node IDs and dataSchema keys are in place. Avoid a premature full matrix; first, {} or only the main tasks is fine.
  7. Self-review — check for contradictions against philosophy.md. When using the CLI, acomo schema show check the type constraints with.
  • The seed can be readFor design seeds,within at most 2 round trips from the reply to the first user messagebe sure to at least once acomo-workflow-model-draft output the (the definition must have a readable start, task sequence, and end).When the first turn is almost empty,ask questions only, andby the reply to the user's next messagebe sure to output a draft at least once.

acomo-workflow-model-draft は One per reply at the end(replaced on each update). The JSON format and node/edge conventions are as before.

Improvement feedback (handling differences)

If the user says something like "make approval two-stage" or "amounts of 100,000 yen or more require department head approval,"do not make it look like a complete rebuild, briefly explain where the change affects definition / dataSchema / policy , and thenthe updated acomo-workflow-model-draft output. Update the progress lines.

Operation flow (list)

1. ユーザーの依頼（設計シード・自由記述）を受け取る
2. 進捗 1 行を書く
3a. 業務内容がほとんど書かれていない短文だけのとき: 逆質問のみ（ドラフトは出さない）→ ユーザーの追加入力を待つ
3b. それ以外: 仮定を列挙しつつ、すぐ acomo-workflow-model-draft（definition 骨子）を出す
4. 必要なら逆質問で 1〜2 問（ドラフト更新用。3a のあとは次ターンで 3b に進む）
5. ユーザーの回答後、acomo-workflow-model-draft を更新（definition 優先）
6. definition が読めたら dataSchema をドラフトに反映し、続けて policy
7. philosophy.md でセルフレビューし、CLI 利用時は acomo schema show
8. 合意後、最終案は acomo-workflow-model-draft のまま（createWorkflowModel は acomo スキル）
9. フィードバックがあれば 2 に戻る（進捗を更新）

Required information checklist (details)

To generate a workflow model, the following must be in place. For each item, determine "clear / unclear / missing" before proceeding to design.

# Required information Impact if missing
1 Purpose and overview of the business The overall direction of the model cannot be determined
2 Requester(who files it) The first task node cannot be determined
3 Approver / reviewer(who makes the decision, how many stages) The number and order of task nodes cannot be determined
4 Work content of each step Node names and roles cannot be determined
5 Rejection / send-back policy(flow termination or send-back to requester) reject Whether to terminate or use send-back operation cannot be determined
6 Whether parallel approval is used(whether multiple approvers make decisions simultaneously) parallelFork/Join whether it is necessary cannot be determined
7 Data items(what information is input, referenced, or updated) dataSchema cannot be defined
8 Type of each data item(string / number / date / file / option) The property type of dataSchema cannot be determined
9 enum options(if it is an option type, what can be selected) The enum values of dataSchema cannot be determined
10 Data permissions per task(for each task, whether an item iseditedorread-onlyか） policy (read/write) cannot be defined
11 Input items limited to a stage(e.g., only approver comments are entered in the approval task) The correspondence between dataSchema keys and policy cannot be determined

Hearing guidelines (supplementary)

When a lot of information is missing: narrow down to the 1-2 most essential questions. In an environment where structured reverse questions can be used, present options and free input.

When it is mostly complete but partially unclear: confirm only the unclear points, or make reasonable assumptions and propose.

When the request is clear: minimize the hearing, explicitly list the assumptions, and proceed to staged generation.

Design procedure (after information is complete)

  1. Enumerate nodes

    • Start event (exactly one)
    • Task node for each actor (1 actor × 1 work = 1 node)
    • End events (as many as there are outcomes)

  2. Set edges

    • Start → first task: normal
    • Task → next task (submission): submit
    • Approval node → approval destination: approve
    • Approval node → rejection destination (end): reject
    • Send-back is handled in business/runtime specifications, and the edge type に revert is not used (FlowType は normal / submit / approve / reject / yes / no 6 types of — philosophy.md See the FlowType table in. The single source in the monorepo is acomo-backend/src/workflow/model/edge.entity.ts）

  3. Design dataSchema

    • Property types conform to the bundled generated schema schemas/dataSchema.json (the single source in the monorepo is acomo-backend/src/workflow/model/schemas/model-schemas.json). Dates are type: "string" + format: "date" + _acomoType: "date". For details, see patterns.md .
    • The exact JSON Schema representation of each type is acomo schema show to check in（acomo config show A built-in command of the same lineage. The backend AJV validation definition statically embedded into the CLI). Be sure to refer to this before building a model.
    • status do not include
    • _order is in increments of 10: 10, 20, 30...

  4. Design the policy (data access policy)

    • definition のEach task node ID と、dataSchema のEach property keyassociate, andwrite(editable) or read(reference only)
    • For multi-stage approvals and parallel tasks, add a matrix for each task node
    • For details and common mistakes, see philosophy.md. For types and the meaning of "when a node has no entry", see acomo の reference.md the ModelPolicy section of

  5. Self-review with philosophy.md

    • Check whether you have fallen into any common design mistakes

  6. Explain to and confirm with the user

    • Explain the flow in natural language (do not hand over JSON right away)
    • Get agreement with "Is this content acceptable?"

  7. Register via CLI（patterns.md CLI procedure)

Details of design principles and constraints

→ philosophy.md see

Sample definitions of typical patterns

→ patterns.md see

How to operate the CLI / API

→ see the acomo skill (SKILL.md)

Type definitions and terminology for the data structure (policy / definition / actionPolicies and the differences from reference.md refer to.