Slack

Changelog

1. 1.32.0

   Slack 1.32.0: an agent reacts with 👀 as soon as it starts on a message

   The posting skill now tells an agent to react with eyes to the message it was asked in before it does anything else, so the person who asked sees at once that it landed and somebody is on it, rather than waiting minutes for the first reply. Once per message, never on its own.

2. 1.31.1

   Slack 1.31.1: findRecent allocates less than half of what it did

   A simple question asked through Slack kept a server allocating hundreds of megabytes a second for twenty minutes until the pod died (orknux-server #616). The server runs this plugin in an interpreter, where every JavaScript function call allocates its frame on the heap, and findRecent matched each message by splitting it into words and walking them with closures: about 80 KB of garbage a message, 16 MB a page of 200, and 400 MB for one scan of fifteen channels.

   A query is now made into one regular expression per phrase, once per call, behind a plain substring check that turns away most messages before any expression runs. The answers are the same - a test holds the new matching to the old over three thousand messages of diacritics, hyphens and punctuation - and a scan of fifteen channels now allocates about 185 MB instead of 400 to 460, most of what is left being the pages themselves.

   pages no longer multiplies across every channel. It was documented for one named channel and applied to all of them, so a model passing pages 5 with no channel read seventy-five pages in one call. Without a channel a scan reads one page of each again, and it says which channels hold more and to name one, rather than saying fifteen times to carry on with a nextCursor that was null.

3. 1.31.0

   Slack 1.31.0: findRecent searches a window moved back by skipDays

   Asked for: can the agent skip days to search deeper? days counted back from now and stopped at a year. skipDays moves the window back - days 30 with skipDays 365 reads the month that ended a year ago - so older history is searched a window at a time, as far as the workspace keeps it, and the answer says until when the window ran.

4. 1.30.0

   Slack 1.30.0: findRecent searches nearly like full text

   Asked for: every word had to appear exactly, capitals aside, so wysylki missed wysyłki and wysyłka missed wysyłek. Words are now folded (diacritics off), split on anything that is not a letter or digit, and matched by stem so other forms of a word match; "phrases", OR and -exclusions work; and attachments, link previews and file names are searched with the text.

5. 1.29.1

   Slack 1.29.1: findRecent carries on through threads it had no room to open

   Reported: a channel read to the end of its window, 2,257 messages and more than thirty threads, answered complete false with nextCursor null, so the agent said the rest was out of reach and blamed a missing scope. Threads left unopened now get a cursor that re-reads the same pages and opens only the older threads, and incompleteBecause says in words why an answer is not the whole window.

6. 1.29.0

   Slack 1.29.0: findRecent reads a channel piece by piece, threads included

   Asked to search a channel iteratively, an agent had to say findRecent could not: it read one page of 200 and never opened a thread. With one channel named it now reads five pages (twenty at most), searches the replies inside up to thirty threads, and answers nextCursor so the next call carries on to the end of the window, a year back at most. search.messages stays out of reach: Slack answers it for a user token only.

7. 1.27.2

   Slack 1.27.2: upload sends a key's bytes as bytes

   A PDF key passed to upload reached Slack as a file of base64 text, and an SVG kept by charts_render - base64 since the server keeps drawings under a key - would have too. A key holding base64 is decoded: markup goes as text, anything else goes up through the binary path.

8. 1.27.1

   Slack 1.27.1: after the message has gone out, no answer is expected

   The page said "leave it out unless something after you needs it", which reads as manners rather than as a fact about the call. It never said the thing that settles it: answer is an optional argument. A model told to leave something out, with no word that omitting it is allowed, puts something harmless there - and harmless there is a second message to whoever reads the next node.

   So it says all three now. No answer is expected of you once the message has gone out - not a short one, not a confirmation, not a note about what you posted. answer is optional, so omit it; it is not the message and nobody in the channel sees it. And where the agent's own instructions say otherwise - told to report back, or wired to a step that needs a value - they are right and this page is not, and what goes in answer is what that step needs rather than the message already sent.

   The same deference the mrkdwn rule got: a page shipped with a plugin cannot know what a workspace has told its agent, and where the two disagree the workspace wins.

9. 1.27.0

   Slack 1.27.0: the pages come back, because the loop was never in them

   An agent spent an afternoon writing itself todos - "Call slack_whoIs", then "Actually call slack_whoIs", then "CALL SLACK WHOIS NOW", then "JUST CALL THE TOOL DAMMIT" - and it was right every time. slack_post, slack_whoIs and slack_mention were not declared in that round: the workspace had them behind find_tools, so a decoder held to the declared list could not emit one however hard the model tried, and every attempt came out as the nearest thing it was allowed to say. Replaying the captured request with those three tools added turns 2-in-3 runaway into four clean runs that call slack_whoIs once.

   So the two rewrites that went looking for it in the prose are reverted. The mrkdwn table is back, with the spellings side by side where they can be compared; so are the worked examples - the bullet list, the quoted reply, the call with its arguments - and the sections on what Slack does with a file, a diagram and a link. Stripping those bought nothing, because the page was never what was wrong.

   What stays is everything that was a real fault: no skill names another skill, every example is a call the way a model has to send it rather than a positional signature, the conversion lives beside the plugin that posts and is a tool of its own, the escape-sequence section is gone, the mrkdwn rule defers to a workspace that converts on the way out, and the page is three pages rather than sixteen kilobytes in one.

   The lesson worth keeping is not about prose. A skill that names tools the round does not declare is a page describing work the agent cannot do, and the model has no way to say so except by failing loudly.

10. 1.26.1

    Slack 1.26.1: the page had no last step, so the model never reached one

    A workspace found the cure by accident: the agent loops on "hi" with this page loaded, and stops looping when ::tl-dr is added. The transcript says why. With both pages loaded the model reasons "according to the tl-dr skill: answer first" and answers; with only this one it lists what this page told it - reply in the thread - and goes looking for the next thing to do. skill_list, memory_search, another skill, round again, two hundred and thirty-four calls in one message.

    Because that is what the page was: preconditions. Write it this way, put it there, never hand-write a mention, read the thread before adding to it, react instead of replying. Seven steps, not one of which was "answer". The pages that never derailed anything all name the answer in their objective - Agents says "the whole answer is that list", tl-dr says "answer first" - and this one said the objective was to write the message the way Slack reads it.

    So it opens with the answer now: answer the person, in one message, in the thread they asked in, and this page is how that message is written rather than a list of things to do before writing it. Step one is write the answer, step five is then stop. The two that depend on the situation - joining a thread already in progress, answering something that is not the message above - are below the steps where they cannot read as a queue.

    Nothing was lost. It is 2.5 KB, and every rule the 16 KB version carried about writing a message is still in it.