re0-import

Land handed-over material in the document of an existing knowledge base that owns it, by rules read from that base.

Goal

Each claim in the material lands at the tier of an existing base that owns its subject, by an edit to that owning document rather than a new neighbour beside it. Placement follows rules the run read from the target at run time. What cannot be placed with confidence is reported, never guessed: the skill neither researches the subject nor invents a tier.

The human names this skill with the material (any shape) and the target root, and may ask for a dry run. The run returns the claim list, edits inside the target root in each destination's grammar (none on a dry run), and the result block.

The skill is user-invoked because landing material in a base is a deliberate human hand-off. A model with this skill in reach would start filing every passing finding into whatever base is open, writing into documents nobody asked it to touch.

Workflow

Phases 1 to 4 run in order. No destination is named before phase 1 completes, and no byte is written before phase 4; a dry run (phase 5) runs phases 1 to 3 and skips phase 4.

1. Read the map. Find the target's routing documents: the agent-facing map at its root and the map at each tier. Extract each tier's definition with the test that separates it from the others, the ownership rows saying which document owns which subject, and any stated anti-pattern. This is the candidate tier list; a run that skips it is guessing at a structure it never read.

2. Classify. Give the material one of four shapes:

   • new information: a subject the target does not carry yet;
   • a correction: it contradicts the headline of a live line whose evidence still stands;
   • a bare reference: a link or citation with no framing;
   • a raw dump: several separable claims in one body.

   Split a dump into claims before scoring any destination and route each independently; a claim still carrying two grammars after the split is two claims. Emit the claim list. Material that is one whole item (a skill, module, script or doc section) rather than a set of claims is not a fifth shape: when its fit in the base is in question, call the Skill tool with "scopechk" before placing it, and place it whole only where that verdict allows.

3. Place. For each claim, name the owning document and quote the phase 1 rule that puts it there; a placement with no quoted rule is not a placement. Apply the confidence floor and write nothing below it. Create a new file only when the run can state why no existing tier holds the claim, and emit that reason. When a claim's subject already lives in two or more documents of the base, report the scatter and call the Skill tool with "ssotize"; do not add a third copy. When the human wants a claim checked before it lands, call the Skill tool with "factchk"; this skill itself never researches.

4. Write. Before the first byte changes, run node scripts/guard.mjs <target-root> <files-to-edit...> [--create <new-file>]... --json (exit 3 when a path is refused): it returns each file's SHA-256 and the refused paths with reasons. Edit each document in the grammar it already uses, per the grammars reference, then emit the result block: Touched (file and pre-edit SHA-256), Placed (claim, destination, quoted rule), Unplaced (claim, rejected candidates, reason each failed), Created (new file, reason no tier holds it). All four fields are written every run, empty ones included.

5. Dry run. When the human asks for one, emit the claim list and the result block and edit nothing.

6. Stop. The diff and the result block go to the human, who decides whether the change is committed. Any claim under the confidence floor stays unplaced for the human to route by hand. When the owning document has drifted beyond the one claim being landed, call the Skill tool with "re0" after the import, as a separate pass.