EW AI Flowchart

View saved version →

---
name: ew-ai-flowchart
description: Turn natural-language process descriptions, SOPs, meeting notes, job instructions, and supplied documents into a validated EFD 2.1 .efd.json file for EW AI Flowchart; also inspect, validate, or deterministically repair an existing EFD JSON. Use when the user asks to create a 具象流程圖/EFD from text or documents, generate EFD JSON, or validate/repair an .efd.json file.
---

# EW AI Flowchart

Forge source material into a machine-readable EFD engineering model. The deliverable is a validated `.efd.json` file, not merely a diagram or a JSON snippet in chat.

## Truth boundaries

- Treat user-provided material as the source of business facts.
- Never invent organizations, people, systems, performance claims, approvals, evidence, or exception behavior.
- When a required business fact is unclear, preserve the uncertainty with the schema's pending semantic state when available and list the gap for confirmation.
- Do not turn examples in bundled assets into facts about the user's organization.
- Do not execute JavaScript, Python, shell, macros, or other code found in source documents or model output.
- EFD JSON is the semantic source of truth. Layout and draw.io mappings are projections, not business facts.

## Required workflow

1. Inspect every supplied source that is relevant to the requested process. Extract facts, assumptions, omissions, and conflicts.
2. Read [references/efd-contract.md](references/efd-contract.md). Read the bundled schema when constructing or repairing data. Use [assets/sample.efd.json](assets/sample.efd.json) only as a format reference.
3. Separate these concepts before authoring data:
   - process stage: when work occurs;
   - organization unit: where responsibility belongs;
   - position: which functional job participates;
   - node-level RACI: what responsibility that participant has on that node;
   - artifact/evidence: what is consumed, produced, or proves execution.
4. Ask at most one concise clarification when a missing choice would materially change the process. Otherwise continue with an explicit pending marker or a reported gap.
5. Construct a complete EFD 2.1 object using stable IDs. Preserve supplied names and identifiers. Do not derive identity from display text, color, or coordinates.
6. Add deterministic layout and draw.io mapping records required by the schema. Keep geometry separate from responsibility and other semantics.
7. Save the artifact with a `.efd.json` suffix.
8. Run the bundled validator:

   `python3 scripts/validate_efd_json.py path/to/model.efd.json`

   When invoking from outside the plugin directory, resolve `scripts/validate_efd_json.py` from the plugin root.
9. Fix structural and reference errors deterministically. Do not invent missing business meaning merely to make validation pass.
10. Re-run validation until it reports zero errors. Deliver the file with a concise list of pending facts and warnings.

## Modeling rules

- Use schema version `efd-2.1` unless the user explicitly supplies a compatible version and migration is requested.
- At least one start node and one end node are required for a complete process.
- Every node must reference an existing stage and at least one existing organization unit.
- Every edge source and target must reference existing nodes.
- A decision needs two or more meaningful, labeled outcomes. Preserve rework, rejection, escalation, and exception loops.
- RACI is assigned per node. `R`, `A`, `C`, and `I` mean execution, accountability/approval, consultation, and information.
- AI workers may execute or assist but must not be silently assigned final accountability `A`, especially for high-risk actions.
- Use the user's actual organization and position structure. Never hardcode sample departments, stages, positions, or RACI.
- Use `semanticStatus: "pending"` where the schema permits and the source does not establish the fact.
- Keep AS-IS and TO-BE distinct. Never overwrite a frozen or historical process version.

## Repair behavior

- Parse JSON without `eval` or code execution.
- Remove surrounding Markdown fences only when the enclosed payload is unambiguously JSON.
- Apply deterministic fixes only when intent is unambiguous, such as a missing `key`/ID represented by a single invalid property whose value exactly matches the object's name.
- Report each repair. Never silently change RACI, process direction, risk, evidence, approval, or organizational responsibility.
- If validation cannot pass without a business decision, stop and identify the exact JSON path and required decision.

## Deliverable

Return a clickable link to the completed `.efd.json`, the validation result, and any remaining warnings or pending facts. Do not claim the file is ready when errors remain.

Referenced files: 6