GitHub

Changelog

1. 1.10.0

   GitHub 1.10.0: an agent finds a line by its number instead of counting to it

   Before this, openFile answered a file as raw text and nothing else. An agent that needed line 312 of a 476-line file had only one way to get there: count every line in its own reasoning, which cost thousands of tokens and was often off by a few. Then, having found the place, it rewrote the whole file to change a few lines of it.

   openFile takes three new optional arguments. fromLine and toLine (1-based, inclusive; toLine 0 reads to the end) read only that stretch, and numbered prefixes every line with its number, as " 12| text". Asking for either puts a first line in the answer saying which lines these are and how many the file has. Asking for neither answers exactly what it always did, so a workflow already calling openFile is unaffected.

   findInFile is new, as a function and as a tool: given a pattern - plain text, or a regular expression with regex true - it answers the file's total line count, how many lines matched, and each match with its line number, its text and, with context, the lines around it. limit caps how many are listed.

   The skills on reviewing a pull request, on reviewing Copilot's work and on getting a build green now say to find a line that way rather than by counting, and two of them say that changing a file means cloning the repository into a box and editing it there with orkbox_edit, not sending the whole file back.

2. 1.9.0

   GitHub 1.9.0: a Copilot task can be given its model, and the models listed

   createAgentTask takes a model, as listAgentModels spells it. Left empty it uses the new defaultModel setting, and with that empty too GitHub chooses, as before. listAgentModels answers the chat models Copilot offers the token's plan, read from Copilot's own API because the agent-tasks API has no list. That address, api.githubcopilot.com, has to be allowed by the installation's proxy rules.

   A task now asks for its pull request outright. GitHub's reference defaults create_pull_request to false, and everything this plugin teaches after starting a task assumes a draft pull request exists.

3. 1.8.0

   GitHub 1.8.0: review threads can be read, a PR approved, and Copilot's finished drafts sent for review

   An agent could post comments on a pull request's diff but not read them back, so it could not tell whether anybody had left an objection nobody answered. pullComments now reads every comment on the diff grouped into threads - the file, the line, whether the thread is resolved, whether the code it was about has since changed - and the comments under the conversation, with unresolved counting the threads still open. It reads through GraphQL, because only GraphQL knows a thread is resolved. Each comment's id is what replyToComment takes.

   approve submits an approving review, with an optional note, as whoever the token belongs to. GitHub refuses an approval of a pull request the token's own account opened. It answers the review the way reviews lists one.

   The skill for working with the Copilot coding agent now says two things it did not:

   • Say what you did first, then watch. Handing work to Copilot is followed at once by two or three lines to whoever asked - what was done and the session or comment link - before the first wait, because a wait ends the turn and what is written with it is a note to the agent itself, not a reply.
   • Take a finished draft out of draft. Copilot opens drafts, and a draft asks nobody for review. Once its task is completed, the build on the current head is green, the whole diff has been read with nothing to object to and no review thread is left unresolved, the agent marks it ready for review and says so only after GitHub answers draft false. Anything short of that goes back to Copilot on the same pull request, and it stays a draft.

   Getting a build green follows the same rules: it reports the hand-off before waiting, and on green takes a Copilot draft that passes the same review out of draft.

4. 1.7.0

   GitHub 1.7.0: a pull request's title and description can be edited

   An agent could read a pull request's title and description with openPull but had no way to change them, so fixing a misleading title or filling in an empty description meant asking a person to do it.

   editPull changes the title, the description, or both. Leave either out and it stays as it is - only what is given is sent, so retitling a pull request cannot wipe its description, and a call with nothing to change is refused rather than sent. The description is replaced whole, not appended to; the tool says to read it with openPull first when only part of it should change. It answers the number, title, description and url as they stand afterwards.

   It needs nothing the token did not already have for commenting: write on pull requests.

5. 1.6.0

   GitHub 1.6.0: a draft pull request can be sent for review, and back

   An agent asked to put a pull request up for review could open it, comment on it and read its draft flag, but not change it: GitHub's REST API reads draft and silently ignores a request to set it. So the agent could only leave a comment asking somebody to press the button, and say it had not.

   markReadyForReview does what the site's "Ready for review" button does, and convertToDraft does the reverse. Both answer the number, whether it is a draft now and its url, so draft false is proof it moved rather than a claim. A pull request already where it was asked to be is answered as it is; a merged or closed one is refused with a sentence saying which.

   They go through GitHub's GraphQL mutations, the only way GitHub offers, and need nothing the token did not already have for commenting: write on pull requests. On an Enterprise Server the GraphQL endpoint is found beside /api/v3, at /api/graphql.

6. 1.5.3

   GitHub 1.5.3: a fix to a Copilot pull request goes to its session

   The Copilot skill said how to steer a task but not what to do when a pull request Copilot opened needs a fix, so an agent could open a second PR or start a new task for it. It now says: messageAgentTask on that pull request, never a new PR or createAgentTask, and a person's PR gets a comment instead.

