ssiertsema/claude-code-plugins

business-process-modeling

Model business processes using BPMN 2.0 conventions.

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/ssiertsema/claude-code-plugins --skill business-process-modeling

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

Business Process Modeling (BPMN)

You model a business process using BPMN 2.0 conventions. Produce a structured spec + Mermaid flowchart approximating BPMN notation, plus optional BPMN XML for dedicated tooling (Camunda, bpmn.io, Signavio).

Core rules

  • BPMN-compliant vocabulary: events, activities, gateways, flows — use the standard element types
  • Swim lanes for actor separation: one lane per actor / role / system
  • Gateway semantics explicit: exclusive (XOR) vs parallel (AND) vs inclusive (OR) — state which
  • Flows typed: sequence (solid) vs message (dashed, across pool boundaries) vs association (dotted, to artifacts)
  • No fabricated process steps: work from supplied process description or interview
  • As-is vs to-be distinct: never blend current-state with proposed-state

Input handling

DimensionRequiredDefault
Process nameYes—
Mode (as-is / to-be / gap)Yes—
Actors / roles / systemsYes—
Process stepsNoElicit
Start + end eventsNoElicit

Phase 1 — Setup

**Process**: [name]
**Mode**: [as-is / to-be / gap (as-is + to-be comparison)]
**Actors**: [list with roles / systems]
**Scope**: [where the process starts and ends]
**Exceptions in scope**: [happy path only / + key exceptions / comprehensive]

Ask render mode per diagram-rendering mixin and output path (default: /documentation/[case]/business-process-modeling/).

Phase 2 — BPMN element vocabulary

Events (circles)

ElementSymbolUse
StartThin circleProcess begins
IntermediateDouble circleEvent during process (time, message, signal, error)
EndThick circleProcess terminates

Event subtypes: message, timer, signal, error, escalation, cancel, compensation, conditional, link.

Activities (rounded rectangles)

ElementUse
TaskAtomic work step
SubprocessCollapsed group of steps (+ marker inside)
Call activityReferences reusable global process
Service taskAutomated system call
User taskHuman task with UI
Manual taskHuman task outside any system
Send / receive taskExplicitly message-driven

Gateways (diamonds)

ElementSemantics
Exclusive (X)Exactly one path taken; condition-based
Parallel (+)All paths taken simultaneously; merge waits for all
Inclusive (O)One or more paths taken based on condition
Event-basedBranch selected by whichever event fires first

Flows

FlowLineUse
SequenceSolid arrowOrder within same pool
MessageDashed arrowBetween pools
AssociationDotted lineTo data object or annotation

Pools & lanes

  • Pool: external participant (customer, partner, vendor) or major system
  • Lane: internal role within a pool (approver, analyst, automated system)

Artifacts

  • Data object — data needed / produced by activity
  • Data store — persistent storage
  • Annotation — explanatory text

Phase 3 — Per-activity spec

For each activity, capture:

FieldDescription
IDA-01, ...
LaneActor / role
Typetask / subprocess / service / user / manual / send / receive
DescriptionVerb-object ("Validate application", "Send confirmation email")
InputsData consumed
OutputsData produced
SLA / duration (optional)Expected time
ExceptionsKnown failure modes

Phase 4 — Per-gateway spec

For each decision point:

FieldDescription
IDG-01, ...
Typeexclusive / parallel / inclusive / event-based
ConditionFormal rule(s) driving selection
BranchesOutgoing flows with labels
Data sourceWhere the decision value comes from

Phase 5 — Exception handling

Per exception path:

ExceptionTriggerHandlerCompensation
Application invalidValidation failsReturn-to-applicant pathNotify applicant
System timeout30s elapsedEscalate to managerLog + retry policy

Exceptions typically become alternative branches or error-boundary events on activities.

Phase 6 — Gap analysis (gap mode only)

If mode = gap, compare as-is to to-be:

AspectAs-isTo-beDelta
Handoffs73−4 (automation)
Manual touches125−7
Average cycle time5 days1 day−4 days
Error-recovery paths25+3

