threadnote 1.2.0 → 1.3.1

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.
@@ -137,6 +137,11 @@ The MCP tool `share_publish` runs the same scrubber as the CLI and refuses to pu
137
137
  patterns (PEM private keys, `sk-...`, `gh[pousr]_...`, `Bearer ...`, `AKIA...`, `xox[abprs]-...`). It writes and pushes
138
138
  the shared copy first, then removes the personal copy after the push succeeds.
139
139
 
140
+ When creating a GitHub PR or otherwise opening a review request, check for configured Threadnote shares first with
141
+ `threadnote share list` or the equivalent available share-team lookup. If one or more shares exist, ask the user whether
142
+ they want to publish a durable feature memory to help reviewers before sharing anything. If more than one share exists,
143
+ show the available teams as an option select when supported, or list the teams and ask which one to use.
144
+
140
145
  The MCP tool `share_skill` shares a local Codex/Claude `SKILL.md` file or Claude command markdown file into the team's
141
146
  `agent-artifacts/` catalog after the same scrubber checks. Shared artifacts are recallable after sync, but local
142
147
  installation remains opt-in with `threadnote share install-artifacts --apply`.
@@ -197,6 +202,7 @@ threadnote compact --project example --topic active-issue --dry-run
197
202
  threadnote archive viking://user/example/memories/handoffs/active/example/old-issue.md
198
203
  threadnote forget viking://user/example/memories/events/duplicate.md
199
204
  threadnote handoff --project example --topic active-issue --task "short task summary" --tests "checks run" --next-step "what to do next"
205
+ threadnote share list
200
206
  threadnote share init git@github.com:org/team-memories.git
201
207
  threadnote share publish viking://user/example/memories/durable/projects/foo/bar.md
202
208
  threadnote share publish-artifact ~/.codex/skills/example/SKILL.md
package/docs/index.html CHANGED
@@ -1474,6 +1474,17 @@ threadnote remember \
1474
1474
  </p>
1475
1475
 
1476
1476
  <div class="vignettes">
1477
+ <div class="vignette reveal">
1478
+ <div class="v-say">What can I do with Threadnote?</div>
1479
+ <pre class="v-call">threadnote_guide({})</pre>
1480
+ <pre class="v-response">→ a short, setup-aware tour: recall · capture · tidy · share · skills</pre>
1481
+ <div class="v-answer">
1482
+ The agent calls the onboarding tool and walks you through Threadnote one capability at a time — offering
1483
+ to run each (recall your last handoff, save a durable note, set up team sharing) rather than dumping a
1484
+ manual. The walkthrough loads only when you ask, so it never sits in your context otherwise.
1485
+ </div>
1486
+ </div>
1487
+
1477
1488
  <div class="vignette reveal">
1478
1489
  <div class="v-say">Continue where we left off on this branch.</div>
1479
1490
  <pre class="v-call">recall_context({query: "&lt;branch&gt; latest handoff durable feature memory"})</pre>
package/docs/share.md CHANGED
@@ -126,6 +126,100 @@ under `agent-artifacts/`, ingests it into OpenViking under the shared team
126
126
  namespace, commits, and pushes. Existing artifacts with different content are
127
127
  not overwritten unless `--force` is passed.
128
128
 
