process-map — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited process-map (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Produces a structured process map with swim lanes, task nodes, decision diamonds, and handoff arrows. Output is in Mermaid flowchart notation (renderable in GitHub, VS Code, Confluence, and Miro) or BPMN-lite text when a formal notation is required. It also generates a companion process narrative for documentation.
miro-board or include it in a requirements-document.| AS-IS | TO-BE | |
|---|---|---|
| Purpose | Document what currently happens, including workarounds and pain points | Define the improved or target process |
| Annotation | Mark pain points (⚠), manual steps (M), and system steps (S) | Mark new capabilities (NEW) and removed steps (REMOVED) |
| Output | Evidence base for improvement | Specification for change |
| Element | Notation | Mermaid syntax |
|---|---|---|
| Start / End | Circle | ([Start]) / ([End]) |
| Task / Activity | Rectangle | [Task name] |
| Decision | Diamond | {Decision?} |
| Sub-process | Double border | [[Sub-process]] |
| Data store | Cylinder | [(Data store)] |
| Swim lane | Subgraph | subgraph Actor |
Each actor (person, role, system, or external party) gets its own swim lane. Handoffs occur when an arrow crosses lane boundaries.
## Process map: [Process name] ([AS-IS / TO-BE])
flowchart TD subgraph Actor1["[Swim lane 1 label]"] A([Start]) --> B[Task 1] B --> C{Decision?} end
subgraph Actor2["[Swim lane 2 label]"] C -->|Yes| D[Task 2] C -->|No| E[Task 3] D --> F[Task 4] E --> F end
subgraph System["[System label]"] F --> G[(Data store)] G --> H([End]) end
### Pain points (AS-IS) / Changes (TO-BE)
| Step | Issue / Change | Severity / Type |
| --- | --- | --- |
| [Task name] | [Description] | Pain point / New / Removed / Automated |
### Process narrative
1. **[Actor]** — [Step description].
2. **[Actor]** — [Step description]. If [condition], go to step N.
3. ...
### Handoff summary
| From | To | Trigger |
| --- | --- | --- |
| [Actor] | [Actor] | [What causes the handoff] |Input: "Map our current order fulfilment process. Customer places order on website, ops team manually checks stock, emails supplier if out of stock, warehouse picks and packs, courier collects."
Expected output: Mermaid diagram with swim lanes for Customer, Ops, Warehouse, Supplier, Courier. Manual email step annotated as pain point. Process narrative with handoff summary.
Input: "Document the new incident response process after we add PagerDuty. Alert fires → PagerDuty pages on-call → engineer acknowledges → triages → resolves or escalates → post-mortem."
Expected output: TO-BE diagram with System (monitoring), PagerDuty, On-call Engineer swim lanes. Steps marked NEW where PagerDuty replaces manual paging. Post-mortem step annotated as new capability.
Input: User provides both current and target process descriptions.
Expected output: Two Mermaid diagrams side by side, a change summary table listing added, removed, and modified steps, and a narrative explaining the key improvements.
TD (top-down) for most processes; LR (left-right) for linear pipelines.gap-analysis (map AS-IS first, then identify gaps to reach TO-BE) and miro-board (Mermaid diagrams can be embedded in Miro frames).~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.