Per changed activity: category (removed / added / modified / automated / merged / split).

Phase 7 — Mermaid rendering

BPMN isn't natively Mermaid — use flowchart with swimlanes via subgraphs:

mermaid
flowchart LR
    subgraph Customer
        Start(("Start"))
        Submit["Submit application"]
    end
    subgraph Agent
        Review["Review app"]
        Approve["Approve"]
        Reject["Reject"]
    end
    subgraph System
        Validate{"Valid?"}
        Notify["Send result"]
    end
    End(("End"))

    Start --> Submit --> Review --> Validate
    Validate -- "Yes" --> Approve --> Notify --> End
    Validate -- "No" --> Reject --> Notify

For fuller BPMN fidelity, emit BPMN 2.0 XML (optional output) that can be imported into Camunda Modeler / bpmn.io.

Phase 8 — Optional BPMN XML emission

If user requests, produce .bpmn file with proper XML. Structure:

xml
<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" ...>
  <bpmn:process id="Process_1" isExecutable="false">
    <bpmn:startEvent id="StartEvent_1" name="Start" />
    <bpmn:task id="Task_1" name="Submit application" />
    <bpmn:sequenceFlow id="Flow_1" sourceRef="StartEvent_1" targetRef="Task_1" />
    <!-- ... -->
  </bpmn:process>
</bpmn:definitions>

Note: skill emits XML structure; positional / diagram info (BPMNDI) minimal — dedicated tools re-layout on import.

Phase 9 — Diagram rendering

Per diagram-rendering mixin. File names:

  • process-[mode].mmd / .png
  • process-[mode].bpmn (XML, optional)
  • gap-analysis.mmd / .png (if gap mode)

Phase 10 — Report assembly and approval

markdown
# Business Process Model: [Process]

**Date**: [date]
**Mode**: [as-is / to-be / gap]
**Actors**: [list]
**Scope**: [start → end]

## Scope
[Process, mode, actors, scope, exceptions]

## Actors / Pools / Lanes
[Pool + lane diagram + actor descriptions]

## Activities
[Table: ID, lane, type, description, inputs, outputs, SLA, exceptions]

## Gateways
[Table: ID, type, condition, branches, data source]

## Flows
[Summary: sequence + message + association counts; notable message flows across pools]

## Exception Handling
[Per exception: trigger, handler, compensation]

## Diagram
[Mermaid flowchart approximating BPMN]

## Gap Analysis (gap mode only)
[Delta per aspect + per-activity category]

## BPMN XML (if requested)
[Link to .bpmn file]

## Assumptions & Limitations
[Process coverage gaps, Mermaid-vs-BPMN fidelity notes]

Present for user approval. Save only after confirmation.

Generation + extraction rules

  • BPMN element vocabulary used strictly
  • Gateway semantics explicit
  • As-is / to-be never mixed
  • No fabricated activities or actors
  • Happy path and exceptions separate (marked)

Failure behavior

SituationBehavior
No processInterview mode (§7)
No actorsAsk; 1 actor = suspicious, 10+ = probably too granular
Gateway condition unclearRequire explicit condition before diagramming
As-is mixed with to-be wishesSplit into two modes
Happy path only but user wants exceptionsExpand scope OR produce happy-path now + exception pass next
mmdc failureSee diagram-rendering mixin
Out-of-scope ("automate the process")"Modeling only; automation is engineering."

Self-check

[] Process name + mode declared
[] Actors / lanes / pools specified
[] Scope (start → end) explicit
[] BPMN vocabulary used strictly
[] Activities have type, I/O, lane
[] Gateways have type + condition + branches
[] Exception handling covered (or happy-path scope declared)
[] Flows typed (sequence / message / association)
[] Gap analysis if gap mode
[] Mermaid diagram valid
[] BPMN XML emitted if requested
[] As-is and to-be not mixed
[] No fabricated activities
[] Report follows output contract

タスクに関連する項目