@ravshansbox/pi-next-issue 2.16.0 → 2.18.0

package/README.md

@@ -14,9 +14,9 @@ Run this in pi, inside a git repository:
 
 - `/next-issue` starts a run of this repository when none is going, and stops the run when one is going. A stop takes effect after the current round, and the issue keeps its saved state, so the next run resumes it.
 - The `next_issue_start` tool lets the model start a run. When no run is going, it starts a run like `/next-issue`. When a run is going, it starts nothing and reports the current run, which picks up new issues by itself. It never stops a run, and it does not ask for confirmation. Its result says whether it started a run.
-- The `next_issue_status` tool lets the model see the run of this repository. It returns the footer line, then one line per handled issue with its outcome, for example `#190 done`. When the worker has no run of this repository, it returns `next-issue · no run of <root>`. When no worker is going, it returns `next-issue · no worker is running` and does not start one. It reports no other repository.
+- The `next_issue_status` tool lets the model see the run of this repository. It returns the footer line, then one line per handled issue with its outcome, for example `#190 done`. When the worker has no run of this repository, it returns `no run of <root>`. When no worker is going, it returns `no worker is running` and does not start one. It reports no other repository.
 
-The footer shows each running issue with its stage, the number of tool calls and the time spent on it, for example `next-issue #12 · review 1 · 37 tools · 4m12s | #13 · implement · 5 tools · 40s`. After a run ends, it keeps the last summary. In the terminal, it uses the dim colour of the theme, like the rest of the footer. A note appears when an issue is done, needs a human or fails while pi is open. Pi does not repeat the notes of a run that ended before it opened.
+The footer shows each running issue with the number of open issues at the latest fetch, its stage, the number of tool calls and the time spent on it, for example `#12/7 · review 2/5 · 37 tools · 4m12s | #13/7 · implement · 5 tools · 40s`. The open count includes the running issues and issues the run skips. A stage with a limited number of rounds shows the round and its limit: `review 2/5`, `review fix 2/5`, `checks fix 1/5` or `commit fix 1/10`. Other lines read, for example, `looking for issues`, `finished: 2 done` or `stopped: 1 done, 1 needs a human`. After a run ends, it keeps the last summary. In the terminal, it uses the dim colour of the theme, like the rest of the footer. A note appears when an issue is done, needs a human or fails while pi is open. Pi does not repeat the notes of a run that ended before it opened.
 
 ## Answer questions
 
@@ -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

@@ -72,27 +72,28 @@ export function formatStatus(progress: Progress, now: number): string {
   switch (progress.status) {
     case 'running': {
       if (running.length === 0) {
-        return 'next-issue · looking for issues';
+        return 'looking for issues';
       }
+      const count = progress.open === undefined ? '' : `/${progress.open}`;
       const lines = running.map((item) => {
-        const parts = [`#${item.issue}`, item.stage ?? 'prepare', `${item.tools} tools`];
+        const parts = [`#${item.issue}${count}`, item.stage ?? 'prepare', `${item.tools} tools`];
         if (item.startedAt !== undefined) {
           parts.push(duration(now - item.startedAt));
         }
         return parts.join(' · ');
       });
-      return `next-issue ${lines.join(' | ')}`;
+      return lines.join(' | ');
     }
     case 'stopping': {
       const issues = running.map((item) => `#${item.issue}`);
-      return `next-issue ${issues.length === 0 ? '#?' : issues.join(' ')} · stopping`;
+      return `${issues.length === 0 ? '#?' : issues.join(' ')} · stopping`;
     }
     case 'stopped':
-      return `next-issue · stopped: ${outcomes(progress)}`;
+      return `stopped: ${outcomes(progress)}`;
     case 'finished':
-      return `next-issue · finished: ${outcomes(progress)}`;
+      return `finished: ${outcomes(progress)}`;
     case 'failed':
-      return `next-issue · failed: ${progress.error ?? 'unknown error'}`;
+      return `failed: ${progress.error ?? 'unknown error'}`;
   }
 }
 
@@ -354,11 +355,11 @@ export function createExtension(options: Options) {
         const client = shared(options.client);
         await client.attach();
         if (!client.connected) {
-          return report('next-issue · no worker is running', root);
+          return report('no worker is running', root);
         }
         const progress = client.runs[root];
         if (progress === undefined) {
-          return report(`next-issue · no run of ${root}`, root);
+          return report(`no run of ${root}`, root);
         }
         const lines = [
           formatStatus(progress, Date.now()),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ravshansbox/pi-next-issue",
-  "version": "2.16.0",
+  "version": "2.18.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
 

package/src/worker.ts

@@ -20,6 +20,7 @@ export type Progress = {
   status: RunStatus;
   issues: IssueProgress[];
   handled: Handled[];
+  open?: number;
   error?: string;
 };