How do I install the Processflow Critic skill?

Run npx skillmds@latest add psquared-development/processflow-critic in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Processflow Critic safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Processflow Critic?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Processflow Critic free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Processflow Critic?

psquared-development (@psquared-development) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Processflow Critic by psquared-development

Name: Processflow Critic
Author: psquared-development

Processflow Critic

Red-team ONE ProcessFlow process from the customer's/Martin's critical lens — assume the concept was generated by a weaker AI without perfect context, and question everything. Use when told to "hinterfrage Prozess <Name>", "kritische Analyse", "red-team this", "critique <process>", or when the wrapper processflow-run calls the critique step. Actively checks the process against the known Fehlermuster-Register (every real mistake we hit on ZIWA + Stütz), web-researches the proposed tools/pricing/technique, and SURFACES concrete issues (evidence + which guard + suggested fix). It does NOT fix — it produces the issue list that gets fed back into the rework.

File contents

ProcessFlow — Critic (the critical lens)

Input: one process (name). Your job is to find what's wrong, not to be reassured. Default assumption: the current concept was produced by a weaker AI without full context — so treat every claim as suspect until verified. You do NOT edit anything; you output a prioritized issue list.

How to critique

Pull the current canvas + report + score + diagrams (Chrome session token) and read the relevant transcript passages. Compare concept ↔ canvas ↔ diagrams ↔ transcript.
Walk the Fehlermuster-Register in processflow-review/references/guardrails.md (the table at the bottom) — for EACH pattern, actively check this process. The recurring killers:
- Wrong company name / invented tool / invented brand or device / invented ERP (grep names vs transcript).
- Wrong industry carried through all fields + diagrams.
- Wrong scenario — the concept describes a different process than the transcript means.
- Rebuilds what the ERP/a product already does (e.g. IPTOR native replenishment, IDP tools, Firefly, InboxMate) — Build-vs-Buy not considered.
- Wrong AI technique (describing VLM instead of image-embeddings; heavy ML where the customer described rules; prompt-extraction instead of IDP).
- Price/"included/free" hallucination (e.g. Firefly credits).
- Over/under-motorized; hours too low; only Phase 1 has an analysis step; existing system assumed free (BMD); canvas≠concept≠diagram≠E)-compliance drift; roles as initials; diagram jargon/too complex/wrong story; OS-module framed as throwaway app; OS solution-class wrong; score stale after rework; agent-set approval/date.
Web-research when the concept names a tool, price, or technique — verify it's the right tool, the price/tier is real, and the technique is state-of-the-art (WebSearch/WebFetch). Cite sources.
Smallest-solution + KI-First tension: is this over-engineered, or under-motorized where the customer expects real KI? Does the KI actually make sense for THIS customer?

Coordination

Read the shared Team-Update-Feed first (GET /api/updates?company=<slug>) — other parallel agents may already have flagged the industry, invented tools, shared modules, or pricing facts you'd otherwise re-derive. If your critique surfaces something cross-cutting (affects other processes), note it so it gets posted to the feed (the wrapper/worker posts POST /api/update).

Output — the issue list

For each issue: [severity] short title — evidence (quote/field) — which guardrail — concrete fix. Group by severity. End with a one-line verdict: is the concept sound, or does it need rework (and on which axis). Be specific and honest; a clean "no blocking issues" is a valid result only after you actually walked the register. This list is meant to be fed straight back into processflow-process.

---name: processflow-criticdescription: Red-team ONE ProcessFlow process from the customer's/Martin's critical lens — assume the concept was generated by a weaker AI without perfect context, and question everything. Use when told to "hinterfrage Prozess <Name>", "kritische Analyse", "red-team this", "critique <process>", or when the wrapper processflow-run calls the critique step. Actively checks the process against the known Fehlermuster-Register (every real mistake we hit on ZIWA + Stütz), web-researches the proposed tools/pricing/technique, and SURFACES concrete issues (evidence + which guard + suggested fix). It does NOT fix — it produces the issue list that gets fed back into the rework.---# ProcessFlow — Critic (the critical lens)Input: one process (name). Your job is to **find what's wrong**, not to be reassured. **Defaultassumption: the current concept was produced by a weaker AI without full context — so treat everyclaim as suspect until verified.** You do NOT edit anything; you output a prioritized issue list.## How to critique1. Pull the current canvas + report + score + diagrams (Chrome session token) and read the relevant transcript passages. Compare concept ↔ canvas ↔ diagrams ↔ transcript.2. **Walk the Fehlermuster-Register** in `processflow-review/references/guardrails.md` (the table at the bottom) — for EACH pattern, actively check this process. The recurring killers: - Wrong company name / **invented tool / invented brand or device / invented ERP** (grep names vs transcript). - **Wrong industry** carried through all fields + diagrams. - **Wrong scenario** — the concept describes a different process than the transcript means. - **Rebuilds what the ERP/a product already does** (e.g. IPTOR native replenishment, IDP tools, Firefly, InboxMate) — Build-vs-Buy not considered. - **Wrong AI technique** (describing VLM instead of image-embeddings; heavy ML where the customer described rules; prompt-extraction instead of IDP). - **Price/"included/free" hallucination** (e.g. Firefly credits). - Over/under-motorized; hours too low; only Phase 1 has an analysis step; existing system assumed free (BMD); canvas≠concept≠diagram≠E)-compliance drift; roles as initials; diagram jargon/too complex/wrong story; OS-module framed as throwaway app; OS solution-class wrong; **score stale after rework**; agent-set approval/date.3. **Web-research when the concept names a tool, price, or technique** — verify it's the right tool, the price/tier is real, and the technique is state-of-the-art (WebSearch/WebFetch). Cite sources.4. **Smallest-solution + KI-First tension**: is this over-engineered, or under-motorized where the customer expects real KI? Does the KI actually make sense for THIS customer?## CoordinationRead the shared **Team-Update-Feed** first (`GET /api/updates?company=<slug>`) — other parallel agentsmay already have flagged the industry, invented tools, shared modules, or pricing facts you'd otherwisere-derive. If your critique surfaces something **cross-cutting** (affects other processes), note it so itgets posted to the feed (the wrapper/worker posts `POST /api/update`).## Output — the issue listFor each issue: **[severity] short title — evidence (quote/field) — which guardrail — concrete fix.**Group by severity. End with a one-line verdict: is the concept sound, or does it need rework (and onwhich axis). Be specific and honest; a clean "no blocking issues" is a valid result only after youactually walked the register. This list is meant to be fed straight back into `processflow-process`.

Frequently asked questions