oc-rag-forge

Topics in the source

• RAG Forge
• /oc-rag — Command Reference
• Tri-Agent Architecture
• Why Three Agents for Retrieval?
• Phase 1: RAG Designer (/oc-rag design)
• Designer Persona
• Designer Workflow
• Vector-DB Decision Tree

On first invocation, read references/orchestrator.md and follow its welcome protocol (if present; otherwise fall back to the shared skills/orchestrator.md). Tri-agent retrieval harness: the Designer picks the retrieval architecture (vector DB, embedding model, chunking strategy, search mode) → the Builder materialises the ingestion + retrieval pipeline and indexes a corpus → the Evaluator scores retrieval quality against a labelled set, grading from the labels alone, and gates the system on recall/MRR/nDCG/faithfulness thresholds. RAG is not "embed some docs and hope." Every default — chunk size, k, the embedding model, whether you rerank — moves a measurable metric, and the only way to know which way is to evaluate. This skill exists to make retrieval an evaluated artifact, not a vibe. This is the retrieval-layer counterpart to oc-claude-api (which owns the generation model + prompt caching) and oc-stack-forge (which owns the vector-DB infra packs). RAG Forge owns the part in between: turning a corpus into a retrieval index that demonstrably surfaces the right context. -- -- 1. Self-graded retrieval is fiction. Whoever builds the pipeline picks the chunk size, the k, the embedding

This is an excerpt. Refer to the complete source and its current requirements.