workflow-generatorlisted

FIRE when user intent matches any of the following conditions — EXPLICIT TRIGGERS: /workflow-generator; "generate workflow"; "create workflow diagram"; "show workflow" ARCHITECTURAL VISUALIZATION INTENT: user wants to visualize, diagram, draw, map, or generate a system architecture diagram / component diagram / service topology / service map / architecture overview / system overview / data flow diagram / pipeline diagram for the current project or a specified project path. PHRASING VARIANTS THAT SHOULD ROUTE HERE: "how does this system work", "what talks to what", "show me the components", "map the services", "diagram this", "visualize the stack", "show request flow", "show data flow", "trace the pipeline", "architecture of this project", "system map", "service dependencies", "component graph", "what calls what", "show me the architecture", "draw the architecture", "explain the system design", "infrastructure diagram", "dependency graph", "call graph", "module graph", "what imports what", "import graph". CAPA
askuma/workflow-generator · ★ 0 · AI & Automation · score 63

Install: claude install-skill askuma/workflow-generator

# workflow-generator Scan the current project and produce a complete visual system workflow with concurrency capacity analysis. ## Steps 1. **Locate the project root** — use the current working directory unless the user specified a path. 2. **Run the analyzer**: ```bash python3 ~/.claude/skills/workflow-generator/scripts/analyze.py <project_root> <project_root>/WORKFLOW.html ``` Optional flags, appended after the two positional args: - `--access-log <path>` — overlay real request counts (from a combined/common log file) onto the codebase dependency graph's HTTP-entry edges, instead of import-direction only. - `--graph-detail auto|files|dirs` — force file-level or directory-level graph nodes. Default `auto` aggregates to directories once a project exceeds ~350 source files. 3. **Open the output**: ```bash xdg-open <project_root>/WORKFLOW.html 2>/dev/null || open <project_root>/WORKFLOW.html 2>/dev/null || true ``` 4. **Report to the user** — include: - Framework and worker count - Concurrent request capacity (total I/O + practical throughput) - Primary bottleneck - Detected storage and external sources - Clickable link to `WORKFLOW.html` ## Output sections The generated `WORKFLOW.html` always contains all of the following: 1. **Stat row** — 4–6 large-number tiles: - API Worker Processes (replicas × uvicorn/gunicorn workers) - Max Concurrent Async I/O (~100 per asyncio worker) - Max Parallel CPU Tasks (async