7. 1.5.2

   Slack 1.23.2, GitHub 1.5.2: a skill shows the call the way a model has to send it

   Every example in every skill was written as a signature - positional, in single quotes:

   slack_post(connection, channel, text, '', [])
   { channel, ts } = slack_post(conn, channel, text, '', [])
   

   That is how a workflow node calls a function, and it is the wrong thing to put in front of an agent, which sends a name and a JSON object with double-quoted argument names. What the page taught has no valid rendering: '' is not a JSON string, { channel, ts } is not a JSON object, and an assignment is not a call at all. A model copying any of it writes arguments no parser takes - which is what came back from one run, a call cut off at {"id":" and a 500 reading "invalid string: missing closing quote".

   The new-thread skill carried two of the three, which is the page a loop kept following.

   So they are written as calls now - the tool's name and an object, double quotes throughout, argument names spelled as the tool spells them. Five examples across the two plugins: post to a channel, the upload that takes the answered ts, the picture by key, finish_answer with its wake-up, and the message that steers Copilot.

   AGENTS.md says it as a rule, next to the one about not naming another skill: a signature belongs in the README, where a workflow author reads it, and never in a page an agent is going to imitate.

8. 1.5.0

   GitHub 1.5.0: wait for a build the cheap way, and fix it where it is failing

   A third skill, autofix-build, for the job of sitting with a pull request until its checks pass. Two things it teaches, and both of them are things an agent gets wrong on its own.

   The first is how to wait. finish_answer takes wake_after_ms now: the turn ends, the step parks, and the run comes back to that node when the time is up, with nothing held while it runs down. So waiting for CI is a call, not a round held open and not a poll in a loop — and the skill says to read what the tool itself reports, because it says how many waits are left and how long one may be, and a wait past the ceiling is quietly shortened rather than refused.

   The second is that the note is the only memory. answer means two different things depending on whether wake_after_ms is beside it: a note to yourself that comes back when the step wakes, or what the step answers with when it is really finishing. A woken turn is handed the step's original input and that note and nothing else — no tool results, no working — so the note has to carry the repo, the PR, the sha being watched, which check failed with what, what was already asked and which attempt this is. A note saying "waiting for the build" is a note that starts the job again from the top.

   Then the loop: openPull every pass, because a new commit moves the head sha and the build being watched belongs to a commit nobody is merging; buildStatus on that sha; wait on pending, one short wait on none before concluding that nothing is triggered, finish on success. On failure, read which reporter failed and what it printed, and check fileHistory before blaming the author of a PR that inherited a red base.

   And the fix goes where the failure is. messageAgentTask comments @copilot on that pull request, so the fix lands on that branch; createAgentTask would start a task in a branch of its own and open a second draft PR, leaving the red one red and somebody holding a merge question. Written out, because it is the plausible-looking wrong move. With stopping rules to match: the same check failing twice after the same instruction means say so on the PR and stop, a sha that has not moved means the instruction never landed, and a comment on every pass is a notification every three minutes for everybody watching.

   The Copilot skill's "do not poll it in a loop" now points at the wake-up rather than at a scheduled workflow, which was the only answer it had before.

9. 1.4.1

   GitHub 1.4.1: the classic token also answers a 404

   1.4.0 asked the classic token in when the fine-grained one drew a 403 on a commit's status, and that was the wrong half of what GitHub does. A token minted without the commit statuses or checks permission does draw a 403. A token an organization has not approved - the setup the classic token was added for - draws a 404, because GitHub will not admit a private repository exists to a token it will not show it to. So the fallback sat unused and buildStatus reported the 404 as if the commit were not there.

   Now either refusal is asked again under classicToken. The reason 404 was kept out - a repository that really is not there would be asked twice - still holds and no longer matters: the second ask costs one request and ends in the same sentence, which is cheaper than reading the wrong one of GitHub's two refusals as the truth.

10. 1.4.0

    GitHub 1.4.0: a classic token for the build status a fine-grained one is refused

    buildStatus was the one call that could fail where everything else worked. The commit status endpoints refuse a fine-grained token outright - a 403 - in setups a classic token still reads: an organization that has not approved fine-grained tokens, or a token minted without the commit statuses or checks permission. The plugin asked once, under the one token it had, and reported the refusal - about the one call a review most needs.

    So a second credential, classicToken: a classic personal access token with repo scope, secret like the other two and optional like them. buildStatus asks under token first and, on a 403, asks the same thing again under the classic one. Each of its two reads - the combined status and the check runs - falls back on its own, because a token can be refused one and not the other.

    Deliberately narrow. Only a 403 falls back: a 404 is the repository not being there, or invisible to both tokens alike, and asking twice would say the same thing twice. And only buildStatus reaches for the classic token at all - nothing else in the plugin ever sends it, so a token with the wide old scope is used for exactly the corner that needs it. Any other answer, and a 403 with no classic token configured, is the error it always was.

    A workspace whose fine-grained token reads builds fine never sets it.