@tryglen/pi 0.0.0-stage → 0.6.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +117 -2
- package/package.json +50 -4
- package/skills/code-search/SKILL.md +19 -0
- package/skills/controls/SKILL.md +45 -0
- package/skills/create-artifact/SKILL.md +11 -0
- package/skills/create-skill/SKILL.md +41 -0
- package/skills/feedback/SKILL.md +59 -0
- package/skills/forget/SKILL.md +41 -0
- package/skills/import-transcripts/SKILL.md +34 -0
- package/skills/invite/SKILL.md +28 -0
- package/skills/search/SKILL.md +35 -0
- package/skills/session-takeover/SKILL.md +67 -0
- package/skills/setup/SKILL.md +60 -0
- package/skills/use-artifact/SKILL.md +11 -0
- package/skills/use-skill/SKILL.md +10 -0
- package/src/_utils/fail-open.ts +7 -0
- package/src/_utils/last-assistant-text.ts +11 -0
- package/src/_utils/parse-hook-output.ts +21 -0
- package/src/_utils/parse-json.ts +8 -0
- package/src/_utils/run-glen-hook.ts +31 -0
- package/src/_utils/text-of.ts +13 -0
- package/src/index.ts +172 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Glen
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
CHANGED
|
@@ -1,3 +1,118 @@
|
|
|
1
|
-
#
|
|
1
|
+
# @tryglen/pi — glen for pi
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Shared team memory for coding agents. Glen automatically recalls relevant context at
|
|
4
|
+
the start of every turn and captures what you build, so your whole team's agents share
|
|
5
|
+
the same institutional knowledge.
|
|
6
|
+
|
|
7
|
+
## What it does
|
|
8
|
+
|
|
9
|
+
This is a [pi](https://pi.dev) package: it ships the glen extension (`src/index.ts`)
|
|
10
|
+
plus the glen skills. Pi has no declarative hooks file — the extension subscribes to
|
|
11
|
+
pi's lifecycle events and runs one frozen `glen` CLI command per event (the same
|
|
12
|
+
thin-hook model as glen's other agent plugins):
|
|
13
|
+
|
|
14
|
+
- **`session_start`** → `glen session-start --agent pi` — surfaces org/mode status
|
|
15
|
+
and queues the review-link instruction.
|
|
16
|
+
- **`before_agent_start`** → `glen ingest --agent pi` — sends the prompt (plus the
|
|
17
|
+
prior assistant turn and workspace context: repo, branch, agent name) to your glen
|
|
18
|
+
org, retrieves matching memories, and injects them as context for the model.
|
|
19
|
+
- **`agent_settled`** → `glen ingest --agent pi` — captures the completed turn
|
|
20
|
+
(your prompt + the final assistant answer) into team memory.
|
|
21
|
+
- **`tool_result` (bash)** → `glen pr-link --agent pi` — after a `git commit`, links
|
|
22
|
+
the commit to the session in glen; when a shell command surfaced a GitHub PR URL,
|
|
23
|
+
appends the matching Glen review link so the agent can share it.
|
|
24
|
+
|
|
25
|
+
Every command is fail-open: a glen outage can never block or break a pi session. If
|
|
26
|
+
the `glen` CLI isn't installed, pi shows one warning per session saying how to install it.
|
|
27
|
+
`glen off` injects and records nothing. In incognito (`glen incognito`) recall still
|
|
28
|
+
works but nothing is recorded to team memory. Glen reads only the hook input, the
|
|
29
|
+
agent's session transcript, and git metadata for the current repo.
|
|
30
|
+
|
|
31
|
+
## Skills
|
|
32
|
+
|
|
33
|
+
The package ships the full glen skill set (see `skills/`). Pi supports the Agent
|
|
34
|
+
Skills standard, so they are available as `/skill:<name>` and are offered to the agent
|
|
35
|
+
automatically.
|
|
36
|
+
|
|
37
|
+
## Install
|
|
38
|
+
|
|
39
|
+
The extension shells out to the glen CLI, so install that first:
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
npm install -g @tryglen/cli
|
|
43
|
+
glen login
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
Then add the package to pi:
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
pi install npm:@tryglen/pi
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
`glen install` does this step for you when it detects pi. Restart pi (or run
|
|
53
|
+
`/reload`) to load the extension.
|
|
54
|
+
|
|
55
|
+
After login your active organization is saved locally. Switch orgs at any time with
|
|
56
|
+
`glen org switch`.
|
|
57
|
+
|
|
58
|
+
## Updating
|
|
59
|
+
|
|
60
|
+
```sh
|
|
61
|
+
pi update npm:@tryglen/pi
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
`glen update` updates the CLI **and** any installed glen plugins (this package
|
|
65
|
+
included) in one go.
|
|
66
|
+
|
|
67
|
+
## Uninstall
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
pi remove npm:@tryglen/pi
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
`glen uninstall` also does this for you.
|
|
74
|
+
|
|
75
|
+
## What data is sent
|
|
76
|
+
|
|
77
|
+
On every turn, glen sends to your glen org:
|
|
78
|
+
|
|
79
|
+
- The current user prompt
|
|
80
|
+
- The prior assistant turn
|
|
81
|
+
- Workspace metadata: repo name, branch, commit hash, remote URL
|
|
82
|
+
- Agent name (`pi`) and session details
|
|
83
|
+
|
|
84
|
+
**Nothing is recorded while incognito is on.** Recall still works — glen fetches
|
|
85
|
+
relevant memories but writes nothing to team memory. Admin analytics still count your
|
|
86
|
+
prompts as numbers only. Toggle with `glen incognito` / `glen on`. `glen off` injects
|
|
87
|
+
and records nothing.
|
|
88
|
+
|
|
89
|
+
The glen CLI also reports content-free error codes about itself (error code, command and flag names, CLI, OS and agent
|
|
90
|
+
versions; never prompts, paths, flag values or content), incognito included. Turn this off with
|
|
91
|
+
`glen telemetry disable` or `DO_NOT_TRACK=1`.
|
|
92
|
+
|
|
93
|
+
Glen never sends data to any third party. All memory is stored in your org's private
|
|
94
|
+
glen instance.
|
|
95
|
+
|
|
96
|
+
## Troubleshooting
|
|
97
|
+
|
|
98
|
+
**Check session status (org, mode):**
|
|
99
|
+
|
|
100
|
+
```sh
|
|
101
|
+
glen status
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
**Full diagnostics:**
|
|
105
|
+
|
|
106
|
+
```sh
|
|
107
|
+
glen doctor
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
**Broken setup?** Ask the agent to "set up glen" — the bundled setup skill runs
|
|
111
|
+
`glen doctor` and fixes whatever it reports.
|
|
112
|
+
|
|
113
|
+
**Extension not loading:** run `/reload` inside pi, or restart pi. Verify the package
|
|
114
|
+
is registered with `pi list` (it should include `npm:@tryglen/pi`).
|
|
115
|
+
|
|
116
|
+
**No active organization error:** run `glen org switch` to select an org, or
|
|
117
|
+
`glen org list` to see your memberships. If the list itself fails with an auth error,
|
|
118
|
+
run `glen login` to reconnect.
|
package/package.json
CHANGED
|
@@ -1,6 +1,52 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@tryglen/pi",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "0.6.2",
|
|
4
|
+
"description": "Shared team memory for coding agents — automatic recall and capture on every turn via the glen CLI.",
|
|
5
|
+
"keywords": [
|
|
6
|
+
"pi-package",
|
|
7
|
+
"pi",
|
|
8
|
+
"memory",
|
|
9
|
+
"team",
|
|
10
|
+
"context"
|
|
11
|
+
],
|
|
12
|
+
"homepage": "https://tryglen.com",
|
|
13
|
+
"license": "MIT",
|
|
14
|
+
"type": "module",
|
|
15
|
+
"files": [
|
|
16
|
+
"src",
|
|
17
|
+
"!src/**/*.test.ts",
|
|
18
|
+
"skills",
|
|
19
|
+
"README.md",
|
|
20
|
+
"LICENSE"
|
|
21
|
+
],
|
|
22
|
+
"pi": {
|
|
23
|
+
"extensions": [
|
|
24
|
+
"./src/index.ts"
|
|
25
|
+
],
|
|
26
|
+
"skills": [
|
|
27
|
+
"./skills"
|
|
28
|
+
]
|
|
29
|
+
},
|
|
30
|
+
"publishConfig": {
|
|
31
|
+
"access": "public"
|
|
32
|
+
},
|
|
33
|
+
"scripts": {
|
|
34
|
+
"prepublishOnly": "echo 'Do not publish from this folder. pi-publish.yml packs, checks and publishes the tarball.' && exit 1",
|
|
35
|
+
"typecheck": "tsc --noEmit",
|
|
36
|
+
"test": "vitest run"
|
|
37
|
+
},
|
|
38
|
+
"peerDependencies": {
|
|
39
|
+
"@earendil-works/pi-coding-agent": "*"
|
|
40
|
+
},
|
|
41
|
+
"peerDependenciesMeta": {
|
|
42
|
+
"@earendil-works/pi-coding-agent": {
|
|
43
|
+
"optional": true
|
|
44
|
+
}
|
|
45
|
+
},
|
|
46
|
+
"devDependencies": {
|
|
47
|
+
"@earendil-works/pi-coding-agent": "1.1.0",
|
|
48
|
+
"@types/node": "^20.0.0",
|
|
49
|
+
"typescript": "^5.5.0",
|
|
50
|
+
"vitest": "^3.0.0"
|
|
51
|
+
}
|
|
52
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: code-search
|
|
3
|
+
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).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Resolve the file and line range the user is asking about, then run
|
|
7
|
+
`glen code-search <path:start-end> "<the user's question>"` via Bash — e.g.
|
|
8
|
+
`glen code-search src/api/rate-limit.ts:40-85 "why is this rate-limited?"`.
|
|
9
|
+
|
|
10
|
+
The output is the ranked memory plus the full transcripts of the conversations
|
|
11
|
+
behind the commits that last touched those lines. Answer from those transcripts —
|
|
12
|
+
Glen owns code-provenance questions; do not guess from the current code alone.
|
|
13
|
+
|
|
14
|
+
This is NOT `glen search` (org-wide memory): `code-search` is scoped to the
|
|
15
|
+
selected code's actual commit history via git blame.
|
|
16
|
+
|
|
17
|
+
If it prints "no Glen trace found", the code predates Glen or was committed
|
|
18
|
+
without recording — say so honestly. If it prints "No active organization",
|
|
19
|
+
tell the user to run `glen org switch`.
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: controls
|
|
3
|
+
description: Control glen memory - turn glen on/off, go off the record (incognito, account-wide), go silent (keep recording, surface nothing), toggle glen's skill suggestions, or switch which organization's memory is active. Use ONLY when the user explicitly asks (e.g. "turn glen off", "go off the record", "stop recording", "stop suggesting skills", "just record, don't inject anything", "switch to my personal org").
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
glen has four modes. Always confirm the change to the user.
|
|
7
|
+
|
|
8
|
+
- **On:** `glen on` — glen injects context and records everything (the default).
|
|
9
|
+
**Account-wide:** resumes recording on every machine, agent, and connected client.
|
|
10
|
+
- **Off:** `glen off` — glen injects nothing AND records nothing until `glen on`.
|
|
11
|
+
**Account-wide and server-enforced:** fully pauses glen on every machine, agent,
|
|
12
|
+
and connected client.
|
|
13
|
+
- **Incognito (off the record):** `glen incognito` — glen keeps recalling/injecting
|
|
14
|
+
but records nothing until `glen on`. **Account-wide and server-enforced:** the
|
|
15
|
+
server blocks memory writes for every machine, agent, and connected client, not
|
|
16
|
+
just this one; the same switch lives on the dashboard's Memories page. Admin
|
|
17
|
+
analytics still count prompts as content-free numbers — never content. Use for "go off the record" / "stop recording".
|
|
18
|
+
- **Silent:** `glen silent` — glen keeps recording everything but surfaces
|
|
19
|
+
nothing: no recall, no suggestions, and `glen search` returns nothing, until
|
|
20
|
+
`glen on`. **Account-wide and server-enforced** (the server returns empty
|
|
21
|
+
results for every machine, agent, and connected client; the same switch lives
|
|
22
|
+
on the dashboard's Memories page). Use for "just collect / stay out of my
|
|
23
|
+
way / record but don't inject".
|
|
24
|
+
|
|
25
|
+
All four mode commands need to reach the glen server (the
|
|
26
|
+
server is the source of truth); if the command fails, the mode did NOT change —
|
|
27
|
+
tell the user.
|
|
28
|
+
|
|
29
|
+
Pick by intent: "stop recording but keep helping" → `glen incognito`; "record but
|
|
30
|
+
don't help/inject" → `glen silent`; "turn glen off entirely / disable glen" →
|
|
31
|
+
`glen off`; "turn glen back on" → `glen on`.
|
|
32
|
+
|
|
33
|
+
- Skill nudges (two per-user toggles, both on by default):
|
|
34
|
+
`glen suggestions skill-create off` stops glen suggesting that finished work be
|
|
35
|
+
turned into a new team skill; `glen suggestions skill-use off` stops glen
|
|
36
|
+
recommending existing team skills. Re-enable with `… on`. **Account-wide and
|
|
37
|
+
server-enforced** (the same toggles live in the Memories page's Suggestions
|
|
38
|
+
menu). Use for "stop suggesting skills" / "don't recommend skills". Like the
|
|
39
|
+
modes, a failed command means the preference did NOT change — tell the user.
|
|
40
|
+
- Switch org: run `glen org switch <slug>` (or `glen org list` to see options).
|
|
41
|
+
This remains per-machine but is audited server-side. NEVER switch organizations
|
|
42
|
+
unless the user explicitly asked — it changes which tenant receives their data.
|
|
43
|
+
- Admin visibility: owners/admins can see every active-org member's current mode,
|
|
44
|
+
suggestion settings, and last update time at `/admin/controls`.
|
|
45
|
+
- Show state: `glen status`.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create-artifact
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
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.
|
|
8
|
+
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>)`.
|
|
9
|
+
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.
|
|
10
|
+
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).
|
|
11
|
+
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.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create-skill
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are authoring a reusable **skill** — a focused markdown prompt another agent will follow later, with no memory of this session.
|
|
7
|
+
|
|
8
|
+
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).
|
|
9
|
+
- **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").
|
|
10
|
+
- **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.
|
|
11
|
+
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.
|
|
12
|
+
3. **Name + describe it.** A short imperative name and a one-sentence description that says *exactly when to trigger it* (this drives discovery).
|
|
13
|
+
4. **Write a tight SKILL.md body.** Best practices:
|
|
14
|
+
- Lead with *when to use it* and the end goal.
|
|
15
|
+
- Give concrete, ordered steps — exact commands, file paths, gotchas — not vague advice.
|
|
16
|
+
- Keep it self-contained: assume zero prior context. Cut anything that isn't actionable.
|
|
17
|
+
- **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.
|
|
18
|
+
- **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.
|
|
19
|
+
5. **Finish based on the destination chosen in step 1:**
|
|
20
|
+
|
|
21
|
+
**Local skill** (and always the incognito path) — nothing leaves the machine:
|
|
22
|
+
- 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.
|
|
23
|
+
- Start the file with YAML frontmatter (`name`, and the `description` from step 3), then the body.
|
|
24
|
+
- No `glen skill create`, no recording. Confirm the saved path to the user.
|
|
25
|
+
|
|
26
|
+
**Glen skill** (only when not incognito):
|
|
27
|
+
- **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.
|
|
28
|
+
- **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):
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
glen skill create --name "<name>" --description "<one-line>" --file /tmp/glen-skill.md --deps /tmp/glen-deps.json
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
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:
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
glen skill create --name "<name>" --description "<one-line>" --dir /tmp/glen-skill-pkg --deps /tmp/glen-deps.json
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
`--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.
|
|
41
|
+
- 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.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: feedback
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
This files a ticket about **glen itself** — the CLI, the memory, the search, the
|
|
7
|
+
dashboard. It is NOT for bugs in the user's own project. If the user says "file a
|
|
8
|
+
bug" about the code you are working on, that belongs in their issue tracker, not
|
|
9
|
+
here.
|
|
10
|
+
|
|
11
|
+
Tickets land in the same Slack channels the dashboard's feedback widget posts to,
|
|
12
|
+
and carry the user's identity, the repo/branch, and a link to this conversation's
|
|
13
|
+
transcript automatically. Never paste secrets, tokens, or file contents into a
|
|
14
|
+
ticket — the transcript link already gives the team the context.
|
|
15
|
+
|
|
16
|
+
## Filing on the user's behalf
|
|
17
|
+
|
|
18
|
+
When the user asks you to report something, run one of these via Bash:
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
glen bug "<title>" --description "<what is wrong>" [--steps "<repro>"] [--severity low|medium|high|critical] --agent <agent>
|
|
22
|
+
glen feedback "<title>" --wants "<the concrete change>" --why "<why it matters>" [--context "<extra>"] --agent <agent>
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Severity defaults to `medium`. Write the description in the user's own words
|
|
26
|
+
where you have them. Infer `--why` when the motivation is obvious rather than
|
|
27
|
+
interrogating the user for it.
|
|
28
|
+
|
|
29
|
+
## Filing on your own behalf
|
|
30
|
+
|
|
31
|
+
When the observation is yours, not the user's, add `--from agent`. It renders
|
|
32
|
+
differently for the team — "Claude Code noticed X" reads very differently from
|
|
33
|
+
"Ada wants X", and both are useful.
|
|
34
|
+
|
|
35
|
+
If you are filing **without being asked** — you hit the problem yourself and
|
|
36
|
+
decided it was worth reporting — also pass `--proactive`. On an off-the-record
|
|
37
|
+
(incognito) session the server refuses self-initiated tickets outright and the
|
|
38
|
+
command tells you so — nothing the user didn't ask for leaves that session.
|
|
39
|
+
Mention it and let them decide.
|
|
40
|
+
|
|
41
|
+
Only file proactively for something concrete and attributable:
|
|
42
|
+
|
|
43
|
+
- a glen CLI command failed or returned a malformed result
|
|
44
|
+
- `glen search` returned results that clearly contradict the code you just read
|
|
45
|
+
- a glen hook misfired, or injected context that was plainly wrong
|
|
46
|
+
|
|
47
|
+
Do NOT file proactively for: a search that merely found nothing, a preference of
|
|
48
|
+
yours about the output format, a hunch, or anything you cannot state as a
|
|
49
|
+
specific observed behaviour. When in doubt, mention it to the user instead and
|
|
50
|
+
let them decide.
|
|
51
|
+
|
|
52
|
+
## After running
|
|
53
|
+
|
|
54
|
+
On success it prints `ok: Bug report sent…` / `ok: Feedback sent…`: tell the user
|
|
55
|
+
it went in. On failure it prints an `error:` line naming the cause, with a `fix:`
|
|
56
|
+
line under it (e.g. "no active organization" → `glen org switch`). Relay that to
|
|
57
|
+
the user and stop.
|
|
58
|
+
**Never retry a failed filing in a loop**, and never re-file the same ticket with
|
|
59
|
+
different wording.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: forget
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
A stale memory gets caught two ways: the user points at it, or you verify it yourself.
|
|
7
|
+
|
|
8
|
+
**User-initiated** — the user says a remembered fact is wrong or outdated:
|
|
9
|
+
|
|
10
|
+
1. Identify the relevant source references. Glen search results end each source with
|
|
11
|
+
an exact `observation:<id>` or `message:<id>` reference. If the result is not
|
|
12
|
+
already in context, run `glen search "<topic>"` via Bash.
|
|
13
|
+
2. Confirm which evidence is wrong. Do not automatically forget every source in a
|
|
14
|
+
synthesized answer. When several sources repeat the same stale claim, select all
|
|
15
|
+
of those references.
|
|
16
|
+
3. Pass the returned references unchanged, in one command:
|
|
17
|
+
`glen forget observation:<id> message:<id>`.
|
|
18
|
+
|
|
19
|
+
**Agent-detected** — recalled evidence is contradicted by current code or state:
|
|
20
|
+
|
|
21
|
+
1. Verify the contradiction directly. Never forget on suspicion, a partial view, or
|
|
22
|
+
merely because two memories disagree; surface uncertain conflicts to the user.
|
|
23
|
+
2. Run `glen forget <reference...>` with only the contradicted source references.
|
|
24
|
+
3. Tell the user exactly what was forgotten and why.
|
|
25
|
+
|
|
26
|
+
Then state the correct fact in the conversation so Glen can record the correction.
|
|
27
|
+
|
|
28
|
+
Notes:
|
|
29
|
+
|
|
30
|
+
- Observation and message references can be mixed in one atomic command.
|
|
31
|
+
- Forgetting an observation hides that distilled memory from recall.
|
|
32
|
+
- Forgetting a message removes it from future recall and hides derived observations
|
|
33
|
+
that have no other active supporting message. The raw message remains visible in
|
|
34
|
+
transcript history for audit.
|
|
35
|
+
- Forget is idempotent; already-hidden references are reported as unchanged.
|
|
36
|
+
- Undo with `glen restore <reference...>`. Automatic restore never revives an
|
|
37
|
+
observation that a user directly forgot.
|
|
38
|
+
- Legacy `[m:<id>]` and bare observation ids remain accepted.
|
|
39
|
+
- If a legacy suffix is ambiguous, retry with the full `observation:<id>` listed.
|
|
40
|
+
- If the CLI reports no active organization, tell the user to run
|
|
41
|
+
`glen org switch`.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: import-transcripts
|
|
3
|
+
description: Import the user's old local coding-agent transcripts (Claude Code, Codex, Cursor, or Pi sessions from before glen was installed) into glen's shared team memory. Use when the user asks to import, backfill, or migrate past sessions/conversations/chat history into glen.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Run `glen import <path…>` via Bash. It parses local transcripts, starts the
|
|
7
|
+
import in the background and returns right away, so don't wait on it. Tell the
|
|
8
|
+
user it is running. glen does not tell you when it finishes: run
|
|
9
|
+
`glen import --status` to check on it (it says running, finished, or stopped,
|
|
10
|
+
with counts), and check again later if the user wants to know it is done.
|
|
11
|
+
|
|
12
|
+
It is safe to re-run: already-imported turns are skipped automatically, so
|
|
13
|
+
re-running the same command resumes or retries a stopped import. Pass `--wait`
|
|
14
|
+
only if the user wants it to run in the foreground.
|
|
15
|
+
|
|
16
|
+
Where old transcripts live:
|
|
17
|
+
|
|
18
|
+
- Claude Code sessions: `~/.claude/projects` (one `<session-uuid>.jsonl` per
|
|
19
|
+
session, grouped by project directory)
|
|
20
|
+
- Codex sessions: `~/.codex/sessions`
|
|
21
|
+
- Pi sessions: `~/.pi/agent/sessions` (one `<timestamp>_<uuid>.jsonl` per session,
|
|
22
|
+
grouped by project directory)
|
|
23
|
+
- Cursor chats: `~/.config/Cursor/User/globalStorage/state.vscdb` on Linux,
|
|
24
|
+
`~/Library/Application Support/Cursor/User/globalStorage/state.vscdb` on
|
|
25
|
+
macOS (needs Node 22.5+; close Cursor first for the freshest data)
|
|
26
|
+
|
|
27
|
+
A path can be a single file or a directory (scanned recursively; formats are
|
|
28
|
+
auto-detected per file). Preview with `glen import --dry-run <path…>` — it
|
|
29
|
+
lists every conversation and turn count without writing anything. For large
|
|
30
|
+
directories, offer the dry run first so the user can confirm the scope.
|
|
31
|
+
|
|
32
|
+
If it (or `glen import --status`) prints "no active organization", tell the
|
|
33
|
+
user to run `glen org switch`. If it prints "not connected" or "connection
|
|
34
|
+
expired", tell the user to run `glen login`. Then re-run the same import.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: invite
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
glen is shared team memory — it gets more useful with every teammate whose context
|
|
7
|
+
lands in the pool. When the user wants to bring someone in:
|
|
8
|
+
|
|
9
|
+
1. Get the teammate's email address. Ask if it isn't given.
|
|
10
|
+
2. Run `glen invite <email>` via Bash. Invite several at once by passing more
|
|
11
|
+
emails: `glen invite alice@co.com bob@co.com`. To make someone an admin, add
|
|
12
|
+
`--role admin` (default is a regular member).
|
|
13
|
+
3. Report the result. Each address prints one of:
|
|
14
|
+
- `ok: Invitation sent to <email>`: an email invite is on its way; they
|
|
15
|
+
accept at the link and join the org.
|
|
16
|
+
- `· <email> is already a member`: nothing to do.
|
|
17
|
+
- `warning: could not invite <email> (<reason>)`: relay the reason.
|
|
18
|
+
|
|
19
|
+
Or share a link instead of emailing: run `glen invite` with NO email to print a
|
|
20
|
+
shareable join link for the org. Anyone who signs in with a verified email on the
|
|
21
|
+
org's work-email domain joins automatically — good for dropping in a team channel.
|
|
22
|
+
(Requires "Let teammates join with their work email" to be enabled in
|
|
23
|
+
Settings → General.)
|
|
24
|
+
|
|
25
|
+
Notes:
|
|
26
|
+
- Invites are sent by email and expire after 48 hours; the teammate clicks the
|
|
27
|
+
link, signs in, and lands directly in the shared memory.
|
|
28
|
+
- If it prints "no active organization", tell the user to run `glen org switch`.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: search
|
|
3
|
+
description: Search the team's shared glen memory for a SPECIFIC fact, decision, or past discussion that is not already in the auto-injected context. Do not use for things already recalled this turn.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
|
|
8
|
+
Run `glen search "<query>"` via Bash — **start with ONE comprehensive query, not a
|
|
9
|
+
fan-out of variants**.
|
|
10
|
+
|
|
11
|
+
Each search takes ~10 seconds of real user-facing wait, and the server ranks results
|
|
12
|
+
with an LLM that reads your query as free-text intent — so one detailed, self-contained
|
|
13
|
+
query beats several keyword variants. Pack everything you know into a single query:
|
|
14
|
+
who/what/where, the repo or system involved, and what kind of answer you need (a
|
|
15
|
+
decision, an owner, a rationale, setup steps).
|
|
16
|
+
|
|
17
|
+
- ✅ `glen search "Shams's recent work on the usage-page redesign in the dashboard repo — what was decided, current status, and who owns it"`
|
|
18
|
+
- ❌ `glen search "Shams"` … `glen search "usage page redesign"` … `glen search "dashboard"`
|
|
19
|
+
|
|
20
|
+
If a hook or reminder suggests multiple search questions, merge the related ones into
|
|
21
|
+
one query and run that single search.
|
|
22
|
+
|
|
23
|
+
Follow-up searches are fine for going DEEPER — when the first result surfaces
|
|
24
|
+
something new worth chasing (a project you didn't know to name, a decision that
|
|
25
|
+
points at another decision), and the answer would genuinely change what you do next.
|
|
26
|
+
But every extra search is another ~10s the user sits waiting, so don't overdo it:
|
|
27
|
+
ask yourself whether the follow-up will provide real value the first result didn't,
|
|
28
|
+
and skip it if you already have enough to act. Never re-run a mere rephrase of a
|
|
29
|
+
query that returned little — same memory, same cost, nothing new.
|
|
30
|
+
|
|
31
|
+
The output is a synthesized answer followed by a "Sources:" list (conversation ·
|
|
32
|
+
date · author · id) — treat the answer as recalled memory (it may be outdated or
|
|
33
|
+
conflicting), and cite the sources when relevant. If it prints no results, say so
|
|
34
|
+
rather than re-searching variants.
|
|
35
|
+
If it prints "No active organization", tell the user to run `glen org switch`.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: session-takeover
|
|
3
|
+
description: Use when the user provides a Glen takeover code or generated command to open its shared transcript in a fresh native agent session.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Session Takeover
|
|
7
|
+
|
|
8
|
+
Use this skill only to open a shared Glen transcript in a fresh native session.
|
|
9
|
+
Do not use it to resume the current session or import local transcript archives.
|
|
10
|
+
|
|
11
|
+
Use this two-stage contract:
|
|
12
|
+
|
|
13
|
+
1. **Select and classify before constructing a command.** Make no tool call.
|
|
14
|
+
Candidate selection has exactly two allowed message shapes:
|
|
15
|
+
|
|
16
|
+
- Plain-message form: the candidate is the entire user message, with nothing
|
|
17
|
+
before or after it.
|
|
18
|
+
- Fenced-block form: the message contains exactly one fenced code block, has
|
|
19
|
+
no non-whitespace content outside that block, and the candidate is the
|
|
20
|
+
block's sole content.
|
|
21
|
+
|
|
22
|
+
Every other message shape is INVALID. Do not search for or extract a
|
|
23
|
+
`glen takeover` substring from prose. Classify the whole unnormalized
|
|
24
|
+
selected candidate:
|
|
25
|
+
|
|
26
|
+
- VALID raw code: the entire candidate matches `^[A-Za-z0-9_-]{43}$`.
|
|
27
|
+
- VALID generated command: the entire candidate matches
|
|
28
|
+
`^glen takeover ([A-Za-z0-9_-]{43})$`; capture group 1 is the code.
|
|
29
|
+
- INVALID: every other candidate. Examples include prefix or suffix prose, a
|
|
30
|
+
command embedded in a paragraph, prose surrounding a fenced block, multiple
|
|
31
|
+
fenced blocks, `glen takeover --help`, `glen takeover <valid-code>.`,
|
|
32
|
+
`glen takeover <valid-code> extra`,
|
|
33
|
+
`glen takeover <valid-code>; printf TAKEOVER_INJECTION_PROBE`,
|
|
34
|
+
`glen takeover <valid-code>$(printf TAKEOVER_INJECTION_PROBE)`, and
|
|
35
|
+
``glen takeover <valid-code>`printf TAKEOVER_INJECTION_PROBE` ``.
|
|
36
|
+
|
|
37
|
+
2. **Produce exactly one allowed output.**
|
|
38
|
+
|
|
39
|
+
- VALID: make exactly one Bash call from the captured code:
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
glen takeover '<validated-code>'
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
- INVALID: make zero tool calls, reply exactly "Please paste the complete
|
|
46
|
+
generated `glen takeover ...` command by itself in a code block.", and
|
|
47
|
+
stop.
|
|
48
|
+
|
|
49
|
+
Construct the VALID Bash call from the captured code as one opaque quoted
|
|
50
|
+
argument, never from the user's pasted command string. Never guess, sanitize,
|
|
51
|
+
decode, alter, summarize, truncate, or invent a code.
|
|
52
|
+
|
|
53
|
+
Treat the CLI output as authoritative:
|
|
54
|
+
|
|
55
|
+
- If disconnected, tell the user to run `glen login`.
|
|
56
|
+
- If no organization is active, tell the user to run `glen org switch`.
|
|
57
|
+
- If the handoff is expired, unavailable, or belongs to another recipient, ask
|
|
58
|
+
the sender for a new command.
|
|
59
|
+
- If compatibility or context-fit validation fails, report the exact failure and
|
|
60
|
+
stop. Never bypass the guard or shorten the transcript.
|
|
61
|
+
- If installation succeeds but launch fails, surface the exact native resume
|
|
62
|
+
command printed by the CLI.
|
|
63
|
+
|
|
64
|
+
On success, explain that Glen opened a fresh native session containing the
|
|
65
|
+
verified inherited history and left the source transcript unchanged. Do not
|
|
66
|
+
pretend the current session became the takeover destination or continue the
|
|
67
|
+
inherited work here.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup
|
|
3
|
+
description: Set up, fix, or update glen on this machine. Use when the user asks to "set up glen", "fix glen", "update glen", says glen is not working / not connected / not recording, or the status line shows glen is not connected or has no org selected.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Run `glen doctor` first and branch on its `status:` lines. Fix ONLY what is
|
|
7
|
+
broken, in this order, then re-run `glen doctor` to verify and confirm to the
|
|
8
|
+
user what changed. After the `status:` lines, doctor lists problems: `error:`
|
|
9
|
+
(broken) and `warning:` (worth fixing) lines, each with a `fix:` line under it,
|
|
10
|
+
then `hint:` lines for things that may not apply. It still exits 0.
|
|
11
|
+
|
|
12
|
+
- `glen: command not found` → install the CLI: `npm install -g @tryglen/cli`,
|
|
13
|
+
then run `glen install` (it sets up the plugin + hooks for this agent).
|
|
14
|
+
- `status: cli=<x> latest=<y> channel=<...>` where y is newer than x → run
|
|
15
|
+
`glen update` (updates the CLI and any installed glen plugins in one go).
|
|
16
|
+
- `status: login=missing ...` → run `glen login` — a browser window opens with
|
|
17
|
+
a short device code prefilled; the user approves it to connect their account.
|
|
18
|
+
If no browser can open (SSH/headless), relay the printed URL and code so the
|
|
19
|
+
user can approve from any device.
|
|
20
|
+
- `status: login=ok org=missing` → run `glen org list`, show the user the
|
|
21
|
+
options, and run `glen org switch <slug>` for their choice. Never pick an
|
|
22
|
+
org for them.
|
|
23
|
+
- `status: claude=detected plugin=not-installed` (or codex/pi) → run
|
|
24
|
+
`glen install --agent <claude|codex|pi>` for the agent you are running in.
|
|
25
|
+
For pi, tell the user to run `/reload` inside pi (or restart pi) afterwards
|
|
26
|
+
so the glen extension loads.
|
|
27
|
+
- `status: codex=detected plugin=... hooks=not-registered` → run
|
|
28
|
+
`glen install --agent codex`.
|
|
29
|
+
- `status: codex-self-heal=failed: ...` → run `glen install --agent codex`,
|
|
30
|
+
then re-check.
|
|
31
|
+
- `status: claude=not-found` (or `status: codex=not-found` /
|
|
32
|
+
`status: pi=not-found`) when the user says it IS installed → ask them to run
|
|
33
|
+
`which claude` (or `which codex` / `which pi`) in their terminal, then run
|
|
34
|
+
`glen install --claude-path <that path>` (or `--codex-path` / `--pi-path`).
|
|
35
|
+
|
|
36
|
+
`glen doctor` also prints one `status: ingest agent=<agent>
|
|
37
|
+
state=<ok|failing|never|fresh-install|idle> lastSuccess=<iso|never>` line per
|
|
38
|
+
detected agent — this tracks whether hooks are actually firing, separate from
|
|
39
|
+
whether the plugin is installed:
|
|
40
|
+
- `ok` / `failing` — reflects the last recorded hook run. For `failing`,
|
|
41
|
+
doctor prints an `error:` line with a `fix:` under it (check `glen status`, then
|
|
42
|
+
`glen login` if disconnected).
|
|
43
|
+
- `fresh-install` — installed under an hour ago with no ingest yet; not a
|
|
44
|
+
fault, just still warming up.
|
|
45
|
+
- `idle` — hooks fire here; nothing recorded yet — logged out, glen off, or
|
|
46
|
+
no completed turn.
|
|
47
|
+
- `never` — hooks have never fired on THIS machine. Doctor prints it as a `warning:` line with a `fix:`
|
|
48
|
+
under it: untrusted hooks (trust them in-agent and start a new
|
|
49
|
+
session), a PATH gap, a failed hook-trust query, or a machine-topology
|
|
50
|
+
mismatch.
|
|
51
|
+
- A topology mismatch usually means the agent process runs on a different
|
|
52
|
+
machine than the one you're looking at: Codex `--remote` / Desktop-SSH and
|
|
53
|
+
Claude Code over SSH/devcontainer both run the agent — and its hooks — on
|
|
54
|
+
the REMOTE host, not locally. Install glen there and run `glen doctor` on
|
|
55
|
+
that machine, as the user the agent connects as. Cloud sessions (Codex
|
|
56
|
+
Cloud tasks, claude.ai/code) can't run user-level hooks at all — only
|
|
57
|
+
repo-committed hooks apply there.
|
|
58
|
+
|
|
59
|
+
Finish with `glen status` and tell the user, in one sentence, what state they
|
|
60
|
+
are in now.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: use-artifact
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
2. **Fetch it.** Run `glen artifact get <slug>` via Bash. The output is the document (Markdown or HTML+CSS).
|
|
8
|
+
3. **Show it.**
|
|
9
|
+
- **Markdown:** present it inline.
|
|
10
|
+
- **HTML:** write it to a local `.html` file, then open it in the system browser (`open <file>`); if that is not available, share the dashboard link below. It is a self-contained page with no JavaScript.
|
|
11
|
+
4. **Always** share the dashboard link so the user has the canonical rendered copy: `https://app.tryglen.com/artifacts/<slug>`.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: use-skill
|
|
3
|
+
description: Find and run a reusable skill from the Glen skill library (your skills plus ones shared with you) when you don't know its exact slug. Use when the user asks to "use a Glen skill", "find a skill for X", or wants a teammate's saved workflow.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
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.
|
|
8
|
+
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.
|
|
9
|
+
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.
|
|
10
|
+
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.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
// A glen failure must never break a pi session, so handler errors resolve to "no change".
|
|
2
|
+
export const failOpen =
|
|
3
|
+
<A extends unknown[], R>(handler: (...args: A) => Promise<R>) =>
|
|
4
|
+
(...args: A): Promise<R | undefined> =>
|
|
5
|
+
Promise.resolve()
|
|
6
|
+
.then(() => handler(...args))
|
|
7
|
+
.catch(() => undefined);
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
import { textOf } from "./text-of";
|
|
2
|
+
|
|
3
|
+
export const lastAssistantText = (messages: readonly unknown[]): string => {
|
|
4
|
+
const last = messages.findLast(
|
|
5
|
+
(m) =>
|
|
6
|
+
m !== null &&
|
|
7
|
+
typeof m === "object" &&
|
|
8
|
+
(m as { role?: unknown }).role === "assistant",
|
|
9
|
+
);
|
|
10
|
+
return textOf((last as { content?: unknown } | undefined)?.content);
|
|
11
|
+
};
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
import { parseJson } from "./parse-json";
|
|
2
|
+
|
|
3
|
+
// A hook prints either the JSON envelope or plain text meant as context.
|
|
4
|
+
export const parseHookOutput = (
|
|
5
|
+
raw: string,
|
|
6
|
+
): { context: string; notice: string } => {
|
|
7
|
+
const text = raw.trim();
|
|
8
|
+
if (!text) return { context: "", notice: "" };
|
|
9
|
+
const parsed = parseJson(text);
|
|
10
|
+
if (parsed === undefined) return { context: text, notice: "" };
|
|
11
|
+
const envelope = (parsed ?? {}) as {
|
|
12
|
+
hookSpecificOutput?: { additionalContext?: unknown };
|
|
13
|
+
systemMessage?: unknown;
|
|
14
|
+
};
|
|
15
|
+
const context = envelope.hookSpecificOutput?.additionalContext;
|
|
16
|
+
const notice = envelope.systemMessage;
|
|
17
|
+
return {
|
|
18
|
+
context: typeof context === "string" ? context : "",
|
|
19
|
+
notice: typeof notice === "string" ? notice : "",
|
|
20
|
+
};
|
|
21
|
+
};
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
import { spawn } from "node:child_process";
|
|
2
|
+
|
|
3
|
+
const HOOK_TIMEOUT_MS = 60_000;
|
|
4
|
+
|
|
5
|
+
// Spawned directly because pi.exec can't write to the child's stdin, and the
|
|
6
|
+
// hooks read their JSON payload from stdin. Never rejects on a glen failure.
|
|
7
|
+
export const runGlenHook = (
|
|
8
|
+
command: string,
|
|
9
|
+
payload: object,
|
|
10
|
+
timeoutMs: number = HOOK_TIMEOUT_MS,
|
|
11
|
+
): Promise<
|
|
12
|
+
{ kind: "ok"; stdout: string } | { kind: "missing" } | { kind: "failed" }
|
|
13
|
+
> =>
|
|
14
|
+
new Promise((resolve) => {
|
|
15
|
+
const [bin = "glen", ...args] = command.split(" ");
|
|
16
|
+
const child = spawn(bin, args, { stdio: ["pipe", "pipe", "ignore"] });
|
|
17
|
+
const chunks: Buffer[] = [];
|
|
18
|
+
const timer = setTimeout(() => child.kill("SIGKILL"), timeoutMs);
|
|
19
|
+
child.stdout.on("data", (chunk: Buffer) => chunks.push(chunk));
|
|
20
|
+
// A glen that exits before reading its payload makes this write fail (EPIPE); close still resolves.
|
|
21
|
+
child.stdin.on("error", () => undefined);
|
|
22
|
+
child.on("error", (error: NodeJS.ErrnoException) => {
|
|
23
|
+
clearTimeout(timer);
|
|
24
|
+
resolve({ kind: error.code === "ENOENT" ? "missing" : "failed" });
|
|
25
|
+
});
|
|
26
|
+
child.on("close", () => {
|
|
27
|
+
clearTimeout(timer);
|
|
28
|
+
resolve({ kind: "ok", stdout: Buffer.concat(chunks).toString("utf8") });
|
|
29
|
+
});
|
|
30
|
+
child.stdin.end(JSON.stringify(payload));
|
|
31
|
+
});
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
// Joins the text blocks of a message or tool result; skips images, thinking and tool calls.
|
|
2
|
+
export const textOf = (content: unknown): string => {
|
|
3
|
+
if (typeof content === "string") return content;
|
|
4
|
+
if (!Array.isArray(content)) return "";
|
|
5
|
+
return content.map(blockText).filter(Boolean).join("\n");
|
|
6
|
+
};
|
|
7
|
+
|
|
8
|
+
const blockText = (block: unknown): string => {
|
|
9
|
+
if (typeof block === "string") return block;
|
|
10
|
+
if (block === null || typeof block !== "object") return "";
|
|
11
|
+
const text = (block as { text?: unknown }).text;
|
|
12
|
+
return typeof text === "string" ? text : "";
|
|
13
|
+
};
|
package/src/index.ts
ADDED
|
@@ -0,0 +1,172 @@
|
|
|
1
|
+
// Frozen: no business logic here; the command lines are pinned by ingest.contract.test.ts.
|
|
2
|
+
import type {
|
|
3
|
+
AgentEndEvent,
|
|
4
|
+
BeforeAgentStartEventResult,
|
|
5
|
+
ExtensionAPI,
|
|
6
|
+
ExtensionContext,
|
|
7
|
+
ToolResultEventResult,
|
|
8
|
+
} from "@earendil-works/pi-coding-agent";
|
|
9
|
+
import { failOpen } from "./_utils/fail-open";
|
|
10
|
+
import { lastAssistantText } from "./_utils/last-assistant-text";
|
|
11
|
+
import { parseHookOutput } from "./_utils/parse-hook-output";
|
|
12
|
+
import { runGlenHook } from "./_utils/run-glen-hook";
|
|
13
|
+
import { textOf } from "./_utils/text-of";
|
|
14
|
+
|
|
15
|
+
const GLEN_PI_HOOK_COMMANDS = {
|
|
16
|
+
sessionStart: "glen session-start --agent pi",
|
|
17
|
+
userPromptSubmit: "glen ingest --agent pi",
|
|
18
|
+
stop: "glen ingest --agent pi",
|
|
19
|
+
postToolUse: "glen pr-link --agent pi",
|
|
20
|
+
};
|
|
21
|
+
|
|
22
|
+
const GLEN_MISSING_NOTICE =
|
|
23
|
+
"glen isn't installed, so team memory is off. Run `npm i -g @tryglen/cli`, then `glen login`.";
|
|
24
|
+
|
|
25
|
+
export default function glenTeamMemory(pi: ExtensionAPI): void {
|
|
26
|
+
// Per-session state; session_start resets it.
|
|
27
|
+
const state = {
|
|
28
|
+
pendingContext: [] as string[],
|
|
29
|
+
lastPrompt: null as string | null,
|
|
30
|
+
lastAssistant: null as string | null,
|
|
31
|
+
lastRunMessages: [] as AgentEndEvent["messages"],
|
|
32
|
+
warnedMissingGlen: false,
|
|
33
|
+
};
|
|
34
|
+
|
|
35
|
+
const sessionIdOf = (ctx: ExtensionContext): string =>
|
|
36
|
+
ctx.sessionManager.getSessionId();
|
|
37
|
+
|
|
38
|
+
const turnIdOf = (ctx: ExtensionContext): string =>
|
|
39
|
+
ctx.sessionManager.getLeafId() ?? `t-${Date.now().toString(36)}`;
|
|
40
|
+
|
|
41
|
+
const callGlen = async (
|
|
42
|
+
ctx: ExtensionContext,
|
|
43
|
+
command: string,
|
|
44
|
+
payload: object,
|
|
45
|
+
showNotice = true,
|
|
46
|
+
): Promise<{ context: string; notice: string }> => {
|
|
47
|
+
const result = await runGlenHook(command, payload);
|
|
48
|
+
if (result.kind === "missing" && !state.warnedMissingGlen) {
|
|
49
|
+
state.warnedMissingGlen = true;
|
|
50
|
+
ctx.ui.notify(GLEN_MISSING_NOTICE, "warning");
|
|
51
|
+
}
|
|
52
|
+
const out = result.kind === "ok" ? result.stdout : "";
|
|
53
|
+
const parsed = parseHookOutput(out);
|
|
54
|
+
if (showNotice && parsed.notice) ctx.ui.notify(parsed.notice, "info");
|
|
55
|
+
return parsed;
|
|
56
|
+
};
|
|
57
|
+
|
|
58
|
+
// Delivered with the first prompt's injection: pi has no pre-prompt context channel.
|
|
59
|
+
pi.on(
|
|
60
|
+
"session_start",
|
|
61
|
+
failOpen(async (event, ctx) => {
|
|
62
|
+
state.pendingContext = [];
|
|
63
|
+
state.lastPrompt = null;
|
|
64
|
+
state.lastAssistant = null;
|
|
65
|
+
state.lastRunMessages = [];
|
|
66
|
+
state.warnedMissingGlen = false;
|
|
67
|
+
const { context } = await callGlen(
|
|
68
|
+
ctx,
|
|
69
|
+
GLEN_PI_HOOK_COMMANDS.sessionStart,
|
|
70
|
+
{
|
|
71
|
+
hook_event_name: "SessionStart",
|
|
72
|
+
session_id: sessionIdOf(ctx),
|
|
73
|
+
cwd: ctx.cwd,
|
|
74
|
+
source: event.reason,
|
|
75
|
+
},
|
|
76
|
+
);
|
|
77
|
+
if (context) state.pendingContext.push(context);
|
|
78
|
+
}),
|
|
79
|
+
);
|
|
80
|
+
|
|
81
|
+
pi.on(
|
|
82
|
+
"before_agent_start",
|
|
83
|
+
failOpen(
|
|
84
|
+
async (event, ctx): Promise<BeforeAgentStartEventResult | undefined> => {
|
|
85
|
+
const prompt = event.prompt;
|
|
86
|
+
if (!prompt) return undefined;
|
|
87
|
+
state.lastPrompt = prompt;
|
|
88
|
+
const { context } = await callGlen(
|
|
89
|
+
ctx,
|
|
90
|
+
GLEN_PI_HOOK_COMMANDS.userPromptSubmit,
|
|
91
|
+
{
|
|
92
|
+
hook_event_name: "UserPromptSubmit",
|
|
93
|
+
session_id: sessionIdOf(ctx),
|
|
94
|
+
cwd: ctx.cwd,
|
|
95
|
+
prompt,
|
|
96
|
+
turn_id: turnIdOf(ctx),
|
|
97
|
+
...(state.lastAssistant
|
|
98
|
+
? { last_assistant_message: state.lastAssistant }
|
|
99
|
+
: {}),
|
|
100
|
+
},
|
|
101
|
+
);
|
|
102
|
+
const combined = [...state.pendingContext, context]
|
|
103
|
+
.filter(Boolean)
|
|
104
|
+
.join("\n\n");
|
|
105
|
+
state.pendingContext = [];
|
|
106
|
+
if (!combined) return undefined;
|
|
107
|
+
return {
|
|
108
|
+
message: {
|
|
109
|
+
customType: "glen-context",
|
|
110
|
+
content: combined,
|
|
111
|
+
display: false,
|
|
112
|
+
},
|
|
113
|
+
};
|
|
114
|
+
},
|
|
115
|
+
),
|
|
116
|
+
);
|
|
117
|
+
|
|
118
|
+
// agent_end fires per low-level run (retries included); agent_settled is the real end of a turn.
|
|
119
|
+
pi.on(
|
|
120
|
+
"agent_end",
|
|
121
|
+
failOpen(async (event) => {
|
|
122
|
+
state.lastRunMessages = event.messages;
|
|
123
|
+
}),
|
|
124
|
+
);
|
|
125
|
+
|
|
126
|
+
pi.on(
|
|
127
|
+
"agent_settled",
|
|
128
|
+
failOpen(async (_event, ctx) => {
|
|
129
|
+
const answer = lastAssistantText(state.lastRunMessages);
|
|
130
|
+
state.lastRunMessages = [];
|
|
131
|
+
if (answer) state.lastAssistant = answer;
|
|
132
|
+
const prompt = state.lastPrompt;
|
|
133
|
+
state.lastPrompt = null;
|
|
134
|
+
if (!prompt || !answer) return;
|
|
135
|
+
const { context } = await callGlen(ctx, GLEN_PI_HOOK_COMMANDS.stop, {
|
|
136
|
+
hook_event_name: "Stop",
|
|
137
|
+
session_id: sessionIdOf(ctx),
|
|
138
|
+
cwd: ctx.cwd,
|
|
139
|
+
prompt,
|
|
140
|
+
text: answer,
|
|
141
|
+
turn_id: turnIdOf(ctx),
|
|
142
|
+
});
|
|
143
|
+
if (context) state.pendingContext.push(context);
|
|
144
|
+
}),
|
|
145
|
+
);
|
|
146
|
+
|
|
147
|
+
pi.on(
|
|
148
|
+
"tool_result",
|
|
149
|
+
failOpen(async (event, ctx): Promise<ToolResultEventResult | undefined> => {
|
|
150
|
+
if (event.toolName !== "bash" || event.isError) return undefined;
|
|
151
|
+
const command =
|
|
152
|
+
typeof event.input.command === "string" ? event.input.command : "";
|
|
153
|
+
const output = textOf(event.content);
|
|
154
|
+
if (!command && !output) return undefined;
|
|
155
|
+
const { context } = await callGlen(
|
|
156
|
+
ctx,
|
|
157
|
+
GLEN_PI_HOOK_COMMANDS.postToolUse,
|
|
158
|
+
{
|
|
159
|
+
hook_event_name: "PostToolUse",
|
|
160
|
+
session_id: sessionIdOf(ctx),
|
|
161
|
+
cwd: ctx.cwd,
|
|
162
|
+
tool_name: "Bash",
|
|
163
|
+
tool_input: { command },
|
|
164
|
+
tool_response: output,
|
|
165
|
+
},
|
|
166
|
+
false,
|
|
167
|
+
);
|
|
168
|
+
if (!context) return undefined;
|
|
169
|
+
return { content: [...event.content, { type: "text", text: context }] };
|
|
170
|
+
}),
|
|
171
|
+
);
|
|
172
|
+
}
|