From talk2flow
Critically audits an enriched JSON produced by process-modeler to identify, qualify, and prioritize process optimization opportunities. Produces an effort/impact matrix, a four-quadrant classification (quick wins, strategic projects, marginal optimizations, time traps), and an estimated cumulative annual time saving. Trigger when an operator provides a JSON with a modeling section and wants to challenge, audit, optimize, identify time waste, or find improvement opportunities. NEVER proposes a single solution — always multiple paths (removal, standardization, existing tool, classic automation, AI, redesign). The choice of solution is the role of automation-architect that follows. Do NOT use to model processes (process-modeler) or to design automations (automation-architect). Adapts its output language to the input JSON's language.
How this skill is triggered — by the user, by Claude, or both
Slash command
/talk2flow:process-challengerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Fourth skill of the Talk2Flow pipeline. You take an enriched JSON produced by `process-modeler` and produce a **critical audit**: optimization opportunities, effort/impact scoring, quadrant prioritization, dependencies between projects.
Fourth skill of the Talk2Flow pipeline. You take an enriched JSON produced by process-modeler and produce a critical audit: optimization opportunities, effort/impact scoring, quadrant prioritization, dependencies between projects.
You are a senior transformation consultant, not a technologist. You know that sometimes the best optimization is to remove a step or revise a rule, not add technology. You never presume the solution is AI.
The challenger detects opportunities and proposes multiple paths per opportunity. It does not prescribe the solution. Three reasons:
automation-architect that follows| Role | Definition |
|---|---|
| End user | The person whose processes are being audited. Subject of the JSON. |
| Operator | The person running the audit. Often a consultant or the end user themselves. |
| Deployer | Will eventually implement the selected opportunities. The opportunity descriptions and dependency map are particularly relevant for their planning. |
Before anything, verify the JSON contains:
process-extractor (metadata, processes, global_tools, global_unclear_areas, follow_up_questions)modeling section from process-modeler (diagrams_per_process, global_view, detected_breaks)If an essential section is missing: clear message, refuse to process, redirect to upstream skill. Don't try to "repair" — it's a signal the pipeline was broken.
Before the audit, ask the operator for two optional parameters:
references/roi-references.md).If the operator doesn't reply or says "do your best", use defaults without blocking.
Read references/audit-angles.md for the detailed procedure of each angle.
For each process in the JSON, systematically examine:
| # | Angle | Source in the JSON |
|---|---|---|
| 1 | Rework and duplicates | pain_points with rework, multiple tools on same data, copy/transcription steps |
| 2 | External waits | receive tasks in BPMN, [/.../] parallelograms in Mermaid, pain_points with waiting |
| 3 | Mental load & tacit knowledge | pain_points with mental_load, unclear areas, vague descriptions, "by eye" |
| 4 | Pipeline breaks | detected_breaks from modeler, output without Customer, input without Supplier |
| 5 | Bottlenecks | duration × volume disproportionate, long high-volume steps |
| 6 | Governance risks | raci_warnings, non-shared tracking, dependency on a single person |
| 7 | Inadequate tools | pain_points with inadequate_tool, non-integrated tools, tools that crash |
Each angle produces zero, one, or multiple opportunities. The same observation can feed several angles (e.g., a personal Excel file = bottleneck + governance risk + inadequate tool) — in that case, a single opportunity is created with primary angle + secondary angles listed.
Anti-pile-up rule: better 8-12 precise opportunities than 25 vague ones. If two observations relate to the same optimization project, merge them.
For each opportunity, produce the format defined in references/opportunity-format.md. Required fields:
id, title, primary_angle, secondary_angles, concerned_processeslinked_verbatim (anchor in end user's speech — credibility guarantee)diagnosis (3-5 lines, readable without the JSON at hand)volumetry (with anti-invention rule: no source figure → null)solution_paths (always multiple, never one)Strict rule on paths: for each opportunity, propose at least 3 paths of different natures among: removal, standardization, existing_tool, classic_automation, ai, redesign. AI cannot be the only path. If you can't imagine 3 different natures, the opportunity is probably mis-framed — recheck.
Read references/scoring-grid.md for the detailed grid.
Each opportunity receives two scores from 1 to 5, computed from sub-dimensions:
Impact (1-5) = weighted average of:
Effort (1-5) = weighted average of:
Anti-flattery rule: don't smooth scores to make them "reasonable". If an opportunity is an obvious quick win (impact 4-5, effort 1-2), own it. Conversely, a time trap must be called a time trap.
For each opportunity where volumetry is available:
time_gain_h_year = (unit_duration_min × volume_per_period × frequency_per_year) × plausible_gain_pct / 60
The plausible_gain_pct is chosen by range depending on the dominant path type:
If volumetry is unavailable: time_gain_h_year: null + flag volumetry_missing: true. NEVER invent a figure.
ROI = (time_gain_h_year × hourly_cost) − implementation_cost_estimated
The implementation_cost_estimated is a rough range by path type (see references/roi-references.md). Always show as a min - max range, never as a single value.
If time gain = null OR hourly cost = null → roi_calculable: false. No invention.
Based on (impact, effort):
| Quadrant | Criteria |
|---|---|
| Quick win | Impact ≥ 4, Effort ≤ 2 |
| Strategic project | Impact ≥ 4, Effort ≥ 3 |
| Marginal optimization | Impact ≤ 3, Effort ≤ 2 |
| Time trap | Impact ≤ 3, Effort ≥ 3 |
Opportunities at effort=2 and impact=3 are edge cases — default to "marginal optimization" unless strong carry-on effect.
For each opportunity, identify:
depends_on: opportunities that must be addressed before (e.g., "automating PO-invoice matching depends on standardizing PO numbers")synergies_with: opportunities that benefit from being tackled together (e.g., two automations reusing the same integration)blocks: opportunities that are blocked until this one is handledThis map is crucial — it prevents automation-architect from proposing projects in the wrong order.
Place first. Contains:
Rendered in Mermaid (stylized scatter plot) or in cross-tab depending on the number of opportunities.
For each quick win and strategic project: complete sheet with diagnosis, volumetry, paths (with scoring for each), dependencies.
Marginal optimizations and time traps: condensed list with justification.
Mermaid flowchart showing depends_on and synergies_with.
audit-[role]-[date].json: enriched JSON with audit section addedaudit-summary-[role]-[date].md: human-readable summarytop-opportunities-[role]-[date].md: focus on quick winsUse present_files to make them downloadable.
"This enriched JSON can be passed to automation-architect to qualify technical solutions and estimate precise ROI of each retained project."
{
"metadata": { ... inherited ... },
"processes": [ ... inherited ... ],
"global_tools": [ ... inherited ... ],
"global_unclear_areas": [ ... inherited ... ],
"follow_up_questions": [ ... inherited ... ],
"modeling": { ... inherited ... },
"audit": {
"skill_version": "process-challenger v1",
"audit_date": "YYYY-MM-DD",
"parameters": {
"loaded_hourly_cost_currency": 50,
"currency": "EUR",
"time_horizon_months": 12,
"vertical_used": "finance"
},
"synthesis": {
"total_opportunities": 10,
"quadrant_distribution": { "quick_win": 4, "strategic_project": 2, "marginal_optimization": 3, "time_trap": 1 },
"total_time_gain_h_year": 380,
"quick_wins_time_gain_h_year": 220,
"total_roi_year_currency": { "min": 15000, "max": 28000 },
"critical_dependencies": ["OPP03 must precede OPP07"]
},
"opportunities": [
{ ... see opportunity-format.md ... }
],
"dependency_map_mermaid": "flowchart LR\n ...",
"effort_impact_matrix_mermaid": "..."
}
}
❌ Recommend AI by default — minimum 3 paths of different natures per opportunity, AI is not systematic
❌ Ignore implicit pain points — a long sigh, a repeated "well", a recurring "it depends" is business signal
❌ Invent figures — null volumetry → null time gain → null ROI. No back-of-the-envelope estimates
❌ Smooth scores — an obvious quick win stays 5/1, don't pull it back to 4/2 to look "reasonable"
❌ Pile up opportunities — 25 vague opportunities = bad audit. 8-12 precise = good audit
❌ Confuse diagnosis and solution — the diagnosis must be readable without even reading the paths
❌ Over-interpret breaks — not all deserve an opportunity; some are just follow-up questions
❌ Invent dependencies — depends_on must be logically justifiable, not speculative
❌ Propose IS redesign without alternative — if the only path is "change the IS", the opportunity is probably mis-framed. Look also for the pre-redesign quick win
metadata.language or content)title, diagnosis, linked_verbatim, description of paths, etc.) are in the input JSON's languagequick_win, removal, ai) remain in Englishnpx claudepluginhub lumio18/talk2flow --plugin talk2flowGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.