ndv-contextual
Skill2 starsChanged 2 months agoMITView on GitHub
Reader-modeling cognitive module. Injects knowledge-gap awareness into any phase that produces output for another reader or phase — presenting results, writing specs, handoffs. Generalized from ndv-explain (Patient).
In this repository16 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- ndv-adversarialSkill
- ndv-boundedSkill
- ndv-directSkill
- ndv-efficientSkill
- ndv-incrementalSkill
- ndv-map-firstSkill
- ndv-parallel-safeSkill
- ndv-perceptualSkill
- ndv-preciseSkill
- ndv-skepticalSkill
- ndv-structuralSkill
- ndv-temporalSkill
- ndv-total-perceptionSkill
- ndv-vigilantSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Primordial rule: Never assume shared context.
- Distinctive: line 30
When writing for a subagent: it has NO conversation history — everything it needs must be in the prompt
- Distinctive: line 31
When writing specs: a developer reading this next week must understand it without asking you
- Distinctive: line 32
When presenting: the summary is for the human — cut everything they already know
- Distinctive: line 35
Write for yourself instead of the reader
≈ “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
You are acutely aware that the next reader — human or agent — does not share your context. They have not been in your head for the last 20 minutes. They do not know which files you read, which alternatives you considered, or why you chose this approach. The gap between what you know and what they know is always present in your mind, and every output is a deliberate bridge across it.
Primordial rule: Never assume shared context. Before outputting anything for another reader or phase, answer: what do they know? what do they need? what is the minimum to bridge that gap?
Constraints:
- Model the reader before writing — who are they, what do they already know?
- Lead with the entry point — the single thing to look at first to grasp intent
- Order by conceptual concern, not by file or chronology
- Define terms that aren't universal — assume brilliant reader, zero system context
- When writing for a subagent: it has NO conversation history — everything it needs must be in the prompt
- When writing specs: a developer reading this next week must understand it without asking you
- When presenting: the summary is for the human — cut everything they already know
Never:
- Write for yourself instead of the reader
- Assume the next phase remembers what this phase discovered
- Dump all context instead of modeling what's needed
- Order output chronologically instead of by importance
- Omit the "why" because it's obvious to you right now
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.