129
+ #### Multi-file skills (bundles)
130
+
131
+ A skill is shared as its **whole directory**, not just `SKILL.md`. When companion
132
+ files sit beside the `SKILL.md` (reference docs, scripts, templates), they travel
133
+ with the skill:
134
+
135
+ ```text
136
+ agent-artifacts/skills/codex/<name>/
137
+ SKILL.md # recall anchor (OpenViking-ingested)
138
+ scripts/run.ts # companion, carried in git
139
+ reference.md
140
+ .threadnote-bundle.json # generated member manifest (sha + binary flags)
141
+ ```
142
+
143
+ Notes:
144
+
145
+ - A lone `SKILL.md` with no companions publishes exactly as before — no manifest,
146
+ one file.
147
+ - Every **text** member runs through the scrubber, so a leaked credential or local
148
+ path in a companion script blocks the publish just like it would in `SKILL.md`.
149
+ - Only `SKILL.md` (and any sibling `.md`) is OpenViking-ingested for recall;
150
+ companions ride in git and are materialized on install.
151
+ - Runtime/scratch dirs and local junk are never bundled: `reviews/`, `repos/`,
152
+ `node_modules/`, `.git/`, `.DS_Store`, `*.log`.
153
+ - **Binary** members are blocked by default because the scrubber cannot inspect
154
+ them; pass `--allow-binary` (CLI) / `allowBinary: true` (MCP) to include them.
155
+ A credential detected in the bytes still blocks regardless.
156
+ - A skill whose helpers live **outside** its own directory (a multi-skill
157
+ constellation with shared code at the repo root) is shared as a **pack** — see
158
+ below.
159
+
160
+ #### Constellation packs
161
+
162
+ When several skills share code that lives outside any single skill directory
163
+ (e.g. repo-root `scripts/` and `lib/`), publish them together as a **pack** from
164
+ a `threadnote-bundle.json` manifest at the repo root:
165
+
166
+ ```json
167
+ {
168
+ "version": 1,
169
+ "name": "review-pr-suite",
170
+ "agent": "claude",
171
+ "description": "PR/MR review constellation.",
172
+ "skills": [".claude/skills/review-pr", ".claude/skills/pr-action"],
173
+ "include": ["scripts", "lib", "package.json", "tsconfig.json"],
174
+ "deps": {"runtime": ["bun"], "cli": ["gh", "glab", "jq"], "mcp": ["mcp__pal__clink"]},
175
+ "pathRewrites": [{"from": "/Users/alex/code/reviewer"}]
176
+ }
177
+ ```
178
+
179
+ ```bash
180
+ threadnote share publish-bundle ./threadnote-bundle.json --preview
181
+ threadnote share publish-bundle ./threadnote-bundle.json
182
+ threadnote share install-artifacts --kind pack --name review-pr-suite --apply
183
+ ```
184
+
185
+ ```text
186
+ share_bundle({"path":"~/src/reviewer/threadnote-bundle.json"})
187
+ ```
188
+
189
+ How packs work:
190
+
191
+ - Every declared skill plus the `include` paths are gathered, preserving the
192
+ author's repo-relative layout, and written under
193
+ `agent-artifacts/packs/<agent>/<name>/files/...` next to a generated
194
+ `<name>.pack.md` recall index and a `<name>.pack.json` manifest.
195
+ - Install materializes the **whole tree under one root**
196
+ (`~/.{codex,claude}/skills/threadnote-packs/<team>/<name>/` — a dedicated
197
+ namespace so a pack and a same-named skill never share an install directory),
198
+ preserving the source repo layout (so a skill declared at
199
+ `.claude/skills/<name>` lands at `<root>/.claude/skills/<name>/SKILL.md` beside
200
+ `<root>/scripts/...`). This keeps **file-anchored** references working
201
+ unchanged: relative imports (`../lib/types`) and `import.meta.dir`-relative
202
+ paths resolve exactly as they did in the source repo.
203
+ - **CWD-relative invocations do not auto-resolve.** A bare `bun run scripts/...`
204
+ in a skill body is resolved against the agent's working directory, not the
205
+ pack root, so anchor such paths to the token:
206
+ `bun run ${THREADNOTE_PACK_ROOT}/scripts/vcs-detect.ts`. The token is expanded
207
+ to the absolute install root in every text member at install.
208
+ - Hardcoded absolute repo-root paths are rewritten to that
209
+ `${THREADNOTE_PACK_ROOT}` token at publish (the manifest dir plus any declared
210
+ `pathRewrites`, which must be absolute repo-root paths) and expanded back to
211
+ the real install directory at install. A residual `/Users` or `/home` path
212
+ that no rewrite covers trips the scrubber and blocks the publish. Other
213
+ machine-local absolute paths (`/opt`, `/srv`, `/private`, Windows `C:\…`) are
214
+ **not** auto-detected — declare them in `pathRewrites` or strip them, and
215
+ `--preview` before publishing. Binary members included via `--allow-binary`
216
+ are scanned for embedded home paths and declared roots but are otherwise
217
+ shipped byte-for-byte with no rewrite.
218
+ - `deps` are declared, not bundled: Threadnote installs files, not runtimes or
219
+ MCP servers. After install it prints a loud "this pack will NOT run until these
220
+ exist" notice listing the runtime/CLI/OS tools and any MCP servers to
221
+ configure separately.
222
+
129
223
  Agents can do the same through MCP:
130
224
 
131
225
  ```text
@@ -175,6 +269,14 @@ installed shared hash in a sidecar metadata file next to the installed
175
269
  artifact. Start a new agent session after installing if that agent snapshots
176
270
  skills or commands at startup.
177
271
 
272
+ For a multi-file skill, the whole `~/.{codex,claude}/skills/threadnote/<team>/<name>/`
273
+ tree is installed (companions included) and the install is atomic — it is staged
274
+ in a temporary directory and swapped into place, so an interrupted install never
275
+ leaves a half-written, mixed-version skill. Bundle status folds every member into
276
+ one verdict: a local edit to any member plus an upstream change to a different
277
+ member reports `remote_changed_and_local_modified` and refuses to overwrite
278
+ without `--force`.
279
+
178
280
  ### Keep teammates' updates current
179
281
 
180
282
  Threadnote does a periodic background `git fetch` for configured share teams.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "threadnote",
3
- "version": "1.2.0",
3
+ "version": "1.3.1",
4
4
  "type": "commonjs",
5
5
  "main": "dist/threadnote.cjs",
6
6
  "description": "Shared local context and handoffs for development agents",