| name | analyzing-workflow-patterns |
| description | Analyzes workflow documents, pasted text, URLs, or repository processes; extracts reusable entities, verbs, boundaries, gates, artifacts, failure paths, and variables; inspects actual repository capabilities; then compares three to five normalized, scored integration flows with validation and rollback before stopping for approval. Use to understand, map, compare, or integrate a workflow design. Do not modify files or external systems before the user selects a flow, and do not assume a language, tracker, provider, or fixed number of variants unless its optional profile is selected.
|
| license | Apache-2.0 |
| metadata | {"polymind.version":"2.0.0","polymind.tags":"workflow-analysis,repository-planning,portable,decision-support","polymind.risk":"read-only-until-approval"} |
Analyzing Workflow Patterns
Turn source material into evidence-backed integration choices. Understand the
workflow before recommending changes and stop before every mutation.
Core protocol
- Acquire every named source. Fetch a URL before interpreting it; identify the
primary source and report anything unavailable.
- Classify the material and extract actors, nouns, verbs, states, transitions,
inputs, outputs, approval gates, failure paths, and reusable variables. Keep
the abstract pattern separate from example identifiers.
- Explain the workflow in the user's requested language and give a small and a
scaled example. Default to the conversation language when none is requested.
- Normalize the source into concise keyword chains so candidate flows use the
same vocabulary and can be compared fairly.
- Inspect the actual repository before designing options. Scan capabilities,
not fixed provider paths:
- shared and scoped instruction mechanisms;
- tracker and planning conventions;
- build, test, CI, release, and rollback commands;
- agent, skill, handoff, and automation surfaces;
- existing artifacts, ownership, and clean-canvas gaps.
- Compare source needs with repository evidence. Mark every inference as
[ASSUMPTION] and distinguish present, absent, conflicting, and unknown
capabilities.
- Generate three flows for a bounded change, four for a cross-cutting change,
or five for a high-risk or organization-wide change. Each flow must include
prerequisites, exact artifacts, approval gates, validation, risk, rollback,
and repo-evidence rationale using
flow-definition.md.
- Score every flow with the all-higher-is-better model in
scoring.md and render
fit-matrix.md. State sensitivity or uncertainty when
close scores depend on assumptions.
- Recommend a flow or an explicit combination, explain the decisive trade-off,
and stop. Do not create files, tracker objects, branches, commits, or remote
resources until the user chooses a flow and separately approves its mutation
plan.
Optional profiles
Load a profile only when the user requests it or repository evidence requires
it. Profiles may add constraints but may not remove the core evidence, approval,
validation, rollback, or hard-stop rules.
Use template-variables.md to resolve generic
tokens. Load output-quality.md for difficult
reviews. The legacy phases.md is loaded only by the
legacy-five profile.
Optional iteration contract
After the decision checkpoint, offer additions or questions only when they can
materially change fit, safety, cost, or validation. Keep them specific and make
clear that answering is optional. Do not append a fixed boilerplate list.
