@ravshansbox/pi-next-issue 6.2.0 → 6.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.
Files changed (3) hide show
  1. package/README.md +6 -5
  2. package/package.json +5 -5
  3. package/skills/create-issue/SKILL.md +11 -8
package/README.md CHANGED
@@ -41,11 +41,12 @@ Press Escape, or leave the guidance empty, to stop. Pi reads the list again befo
41
41
  The package ships the `create-issue` skill. Ask pi to write an issue, ask for a change in a repository with `.next-issue/config.json`, or run `/skill:create-issue <problem>`. Pi then:
42
42
 
43
43
  1. restates the problem, reads the code when the problem touches it, and finds the open issues that must be done first;
44
- 2. asks numbered questions until none is open;
45
- 3. creates the `status:todo` label with `gh label create` when the repository does not have it, then runs `gh issue create --body-file` with the body from [`template.md`](skills/create-issue/template.md) and the `status:todo` label, without showing the body first;
46
- 4. links each blocker with `gh issue edit --add-blocked-by`, so the worker waits for it;
47
- 5. gives you the issue url and asks once whether to start a run, leave it or change it, and changes it with `gh issue edit --body-file` or `--title` until you start a run or leave it;
48
- 6. calls `next_issue_start` when you asked for a run.
44
+ 2. judges whether the change fits one atomic commit that leaves the trunk green. When it is too big for one atomic commit, it proposes a split into issues that each land alone and keep the trunk green;
45
+ 3. asks numbered questions until none is open, including whether you confirm the split;
46
+ 4. creates the `status:todo` label with `gh label create` when the repository does not have it, then runs `gh issue create --body-file` with the body from [`template.md`](skills/create-issue/template.md) and the `status:todo` label, without showing the body first;
47
+ 5. links each blocker with `gh issue edit --add-blocked-by`, so the worker waits for it. For a confirmed split, it creates each issue in turn and links it to the issues of the split it depends on;
48
+ 6. gives you the issue url and asks once whether to start a run, leave it or change it, and changes it with `gh issue edit --body-file` or `--title` until you start a run or leave it;
49
+ 7. calls `next_issue_start` when you asked for a run.
49
50
 
50
51
  The issue gets `status:todo` when it is created, so a run that is already going may claim it before you review it.
51
52
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ravshansbox/pi-next-issue",
3
- "version": "6.2.0",
3
+ "version": "6.3.1",
4
4
  "description": "Pi extension that works through GitHub issues with the next-issue worker",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -42,10 +42,10 @@
42
42
  "typebox": "*"
43
43
  },
44
44
  "devDependencies": {
45
- "@types/node": "^26.6.5",
45
+ "@types/node": "^26.6.6",
46
46
  "@types/ws": "^8.18.2",
47
- "oxfmt": "^0.74.0",
48
- "oxlint": "^1.89.0",
47
+ "oxfmt": "^0.78.0",
48
+ "oxlint": "^1.93.0",
49
49
  "typescript": "^7.0.2"
50
50
  },
51
51
  "files": [
@@ -57,6 +57,6 @@
57
57
  "access": "public"
58
58
  },
59
59
  "dependencies": {
60
- "ws": "^8.22.1"
60
+ "ws": "^8.23.0"
61
61
  }
62
62
  }
package/skills/create-issue/SKILL.md CHANGED
@@ -5,13 +5,14 @@ description: Turn a problem into a clear GitHub issue that the next-issue worker
5
5
 
6
6
  # Create an issue
7
7
 
8
- Turn the problem of the user into one GitHub issue in the format of `template.md`, next to this file.
8
+ Turn the problem of the user into one GitHub issue, or a split of linked issues when the change is too big for one commit, in the format of `template.md`, next to this file.
9
9
 
10
10
  1. Understand the problem. Restate it in your own words.
11
11
  2. Investigate the code when the problem touches it. Read the relevant files and note what you find, with file paths. Run `gh issue list` and note each open issue that must be done first, including the issues you create in the same session.
12
- 3. Ask numbered questions about anything that is unclear: the scope, the expected behaviour, the acceptance criteria. Label options with letters and recommend one. Ask again until no question is open.
13
- 4. Write the body from `template.md` into a temporary file. Keep every heading of the template and its order. Leave `Open questions` empty.
14
- 5. Create the `status:todo` label when the repository does not have it, so the worker can claim the issue:
12
+ 3. Judge whether the change fits one atomic commit that leaves the trunk green. When it does not, propose a split into issues that each land alone and keep the trunk green, in the order they land, and note which issues of the split each one depends on.
13
+ 4. Ask numbered questions about anything that is unclear: the scope, the expected behaviour, the acceptance criteria. When you propose a split, ask the user to confirm the split with the other questions. Label options with letters and recommend one. Ask again until no question is open.
14
+ 5. Write the body from `template.md` into a temporary file. Keep every heading of the template and its order. Leave `Open questions` empty.
15
+ 6. Create the `status:todo` label when the repository does not have it, so the worker can claim the issue:
15
16
 
16
17
  ```bash
17
18
  gh label list --search status:todo
@@ -24,14 +25,16 @@ Turn the problem of the user into one GitHub issue in the format of `template.md
24
25
  gh issue create --title "<title>" --body-file <file> --label status:todo
25
26
  ```
26
27
 
27
- 6. Link each blocker:
28
+ 7. Link each blocker:
28
29
 
29
30
  ```bash
30
31
  gh issue edit <number> --add-blocked-by <blocker>
31
32
  ```
32
33
 
33
- 7. Give the user the issue url. Ask once: a) start a run, b) leave it, c) change the issue.
34
- 8. When the user picks c, make the change on GitHub and ask again. Write the new body into the temporary file and run:
34
+ For a confirmed split, repeat steps 5 to 7 for each issue of the split, in order. Link each one to the issues of the split it depends on.
35
+
36
+ 8. Give the user the issue url, or each url of a split. Ask once: a) start a run, b) leave it, c) change the issue.
37
+ 9. When the user picks c, make the change on GitHub and ask again. Write the new body into the temporary file and run:
35
38
 
36
39
  ```bash
37
40
  gh issue edit <number> --body-file <file>
@@ -43,7 +46,7 @@ Turn the problem of the user into one GitHub issue in the format of `template.md
43
46
  gh issue edit <number> --title "<title>"
44
47
  ```
45
48
 
46
- 9. Only when the user picks a, call the `next_issue_start` tool, and tell the user what it reports.
49
+ 10. Only when the user picks a, call the `next_issue_start` tool, and tell the user what it reports.
47
50
 
48
51
  Once the issue exists, do not implement it in this session. The next-issue worker does the work. Once the user picks a or b, do not ask about a run again.
49
52