diff --git a/aimem/SKILL.md b/aimem/SKILL.md
index 0b652af..e271156 100644
--- a/aimem/SKILL.md
+++ b/aimem/SKILL.md
@@ -34,8 +34,8 @@ environment and this skill does not apply.
 
 Read these (co-located with this file, under `references/`) on demand:
 
-- **`references/navigation.md`** — how to identify the bucket/region/endpoint
-  of your mount, and the conventional layout of files at the root.
+- **`references/navigation.md`** — how to locate your mount and the
+  conventional layout of files at its root.
 - **`references/workspace.md`** — POSIX semantics: copy-on-write staging,
   close/fsync durability, rename, and what doesn't work.
 - **`references/memory.md`** — where to put long-lived agent context
diff --git a/aimem/references/annotations.md b/aimem/references/annotations.md
index e470c4e..0cddfa3 100644
--- a/aimem/references/annotations.md
+++ b/aimem/references/annotations.md
@@ -34,7 +34,7 @@ object), so annotations can never collide with actual keys.
 
 If a note write fails with an I/O error or "No such file or directory", you
 almost certainly used the wrong `<object-path>` (a dropped directory prefix
-or a stale name) — you do **not** need to `mkdir` the annotation directory,
+or a stale name). You do **not** need to `mkdir` the annotation directory;
 it resolves automatically for an object that exists. Re-derive the path from
 the object's exact key and retry; do not conclude the annotation channel is
 unavailable.
diff --git a/aimem/references/memory.md b/aimem/references/memory.md
index f0bef41..d21ec33 100644
--- a/aimem/references/memory.md
+++ b/aimem/references/memory.md
@@ -3,8 +3,8 @@
 aimem warms a curated set of well-known agent memory files into
 its read cache on mount, so that recalling them from a fresh
 sandbox is fast. Write your project context to one of these
-conventional paths and other agents on this mount will be able to
-read it without you having to point at it.
+conventional paths. Other agents on this mount can then read it
+without you pointing them at it.
 
 The exact set warmed depends on the `--agent` profile the mount was
 started with (claude, codex, cursor, or auto — which warms all of
diff --git a/aimem/references/metadata.md b/aimem/references/metadata.md
index 3b26483..80f08b8 100644
--- a/aimem/references/metadata.md
+++ b/aimem/references/metadata.md
@@ -49,11 +49,11 @@ lookup/listing. The filesystem does not reject a
 `setfattr -n user.s3.meta.foo -v bar path` — but it does **not** update
 the object's native S3 user metadata or create an S3 tag either. The
 value is instead stored under aimem's own private, base64-encoded
-`xattr-` header and uploaded under that key on next close/sync; the
+`xattr-` header and uploaded under that key on next close/sync. The
 `user.s3.meta.*`/`user.s3.tags.*` reflection keeps coming from the
 native headers, so your value never appears back under the name you set
-it — even though the write itself did persist, just not where you'd look
-for it. Treat both namespaces as observe-only.
+it. The write itself did persist — just not where you'd look for it.
+Treat both namespaces as observe-only.
 
 To attach durable, natively-visible metadata to an object, set it where
 the object is produced (the writer/uploader that PUTs it), not via
diff --git a/aimem/references/navigation.md b/aimem/references/navigation.md
index 9b91ce5..899cf19 100644
--- a/aimem/references/navigation.md
+++ b/aimem/references/navigation.md
@@ -16,9 +16,9 @@ mount point is the root of the configured prefix, not necessarily the bucket
 itself: `ls <mount-root>` lists the top-level objects under that prefix, plus
 the synthetic `.aimem/` namespace (e.g. `.aimem/annot/` for object
 annotations). Every ordinary persistent file you read or write under the mount
-maps to an object on the backing MinIO AIStor bucket; entries under `.aimem/`
-are agent-native surfaces — object annotations are stored as native AIStor
-object metadata, not as object bytes — and are not ordinary objects.
+maps to an object on the backing MinIO AIStor bucket. Entries under `.aimem/`
+are agent-native surfaces, not ordinary objects — object annotations are stored
+as native AIStor object metadata, not as object bytes.
 
 ## How to find things
 
diff --git a/aimem/references/search.md b/aimem/references/search.md
index 3fdf23f..2c948fd 100644
--- a/aimem/references/search.md
+++ b/aimem/references/search.md
@@ -31,7 +31,7 @@ Other flags: `--no-recursive` (only keys directly under `--prefix`),
 Connection comes from the standard flags/env (`--endpoint-url` /
 `AIMEM_ENDPOINT_URL`, `--access-key` / `AIMEM_ACCESS_KEY`, `--secret-key` /
 `AIMEM_SECRET_KEY`, optional `--session-token`). Output is one matching object
-key per line, or — with `--content` — `name:line[:col]:text` matching lines
+key per line. With `--content`, each matching line is `name:line[:col]:text`
 (context lines on `name-…` separators). A stderr summary reports
 `N matches in M files / K scanned`, adding `/ skipped`, `/ errors`, and
 `(truncated)` when relevant.
diff --git a/aimem/references/workspace.md b/aimem/references/workspace.md
index 6a42d8e..57201e9 100644
--- a/aimem/references/workspace.md
+++ b/aimem/references/workspace.md
@@ -27,11 +27,11 @@ This means:
   opening. aimem warns at mount if free space is below the
   configured threshold.
 - **Concurrent writers fight.** If two processes open the same path
-  for writing, whichever closes last wins — close order isn't
-  guaranteed to match open order — and the other's data is silently
-  overwritten. This is this mount's staged-upload policy (the last
-  `close()` is what gets uploaded), not a universal POSIX guarantee —
-  worth re-stating here because the blast radius is the bucket.
+  for writing, whichever closes last wins, and the other's data is
+  silently overwritten. Close order isn't guaranteed to match open
+  order. This is this mount's staged-upload policy (the last
+  `close()` is what gets uploaded), not a universal POSIX guarantee,
+  and the blast radius is the bucket.
 
 ## Rename