1 files changed, 23 insertions, 0 deletions
diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md
index 895526f..0bfd3d3 100644
--- a/claude-rules/todo-format.md
+++ b/claude-rules/todo-format.md
@@ -263,3 +263,26 @@ are noise that pollute his `cj:` greps.
     ** DOING [#A] Kostya's contract :admin:kostya:
     *** 2026-05-15 Fri @ 14:00:00 -0500 Kostya basis — part-time, 20 hr/week
     Nerses confirmed 5/15 13:30 CDT: Kostya runs at 20 hr/week part-time, mirroring Vrezh's structure. Plugged into Exhibit A § 2 of the contract draft.
+
+## Cross-Project Dependency Tag
+
+A task can be blocked by work that has to happen in a *different project* — a rulesets task that can't finish until `.emacs.d` ships a companion function, say. Left unmarked, two things go wrong: the what's-next workflow keeps recommending the blocked task even though it can't move, and the blocker sits at low priority in the other project, so the dependency stalls silently.
+
+Mark the dependency with the `:blocked:` tag plus a `:BLOCKED_BY:` property:
+
+```
+** DOING [#B] Wrap-teardown feature :feature:blocked:
+:PROPERTIES:
+:BLOCKED_BY: emacsd: ai-term companion functions (cj/ai-term-quit, -live-count)
+:END:
+Body...
+```
+
+- The `:blocked:` tag on the heading is the filterable marker — it's what `open-tasks.org` reads to pull the task out of the "do this next" recommendation.
+- The `:BLOCKED_BY:` property names *which* project blocks the task and *what* that project owes, as `<project>: <what>`. The project token is the short basename (`emacsd`, `home`, `work`), matching the inbox/handoff naming.
+
+A task stays `:blocked:` only while the external dependency is genuinely outstanding. When the other project delivers, or the dependency dissolves, drop the `:blocked:` tag and the `:BLOCKED_BY:` property in the same edit — the task is workable again.
+
+`open-tasks.org` Next Mode surfaces `:blocked:` tasks in a dedicated "Blocked on other projects" section instead of the cascade, naming each blocker so a stalled cross-project dependency stays visible (and can be nudged via `inbox-send`) rather than rotting. See that workflow for the surfacing behavior.
+
+This is distinct from `VERIFY`, which marks "waiting on Craig's input." `:blocked:` marks "waiting on another *project's* work." If Craig's input is what's needed, it's a VERIFY, not `:blocked:`.