@tryglen/pi 0.6.5 → 0.6.6

package/README.md

@@ -1,4 +1,4 @@
-# @tryglen/pi — glen for pi
+# @tryglen/pi: glen for pi
 
 Shared team memory for coding agents. Glen automatically recalls relevant context at
 the start of every turn and captures what you build, so your whole team's agents share
@@ -7,18 +7,18 @@ the same institutional knowledge.
 ## What it does
 
 This is a [pi](https://pi.dev) package: it ships the glen extension (`src/index.ts`)
-plus the glen skills. Pi has no declarative hooks file — the extension subscribes to
+plus the glen skills. Pi has no declarative hooks file; the extension subscribes to
 pi's lifecycle events and runs one frozen `glen` CLI command per event (the same
 thin-hook model as glen's other agent plugins):
 
-- **`session_start`** → `glen session-start --agent pi` — surfaces org/mode status
+- **`session_start`** → `glen session-start --agent pi`: surfaces org/mode status
   and queues the review-link instruction.
-- **`before_agent_start`** → `glen ingest --agent pi` — sends the prompt (plus the
+- **`before_agent_start`** → `glen ingest --agent pi`: sends the prompt (plus the
   prior assistant turn and workspace context: repo, branch, agent name) to your glen
   org, retrieves matching memories, and injects them as context for the model.
-- **`agent_settled`** → `glen ingest --agent pi` — captures the completed turn
+- **`agent_settled`** → `glen ingest --agent pi`: captures the completed turn
   (your prompt + the final assistant answer) into team memory.
-- **`tool_result` (bash)** → `glen pr-link --agent pi` — after a `git commit`, links
+- **`tool_result` (bash)** → `glen pr-link --agent pi`: after a `git commit`, links
   the commit to the session in glen; when a shell command surfaced a GitHub PR URL,
   appends the matching Glen review link so the agent can share it.
 
@@ -81,7 +81,7 @@ On every turn, glen sends to your glen org:
 - Workspace metadata: repo name, branch, commit hash, remote URL
 - Agent name (`pi`) and session details
 
-**Nothing is recorded while incognito is on.** Recall still works — glen fetches
+**Nothing is recorded while incognito is on.** Recall still works: glen fetches
 relevant memories but writes nothing to team memory. Admin analytics still count your
 prompts as numbers only. Toggle with `glen incognito` / `glen on`. `glen off` injects
 and records nothing.
@@ -107,7 +107,7 @@ glen status
 glen doctor
 ```
 
-**Broken setup?** Ask the agent to "set up glen" — the bundled setup skill runs
+**Broken setup?** Ask the agent to "set up glen"; the bundled setup skill runs
 `glen doctor` and fixes whatever it reports.
 
 **Extension not loading:** run `/reload` inside pi, or restart pi. Verify the package

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tryglen/pi",
-  "version": "0.6.5",
-  "description": "Shared team memory for coding agents — automatic recall and capture on every turn via the glen CLI.",
+  "version": "0.6.6",
+  "description": "Shared team memory for coding agents: automatic recall and capture on every turn via the glen CLI.",
   "keywords": [
     "pi-package",
     "pi",

package/skills/code-search/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: code-search
-description: Trace a specific piece of code to the agent conversations that produced it. Glen calls it whenever the user asks about the prior semantics of code — "why is this code like this", "why was this done this way", "what's the history of this block", "who decided this". NOT for org-wide memory questions (that's glen search).
+description: Trace a specific piece of code to the agent conversations that produced it. Glen calls it whenever the user asks about the prior semantics of code, such as "why is this code like this", "why was this done this way", "what's the history of this block", "who decided this". NOT for org-wide memory questions (that's glen search).
 ---
 
 Resolve the file and line range the user is asking about, then run
-`glen code-search <path:start-end> "<the user's question>"` via Bash — e.g.
+`glen code-search <path:start-end> "<the user's question>"` via Bash, e.g.
 `glen code-search src/api/rate-limit.ts:40-85 "why is this rate-limited?"`.
 
 The output is the ranked memory plus the full transcripts of the conversations
-behind the commits that last touched those lines. Answer from those transcripts —
+behind the commits that last touched those lines. Answer from those transcripts.
 Glen owns code-provenance questions; do not guess from the current code alone.
 
 This is NOT `glen search` (org-wide memory): `code-search` is scoped to the
 selected code's actual commit history via git blame.
 
 If it prints "no Glen trace found", the code predates Glen or was committed
-without recording — say so honestly. If it prints "No active organization",
+without recording; say so honestly. If it prints "No active organization",
 tell the user to run `glen org switch`.

package/skills/controls/SKILL.md

@@ -5,17 +5,17 @@ description: Control glen memory - turn glen on/off, go off the record (incognit
 
 glen has four modes. Always confirm the change to the user.
 
-- **On:** `glen on` — glen injects context and records everything (the default).
+- **On:** `glen on`: glen injects context and records everything (the default).
   **Account-wide:** resumes recording on every machine, agent, and connected client.
-- **Off:** `glen off` — glen injects nothing AND records nothing until `glen on`.
+- **Off:** `glen off`: glen injects nothing AND records nothing until `glen on`.
   **Account-wide and server-enforced:** fully pauses glen on every machine, agent,
   and connected client.
-- **Incognito (off the record):** `glen incognito` — glen keeps recalling/injecting
+- **Incognito (off the record):** `glen incognito`: glen keeps recalling/injecting
   but records nothing until `glen on`. **Account-wide and server-enforced:** the
   server blocks memory writes for every machine, agent, and connected client, not
   just this one; the same switch lives on the dashboard's Memories page. Admin
-  analytics still count prompts as content-free numbers — never content. Use for "go off the record" / "stop recording".
-- **Silent:** `glen silent` — glen keeps recording everything but surfaces
+  analytics still count prompts as content-free numbers, never content. Use for "go off the record" / "stop recording".
+- **Silent:** `glen silent`: glen keeps recording everything but surfaces
   nothing: no recall, no suggestions, and `glen search` returns nothing, until
   `glen on`. **Account-wide and server-enforced** (the server returns empty
   results for every machine, agent, and connected client; the same switch lives
@@ -23,7 +23,7 @@ glen has four modes. Always confirm the change to the user.
   way / record but don't inject".
 
 All four mode commands need to reach the glen server (the
-server is the source of truth); if the command fails, the mode did NOT change —
+server is the source of truth); if the command fails, the mode did NOT change;
 tell the user.
 
 Pick by intent: "stop recording but keep helping" → `glen incognito`; "record but
@@ -36,10 +36,10 @@ don't help/inject" → `glen silent`; "turn glen off entirely / disable glen"
   recommending existing team skills. Re-enable with `… on`. **Account-wide and
   server-enforced** (the same toggles live in the Memories page's Suggestions
   menu). Use for "stop suggesting skills" / "don't recommend skills". Like the
-  modes, a failed command means the preference did NOT change — tell the user.
+  modes, a failed command means the preference did NOT change; tell the user.
 - Switch org: run `glen org switch <slug>` (or `glen org list` to see options).
   This remains per-machine but is audited server-side. NEVER switch organizations
-  unless the user explicitly asked — it changes which tenant receives their data.
+  unless the user explicitly asked: it changes which tenant receives their data.
 - Admin visibility: owners/admins can see every active-org member's current mode,
   suggestion settings, and last update time at `/admin/controls`.
 - Show state: `glen status`.

package/skills/create-artifact/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: create-artifact
-description: Save a document you produced (a report, runbook, spec, dashboard, HTML page) to your Glen artifact library — private to you by default, sharable with teammates or the whole org. Use when the user says "save this as an artifact", or when you've generated a substantial standalone document worth keeping.
+description: Save a document you produced (a report, runbook, spec, dashboard, HTML page) to your Glen artifact library, private to you by default, sharable with teammates or the whole org. Use when the user says "save this as an artifact", or when you've generated a substantial standalone document worth keeping.
 ---
 
-1. **Decide it's worth saving.** Save when the output is a durable, standalone document (Markdown prose or a self-contained HTML+CSS page — no JavaScript). Skip ephemeral chat answers.
+1. **Decide it's worth saving.** Save when the output is a durable, standalone document (Markdown prose or a self-contained HTML+CSS page, no JavaScript). Skip ephemeral chat answers.
 2. **Check the record.** Run `glen status` via Bash. If incognito/off, tell the user nothing will be saved and stop unless they switch on.
 3. **Write it to a file.** Save the document to a local file (`.md` for Markdown, `.html` for HTML+CSS). To link to another artifact or skill, use `[label](glen:artifact/<slug>)` or `[label](glen:skill/<slug>)`.
-4. **Save it.** Run `glen artifact create --file <path> --title "<title>" --format auto` via Bash (piping works too: `--file -` reads stdin, but then `--title` is required). The artifact is **private to the user by default**; add `--org` if the user asked to share it with their whole org. Add `--update` to overwrite your own same-named artifact (an update without `--org` keeps the current sharing). If it reports unresolved references, the linked slug doesn't exist yet — create it or fix the link.
-5. **Confirm.** Tell the user the artifact slug and its visibility: private by default (only they can see it in the Glen dashboard under Artifacts), or shared with the org if `--org` was passed. To share it with specific teammates — or grab a shareable link — they can open the artifact's page and click **Share** (the link is access-controlled; only people it's shared with can open it).
-6. **Manage it (author-only, when asked).** Share from the CLI with `glen artifact share <slug> --with <email>[,<email>…]` (adds teammates) and/or `--org` (whole-org visibility) — both are additive; existing access is kept, and revoking access stays in the dashboard's Share dialog. Delete permanently with `glen artifact delete <slug>` — confirm with the user first; this can't be undone.
+4. **Save it.** Run `glen artifact create --file <path> --title "<title>" --format auto` via Bash (piping works too: `--file -` reads stdin, but then `--title` is required). The artifact is **private to the user by default**; add `--org` if the user asked to share it with their whole org. Add `--update` to overwrite your own same-named artifact (an update without `--org` keeps the current sharing). If it reports unresolved references, the linked slug doesn't exist yet; create it or fix the link.
+5. **Confirm.** Tell the user the artifact slug and its visibility: private by default (only they can see it in the Glen dashboard under Artifacts), or shared with the org if `--org` was passed. To share it with specific teammates (or grab a shareable link), they can open the artifact's page and click **Share** (the link is access-controlled; only people it's shared with can open it).
+6. **Manage it (author-only, when asked).** Share from the CLI with `glen artifact share <slug> --with <email>[,<email>…]` (adds teammates) and/or `--org` (whole-org visibility). Both are additive; existing access is kept, and revoking access stays in the dashboard's Share dialog. Delete permanently with `glen artifact delete <slug>`. Confirm with the user first; this can't be undone.

package/skills/create-skill/SKILL.md

@@ -1,41 +1,41 @@
 ---
 name: create-skill
-description: Turn what you just did (or a markdown prompt the user provides) into a reusable skill — either a local SKILL.md on this machine or a shared Glen skill saved to the org's library. Use when the user says "make this a skill", "save this as a skill", "save this as a Glen skill", or wants to capture a repeatable workflow.
+description: Turn what you just did (or a markdown prompt the user provides) into a reusable skill, either a local SKILL.md on this machine or a shared Glen skill saved to the org's library. Use when the user says "make this a skill", "save this as a skill", "save this as a Glen skill", or wants to capture a repeatable workflow.
 ---
 
-You are authoring a reusable **skill** — a focused markdown prompt another agent will follow later, with no memory of this session.
+You are authoring a reusable **skill**: a focused markdown prompt another agent will follow later, with no memory of this session.
 
-1. **Pick the destination FIRST — local file or Glen skill.** A skill is either a **local `SKILL.md`** on this machine (a Pi skill, visible only to you) or a **Glen skill** saved to your Glen library (recorded; private to you by default, sharable with teammates or the whole org).
-   - **Check incognito before anything else:** run `glen status` via Bash. If it reports `incognito: ON`, a Glen skill is off the table — nothing is recorded off the record — so go straight to a **local skill** and tell the user that's why (e.g. "you're off the record, so I'll save this as a local skill").
+1. **Pick the destination FIRST: local file or Glen skill.** A skill is either a **local `SKILL.md`** on this machine (a Pi skill, visible only to you) or a **Glen skill** saved to your Glen library (recorded; private to you by default, sharable with teammates or the whole org).
+   - **Check incognito before anything else:** run `glen status` via Bash. If it reports `incognito: ON`, a Glen skill is off the table (nothing is recorded off the record), so go straight to a **local skill** and tell the user that's why (e.g. "you're off the record, so I'll save this as a local skill").
    - **Otherwise, ask the user which they want** before authoring anything: a local `SKILL.md` (a Pi skill on this machine) or a Glen skill (saved to your Glen library). Don't start writing until they answer.
 2. **Gather the real workflow.** Read this conversation for the steps that actually worked. For anything done in an earlier session, run `glen search "<topic>"` via Bash to pull the relevant memory. Ask one or two clarifying questions only if the goal or trigger is genuinely ambiguous.
 3. **Name + describe it.** A short imperative name and a one-sentence description that says *exactly when to trigger it* (this drives discovery).
 4. **Write a tight SKILL.md body.** Best practices:
    - Lead with *when to use it* and the end goal.
-   - Give concrete, ordered steps — exact commands, file paths, gotchas — not vague advice.
+   - Give concrete, ordered steps (exact commands, file paths, gotchas), not vague advice.
    - Keep it self-contained: assume zero prior context. Cut anything that isn't actionable.
-   - **Reference other skills** when a step is itself a saved skill: write a markdown link `[Display text](glen:<slug>)` (find the slug with `glen skill search`). Glen tracks the link automatically and the reader will get a runnable `glen skill use <slug>` command exactly there — keep each referenced skill focused and say *when* to reach for it. Reserve this for genuinely **shared** skills — ones that also get used on their own, independent of this one.
-   - **If the skill needs supporting material, bundle it in one skill directory, not separate subskills.** Put long reference material in `references/*.md` and executable helpers in `scripts/` alongside `SKILL.md`, and point to them from the body as `${GLEN_SKILL_DIR}/references/<name>.md` / `${GLEN_SKILL_DIR}/scripts/<name>` — `glen skill use` materializes the whole directory to disk and substitutes `${GLEN_SKILL_DIR}` with its real absolute path before printing, so the reader can run the script or open the reference exactly as written. This keeps one topic as one skill instead of splintering it into a root + subskills just to hold its own files.
+   - **Reference other skills** when a step is itself a saved skill: write a markdown link `[Display text](glen:<slug>)` (find the slug with `glen skill search`). Glen tracks the link automatically and the reader will get a runnable `glen skill use <slug>` command exactly there. Keep each referenced skill focused and say *when* to reach for it. Reserve this for genuinely **shared** skills: ones that also get used on their own, independent of this one.
+   - **If the skill needs supporting material, bundle it in one skill directory, not separate subskills.** Put long reference material in `references/*.md` and executable helpers in `scripts/` alongside `SKILL.md`, and point to them from the body as `${GLEN_SKILL_DIR}/references/<name>.md` / `${GLEN_SKILL_DIR}/scripts/<name>`. `glen skill use` materializes the whole directory to disk and substitutes `${GLEN_SKILL_DIR}` with its real absolute path before printing, so the reader can run the script or open the reference exactly as written. This keeps one topic as one skill instead of splintering it into a root + subskills just to hold its own files.
 5. **Finish based on the destination chosen in step 1:**
 
-   **Local skill** (and always the incognito path) — nothing leaves the machine:
-   - Save it to `.pi/skills/<name>/SKILL.md` in this project — or `~/.pi/agent/skills/<name>/SKILL.md` for a personal skill that follows you across every project.
+   **Local skill** (and always the incognito path); nothing leaves the machine:
+   - Save it to `.pi/skills/<name>/SKILL.md` in this project, or `~/.pi/agent/skills/<name>/SKILL.md` for a personal skill that follows you across every project.
    - Start the file with YAML frontmatter (`name`, and the `description` from step 3), then the body.
    - No `glen skill create`, no recording. Confirm the saved path to the user.
 
    **Glen skill** (only when not incognito):
-   - **Declare its dependencies.** List the external tools/runtimes/MCPs the skill needs (node, an MCP, a CLI, …). For each: run `glen dependency search "<tool>"` via Bash — if a confident match exists, note its `[id]`; otherwise web-search the canonical source/install page and note `{ name, description, sourceUrl, kind }` (kind = mcp|cli|runtime|library|service). Write them to a JSON array file, e.g. `/tmp/glen-deps.json`, mixing `{ "dependencyId": "<id>" }` (reuse) and new objects.
+   - **Declare its dependencies.** List the external tools/runtimes/MCPs the skill needs (node, an MCP, a CLI, …). For each: run `glen dependency search "<tool>"` via Bash. If a confident match exists, note its `[id]`; otherwise web-search the canonical source/install page and note `{ name, description, sourceUrl, kind }` (kind = mcp|cli|runtime|library|service). Write them to a JSON array file, e.g. `/tmp/glen-deps.json`, mixing `{ "dependencyId": "<id>" }` (reuse) and new objects.
    - **Save it** via Bash. Text-only skill (no `references/`/`scripts/`): write the body to a file (e.g. `/tmp/glen-skill.md`), then run (add `--deps /tmp/glen-deps.json` if there are any):
 
      ```
      glen skill create --name "<name>" --description "<one-line>" --file /tmp/glen-skill.md --deps /tmp/glen-deps.json
      ```
 
-     Skill with bundled files: build the package in a temp directory first — `SKILL.md` at its root, plus whichever of `scripts/`, `references/`, `assets/` it needs (only those three subdirs are uploaded; caps are 100 files, 1MB per text file, 2MB per binary file, 3MB total) — then run:
+     Skill with bundled files: build the package in a temp directory first, with `SKILL.md` at its root, plus whichever of `scripts/`, `references/`, `assets/` it needs (only those three subdirs are uploaded; caps are 100 files, 1MB per text file, 2MB per binary file, 3MB total). Then run:
 
      ```
      glen skill create --name "<name>" --description "<one-line>" --dir /tmp/glen-skill-pkg --deps /tmp/glen-deps.json
      ```
 
-     `--file` and `--dir` are mutually exclusive. On a name collision either form errors — pick a different name and retry, or pass `--update` to overwrite a skill you previously authored.
+     `--file` and `--dir` are mutually exclusive. On a name collision either form errors; pick a different name and retry, or pass `--update` to overwrite a skill you previously authored.
    - The skill is **private to the user by default**. Ask the user whether to share it: with the whole org (add `--org` to `glen skill create`, or later `glen skill share <slug> --org`) or with specific teammates (`glen skill share <slug> --with <email>[,<email>…]`). Confirm the saved slug and its visibility back to the user.

package/skills/feedback/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: feedback
-description: Send a bug report or product feedback about glen itself to the Glen team. Use when the user says things like "tell the glen team", "file a bug about glen", "glen search is useless — report it", "give feedback on glen", or when YOU hit a concrete, reproducible glen malfunction worth reporting.
+description: Send a bug report or product feedback about glen itself to the Glen team. Use when the user says things like "tell the glen team", "file a bug about glen", "glen search is useless, report it", "give feedback on glen", or when YOU hit a concrete, reproducible glen malfunction worth reporting.
 ---
 
-This files a ticket about **glen itself** — the CLI, the memory, the search, the
+This files a ticket about **glen itself**: the CLI, the memory, the search, the
 dashboard. It is NOT for bugs in the user's own project. If the user says "file a
 bug" about the code you are working on, that belongs in their issue tracker, not
 here.
@@ -11,7 +11,7 @@ here.
 Tickets land in the same Slack channels the dashboard's feedback widget posts to,
 and carry the user's identity, the repo/branch, and a link to this conversation's
 transcript automatically. Never paste secrets, tokens, or file contents into a
-ticket — the transcript link already gives the team the context.
+ticket; the transcript link already gives the team the context.
 
 ## Filing on the user's behalf
 
@@ -29,13 +29,13 @@ interrogating the user for it.
 ## Filing on your own behalf
 
 When the observation is yours, not the user's, add `--from agent`. It renders
-differently for the team — "Claude Code noticed X" reads very differently from
+differently for the team: "Claude Code noticed X" reads very differently from
 "Ada wants X", and both are useful.
 
-If you are filing **without being asked** — you hit the problem yourself and
-decided it was worth reporting — also pass `--proactive`. On an off-the-record
+If you are filing **without being asked** (you hit the problem yourself and
+decided it was worth reporting), also pass `--proactive`. On an off-the-record
 (incognito) session the server refuses self-initiated tickets outright and the
-command tells you so — nothing the user didn't ask for leaves that session.
+command tells you so; nothing the user didn't ask for leaves that session.
 Mention it and let them decide.
 
 Only file proactively for something concrete and attributable:

package/skills/forget/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: forget
-description: Correct glen's memory — forget evidence that is wrong, outdated, or no longer relevant, so the team stops being told it. Use when the user says things like "that's wrong, forget it", "glen has the wrong X", "that memory is out of date", or "stop remembering that" — or when YOU verify that recalled evidence is contradicted by current code or state.
+description: Correct glen's memory by forgetting evidence that is wrong, outdated, or no longer relevant, so the team stops being told it. Use when the user says things like "that's wrong, forget it", "glen has the wrong X", "that memory is out of date", or "stop remembering that", or when YOU verify that recalled evidence is contradicted by current code or state.
 ---
 
 A stale memory gets caught two ways: the user points at it, or you verify it yourself.
 
-**User-initiated** — the user says a remembered fact is wrong or outdated:
+**User-initiated**: the user says a remembered fact is wrong or outdated:
 
 1. Identify the relevant source references. Glen search results end each source with
    an exact `observation:<id>` or `message:<id>` reference. If the result is not
@@ -16,7 +16,7 @@ A stale memory gets caught two ways: the user points at it, or you verify it you
 3. Pass the returned references unchanged, in one command:
    `glen forget observation:<id> message:<id>`.
 
-**Agent-detected** — recalled evidence is contradicted by current code or state:
+**Agent-detected**: recalled evidence is contradicted by current code or state:
 
 1. Verify the contradiction directly. Never forget on suspicion, a partial view, or
    merely because two memories disagree; surface uncertain conflicts to the user.

package/skills/import-transcripts/SKILL.md

@@ -25,7 +25,7 @@ Where old transcripts live:
   macOS (needs Node 22.5+; close Cursor first for the freshest data)
 
 A path can be a single file or a directory (scanned recursively; formats are
-auto-detected per file). Preview with `glen import --dry-run <path…>` — it
+auto-detected per file). Preview with `glen import --dry-run <path…>`; it
 lists every conversation and turn count without writing anything. For large
 directories, offer the dry run first so the user can confirm the scope.
 

package/skills/invite/SKILL.md

@@ -3,7 +3,7 @@ name: invite
 description: Invite a teammate to the user's glen organization by email, so the team's shared memory grows. Use when the user says things like "invite Alice", "add my teammate to glen", "get my team on glen", or asks how to bring coworkers in.
 ---
 
-glen is shared team memory — it gets more useful with every teammate whose context
+glen is shared team memory: it gets more useful with every teammate whose context
 lands in the pool. When the user wants to bring someone in:
 
 1. Get the teammate's email address. Ask if it isn't given.

package/skills/search/SKILL.md

@@ -5,31 +5,31 @@ description: Search the team's shared glen memory for a SPECIFIC fact, decision,
 
 For current or source-owned facts, use the available source-of-truth tool first (for example, Slack, GitHub, Notion, or logs), especially when the user names it. Use Glen only for durable history or to supplement that source; if the live source is unavailable, say so, and if it conflicts with Glen, prefer it for current state.
 
-Run `glen search "<query>"` via Bash — **start with ONE comprehensive query, not a
+Run `glen search "<query>"` via Bash. **Start with ONE comprehensive query, not a
 fan-out of variants**.
 
 Each search takes ~10 seconds of real user-facing wait, and the server ranks results
-with an LLM that reads your query as free-text intent — so one detailed, self-contained
+with an LLM that reads your query as free-text intent, so one detailed, self-contained
 query beats several keyword variants. Pack everything you know into a single query:
 who/what/where, the repo or system involved, and what kind of answer you need (a
 decision, an owner, a rationale, setup steps).
 
-- ✅ `glen search "Shams's recent work on the usage-page redesign in the dashboard repo — what was decided, current status, and who owns it"`
+- ✅ `glen search "Shams's recent work on the usage-page redesign in the dashboard repo: what was decided, current status, and who owns it"`
 - ❌ `glen search "Shams"` … `glen search "usage page redesign"` … `glen search "dashboard"`
 
 If a hook or reminder suggests multiple search questions, merge the related ones into
 one query and run that single search.
 
-Follow-up searches are fine for going DEEPER — when the first result surfaces
+Follow-up searches are fine for going DEEPER: when the first result surfaces
 something new worth chasing (a project you didn't know to name, a decision that
 points at another decision), and the answer would genuinely change what you do next.
 But every extra search is another ~10s the user sits waiting, so don't overdo it:
 ask yourself whether the follow-up will provide real value the first result didn't,
 and skip it if you already have enough to act. Never re-run a mere rephrase of a
-query that returned little — same memory, same cost, nothing new.
+query that returned little: same memory, same cost, nothing new.
 
 The output is a synthesized answer followed by a "Sources:" list (conversation ·
-date · author · id) — treat the answer as recalled memory (it may be outdated or
+date · author · id). Treat the answer as recalled memory (it may be outdated or
 conflicting), and cite the sources when relevant. If it prints no results, say so
 rather than re-searching variants.
 If it prints "No active organization", tell the user to run `glen org switch`.

package/skills/setup/SKILL.md

@@ -13,7 +13,7 @@ then `hint:` lines for things that may not apply. It still exits 0.
   then run `glen install` (it sets up the plugin + hooks for this agent).
 - `status: cli=<x> latest=<y> channel=<...>` where y is newer than x → run
   `glen update` (updates the CLI and any installed glen plugins in one go).
-- `status: login=missing ...` → run `glen login` — a browser window opens with
+- `status: login=missing ...` → run `glen login`. A browser window opens with
   a short device code prefilled; the user approves it to connect their account.
   If no browser can open (SSH/headless), relay the printed URL and code so the
   user can approve from any device.
@@ -35,25 +35,25 @@ then `hint:` lines for things that may not apply. It still exits 0.
 
 `glen doctor` also prints one `status: ingest agent=<agent>
 state=<ok|failing|never|fresh-install|idle> lastSuccess=<iso|never>` line per
-detected agent — this tracks whether hooks are actually firing, separate from
+detected agent. This tracks whether hooks are actually firing, separate from
 whether the plugin is installed:
-- `ok` / `failing` — reflects the last recorded hook run. For `failing`,
+- `ok` / `failing`: reflects the last recorded hook run. For `failing`,
   doctor prints an `error:` line with a `fix:` under it (check `glen status`, then
   `glen login` if disconnected).
-- `fresh-install` — installed under an hour ago with no ingest yet; not a
+- `fresh-install`: installed under an hour ago with no ingest yet; not a
   fault, just still warming up.
-- `idle` — hooks fire here; nothing recorded yet — logged out, glen off, or
-  no completed turn.
-- `never` — hooks have never fired on THIS machine. Doctor prints it as a `warning:` line with a `fix:`
+- `idle`: hooks fire here; nothing recorded yet (logged out, glen off, or
+  no completed turn).
+- `never`: hooks have never fired on THIS machine. Doctor prints it as a `warning:` line with a `fix:`
   under it: untrusted hooks (trust them in-agent and start a new
   session), a PATH gap, a failed hook-trust query, or a machine-topology
   mismatch.
 - A topology mismatch usually means the agent process runs on a different
   machine than the one you're looking at: Codex `--remote` / Desktop-SSH and
-  Claude Code over SSH/devcontainer both run the agent — and its hooks — on
+  Claude Code over SSH/devcontainer both run the agent (and its hooks) on
   the REMOTE host, not locally. Install glen there and run `glen doctor` on
   that machine, as the user the agent connects as. Cloud sessions (Codex
-  Cloud tasks, claude.ai/code) can't run user-level hooks at all — only
+  Cloud tasks, claude.ai/code) can't run user-level hooks at all; only
   repo-committed hooks apply there.
 
 Finish with `glen status` and tell the user, in one sentence, what state they

package/skills/use-artifact/SKILL.md

@@ -3,7 +3,7 @@ name: use-artifact
 description: Fetch and display an artifact from the user's Glen library (their own artifacts plus ones shared with them). Use when the user asks to open, view, render, or download a saved Glen artifact.
 ---
 
-1. **Find it.** If you don't know the slug, run `glen artifact search "<intent>"` via Bash and confirm the right one with the user. Search covers the user's own artifacts plus ones shared with them (directly or org-wide) — a teammate's unshared artifact won't appear.
+1. **Find it.** If you don't know the slug, run `glen artifact search "<intent>"` via Bash and confirm the right one with the user. Search covers the user's own artifacts plus ones shared with them (directly or org-wide); a teammate's unshared artifact won't appear.
 2. **Fetch it.** Run `glen artifact get <slug>` via Bash. The output is the document (Markdown or HTML+CSS).
 3. **Show it.**
    - **Markdown:** present it inline.

package/skills/use-skill/SKILL.md

@@ -4,7 +4,7 @@ description: Find and run a reusable skill from the Glen skill library (your ski
 ---
 
 1. **Search.** Run `glen skill search "<intent>"` via Bash (add `--by "<author>"`, or `--by me` for your own skills). It prints ranked candidates, each with its **[slug]**, author, and description.
-2. **Confirm.** If several plausibly match, show the top 2–3 (name + description + author) and ask the user which one. If it prints "no matching skills", say so — don't invent a skill.
-3. **Check requirements.** If the output has a `## Requirements` section, make sure each listed tool is available — follow its source link to install/enable it (or tell the user) — before you start.
-4. **Run it.** Run `glen skill use <slug>` via Bash. The output is markdown **instructions to execute now** — follow them as if they were a skill. If the skill bundles files, they're materialized locally first and the output references them by **absolute path** (e.g. a script under `~/.glen/skills/<slug>/scripts/`) — run scripts exactly as written, don't rewrite the paths.
-5. **Follow referenced skills on demand.** The instructions may contain runnable `glen skill use <slug>` commands for related skills. Run one via Bash only when its step applies — they're pulled on demand, not all upfront. Skills mentioned via `glen:` links are prefetched — their files are already materialized on disk by the time you pull them, and every `glen skill use` verifies freshness with the server so files on disk are always current.
+2. **Confirm.** If several plausibly match, show the top 2–3 (name + description + author) and ask the user which one. If it prints "no matching skills", say so; don't invent a skill.
+3. **Check requirements.** If the output has a `## Requirements` section, make sure each listed tool is available (follow its source link to install/enable it, or tell the user) before you start.
+4. **Run it.** Run `glen skill use <slug>` via Bash. The output is markdown **instructions to execute now**. Follow them as if they were a skill. If the skill bundles files, they're materialized locally first and the output references them by **absolute path** (e.g. a script under `~/.glen/skills/<slug>/scripts/`). Run scripts exactly as written, don't rewrite the paths.
+5. **Follow referenced skills on demand.** The instructions may contain runnable `glen skill use <slug>` commands for related skills. Run one via Bash only when its step applies; they're pulled on demand, not all upfront. Skills mentioned via `glen:` links are prefetched: their files are already materialized on disk by the time you pull them, and every `glen skill use` verifies freshness with the server so files on disk are always current.