The dr-init-id-collision-window Skill — Task-ID Collision Detection and Rename
How Datarim detects and resolves task-ID conflicts that occur when two parallel sessions reserve the same identifier in the window between /dr-init and /dr-archive.
Two agent sessions running on the same workspace can end up choosing the same TASK-PREFIX-NNNN identifier. The collision stays invisible until one session tries to write an archive document that the other session already created. By that point, the losing session has a full chain of derived artefacts — PRD, plan, verify audit logs, reflection, snapshot — all stamped with the conflicting ID.
The dr-init-id-collision-window skill describes how to detect this situation early and how to rename everything cleanly when it is caught late.
Where the window opens
The gap sits between the probe in /dr-init Step 2.5 — where the next free ID is reserved — and the moment /dr-archive commits its document to disk. A second session probing during that window sees no evidence of the first session's reservation, picks the same number, and both proceed in parallel under duplicate IDs.
The skill is invoked in two places: by /dr-init for early detection before any artefact is written, and by /dr-archive when a collision is discovered at the moment of final commit.
Detection scope
A probe runs against the full canonical artefact set: tasks.md, backlog.md, activeContext.md, every per-task file under datarim/, and every archive document under documentation/archive/. Any hit outside the calling session's own scope indicates a collision. The probe also distinguishes an operator's own earlier session from a genuinely parallel one, using frontmatter timestamps and commit author — not file presence alone.
The skill also covers the hot-fix case where an operator starts a branch without running /dr-init. Before any git checkout -b with a candidate ID, the same probe must confirm the ID is free in the backlog and archive — the candidate can look unused inside the current conversation context yet already be filed as a follow-up in another session's backlog entry.
Resolution procedure
The losing session (the one with the lower commit timestamp, or the one the operator designates) takes a new ID. A sed batch renames every occurrence of the old ID inside all artefact bodies in a single pass. Then git mv renames the files themselves. Index entries in tasks.md and activeContext.md update to match. Verify audit logs that were already write-locked by post-stage hardening need a temporary chmod u+w before the rename and a matching chmod a-w restore after.
The procedure ends with a one-line collision record appended to the init-task artefact of the renamed session, and a final grep confirming no stale references to the old ID remain outside intended historical-evidence quotations.
What the skill does not allow
The rename window opens at detection and closes at the next stage commit. Renaming mid-execution leaves stale references in snapshot frontmatter and in-progress QA drafts. Renaming only file paths via git mv without updating artefact bodies causes frontmatter mismatches. Deleting the losing session's artefacts outright is also ruled out — the content is salvageable under the new ID and should not be discarded.
See also: the /dr-init command where the probe is embedded, and what Datarim is for the broader task lifecycle.