pi-autotalk 0.1.0 → 0.1.3

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/CHANGELOG.md CHANGED
@@ -4,10 +4,34 @@ All notable changes to this project will be documented in this file.
4
4
 
5
5
  This project follows semantic versioning.
6
6
 
7
- ## [0.1.0] - YYYY-MM-DD
7
+ ## [0.1.3] - 2026-06-18
8
+
9
+ ### Fixed
10
+
11
+ - Release pipeline recovery: `publish.yml` now runs `npm publish --provenance` so npm Trusted Publishing (GitHub Actions OIDC) authenticates correctly. Without provenance, auto-release could create tags and GitHub Releases while npm publish failed with `E404`.
12
+
13
+ ### Changed
14
+
15
+ - Maintainer release docs (`docs/release.md`, README) now point maintainers at the post-release verification checklist for GitHub release state and npm `latest` after every version bump.
16
+
17
+ ## [0.1.2] - 2026-06-06
18
+
19
+ ### Fixed
20
+
21
+ - Auto-release workflow was added in 0.1.1 but version never changed in that commit, preventing npm publish. This release bumps the version so auto-release triggers and publishes to npm.
22
+
23
+ ## [0.1.1] - 2026-06-03
24
+
25
+ ### Changed
26
+
27
+ - Removed stale template docs (`examples.md`, `github-template.md`, `repository-settings.md`, `template-checklist.md`, `typescript.md`) that referenced non-existent files and commands.
28
+ - Updated README Package contents to reflect remaining docs.
29
+
30
+ ## [0.1.0] - 2025-06-01
8
31
 
9
32
  ### Added
10
33
 
11
- - Initial Pi package template.
12
- - Example extension, Agent Skill, prompt, and theme.
34
+ - Initial pi-autotalk MVP: timed AutoTalk brainstorming from the editor input.
35
+ - Commands: `/autotalk:on`, `/autotalk:off`, `/autotalk:mode`, `/autotalk:settings`.
36
+ - Settings persistence and validation.
13
37
  - CI and npm Trusted Publishing workflow.
package/README.md CHANGED
@@ -1,6 +1,7 @@
1
1
  # Pi AutoTalk
2
2
 
