@geminixiang/pi-simplify 0.0.6 → 0.0.8
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/.pi/skills/release/SKILL.md +146 -0
- package/CHANGELOG.md +35 -0
- package/README.md +6 -11
- package/index.ts +3 -595
- package/package.json +4 -2
- package/prompt.ts +93 -0
- package/selector.ts +176 -0
- package/types.ts +12 -0
- package/workflow.ts +394 -0
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: release
|
|
3
|
+
description: Prepare and publish a new pi-simplify release. Use when bumping the version, committing and pushing it, and creating a GitHub release in the style of earlier pi-simplify releases.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# pi-simplify Release
|
|
7
|
+
|
|
8
|
+
Repo defaults:
|
|
9
|
+
|
|
10
|
+
- branch: `main`
|
|
11
|
+
- remote: `origin`
|
|
12
|
+
- repo: `geminixiang/pi-simplify`
|
|
13
|
+
- npm package: `@geminixiang/pi-simplify`
|
|
14
|
+
- use `package.json` version for npm/package files, and `v<version>` for the git tag and GitHub release title
|
|
15
|
+
- versions with `-alpha.`, `-beta.`, or `-rc.` are prereleases by default
|
|
16
|
+
|
|
17
|
+
## Version rules
|
|
18
|
+
|
|
19
|
+
Examples:
|
|
20
|
+
|
|
21
|
+
- stable package version: `0.2.1`, `0.3.0`, `1.0.0` → release tag/title: `v0.2.1`, `v0.3.0`, `v1.0.0`
|
|
22
|
+
- prerelease package version: `0.2.0-beta.8`, `0.3.0-rc.1`, `1.0.0-alpha.2` → release tag/title: `v0.2.0-beta.8`, `v0.3.0-rc.1`, `v1.0.0-alpha.2`
|
|
23
|
+
|
|
24
|
+
Guidance:
|
|
25
|
+
|
|
26
|
+
- `patch` = bugfix / small maintenance
|
|
27
|
+
- `minor` = backward-compatible features
|
|
28
|
+
- `major` = breaking changes
|
|
29
|
+
- prerelease numbers increase within the same line, e.g. `beta.8 -> beta.9`
|
|
30
|
+
- promote prerelease to stable by dropping the suffix, e.g. `0.2.0-beta.8 -> 0.2.0`
|
|
31
|
+
|
|
32
|
+
## Flow
|
|
33
|
+
|
|
34
|
+
### 1. Check state
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
git status --short
|
|
38
|
+
git branch --show-current
|
|
39
|
+
git remote -v
|
|
40
|
+
git tag --list | tail -20
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Read `package.json` and `package-lock.json`. If unrelated files are modified, ask before committing.
|
|
44
|
+
|
|
45
|
+
### 2. Sync version files
|
|
46
|
+
|
|
47
|
+
Preferred:
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
npm version <version> --no-git-tag-version
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Use this to sync `package.json` and `package-lock.json` without creating an automatic commit or tag. If the user already edited `package.json`, just verify `package-lock.json` matches.
|
|
54
|
+
|
|
55
|
+
### 3. Update CHANGELOG
|
|
56
|
+
|
|
57
|
+
`CHANGELOG.md` follows Keep a Changelog with `### Added / Changed / Fixed / Removed / Security / Performance / Tests` subsections. The newest release sits at the top under an `## [Unreleased]` placeholder.
|
|
58
|
+
|
|
59
|
+
Gather user-visible changes since the previous tag:
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
git log --pretty=format:'%h %s' <previous-tag>..HEAD | grep -v "^[a-f0-9]* chore: bump version"
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Then in `CHANGELOG.md`:
|
|
66
|
+
|
|
67
|
+
- Keep `## [Unreleased]` at the top as an empty placeholder.
|
|
68
|
+
- Insert a new section `## [<version>] - <YYYY-MM-DD>` (use today's date for stable, omit the date for prereleases to match the existing style).
|
|
69
|
+
- Group entries by subsection; one bullet per user-visible change, imperative voice, no commit hashes.
|
|
70
|
+
- Skip pure internal refactors that don't change behavior unless they affect contributors (then list under `### Changed`).
|
|
71
|
+
|
|
72
|
+
If you generated draft release notes in step 5 first, copy the same wording into CHANGELOG — they should match.
|
|
73
|
+
|
|
74
|
+
### 4. Commit and push
|
|
75
|
+
|
|
76
|
+
Stage version files and CHANGELOG together — the bump and the changelog entry belong in the same commit.
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
git add package.json package-lock.json CHANGELOG.md
|
|
80
|
+
git commit -m "chore: bump version to <version>"
|
|
81
|
+
git push origin main
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### 5. Draft release notes
|
|
85
|
+
|
|
86
|
+
Use the previous GitHub release as the style reference.
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
gh release list --repo geminixiang/pi-simplify --limit 10
|
|
90
|
+
gh release view <previous-tag> --repo geminixiang/pi-simplify --json tagName,name,body,url,publishedAt
|
|
91
|
+
git log --pretty=format:'%h %s' <previous-tag>..HEAD
|
|
92
|
+
git diff --stat <previous-tag>..HEAD
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Write concise notes focused on user-visible changes, usually with:
|
|
96
|
+
|
|
97
|
+
- `## What's changed`
|
|
98
|
+
- `### Highlights`
|
|
99
|
+
- `### Notable changes`
|
|
100
|
+
- `### Docs and maintenance`
|
|
101
|
+
- `### Verification`
|
|
102
|
+
|
|
103
|
+
Write notes to `/tmp/pi-simplify-release-<version>.md`. Keep them consistent with the CHANGELOG entry from step 3. Use `v<previous-version>...v<version>` in compare links.
|
|
104
|
+
|
|
105
|
+
### 6. Create or update release
|
|
106
|
+
|
|
107
|
+
Prerelease:
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
gh release create v<version> \
|
|
111
|
+
--repo geminixiang/pi-simplify \
|
|
112
|
+
--target main \
|
|
113
|
+
--title v<version> \
|
|
114
|
+
--notes-file /tmp/pi-simplify-release-<version>.md \
|
|
115
|
+
--prerelease
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Stable:
|
|
119
|
+
|
|
120
|
+
```bash
|
|
121
|
+
gh release create v<version> \
|
|
122
|
+
--repo geminixiang/pi-simplify \
|
|
123
|
+
--target main \
|
|
124
|
+
--title v<version> \
|
|
125
|
+
--notes-file /tmp/pi-simplify-release-<version>.md
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
If it already exists, use `gh release edit v<version> ...` and keep prerelease/stable intent consistent.
|
|
129
|
+
|
|
130
|
+
## Report back
|
|
131
|
+
|
|
132
|
+
Return:
|
|
133
|
+
|
|
134
|
+
- released version
|
|
135
|
+
- stable or prerelease
|
|
136
|
+
- version-bump commit hash
|
|
137
|
+
- push status
|
|
138
|
+
- release URL
|
|
139
|
+
|
|
140
|
+
## Guardrails
|
|
141
|
+
|
|
142
|
+
- Always use `geminixiang/pi-simplify`.
|
|
143
|
+
- Infer stable vs prerelease from the version, or ask.
|
|
144
|
+
- Do not include raw commit hashes in release notes unless requested.
|
|
145
|
+
- If hooks fail during commit, fix or report before retrying.
|
|
146
|
+
- Never publish a release without a corresponding CHANGELOG entry — the version bump commit must include the new CHANGELOG section.
|
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to this project will be documented in this file.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
|
|
6
|
+
|
|
7
|
+
## [Unreleased]
|
|
8
|
+
|
|
9
|
+
## [0.0.8] - 2026-05-25
|
|
10
|
+
|
|
11
|
+
### Added
|
|
12
|
+
|
|
13
|
+
- Support simplifying specific folders and files as snapshot reviews.
|
|
14
|
+
- Add a preset selector for choosing uncommitted changes or folder snapshot mode.
|
|
15
|
+
|
|
16
|
+
### Fixed
|
|
17
|
+
|
|
18
|
+
- Keep release tags and GitHub release titles v-prefixed.
|
|
19
|
+
|
|
20
|
+
## [0.0.7] - 2026-05-25
|
|
21
|
+
|
|
22
|
+
### Changed
|
|
23
|
+
|
|
24
|
+
- Use pi's native select list for findings selection.
|
|
25
|
+
- Wrap long finding recommendations in the selection menu.
|
|
26
|
+
- Split the simplify extension into prompt, selector, workflow, and shared type modules.
|
|
27
|
+
- Update dependencies to the current `@earendil-works` pi packages.
|
|
28
|
+
|
|
29
|
+
### Removed
|
|
30
|
+
|
|
31
|
+
- Remove the `/simplify-quick` command and its documentation.
|
|
32
|
+
|
|
33
|
+
### Added
|
|
34
|
+
|
|
35
|
+
- Add a project release workflow skill for future releases.
|
package/README.md
CHANGED
|
@@ -30,26 +30,21 @@ pi install npm:@geminixiang/pi-simplify
|
|
|
30
30
|
/simplify
|
|
31
31
|
```
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
Opens a preset selector. Choose uncommitted changes or a folder snapshot.
|
|
34
|
+
|
|
35
|
+
Uncommitted mode analyzes all git changes and presents cleanup candidates:
|
|
34
36
|
|
|
35
37
|
- **Safe** (green) - auto-selected, will be deleted
|
|
36
38
|
- **Confirm** (yellow) - delete after user confirms
|
|
37
39
|
- **Review** (orange) - user should review first
|
|
38
40
|
|
|
39
|
-
###
|
|
41
|
+
### Simplify Folders
|
|
40
42
|
|
|
41
43
|
```
|
|
42
|
-
/simplify
|
|
44
|
+
/simplify folder src docs
|
|
43
45
|
```
|
|
44
46
|
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
- `console.log` / `console.warn` / `console.error`
|
|
48
|
-
- `debugger` statements
|
|
49
|
-
- Unused imports
|
|
50
|
-
- Empty catch blocks
|
|
51
|
-
|
|
52
|
-
No confirmation needed - just does it.
|
|
47
|
+
Analyzes the specified folders/files as a snapshot (not a diff), even when there are no local git changes.
|
|
53
48
|
|
|
54
49
|
### With Focus
|
|
55
50
|
|