rag-project-remember
Skill2 starsChanged 7 months agoMITView on GitHub
Store project-specific knowledge into the project-level LightRAG knowledge graph
- Reads credentials
- Sends data out
In this repository6 other files it gives its agents.
- rag-project-querySkill
- rag-project-syncSkill
- rag-querySkill
- rag-rememberSkill
- rag-setup-projectSkill
- rag-syncSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 66
Do NOT dump the raw API response
- Very specific: line 70
Use /rag-remember (personal graph) instead for:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
RAG Project Remember — Store to Project Knowledge Graph
Store project-specific knowledge — architecture decisions, conventions, dependencies, and requirements — into the project-level LightRAG graph.
Formatting rules
Format each entry as:
[TYPE] Title — YYYY-MM-DD
What: Brief description
Why: The reasoning or constraint behind it
Files: Relevant file paths (if applicable)Entry types
| Type | Use for |
ARCHITECTURE | System design choices, component structure, data flow |
CONVENTION | Coding standards, naming patterns, file organization rules |
DECISION | Technology choices, library selections, approach decisions |
DEPENDENCY | External services, APIs, packages, version constraints |
CONFIG | Environment setup, build config, deployment settings |
REQUIREMENT | Business rules, constraints, acceptance criteria |
INSIGHT | Performance findings, gotchas, non-obvious behaviors |
How to store
node -e "
const BASE = 'http://YOUR_LIGHTRAG_HOST:YOUR_PROJECT_PORT';
const API_KEY = process.env.LIGHTRAG_API_KEY || 'YOUR_API_KEY';
(async () => {
const res = await fetch(BASE + '/documents/text', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-API-Key': API_KEY
},
body: JSON.stringify({
file_source: '[TYPE] Title — YYYY-MM-DD',
text: 'Full content here with What/Why/Files structure'
})
});
console.log('Status:', res.status);
})();
"After inserting
- Confirm to the user: "Stored to project memory: [TYPE] Title"
- Do NOT dump the raw API response
When NOT to use this
Use /rag-remember (personal graph) instead for:
- User preferences — working style, tool preferences, communication style
- Cross-project knowledge — things that apply to all projects
- Personal context — roles, responsibilities, machine config
- People info — contacts, working relationships
This skill is for things specific to the current project that wouldn't be relevant elsewhere.
Infrastructure
- Server:
YOUR_LIGHTRAG_HOST:YOUR_PROJECT_PORT - Auth: X-API-Key header (auth-enabled mode)
- Env var:
LIGHTRAG_API_KEY
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