3
3
  [![CI](https://github.com/eiei114/pi-autotalk/actions/workflows/ci.yml/badge.svg)](https://github.com/eiei114/pi-autotalk/actions/workflows/ci.yml)
4
+ [![Auto Release](https://github.com/eiei114/pi-autotalk/actions/workflows/auto-release.yml/badge.svg)](https://github.com/eiei114/pi-autotalk/actions/workflows/auto-release.yml)
4
5
  [![Publish](https://github.com/eiei114/pi-autotalk/actions/workflows/publish.yml/badge.svg)](https://github.com/eiei114/pi-autotalk/actions/workflows/publish.yml)
5
6
  [![npm version](https://img.shields.io/npm/v/pi-autotalk.svg)](https://www.npmjs.com/package/pi-autotalk)
6
7
  [![npm downloads](https://img.shields.io/npm/dm/pi-autotalk.svg)](https://www.npmjs.com/package/pi-autotalk)
@@ -70,7 +71,7 @@ If the editor is empty, AutoTalk sends a one-shot continuation prompt:
70
71
 
71
72
  ```text
72
73
  [AutoTalk]
73
- 入力欄が空です。ここまでの流れから、次に考える問いを1つ出してください。
74
+ The editor is empty. From the conversation so far, ask one question to think about next.
74
75
  ```
75
76
 
76
77
  That empty prompt is sent only once. It resets after a real non-empty thought memo is sent.
@@ -90,11 +91,11 @@ Non-empty editor text is sent like this:
90
91
 
91
92
  ```text
92
93
  [AutoTalk]
93
- これは自動送信されたユーザーの思考メモです。
94
- アイデアを広げ、論点を整理し、次の問いを1つ出してください。
95
- 明示依頼でない限り、ファイル編集・コマンド実行・外部送信はしないでください。
94
+ This is an automatically sent user thought memo.
95
+ Expand the ideas, organize the key points, and ask one follow-up question.
96
+ Unless explicitly requested, do not edit files, run commands, or send external messages.
96
97
 
97
- --- 思考メモ ---
98
+ --- Thought memo ---
98
99
  {editor text}
99
100
  ```
100
101
 
@@ -178,7 +179,7 @@ Useful commands:
178
179
  | `extensions/index.ts` | Pi extension entrypoint and command/timer wiring. |
179
180
  | `lib/autotalk.ts` | Settings validation, persistence, and message formatting helpers. |
180
181
  | `tests/` | Node test suite for package metadata, formatting, settings, and registration. |
181
- | `docs/` | Release and template maintenance docs. |
182
+ | `docs/` | Release and publishing docs. |
182
183
 
183
184
  ## Development
184
185
 
@@ -213,14 +214,22 @@ For vulnerability reporting, see [`SECURITY.md`](SECURITY.md).
213
214
 
214
215
  ## Release
215
216
 
216
- This package is set up for npm Trusted Publishing, so no `NPM_TOKEN` is required.
217
+ This package uses npm Trusted Publishing (OIDC). No `NPM_TOKEN` is required.
218
+
219
+ On merge to `main` with a `package.json` version bump, `.github/workflows/auto-release.yml` creates the `v*` tag and GitHub release, then dispatches `.github/workflows/publish.yml` to publish to npm.
220
+
221
+ Maintainer flow:
217
222
 
218
223
  ```bash
219
- npm version patch
220
- git push --follow-tags
224
+ npm version patch # or minor/major — updates package.json, package-lock.json (if present), creates a git commit and tag by default
225
+ git push origin main
221
226
  ```
222
227
 
223
- See [`docs/release.md`](docs/release.md) for setup details.
228
+ You can also bump `version` in `package.json` in a PR; after merge, auto-release handles tagging and publish.
229
+
230
+ After merge, run the [post-release verification checklist](docs/release.md#post-release-verification-checklist) in `docs/release.md` to confirm the GitHub tag/release, Publish Package workflow, and npm `latest` all match the new version. A green auto-release run alone is not proof npm received the package.
231
+
232
+ See [`docs/release.md`](docs/release.md) for setup, recovery, and verification details.
224
233
 
225
234
  ## Links
226
235
 
@@ -230,4 +239,4 @@ See [`docs/release.md`](docs/release.md) for setup details.
230
239
 
231
240
  ## License
232
241
 
233
- MIT
242
+ MIT
package/docs/release.md CHANGED
@@ -1,38 +1,303 @@
1
1
  # Release
2
2
 
3
- This package uses npm Trusted Publishing with GitHub Actions OIDC.
3
+ This package publishes to npm with **npm Trusted Publishing (GitHub Actions OIDC)**.
4
4
 
5
- Do not add `NPM_TOKEN` or long-lived npm tokens to GitHub Secrets.
5
+ Do **not** add `NPM_TOKEN` or any long-lived npm token to GitHub Secrets. The
6
+ publish step authenticates via an OIDC token minted by GitHub Actions and linked
7
+ to this package on npmjs.com.
8
+
9
+ > **Release pipeline recovery (`0.1.3`):** Prior drift (GitHub at `v0.1.2`, npm
10
+ > `latest` at `0.1.0`) was caused by `publish.yml` running `npm publish` without
11
+ > `--provenance`, so OIDC Trusted Publishing never authenticated. `0.1.3` fixes
12
+ > the workflow and is the supported path to bring npm `latest` back in sync.
13
+ > After merge, run the [verification checklist](#post-release-verification-checklist)
14
+ > below. Historical drift details remain in [Known release drift](#known-release-drift--2026-06-investigation).
15
+
16
+ ## Model
17
+
18
+ Two workflows cooperate:
19
+
20
+ - `.github/workflows/auto-release.yml` — on push to `main` that increases
21
+ `package.json#version`, creates tag `v<version>`, creates the GitHub Release,
22
+ then dispatches `publish.yml` at that ref.
23
+ - `.github/workflows/publish.yml` — checks out the ref, runs CI, then publishes
24
+ to npm. It triggers on `push: tags v*` (manual `npm version` + push) **and** on
25
+ `workflow_dispatch` from `auto-release.yml`.
26
+
27
+ The critical handoff is the last hop: auto-release can succeed (tag + release
28
+ created, publish dispatched) while the dispatched `publish.yml` still fails at
29
+ `npm publish`. A green auto-release run is **not** proof that npm received the
30
+ package — always run the [verification checklist](#post-release-verification-checklist).
6
31
 
7
32
  ## One-time npm setup
8
33
 
9
- On npmjs.com, configure Trusted Publishing for this package:
34
+ On npmjs.com, configure Trusted Publishing for this package (`eiei114/pi-autotalk`):
10
35
 
11
36
  - Publisher: GitHub Actions
12
- - Repository: this GitHub repository
37
+ - Repository: `eiei114/pi-autotalk`
13
38
  - Workflow filename: `publish.yml`
39
+ - (Optional) Environment: leave unset unless you pin one in the workflow
40
+
41
+ This must be done **before** the first automated publish. If 0.1.0 was published
42
+ manually with a local login, the Trusted Publisher link may have never been
43
+ created — verify it during [recovery](#recovery-github-release-exists-but-npm-latest-is-stale).
14
44
 
15
45
  ## Publish
16
46
 
47
+ ### Automated (recommended)
48
+
49
+ 1. Bump `version` in `package.json` and update `CHANGELOG.md` in the same change
50
+ (e.g. via a PR; the CI `version:check` guard requires a matching CHANGELOG
51
+ entry when the version increases).
52
+ 2. Merge to `main`.
53
+ 3. `auto-release.yml` detects the version increase, creates tag `v<version>` and
54
+ a GitHub Release, then runs `gh workflow run publish.yml --ref v<version>`.
55
+ 4. `publish.yml` checks out that ref, runs CI, and publishes via OIDC.
56
+ 5. Run the [verification checklist](#post-release-verification-checklist).
57
+
58
+ ### Manual tag (fallback)
59
+
17
60
  ```bash
18
- npm version patch
19
- git push --follow-tags
61
+ npm version patch # or minor / major
62
+ git push origin main --follow-tags
20
63
  ```
21
64
 
22
- The `v*` tag triggers `.github/workflows/publish.yml`, which runs CI and publishes to npm.
65
+ A `v*` tag push triggers `publish.yml` directly. Use this for a one-off release
66
+ when you do not want to rely on auto-release. Still run the verification
67
+ checklist afterward.
68
+
69
+ ## Post-release verification checklist
70
+
71
+ Run **after every version bump**, whether automated or manual. A release is only
72
+ "done" when npm `latest` equals the new version.
73
+
74
+ Replace `<v>` with the version (e.g. `0.1.2`) and `<V>` with the tag (e.g. `v0.1.2`).
75
+
76
+ - [ ] **Auto Release ran and succeeded** on the `main` commit that bumped the
77
+ version.
78
+ `gh run list --workflow=auto-release.yml --limit 5`
79
+ - [ ] **Tag `<V>` exists** on the remote and points at the bump commit.
80
+ `git ls-remote --tags origin 'v*'` → must list `<V>`
81
+ - [ ] **GitHub Release `<V>` exists** and is published (not draft, not prerelease).
82
+ `gh release view <V>`
83
+ - [ ] **Publish Package ran for `<V>`** and its conclusion is `success`. This is
84
+ the run auto-release dispatched (event `workflow_dispatch`, branch `<V>`).
85
+ `gh run list --workflow=publish.yml --limit 10`
86
+ - [ ] If Publish Package **failed**, open the run and read the `Run npm publish`
87
+ step log. The most common failure is `npm error code E404 ... PUT
88
+ https://registry.npmjs.org/pi-autotalk - Not found` (see
89
+ [Recovery](#recovery-github-release-exists-but-npm-latest-is-stale)).
90
+ `gh run view <run-id> --log`
91
+ - [ ] **npm `latest` equals `<v>`.**
92
+ `npm view pi-autotalk version`
93
+ - [ ] **npm shows `<v>` in `time`.**
94
+ `npm view pi-autotalk time --json`
95
+
96
+ One-liner snapshot for a quick diff after release:
97
+
98
+ ```bash
99
+ node -p "require('./package.json').version" # repo
100
+ git ls-remote --tags origin 'v*' # tags
101
+ gh release list --limit 5 # releases
102
+ gh run list --workflow=publish.yml --limit 5 # publish runs
103
+ npm view pi-autotalk version # npm latest
104
+ ```
105
+
106
+ A release is healthy **iff** the repo version, the newest `v*` tag, the newest
107
+ GitHub Release, the newest successful Publish run, and npm `latest` all agree.
108
+
109
+ ## Recovery: GitHub release exists but npm latest is stale
110
+
111
+ Use this when a tag + GitHub Release exist for `<V>` but `npm view
112
+ pi-autotalk version` returns an older version. This matches the 2026-06 drift.
113
+
114
+ ### 1. Confirm and scope the drift
115
+
116
+ ```bash
117
+ npm view pi-autotalk version # current npm latest
118
+ npm view pi-autotalk time --json # every published version + dates
119
+ git ls-remote --tags origin 'v*' # every GitHub tag
120
+ gh release list # every GitHub Release
121
+ ```
122
+
123
+ Any tag `<V>` with no matching entry in npm `time` is a missing publish. List
124
+ them; you will republish each missing version.
125
+
126
+ ### 2. Find why the publish failed
127
+
128
+ Find the Publish Package run that auto-release dispatched for `<V>` (event
129
+ `workflow_dispatch`, branch `<V>`):
130
+
131
+ ```bash
132
+ gh run list --workflow=publish.yml --branch <V> --limit 5
133
+ gh run view <run-id> --log # read the "Run npm publish" step
134
+ ```
135
+
136
+ For the 2026-06 drift the failing run was `27050120988` and the error was:
137
+
138
+ ```bash
139
+ npm error code E404
140
+ npm error 404 Not Found - PUT https://registry.npmjs.org/pi-autotalk - Not found
141
+ npm error 404 'pi-autotalk@0.1.2' is not in this registry.
142
+ ```
143
+
144
+ The most likely root cause (this repo's model is Trusted Publishing, no token):
145
+
146
+ - `publish.yml` runs `npm publish` **without `--provenance`** and exposes **no
147
+ `NODE_AUTH_TOKEN`**. npm Trusted Publishing via GitHub Actions OIDC is only
148
+ exercised when the publish runs with `--provenance`; without it the npm CLI
149
+ never mints the OIDC token, the PUT is effectively unauthenticated, and npm
150
+ returns `E404` (it hides package existence from unauthenticated callers).
151
+ - Rule out the secondary cause: the **Trusted Publisher is not registered on
152
+ npmjs.com**, or is scoped to the wrong workflow file / trigger. On npmjs.com
153
+ open the package → Settings → Trusted Publishers and confirm: repository
154
+ `eiei114/pi-autotalk`, workflow filename `publish.yml`. Because 0.1.0 was
155
+ published with a manual login, this link may have never been created.
156
+
157
+ ### 3. Fix the publish path before republishing
158
+
159
+ Pick the fix that matches this repo's model (Trusted Publishing):
160
+
161
+ - Ensure `publish.yml` publishes with provenance (`npm publish --provenance`)
162
+ and that the job still has `permissions: id-token: write`. This is fixed on
163
+ `main` starting with `0.1.3`.
164
+ - Confirm the Trusted Publisher registration on npmjs.com (step 2).
165
+
166
+ (If you ever move away from Trusted Publishing, the alternative is to set an npm
167
+ automation token in `NPM_TOKEN` and expose `NODE_AUTH_TOKEN: ${{
168
+ secrets.NPM_TOKEN }}` on the publish step. This repo deliberately does **not** do
169
+ that.)
170
+
171
+ Do the fix on `main` first and verify with a real release before republishing
172
+ historical versions — otherwise every republish will fail the same way.
173
+
174
+ ### 4. Republish the missing version(s)
175
+
176
+ Each missing version must be published from its **own** tagged commit (npm
177
+ rejects re-publishing a version, and you cannot publish `0.1.2` from the `0.1.1`
178
+ tree). For each `<V>` that exists as a tag but not on npm:
179
+
180
+ ```bash
181
+ # Re-dispatch publish.yml at the existing tag (mirrors what auto-release does).
182
+ gh workflow run publish.yml --ref <V> -f ref=<V>
183
+
184
+ # Watch the run.
185
+ gh run list --workflow=publish.yml --branch <V> --limit 3
186
+ gh run watch <run-id>
187
+ ```
188
+
189
+ `--ref <V>` checks out the tagged commit, so the published `package.json`
190
+ version matches the tag. Do **not** create new tags or bump the version for a
191
+ recovery publish — you are publishing a version that already exists on GitHub.
192
+
193
+ For the 2026-06 drift, repeat for `v0.1.1` and `v0.1.2` if both should appear on
194
+ npm; if only the newest matters, publish `v0.1.2` and accept the `0.1.1` gap
195
+ (document it here under [Known release drift](#known-release-drift--2026-06-investigation)).
196
+
197
+ ### 5. Confirm npm and fix the `latest` dist-tag
198
+
199
+ ```bash
200
+ npm view pi-autotalk version # should now be <v>
201
+ npm view pi-autotalk dist-tags # latest should point at <v>
202
+ ```
203
+
204
+ `npm publish` moves `latest` to the highest published version automatically. If
205
+ it is wrong (e.g. you published an older missing version after a newer one),
206
+ repoint it explicitly:
207
+
208
+ ```bash
209
+ npm dist-tag add pi-autotalk@<v> latest
210
+ ```
211
+
212
+ ### 6. Notes and caveats
213
+
214
+ - npm only allows `unpublish` within 72 hours of publish, and only when nothing
215
+ depends on the version. Prefer `npm deprecate pi-autotalk@<v> "reason"` over
216
+ unpublish for old versions.
217
+ - You cannot republish a version that is already on npm. If a partial publish
218
+ created the version but `latest` is wrong, fix the dist-tag, do not republish.
219
+ - A failed `Publish Package` run leaves **no** artifact on npm — retrying the
220
+ same version is safe and expected.
221
+
222
+ ## Known release drift — 2026-06 investigation
223
+
224
+ Snapshot taken 2026-06-14. Concrete versions, dates, and SHAs so future audits
225
+ are not relative-time ambiguous.
226
+
227
+ | Artifact | Value | Observed |
228
+ |---|---|---|
229
+ | `package.json` version (main HEAD) | `0.1.2` | commit `bdd0807`, merged 2026-06-06 |
230
+ | Git tags (local + remote) | `v0.1.2` only | points at `bdd0807`; created 2026-06-06T02:30:07Z |
231
+ | GitHub Releases | `v0.1.2` only | published 2026-06-06T02:30:16Z |
232
+ | npm `latest` dist-tag | `0.1.0` | — |
233
+ | npm published versions | `0.1.0` only | `0.1.0` published 2026-05-31T02:52:46Z; registry not modified since |
234
+ | npm package maintainer | `eiei114` | — |
235
+
236
+ **Drift:** GitHub and `package.json` are at `v0.1.2`; npm `latest` is `0.1.0`.
237
+ `0.1.1` and `0.1.2` exist on GitHub but were never published to npm.
238
+
239
+ ### How each version reached its current state
240
+
241
+ - **`0.1.0`** — published to npm 2026-05-31T02:52:46Z. The auto-release and
242
+ publish workflows did not exist yet (auto-release was added in commit
243
+ `03073d8`, 2026-06-06). 0.1.0 was therefore a **manual** publish by the
244
+ maintainer, not a workflow publish. No `v0.1.0` tag and no GitHub Release were
245
+ created.
246
+ - **`0.1.1`** — `version` set to `0.1.1` in `package.json` at commit `34e2a2a`
247
+ (2026-06-03). Auto-release did not exist yet, so the bump was never observed:
248
+ no tag, no release, no publish. npm never received 0.1.1.
249
+ - **`0.1.2`** — bump at commit `3f32c88`, merged to `main` as `bdd0807`
250
+ (2026-06-06T02:30Z). Auto-release ran and **succeeded**: it created tag
251
+ `v0.1.2`, GitHub Release `v0.1.2`, and dispatched `publish.yml` at `v0.1.2`
252
+ (run `27050120988`, event `workflow_dispatch`). That Publish Package run
253
+ **failed** at the `Run npm publish` step with `npm error code E404 / 404 Not
254
+ Found - PUT https://registry.npmjs.org/pi-autotalk`. Every preceding step
255
+ (checkout, setup-node, `npm ci`, typecheck, test, `pack:check`) passed and the
256
+ tarball was built correctly (`pi-autotalk@0.1.2`, 7 files, 7.6 kB).
257
+
258
+ ### Most likely failure point
259
+
260
+ The break is the **last hop**: `npm publish` inside `publish.yml`.
261
+
262
+ - `publish.yml` runs `npm publish` with no `--provenance` and exposes no
263
+ `NODE_AUTH_TOKEN`. With the Trusted Publishing model there is no token secret
264
+ by design.
265
+ - npm Trusted Publishing via GitHub Actions OIDC is only exercised when the
266
+ publish runs **with `--provenance`**. Without it the npm CLI never mints the
267
+ OIDC token, the PUT is effectively anonymous, and npm returns `E404`.
268
+ - Secondary cause to rule out during recovery: the Trusted Publisher is not
269
+ registered on npmjs.com, or is scoped to the wrong workflow file / trigger
270
+ (e.g. registered for `push: tags` only, not `workflow_dispatch`). Because
271
+ `0.1.0` was published manually, the link may have never been created.
272
+
273
+ The fix, verification, and republish steps are in
274
+ [Recovery](#recovery-github-release-exists-but-npm-latest-is-stale). No version
275
+ bump, CHANGELOG entry, tag, or npm publish was performed as part of this
276
+ investigation slice — it is documentation only; the actual republish is a
277
+ separate, explicitly approved action.
23
278
 
24
279
  ## GitHub Actions requirements
25
280
 
26
- - `permissions: id-token: write`
281
+ - `permissions: id-token: write` on the publish job
27
282
  - GitHub-hosted runner
28
283
  - No `NPM_TOKEN`
29
- - `npm publish` from the configured workflow file
284
+ - `npm publish` (with `--provenance` for Trusted Publishing) from the configured
285
+ workflow file (`publish.yml`)
286
+
287
+ ## Local prerelease dry run
288
+
289
+ ```bash
290
+ npm run ci # typecheck + tests + pack:check
291
+ npm pack --dry-run # confirm only intended files are included
292
+ ```
30
293
 
31
294
  ## First release checklist
32
295
 
33
- - [ ] `package.json` name is final
296
+ - [ ] `package.json` name is final (`pi-autotalk`)
34
297
  - [ ] `repository.url` points to the real GitHub repository
35
- - [ ] npm Trusted Publisher is configured
298
+ - [ ] npm Trusted Publisher is configured on npmjs.com (repo + `publish.yml`)
36
299
  - [ ] `npm run ci` passes
37
300
  - [ ] `npm pack --dry-run` contains only intended files
38
- - [ ] `CHANGELOG.md` has the release date
301
+ - [ ] `CHANGELOG.md` has the release date
302
+ - [ ] First automated publish passes the
303
+ [verification checklist](#post-release-verification-checklist)
package/lib/autotalk.ts CHANGED
@@ -20,14 +20,17 @@ export const DEFAULT_SETTINGS: AutoTalkSettings = {
20
20
  deliveryMode: "followUp",
21
21
  };
22
22
 
23
+ /** Path to the global AutoTalk settings JSON file under `~/.pi`. */
23
24
  export function getSettingsPath(): string {
24
25
  return join(homedir(), ".pi", "agent", "extensions", "autotalk", "settings.json");
25
26
  }
26
27
 
28
+ /** Returns true when `value` is a supported AutoTalk delivery mode. */
27
29
  export function isDeliveryMode(value: unknown): value is DeliveryMode {
28
30
  return value === "followUp" || value === "steer";
29
31
  }
30
32
 
33
+ /** Coerces unknown persisted settings into a valid `AutoTalkSettings` object. */
31
34
  export function normalizeSettings(value: unknown): AutoTalkSettings {
32
35
  if (!value || typeof value !== "object") return { ...DEFAULT_SETTINGS };
33
36
 
@@ -40,6 +43,7 @@ export function normalizeSettings(value: unknown): AutoTalkSettings {
40
43
  return { intervalSec, deliveryMode };
41
44
  }
42
45
 
46
+ /** Parses an interval in seconds; returns `undefined` when out of range or invalid. */
43
47
  export function normalizeInterval(value: unknown): number | undefined {
44
48
  if (typeof value === "string" && value.trim() !== "") {
45
49
  return normalizeInterval(Number(value));
@@ -50,6 +54,7 @@ export function normalizeInterval(value: unknown): number | undefined {
50
54
  return value;
51
55
  }
52
56
 
57
+ /** Loads settings from disk, falling back to defaults when the file is missing or invalid. */
53
58
  export async function loadSettings(path = getSettingsPath()): Promise<AutoTalkSettings> {
54
59
  try {
55
60
  const text = await readFile(path, "utf8");
@@ -59,6 +64,7 @@ export async function loadSettings(path = getSettingsPath()): Promise<AutoTalkSe
59
64
  }
60
65
  }
61
66
 
67
+ /** Persists settings as formatted JSON, creating parent directories when needed. */
62
68
  export async function saveSettings(
63
69
  settings: AutoTalkSettings,
64
70
  path = getSettingsPath(),
@@ -68,17 +74,19 @@ export async function saveSettings(
68
74
  `, "utf8");
69
75
  }
70
76
 
77
+ /** Wraps editor text in the AutoTalk thought-memo prompt sent to the agent. */
71
78
  export function formatThoughtMemo(text: string): string {
72
79
  return `[AutoTalk]
73
- これは自動送信されたユーザーの思考メモです。
74
- アイデアを広げ、論点を整理し、次の問いを1つ出してください。
75
- 明示依頼でない限り、ファイル編集・コマンド実行・外部送信はしないでください。
80
+ This is an automatically sent user thought memo.
81
+ Expand the ideas, organize the key points, and ask one follow-up question.
82
+ Unless explicitly requested, do not edit files, run commands, or send external messages.
76
83
 
77
- --- 思考メモ ---
84
+ --- Thought memo ---
78
85
  ${text}`;
79
86
  }
80
87
 
88
+ /** Returns the one-shot empty-editor continuation prompt. */
81
89
  export function formatEmptyPrompt(): string {
82
90
  return `[AutoTalk]
83
- 入力欄が空です。ここまでの流れから、次に考える問いを1つ出してください。`;
91
+ The editor is empty. From the conversation so far, ask one question to think about next.`;
84
92
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "pi-autotalk",
3
- "version": "0.1.0",
3
+ "version": "0.1.3",
4
4
  "description": "A Pi extension for timed AutoTalk brainstorming from the editor input.",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -33,7 +33,8 @@
33
33
  "typecheck": "tsc --noEmit",
34
34
  "test": "node --test tests/*.test.mjs",
35
35
  "ci": "npm run typecheck && npm test && npm run pack:check",
36
- "pack:check": "npm pack --dry-run"
36
+ "pack:check": "npm pack --dry-run",
37
+ "version:check": "node scripts/check-version-bump.mjs"
37
38
  },
38
39
  "pi": {
39
40
  "extensions": [
@@ -48,7 +49,7 @@
48
49
  },
49
50
  "devDependencies": {
50
51
  "@earendil-works/pi-coding-agent": "latest",
51
- "@types/node": "^22.0.0",
52
+ "@types/node": "^25.9.1",
52
53
  "typescript": "^6.0.3"
53
54
  }
54
55
  }
package/docs/examples.md DELETED
@@ -1,49 +0,0 @@
1
- # Examples
2
-
3
- This template ships one minimal example for each Pi package resource type.
4
-
5
- ## Extension
6
-
7
- `extensions/hello.ts` registers:
8
-
9
- - `/template-hello`
10
- - a small session status indicator
11
-
12
- Try it with:
13
-
14
- ```bash
15
- pi -e .
16
- ```
17
-
18
- Then run:
19
-
20
- ```txt
21
- /template-hello YourName
22
- ```
23
-
24
- ## Agent Skill
25
-
26
- `skills/example-skill/SKILL.md` demonstrates a minimal Agent Skill.
27
-
28
- Replace it with your real workflow instructions.
29
-
30
- ## Prompt template
31
-
32
- `prompts/example.md` demonstrates a tiny prompt template with one variable.
33
-
34
- ## Theme
35
-
36
- `themes/example-theme.json` is a placeholder theme. Replace it or remove `themes/` if your package does not ship themes.
37
-
38
- ## Typed custom tool
39
-
40
- `extensions/index.ts` registers:
41
-
42
- - `/template-info`
43
- - `template_greet` custom tool
44
-
45
- The tool demonstrates:
46
-
47
- - TypeBox object parameters
48
- - a string enum schema via `StringEnum`
49
- - shared logic imported from `lib/greeting.ts`
@@ -1,43 +0,0 @@
1
- # GitHub Template Repository
2
-
3
- Enable template mode on the source repository:
4
-
5
- ```txt
6
- GitHub repo → Settings → General → Template repository
7
- ```
8
-
9
- Create a public repository from the template:
10
-
11
- ```bash
12
- gh repo create OWNER/new-pi-extension \
13
- --public \
14
- --template OWNER/pi-extension-template \
15
- --clone
16
- ```
17
-
18
- Create a private repository from the template:
19
-
20
- ```bash
21
- gh repo create OWNER/new-pi-extension \
22
- --private \
23
- --template OWNER/pi-extension-template \
24
- --clone
25
- ```
26
-
27
- Include all branches if needed:
28
-
29
- ```bash
30
- gh repo create OWNER/new-pi-extension \
31
- --public \
32
- --template OWNER/pi-extension-template \
33
- --include-all-branches \
34
- --clone
35
- ```
36
-
37
- After creation:
38
-
39
- ```bash
40
- cd new-pi-extension
41
- npm install
42
- npm run ci
43
- ```
@@ -1,41 +0,0 @@
1
- # Repository Settings
2
-
3
- Use this file after creating a real repository from the template.
4
-
5
- ## GitHub About
6
-
7
- Suggested fields:
8
-
9
- - Description: one-line pitch for the Pi package
10
- - Website: npm package URL or project docs URL
11
- - Topics:
12
- - `pi`
13
- - `pi-package`
14
- - `agent-skill`
15
- - `typescript`
16
-
17
- ## Template mode
18
-
19
- If this repository itself should be reusable as a template:
20
-
21
- ```txt
22
- Settings → General → Template repository
23
- ```
24
-
25
- ## Branch protection
26
-
27
- Recommended for public packages:
28
-
29
- - Require pull request before merging
30
- - Require status checks to pass
31
- - Require `CI` workflow
32
- - Block force pushes on the default branch
33
-
34
- ## npm package page
35
-
36
- After first publish:
37
-
38
- - Confirm README renders correctly
39
- - Confirm package provenance appears
40
- - Confirm package contents are intentional
41
- - Add npm URL to GitHub About and README
@@ -1,85 +0,0 @@
1
- # Template Setup Checklist
2
-
3
- このテンプレートから新しい Pi 拡張OSSを作った後に埋めること。
4
-
5
- ## Repository
6
-
7
- - [ ] GitHub repository name を決める
8
- - [ ] GitHub About 欄を書く
9
- - [ ] GitHub topics を設定する
10
- - [ ] `pi`
11
- - [ ] `pi-package`
12
- - [ ] `agent-skill`
13
- - [ ] `typescript`
14
- - [ ] GitHub Settingsで `Template repository` をONにする
15
- - [ ] Repository URL を `package.json` に反映する
16
- - [ ] README の `OWNER/REPO` を実リポジトリに置き換える
17
-
18
- ## Package metadata
19
-
20
- - [ ] `package.json` の `name` を変更する
21
- - [ ] `description` を書く
22
- - [ ] `author` を入れる
23
- - [ ] `repository.url` を埋める
24
- - [ ] `bugs.url` を埋める
25
- - [ ] `homepage` を埋める
26
- - [ ] `keywords` を見直す
27
- - [ ] `LICENSE` の年・名前を更新する
28
-
29
- ## README placeholders
30
-
31
- - [ ] `PACKAGE_DISPLAY_NAME` を置き換える
32
- - [ ] `PACKAGE_NAME` を置き換える
33
- - [ ] `OWNER/REPO` を置き換える
34
- - [ ] one-line pitch を書く
35
- - [ ] feature list を書く
36
- - [ ] quick start command を実コマンドにする
37
- - [ ] npm URL を確認する
38
- - [ ] GitHub URL を確認する
39
-
40
- ## Pi package manifest
41
-
42
- - [ ] `pi.extensions` に公開する拡張だけを残す
43
- - [ ] `pi.skills` に公開する skill だけを残す
44
- - [ ] 不要なら `prompts/` を消す
45
- - [ ] 不要なら `themes/` を消す
46
- - [ ] サンプル名を実名に変える
47
-
48
- ## TypeScript
49
-
50
- - [ ] `extensions/index.ts` を実装に合わせて更新する
51
- - [ ] `extensions/hello.ts` が不要なら削除する
52
- - [ ] 共通ロジックを `lib/` に切り出す
53
- - [ ] `strict: true` を維持する
54
- - [ ] custom tool parameters は TypeBox schema で定義する
55
- - [ ] string choices は `StringEnum` helper を使う
56
- - [ ] runtime dependency は `dependencies`、Pi提供packageは `peerDependencies` に置く
57
- - [ ] `package.json.files` に公開対象だけを入れる
58
-
59
- ## GitHub Template repo
60
-
61
- - [ ] `gh repo create --template OWNER/pi-extension-template` で作成できることを確認する
62
- - [ ] public/privateどちらの作成例もdocsに載せる
63
-
64
- ## CI / Release
65
-
66
- - [ ] `npm run ci` が通る
67
- - [ ] `npm pack --dry-run` が通る
68
- - [ ] npm Trusted Publishing を設定する
69
- - [ ] `NPM_TOKEN` を使っていないことを確認する
70
- - [ ] tag publish が動くことを初回リリースで確認する
71
-
72
- ## npm page
73
-
74
- - [ ] npm package URL を README に追加する
75
- - [ ] npm description が適切に表示されるか確認する
76
- - [ ] provenance が付いているか確認する
77
- - [ ] 不要なファイルが package に含まれていないか確認する
78
-
79
- ## Before first release
80
-
81
- - [ ] サンプルコードを実機 Pi でロードする
82
- - [ ] `pi install git:github.com/OWNER/REPO` を試す
83
- - [ ] `pi -e .` を試す
84
- - [ ] README のコマンドがコピペで動くか確認する
85
- - [ ] CHANGELOG に `0.1.0` を書く
@@ -1,75 +0,0 @@
1
- # TypeScript Guide
2
-
3
- This is a TypeScript-first Pi package template.
4
-
5
- ## Layout
6
-
7
- ```txt
8
- extensions/*.ts Pi extension entrypoints
9
- lib/*.ts Shared TypeScript helpers
10
- skills/*/SKILL.md Agent Skills
11
- prompts/*.md Prompt templates
12
- themes/*.json Themes
13
- tests/*.test.mjs Smoke tests
14
- tests/*.test.ts Optional TypeScript tests if you add a TS test runner
15
- ```
16
-
17
- Pi loads TypeScript extensions directly, so no build step is required for normal use.
18
-
19
- ## Strict mode
20
-
21
- `tsconfig.json` keeps `strict: true`. Prefer fixing types over loosening compiler options.
22
-
23
- ## Extension entrypoints
24
-
25
- Two entrypoint styles are shown:
26
-
27
- - `extensions/hello.ts`: single-file extension
28
- - `extensions/index.ts`: index-style extension that imports shared code from `lib/`
29
-
30
- For larger packages, keep entrypoints thin and put reusable logic in `lib/`.
31
-
32
- ## TypeBox schemas
33
-
34
- Use TypeBox schemas for custom tool parameters.
35
-
36
- ```ts
37
- import { Type } from "typebox";
38
-
39
- const parameters = Type.Object({
40
- name: Type.String({ description: "Name to greet" }),
41
- });
42
- ```
43
-
44
- ## String enums
45
-
46
- For string choices, use the local `StringEnum` helper from `lib/schema.ts`.
47
-
48
- ```ts
49
- import { StringEnum } from "../lib/schema.ts";
50
-
51
- const mode = StringEnum(["short", "friendly"], {
52
- description: "Greeting style",
53
- });
54
- ```
55
-
56
- This emits a JSON Schema `enum`, which is friendlier to model providers than a union of string literals.
57
-
58
- ## Runtime dependencies vs peer dependencies
59
-
60
- Pi bundles core packages for extension authors. Keep Pi-provided packages as `peerDependencies` and also install them as `devDependencies` for local typechecking.
61
-
62
- Use `peerDependencies` for:
63
-
64
- - `@earendil-works/pi-coding-agent`
65
- - `@earendil-works/pi-ai`
66
- - `@earendil-works/pi-tui`
67
- - `typebox`
68
-
69
- Use `dependencies` for runtime packages your extension imports that Pi does not provide.
70
-
71
- Use `devDependencies` for local-only tools such as TypeScript, test runners, and linters.
72
-
73
- ## Package contents
74
-
75
- Control npm package contents with `package.json` `files`. Prefer this over `.npmignore` so the published package stays explicit.