@ravshansbox/pi-next-issue 2.7.0 → 2.8.0

package/README.md

@@ -21,11 +21,12 @@ The footer shows the issue, the stage, the number of tool calls and the time spe
 
 The package ships the `create-issue` skill. Ask pi to write an issue, or run `/skill:create-issue <problem>`. Pi then:
 
-1. restates the problem and reads the code when the problem touches it;
+1. restates the problem, reads the code when the problem touches it, and finds the open issues that must be done first;
 2. asks numbered questions until none is open;
-3. shows the title and the body, and asks once whether to create the issue and start a run;
+3. shows the title, the body and those blockers, and asks once whether to create the issue and start a run;
 4. runs `gh issue create --body-file` with the body from [`template.md`](skills/create-issue/template.md) and the `status:todo` label;
-5. calls `next_issue_start` when you asked for a run.
+5. links each blocker with `gh issue edit --add-blocked-by`, so the worker waits for it;
+6. calls `next_issue_start` when you asked for a run.
 
 Pi does not implement the issue in that session. The worker does the work. The body holds the sections of the [issue format](../next-issue/README.md#issue-format).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ravshansbox/pi-next-issue",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "Pi extension that works through GitHub issues with the next-issue worker",
   "license": "MIT",
   "type": "module",

package/skills/create-issue/SKILL.md

@@ -8,18 +8,24 @@ description: Turn a problem into a clear GitHub issue that the next-issue worker
 Turn the problem of the user into one GitHub issue in the format of `template.md`, next to this file.
 
 1. Understand the problem. Restate it in your own words.
-2. Investigate the code when the problem touches it. Read the relevant files and note what you find, with file paths.
+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.
 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.
 4. Write the body from `template.md` into a temporary file. Keep every heading of the template and its order. Leave `Open questions` empty.
-5. Show the title and the body to the user. Ask once whether to create the issue and start a run: a) create the issue and start a run, b) create the issue only, c) change the draft. Change the draft and show it again until the user picks a or b.
+5. Show the title, the body and the blockers to the user. Ask once whether to create the issue and start a run: a) create the issue and start a run, b) create the issue only, c) change the draft. Change the draft and show it again until the user picks a or b.
 6. Only after the user picks a or b, create the issue:
 
    ```bash
    gh issue create --title "<title>" --body-file <file> --label status:todo
    ```
 
-7. Tell the user the issue url.
-8. Only when the user picked a, call the `next_issue_start` tool, and tell the user what it reports.
+7. Link each blocker:
+
+   ```bash
+   gh issue edit <number> --add-blocked-by <blocker>
+   ```
+
+8. Tell the user the issue url.
+9. Only when the user picked a, call the `next_issue_start` tool, and tell the user what it reports.
 
 Once the issue exists, do not implement it in this session. The next-issue worker does the work. Do not ask about a run a second time.