diff options
| -rw-r--r-- | .claude/commands/respond-to-cj-comments.md | 48 | ||||
| -rw-r--r-- | claude-rules/cross-project.md | 50 |
2 files changed, 98 insertions, 0 deletions
diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md index 54308e6..01a76ac 100644 --- a/.claude/commands/respond-to-cj-comments.md +++ b/.claude/commands/respond-to-cj-comments.md @@ -40,6 +40,33 @@ Treat the whole contiguous block as one `cj:` item. ## Instructions +### 0. Cross-Project Boundary Check (run before reading the file) + +Before scanning the target file, compare its path against the current cwd. If the file lives under a *different* project's `.ai/`-scoped root than the cwd does, stop and surface the boundary crossing — don't read the file yet. + +Detection: find the nearest ancestor of the target path that contains an `.ai/` directory (or, lacking that, the nearest ancestor that is a git repo root). Do the same for cwd. If the two roots differ, this is a cross-project invocation. + +When triggered, present inline numbered options (no popup): + +``` +The target <path> looks like it belongs to <other-project>'s session +(its root is <other-root>, the current cwd is <cwd-root>). + +1. Do it from here — I'll process the file and drop a handoff note in <other-project>/inbox/ so the other project's next session picks up the carry-forward. +2. Switch projects — stop here; reopen Claude with cwd = <other-root> and re-run. + +Pick a number. +``` + +Wait for the answer: + +- **Option 1 ("do it from here")** — proceed. Plan to write a handoff file at `<other-project>/inbox/YYYY-MM-DD-handoff-from-<this-project>-<topic>.org` as part of the cleanup pass at the end of the run. The handoff covers: scope of changes, files touched, carry-forward context, any pending Craig-asks (STALLED entries, drafts awaiting approval), and subagent-output traceability. +- **Option 2 ("switch projects")** — stop the skill, output a short confirmation, exit. Do not read the file. + +If the target file is *inside* the cwd's project root, skip this step silently. + +Canonical rule: `~/code/rulesets/claude-rules/cross-project.md`. + ### 1. Scan the file Read the target file and collect every `cj:` comment. For each one, record: @@ -184,6 +211,27 @@ Remove every `cj:` comment that was handled in step 4 (instructions done) or ste Confirm the cleanup by re-scanning the file after removals. If any `cj:` line survives that shouldn't, remove it and note the correction. +### 7. Cross-project handoff (only if step 0 triggered) + +If step 0 detected a cross-project invocation and Craig picked option 1, write the handoff before exiting: + +``` +<other-project>/inbox/YYYY-MM-DD-handoff-from-<this-project>-<topic>.org +``` + +Contents: + +- Top-of-file note: this work happened cross-project. The acting Claude was running in `<this-project>` cwd; the file lives in `<other-project>`. The target project's next Claude reads this during inbox processing and folds the work-log into its own `session-context.org` before deleting the handoff. +- Scope of changes: what `cj:` items were processed, what was changed, what's still open. +- Files touched: full paths, line-level granularity where it helps. +- Pending Craig-asks: every `STALLED` entry the run created or left in place. +- Subagent traceability: which subagents ran, what they cited, what changes they proposed. +- Carry-forward findings: anything substantive the next session needs to know. + +Mention the handoff in the current session's own `session-context.org` too, so both projects' logs are internally consistent. + +See `~/code/rulesets/claude-rules/cross-project.md` for the canonical rule. + ## Principles - **Accuracy > speed.** Subagent generously. A wrong answer to a `cj:` comment is worse than a slow one. diff --git a/claude-rules/cross-project.md b/claude-rules/cross-project.md new file mode 100644 index 0000000..b451c5a --- /dev/null +++ b/claude-rules/cross-project.md @@ -0,0 +1,50 @@ +# Cross-Project Boundaries + +Applies to: `**/*` + +How to handle requests that target files or tasks belonging to a different project's `.ai/` scope than the current session. + +## The Rule + +When a request points at a file or task living under a *different* project's `.ai/` scope, stop before doing the work. Surface the boundary crossing in one line and ask: "this looks like it belongs to `<other project>`'s session — confirm you want me to do it from here, or switch projects?" + +Each project's `.ai/` directory is the scope boundary. It carries that project's `protocols.org`, `session-context.org`, `sessions/`, `notes.org`, `todo.org`, `inbox/`, and its own memory dir under `~/.claude/projects/<encoded-cwd>/memory/`. Crossing the boundary without flagging it pollutes the current session's log with the other project's content, drops memories into the wrong dir, and skips the other project's protocols / CLAUDE.md / startup-extras that would otherwise apply. + +## When to Detect + +Trigger the check on any of these: + +- A skill or tool argument names a file under another known project (e.g. cwd is `~/.emacs.d/` and the path is `~/projects/work/todo.org`). +- A file read or write would cross into another project's `.ai/`. +- A user request names another project by topic ("the work todo", "the deepsat repo", "my emacs config") while we're not in that project. + +## How to Apply + +State the mismatch and offer the two acceptable answers. Inline numbered options per `interaction.md` — no popup. + +Two acceptable outcomes: + +1. **"Yes, do it from here"** — proceed. Record the cross-project artifact in a handoff file under the *other* project's `inbox/`, named `YYYY-MM-DD-handoff-from-<this-project>-<topic>.org`, with a top note explaining the crossover. The other project's startup workflow picks it up during inbox processing. +2. **"Switch projects"** — stop. Let the user reopen Claude in the right cwd. + +Don't assume which one was meant. Either guess is wrong half the time and the cost of asking once is one short turn. + +## Recovery When It Goes Wrong + +If you do the work first and the boundary issue surfaces afterwards: + +1. Move the cross-project session-log entries out of the current session's `.ai/session-context.org` into `<other-project>/inbox/YYYY-MM-DD-handoff-from-<this-project>-<topic>.org`. Top of that file: a heads-up explaining the crossover so the other project's next session knows what happened. +2. Replace the moved content in `session-context.org` with a brief stub pointing at the handoff file. +3. Move any project-specific memories you saved into the right project's memory dir, or note them in the handoff file if you can't move them. + +## Why + +The user sometimes invokes a skill from whatever shell they happen to be in. The request may be accidental (they meant to be in the other project's terminal) or deliberate (knowing cross-project handoff). The model can't tell from the request alone, and assuming wrong both times costs more than asking once. + +The per-project scope of `.ai/` is the design — protocols, history, memory, inbox, and todo all coupled to one project. Cross-project work breaks every assumption the next session of each project will make. + +## Related + +- `subagents.md` — the per-agent context-isolation discipline. Same principle, smaller scope. +- `interaction.md` — inline numbered options for the "from here / switch?" prompt. +- Per-project `.ai/protocols.org` — the project-scoped instructions this rule protects. |