AI Skill Report Card
Extracting Workflow Templates From Raw Sources
YAML--- name: extracting-workflow-templates-from-raw-sources description: Converts raw webpage sources (SOP repositories, prompt libraries, checklists, process documentation) into modular, reusable AI workflow building blocks with variable placeholders and structured prompt scaffolds. Use when repackaging existing documentation, SOPs, or prompt collections into productized AI templates, or when building a library of freelancer prompt building blocks from scattered web sources. --- # Extracting Workflow Templates From Raw Sources
Quick Start14 / 15
Given any raw source (SOP page, prompt library, checklist, process doc), produce this deliverable structure for each source:
### [N]. [Source Name]
Category: [SOP Repository | Prompt Library | Process Documentation | Checklist]
What it provides: [2-3 sentences describing the structural elements present]
Link: [verified, working URL]
Prompt to use:
[the extraction prompt itself, in a code block]
Example extraction prompt for an SOP page:
Extract the structural template from this SOP page. Identify: (1) role definitions
(who performs each step), (2) sequential procedure steps with numbered IDs,
(3) inputs/materials as parameters, (4) calculation/validation steps as logic,
and (5) reporting requirements as output format. Convert into a reusable
CONTEXT-ROLE-TASK-FORMAT scaffold with ${variable} placeholders.
Recommendation▾
Add a bad-example (generic/interchangeable extraction prompt) alongside good ones to make the pitfall concrete rather than described abstractly
Workflow14 / 15
Progress:
- Step 1: Identify candidate sources matching the target categories (SOP repos, prompt libraries, checklists, process templates, QMS frameworks)
- Step 2: Verify each URL actually resolves and contains extractable text/structure (not a paywall, not a dead link, not just a marketing landing page)
- Step 3: Open/inspect each source to identify its underlying schema (roles, steps, variables, phases, constraints)
- Step 4: Classify the source into a category (SOP Repository, Prompt Library, Process Documentation, Checklist)
- Step 5: Write a 2-3 sentence "what it provides" summary naming the concrete structural elements (not generic praise)
- Step 6: Craft a source-specific extraction prompt that names the exact schema fields to pull out and the exact output format to convert them into
- Step 7: Compile all sources into a numbered list with consistent formatting
- Step 8: Spot-check that no two extraction prompts are generic/interchangeable — each must reference the specific structure of its source
Recommendation▾
Include an edge case for sources with mixed/ambiguous categories or non-English content
Extraction Prompt Anatomy
Every extraction prompt must contain three parts:
- Identify — a numbered list of the specific structural elements present in THIS source (roles, steps, variables, phases, constraints, validation criteria). Never say "extract the key points" — name the actual fields.
- Convert — an explicit target schema (YAML, JSON, Markdown sections, or a named scaffold pattern like CONTEXT-ROLE-TASK-FORMAT).
- Output — the concrete shape of the deliverable (e.g., "a reusable prompt registry where each entry has fields: archetype, role_block, task_block, input_schema, output_schema, constraints").
Examples16 / 20
Example 1: Input: A government SOP repository with 100+ documents organized by pre-analytic/analytic/post-analytic phases and 12 quality domains. Output:
Analyze this QMS framework. Extract: (1) the 12 Quality Systems Essentials as
modular role/domain blocks, (2) the pre-analytic → analytic → post-analytic
sequence as a three-stage prompt chain, (3) the SOP template fields (purpose,
scope, responsibilities, procedure, records), and (4) validation checkpoints.
Output a YAML-formatted prompt library with blocks for ROLE, SEQUENCE,
VALIDATION, and OUTPUT_FORMAT.
Example 2:
Input: A GitHub prompt library using ${variable} placeholder syntax with a JSON API export.
Output:
Extract the modular prompt architecture from this library. Identify: (1) the
${variable} placeholder syntax and required vs. optional denotation, (2) output
format specifications, (3) constraint/rule patterns, and (4) the category
taxonomy. Convert into: [CONTEXT_BLOCK] + [ROLE_BLOCK] + [TASK_BLOCK with
${variables}] + [FORMAT_BLOCK] + [CONSTRAINT_BLOCK].
Recommendation▾
Consider trimming overlap between 'Extraction Prompt Anatomy' and 'Best Practices' sections which restate similar guidance twice
Best Practices
- Always verify links resolve before including them — open the page, don't trust search snippets
- Prefer sources with machine-readable exports (CSV, JSON, JSONL, YAML) over pure prose pages
- Name the exact schema fields visible in the source (e.g., "apparatus/reagents lists," "pre-analytic phase") rather than generic terms like "important details"
- Vary the target output format across sources (YAML for QMS frameworks, JSON registries for prompt libraries, scaffolds for SOPs) to keep the final library diverse and non-repetitive
- Keep "what it provides" descriptions factual and structural — describe the schema, not the value proposition
- Batch-verify multiple URLs in parallel before writing any prompts, so broken links don't block the whole deliverable
Common Pitfalls
- Don't write interchangeable extraction prompts — if the same prompt could apply to any of the 10 sources, it's too generic
- Don't include landing pages that link out to the actual content (e.g., a program homepage) as if they were the raw source itself — find the actual document
- Don't skip link verification — placeholder IDs, double slashes, or redirects often indicate an unverified/broken URL
- Don't pad "what it provides" with marketing language ("comprehensive," "world-class") instead of concrete structural facts
- Don't exceed the requested count of sources; if asked for 10, deliver exactly 10, not 20 with a note to pick