The docs: --detach runs the editor as $!, a line with no newline fails only in the log, data reads to the end

The skill said --detach forks and $! was not the editor's pid; it is, and
/status agrees. A line written with no newline runs at the close, after
the write is answered, so its failure is in the log alone: end lines
with their newline. And `cat data` reads from the address to the end of
the text, as acme's does; xdata is the range.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 3 insertions, 3 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 5ac1ba46..0575fab7 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -17,9 +17,9 @@ Check `$NINE_MOUNT` first. `9ns --mntgen` sets it for every process it starts
 (an interactive shell on this machine runs inside one), so a set `$NINE_MOUNT`
 means the posted-9P registry is mounted there, usually `/mnt/9p`, and each
 running editor is a directory `$NINE_MOUNT/pardes/<pid>/` (a `--detach=NAME`
-session's is `pardes/NAME/`; `pardes --detach=NAME` forks, its parent
-returning at once, so the running editor's pid is not `$!`: read it from
-`$m/status`, whose first line is `pid <n>`). Inside a pane, `$PARDES_9P` is that session's
+session's is `pardes/NAME/`; `pardes --detach=NAME &` runs the editor as
+that process, so `$!` is its pid, and `$m/status`'s first line, `pid <n>`,
+says the same). Inside a pane, `$PARDES_9P` is that session's
 socket (`/run/user/1000/pardes-9p-<pid or NAME>.sock`), which names the
 directory either way, and `$PARDES_PANE` is the calling pane's serial: