How do I install the RAG Build skill?

Run npx skillmds@latest add qaia-project/rag-build in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is RAG Build safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with RAG Build?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is RAG Build free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published RAG Build?

QAIA-Project (@qaia-project) published this skill. Their other Agent Skills are listed on their SkillMD profile.

RAG Build by qaia-project — Agent Skill

Name: RAG Build
Author: QAIA-Project

RAG Build

Create or enrich the team's git-versioned QAIA knowledge base (.qaia/knowledge/) - glossary, business rules, application map, anomaly history - with a mandatory master index and small focused files. Use when capturing project knowledge or when another skill hands over a reusable rule.

QAIA-Project 263cd4a 2.3 KB Updated Sep 17, 2026

File contents

rag-build — team knowledge base

Follow the shared contract in ../README.md. The knowledge base is shared by the team through git: treat every change as something a teammate will review in a PR.

Layout it maintains

knowledge/index.md — master index, mandatory: one line per file — path | topic | tags. Every read by any skill goes through this index — selective loading is what keeps the knowledge base affordable — so a file absent from the index is invisible.
knowledge/*.md — one concern per file (a business rule cluster, a glossary section, one application area), ≤ ~2k tokens each. Split rather than grow.

Steps

Initialize (first use): create knowledge/ with index.md and offer the four starter files — glossary.md, business-rules.md, application-map.md, anomaly-history.md — asking the user 2-3 seed questions for each they accept.
Enrich (routine): given a candidate rule/term (from the user or handed over by need-understanding / feedback / confirm-fix, whose closed defects land in anomaly-history.md as the missing test condition rather than as the bug):
- check the index for the right target file; check the file for duplicates or contradictions with existing content;
- on contradiction: show both statements, ⚠ VALIDATION — the user arbitrates which is true (loser is removed or marked superseded, never both kept);
- write the entry with its provenance (US-ID, date, decided-by);
- update index.md (and split the file if it crossed the size budget).
Report. Summarize what changed so the user can commit it (suggest a one-line commit message). Do not run git commands yourself unless the user asks.

Guardrails

Never store secrets, credentials, URLs of internal environments, or personal data in knowledge files.
Provenance is mandatory on every entry — an unsourced rule cannot be trusted or challenged later.
Keep entries declarative and testable ("cancellation is refused < 4h before start"), not narrative.

---name: rag-builddescription: Create or enrich the team's git-versioned QAIA knowledge base (.qaia/knowledge/) - glossary, business rules, application map, anomaly history - with a mandatory master index and small focused files. Use when capturing project knowledge or when another skill hands over a reusable rule.---# rag-build — team knowledge baseFollow the shared contract in `../README.md`. The knowledge base is shared by the team through git: treat every change as something a teammate will review in a PR.## Layout it maintains- `knowledge/index.md` — **master index, mandatory**: one line per file — `path | topic | tags`. Every read by any skill goes through this index — selective loading is what keeps the knowledge base affordable — so a file absent from the index is invisible.- `knowledge/*.md` — one concern per file (a business rule cluster, a glossary section, one application area), **≤ ~2k tokens each**. Split rather than grow.## Steps1. **Initialize** (first use): create `knowledge/` with `index.md` and offer the four starter files — `glossary.md`, `business-rules.md`, `application-map.md`, `anomaly-history.md` — asking the user 2-3 seed questions for each they accept.2. **Enrich** (routine): given a candidate rule/term (from the user or handed over by `need-understanding` / `feedback` / `confirm-fix`, whose closed defects land in `anomaly-history.md` as the missing test condition rather than as the bug): - check the index for the right target file; check the file for duplicates or **contradictions** with existing content; - on contradiction: show both statements, ⚠ VALIDATION — the user arbitrates which is true (loser is removed or marked superseded, never both kept); - write the entry with its provenance (US-ID, date, decided-by); - update `index.md` (and split the file if it crossed the size budget).3. **Report.** Summarize what changed so the user can commit it (suggest a one-line commit message). Do not run git commands yourself unless the user asks.## Guardrails- Never store secrets, credentials, URLs of internal environments, or personal data in knowledge files.- Provenance is mandatory on every entry — an unsourced rule cannot be trusted or challenged later.- Keep entries declarative and testable ("cancellation is refused < 4h before start"), not narrative.

Frequently asked questions