@ravshansbox/pi-next-issue 2.15.0 → 2.17.0

package/README.md

@@ -22,7 +22,7 @@ The footer shows each running issue with its stage, the number of tool calls and
 
 When an issue waits for a person, with the `needsHuman` label of the [config](../next-issue/README.md), the footer shows the count, for example `2 questions waiting`, and a note appears once for each new question. Neither interrupts what you do. Pi asks the worker for the list when it connects and every minute, and the worker also sends it after each issue of a run. A question answered on GitHub or in another pi leaves the count with the next list.
 
-Run `/next-issue answer` to go through the waiting questions one at a time. Each shows the issue, the title and the reason of the hand-over. Choose:
+Run `/next-issue answer` to go through the waiting questions one at a time. Pi suggests `answer` as you type after `/next-issue `. Each shows the issue, the title and the reason of the hand-over. Choose:
 
 - **Retry**: takes the `needsHuman` label off the issue and its pull request, so the next run resumes it.
 - **Retry with guidance**: asks for text, posts it as a comment where the worker reads it, on the pull request of the issue or on the issue when it has none, then takes the `needsHuman` label off.
@@ -36,11 +36,13 @@ The package ships the `create-issue` skill. Ask pi to write an issue, or run `/s
 
 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, 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. links each blocker with `gh issue edit --add-blocked-by`, so the worker waits for it;
+3. 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;
+4. links each blocker with `gh issue edit --add-blocked-by`, so the worker waits for it;
+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;
 6. calls `next_issue_start` when you asked for a run.
 
+The issue gets `status:todo` when it is created, so a run that is already going may claim it before you review it.
+
 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).
 
 ## Worker
@@ -53,4 +55,4 @@ The extension does no work itself. On `/next-issue` or `next_issue_start` it con
 - The worker stays when every pi is closed. Stop it with `npx next-issue stop`.
 - When the extension is newer than the worker, the worker closes once no run is going, and the extension starts the newer worker.
 
-Each run asks the worker to merge the pull requests. See the [`next-issue` README](../next-issue/README.md) for what a run does, its labels, its state and its config.
+Each run asks the worker to merge the pull requests. [ADR 0002](https://github.com/ravshansbox/next-issue/blob/main/docs/adr/0002-merge-setting.md) compares where the merge setting could live. See the [`next-issue` README](../next-issue/README.md) for what a run does, its labels, its state and its config.

package/index.ts

@@ -445,6 +445,8 @@ export function createExtension(options: Options) {
     pi.registerCommand('next-issue', {
       description:
         'Start or stop working through the GitHub issues of this repository, or answer the waiting questions with "answer"',
+      getArgumentCompletions: (prefix) =>
+        'answer'.startsWith(prefix) ? [{ value: 'answer', label: 'answer' }] : null,
       handler: async (args, ctx) => {
         if (args.trim() === 'answer') {
           try {

package/package.json

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

package/skills/create-issue/SKILL.md

@@ -11,23 +11,34 @@ Turn the problem of the user into one GitHub issue in the format of `template.md
 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, 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:
+5. Create the issue without showing the body first:
 
    ```bash
    gh issue create --title "<title>" --body-file <file> --label status:todo
    ```
 
-7. Link each blocker:
+6. 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.
+7. Give the user the issue url. Ask once: a) start a run, b) leave it, c) change the issue.
+8. When the user picks c, make the change on GitHub and ask again. Write the new body into the temporary file and run:
 
-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.
+   ```bash
+   gh issue edit <number> --body-file <file>
+   ```
+
+   To change the title, run:
+
+   ```bash
+   gh issue edit <number> --title "<title>"
+   ```
+
+9. Only when the user picks 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. Once the user picks a or b, do not ask about a run again.
 
 ## Sections