Reconciling Prompt Registries
YAML--- name: reconciling-prompt-registries description: Audits, normalizes, and consolidates disparate prompt catalogs, workflow documents, and URL inventories into an authoritative deduplicated Master Index. Use when merging multiple prompt libraries or documentation sources, validating and canonicalizing URLs across a registry, deduplicating overlapping task/prompt definitions, or producing a unified schema-normalized index from fragmented project files. ---
Given N source files (docs, prompt catalogs, URL lists), produce a single Master Index with five sections: Resolved Source Asset Registry, Reconciled Atomic Task Directory, Normalized Prompt Component Library, Pipeline Topology, and Audit Log.
Input: file1.md, file2.md, file3.md (each containing prompts/URLs/tasks)
Output: MASTER_INDEX.md with zero dead links, zero duplicate tasks, zero naming collisions
Do not summarize or comment conversationally — output only the structured deliverable.
Progress:
- Step 1: Ingest all source files; extract every URL, prompt, task definition, and workflow reference into a flat working list with source-file provenance tags
- Step 2: Validate each URL — check for dead domains, temporary redirects, malformed query params; resolve to canonical stable equivalents (official docs, GitHub, prompts.chat mirrors); discard/replace anything unverifiable
- Step 3: Cluster prompts/tasks by semantic similarity; merge variants into one canonical version preserving all edge cases and constraints from each variant
- Step 4: Normalize terminology — enforce
CONTEXT,ROLE,TASK,FORMAT,CONSTRAINTlabels and${var}variable notation across every entry - Step 5: Assign canonical IDs (
SRC-##,TSK-##,BRICK_ID) to every deduplicated entity; cross-check that every task referenced in a pipeline has a corresponding spec, and every pipeline stage references an existing brick - Step 6: Render the five-section Master Index in strict markdown; log every correction made in the Audit Log
Example 1: Input: Two files both define a "summarize customer feedback" prompt with slightly different constraints (one limits to 3 bullets, one requires sentiment tag). Output:
- `BRICK_04` Feedback Summarizer (Type: Task)
* Schema: CONTEXT, TASK, FORMAT, CONSTRAINT
* Text: "TASK: Summarize ${feedback_text} into max 3 bullet points. CONSTRAINT: Each bullet must include a sentiment tag (positive/neutral/negative)."
Merged into one brick; duplicate entry removed and logged in Audit Log as "Merged TSK-07/TSK-12 → BRICK_04."
Example 2:
Input: A source cites http://old-gov-portal.example/sop/v1?tmp=redirect
Output:
| SRC-03 | Federal SOP Reference | Compliance | Federal SOP Static Doc | Extracted: procurement approval steps |
Audit Log entry: "SRC-03: replaced dead redirect URL with canonical static gov domain."
- Always tag extracted items with source-file provenance before deduplication — needed for the Audit Log
- Prefer static/canonical URLs (official docs, pinned GitHub commits/releases) over search results, shorteners, or temp redirects
- When merging prompt variants, take the union of constraints, not the intersection — never silently drop an edge case
- Use strict, minimal IDs (
SRC-01,TSK-01,BRICK_01) — never reuse an ID across sections - Cross-validate structural integrity last, after dedup, so IDs referenced in Pipeline Topology are guaranteed to exist
- Do not fabricate a "canonical" URL if the original cannot be verified — mark as
UNRESOLVEDin Audit Log instead of hallucinating a replacement - Do not merge two tasks just because their names are similar if their input/output contracts differ — treat as distinct with a naming-collision note
- Do not leave conversational commentary, caveats, or explanations in the final deliverable — output must be pure structured markdown
- Do not skip the Audit Log — every silent fix is a hidden defect for downstream consumers