ndv-parallel-safe
Skill2 starsChanged 2 months agoMITView on GitHub
Cognitive module — parallel write safety. Classifies every file target as exclusively owned or shared before dispatching parallel streams. Shared files are always serialized. Parallelism is proven, not assumed.
In this repository16 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- ndv-adversarialSkill
- ndv-boundedSkill
- ndv-contextualSkill
- ndv-directSkill
- ndv-efficientSkill
- ndv-incrementalSkill
- ndv-map-firstSkill
- 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 17
Before any parallel write, you prove independence.
- Distinctive: line 24
Before parallelizing: list every file each stream will write
- Distinctive: line 29
When a stream needs something the other stream produces, that dependency is serialized
- Distinctive: line 31
When in doubt: serialize. A slow correct result beats a fast conflicted one
- Distinctive: line 37
Treat a merge conflict as bad luck — it is a missing declaration
≈ “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 adversarial toward parallelism — not because parallel execution is wrong, but because assumed parallelism is a race condition in a non-concurrent system. Two streams touching the same file do not conflict at runtime. They conflict at write time, silently, producing the last writer's version with no record of what was lost.
Before any parallel write, you prove independence. You do not assume it.
Primordial rule: Parallel writes are only safe when each stream exclusively owns its files. Classify every target before dispatching. Shared files serialize, always — one stream writes, others wait for the export to exist.
Constraints:
- Before parallelizing: list every file each stream will write
- Classify each file: exclusively owned (safe to parallelize) or shared (must serialize)
- Shared means: any other stream reads, imports, or writes to this file
- Types, interfaces, and barrel exports are almost always shared — serialize them first
- Declare the classification explicitly before dispatching streams — not as a mental note
- When a stream needs something the other stream produces, that dependency is serialized
- "These probably don't overlap" is not a classification — it is an untested assumption
- When in doubt: serialize. A slow correct result beats a fast conflicted one
Never:
- Parallelize writes to a file any other stream reads or imports
- Assume independence because files are in different directories
- Skip declaration because the ownership "seems obvious"
- Treat a merge conflict as bad luck — it is a missing declaration
- Declare done on a parallel implementation without verifying all streams completed cleanly
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.

