| name | analyzing-workflow-patterns |
| description | Analyzes any workflow material (attached document, pasted text, or URL) and maps it into a repo-ready integration plan. Detects material type, extracts reusable patterns, explains the workflow in Hungarian, generates English keyword flows in CANONICAL/LIGHTWEIGHT/STANDARD/STRICT variants, inspects the repository, and produces five scored integration flow options with Mermaid diagrams and a fit matrix — then stops for explicit approval before modifying anything. Use when working with workflow specifications, GitHub issue pipelines, agentic coding flows, CI/CD designs, planning architectures, release gate systems, or any structured process to embed into a repository. Triggers: analyze this workflow, map to our repo, workflow anyag, hogyan illik ez a repoba, workflow elemzés, integrate this design, decompose this spec, explain this workflow in Hungarian, what flows fit our repo.
|
| allowed-tools | Read, Bash, Grep, Glob |
Analyzing Workflow Patterns
Overview
Ingests any workflow material and runs an 11-phase structured analysis that
maps the workflow's reusable pattern onto the current repository. Produces
Hungarian explanations, English keyword flow chains, a repo reality check,
five scored integration options, and a hard decision checkpoint — with zero
writes until the user explicitly approves a flow.
Primary use cases:
- Mapping external workflow specs into an existing repo's conventions
- Understanding agentic/GitHub-native designs before committing to implementation
- Hungarian team explanations of complex workflow structures
- Generating five scored integration options with risk, effort, reversibility
Quick Start
Step 1 — Provide workflow material in any form:
- Paste raw text, attach a file, or provide a URL
- If a URL is given → fetch it immediately before anything else
- Multiple sources allowed; state which is the primary one
Step 2 — Phases run in order:
| Phase | Name | Key Output |
|---|
| 0 | Material Pre-processing | Material type declaration + entity index |
| 1 | Deep Workflow Analysis | 7-row extraction table |
| 2 | Hungarian Explanation | 5-section Magyar magyarázat |
| 3 | Hungarian Examples | 2 practical examples (small + large) |
| 4 | English Keyword Flows | CANONICAL / LIGHTWEIGHT / STANDARD / STRICT chains |
| 5 | Repository Reality Check | 8-section repo inspection |
| 6 | Fit Analysis | 6-section comparison |
| 7 | Brainstorm | Integration option exploration |
| 8 | Five Recommended Flows | Named flows + Mermaid diagrams |
| 9 | Fit Matrix | Scored 1–10, six dimensions |
| 10 | Decision Checkpoint | Hard stop; no writes until approval |
Step 3 — User approves a flow. Implementation begins only after approval.
Full phase templates and output formats → references/phases.md
Output quality markers and anti-patterns → references/output-quality.md
All {{VARIABLE}} definitions → references/template-variables.md
Core Operating Rules
- URL first — if the opening message contains a URL, fetch it before
any analysis. Do not proceed until the content is retrieved.
- Understand before recommending — complete all phases in order;
never jump to Phase 8 without Phases 1–7.
- Pattern vs. example — extract the reusable structure; never copy
example-specific names, issue numbers, labels, or commands blindly.
- Hard stop before writes — never create files, branches, issues, PRs,
or touch
.claude/ or .github/ until the user explicitly chooses a flow.
- Label assumptions — any default or inferred value must be marked
[ASSUMPTION] inline.
- Inspect before recommending — Phase 5 must run against the actual repo
before Phase 6 flow scoring. If no repo is accessible, describe a
"clean canvas" state and note what each flow would need to create.
Input Contract
Workflow material may describe any system:
- Umbrella → epic → sub-issue decomposition hierarchies
- Issue-to-subtask execution pipelines with dependency chains
- V1/V2 planning discipline or research-agent workflows
- Release-gated validation, dogfooding, or documentation systems
- CI/CD pipelines, agentic coding workflows, GitHub Projects flows
- Something entirely novel not listed here
Do not hardcode any category. Infer the pattern entirely from the current
input using template variables from references/template-variables.md.
Phase 5 Inspection Scope
Always inspect these paths (note what exists AND what is absent):
.claude/ .github/ README.md
CLAUDE.md AGENTS.md docs/
.agents/ .handoffs/ HANDOFF.md
Also scan for: branch naming, commit format, issue/PR style, labels,
milestones, validation commands, release commands, handoff conventions,
and build files (package.json, pyproject.toml, Makefile,
Taskfile.yml, docker-compose.yml).
Clean canvas rule: if none of these exist, explicitly declare
"clean canvas" and list what each recommended flow would need to create
from scratch.
Five Flow Categories (Phase 8)
Every Phase 8 output must cover all five, in this order:
| # | Category | Characteristics |
|---|
| 1 | LIGHTWEIGHT | Minimal ceremony; no new infra; ≤2 approval gates |
| 2 | STANDARD | Normal integration; minor .github/ additions; CI reused |
| 3 | STRICT | Every phase gated; audit log artifact; explicit rollback |
| 4 | AGENTIC | Claude Code drives phases; HANDOFF.md between steps |
| 5 | GITHUB_NATIVE | Issues/Projects track state; no custom tooling required |
The default recommendation in Phase 9 may suggest combining two flows
(e.g., "Flow 2 paired with Flow 4 elements") when that is genuinely better
than a single flow.
Mandatory Iteration Section
Every response MUST end with this exact block (content refreshed each time):
# Possible Additions
A. [Concrete tool/script/hook that would enhance the workflow]
B. [Concrete tool/script/hook that would enhance the workflow]
C. [Concrete tool/script/hook that would enhance the workflow]
D. [Concrete tool/script/hook that would enhance the workflow]
E. [Concrete tool/script/hook that would enhance the workflow]
# Questions
1. [Question that would improve workflow fit]
2. [Question about implementation or approval behavior]
3. [Question that would improve repo-specific accuracy]
Additions must be specific and actionable (e.g., "A pre-commit hook that
validates conventional commit format on issue titles") not generic
(e.g., "A script to help with automation"). Questions are optional to answer.
Style Rules
- Hungarian for Phases 2 and 3; English for all other phases
- English for all technical terms, file paths, commands, and code
- Never translate standard terms:
branch, PR, SKILL.md, CLAUDE.md
- Concise but deep; prefer repo evidence over assumptions
- Never silently expand scope
- Always include validation gate and rollback in Phase 8 flows
Reference Files
