# [AIN#35] Hand off communication, cut context switching

- Publication: Loop Labs Lab Notes (https://looplabs.cc/blog/)
- Author: Rich Steinmetz
- Published: 30 Aug 2026
- Canonical HTML: https://looplabs.cc/blog/ain-35-hand-off-communication-cut-context-switching/

---

Having 3-4+ parallel WIP items in a team-based project means having as many communication threads as there are communication platforms, multiplied by the implementation phases (research, implementation, and post-deploy). That is unsustainable to handle completely manually with today's workloads. But you still need the human touch.

Solving one ask may mean communicating about the initial requirements in the project management platform (like Jira or Linear). Then, communicating about the implementation change (PR reviews and/or Slack). And after the issue is fixed, doing the post-deploy items. Communication is needed here to let people and the world know that the feature shipped or the bug was fixed.

Over the past couple of months, these skills have crystallized for me as the daily communication drivers.

## /slack-message

My control center isn’t fully settled yet. Depending on the task, it’s a Conductor worktree, Claude Code in the home folder (or wherever I'm in right now), or a Codex Desktop app worktree. When I’m asked to solve an issue, I pass the context to one of them. The initial spike needs to be communicated back to where the conversation started and tracked, which, in most cases, is Slack. So after I understand the issue, I don't have to go back to Slack, find the thread, and post it there anymore. That's what `/slack-message` does for me now. It drafts a message I send manually, or creates the message if I explicitly ask it to. It might not seem like a big time-efficiency win, but I'm using it multiple times a day, and as you know, it adds up:

![](https://looplabs.cc/assets/ain-35-time-savings-chart.png)

*[A money-focused remix](https://www.reddit.com/r/xkcd/comments/31rlfh/remix_of_xkcd_1205_is_it_worth_the_money_third/) of [XKCD 1205, “Is It Worth the Time?”](https://xkcd.com/1205/).*

The even bigger win is saving yourself the cost of switching to Slack while working through a worktree batch. If you've ever used chat apps at work, you know it can be a gate that, once opened, leads you through some rabbit holes to the end of your working day, your main tasks untouched.

## /review-comment

Once the item enters implementation, bots and humans start commenting on the PR. Without automation, this is where I would get confused and spend tons of time switching between my control center and the browser. My `/review-comment` skill now knows how to differentiate between commenting as an approving or rejecting PR review, replying to someone's review comments and resolving them, and sharing my self-QA results in a comment or the PR description. Unless indicated otherwise, the text is a block quote, and the bot signs with its model and whether the comment was just discussed or approved as is:

![](https://looplabs.cc/assets/ain-35-review-comment.png)

*A resolved review finding, with the fixing commit and bot authorship.*

## /submit-review-after-hands-on-review

`/hands-on-review` is a skill that teaches the agent how to run QA on a PR at hand. It records all steps taken to test a PR end-to-end, including actual API calls or UI walkthroughs with screenshots and request/response cycle recordings. It also knows how to fix small findings on its own. After all this is done, `/submit-review-after-hands-on-review` knows where to post each kind of `/review-comment`. It can also submit an approving or rejecting review, provide commit references, and comment on the right lines of code or threads.

## /post-deploy-check

Most of the time, at the end of the day, there is a batch of recently shipped production items. This skill goes through all of them, performs any post-deploy items it can (ship public docs, initiate feature flag deletion, etc.), and creates short Slack drafts in the relevant threads to communicate the production change.

---

Bottom line: it might seem silly to use the power of agents to "just send a message," but this is what works for me to focus more on thinking instead of switching tools, finding the right places, and writing everything by hand.

## Last call for the Rails.Builders

The Continuous r-AI-ls.Builders round restarts **this Thursday**, and as I write this there are still **2 spots** open [rails.builders](https://rails.builders).

## [AIN#35] AI Nuggets Week#35

### 📺 Expert Knowledge YouTube Nuggets

**State of Agentic Coding #7 with Armin and Ben** (Armin Ronacher & Ben Vinegar) - There is an interesting argument for Ruby not being agent-friendly. Also, I didn't know you can't use AI for even research for the open source Zig programming language. It's the last bastion that does not allow any AI (slop) at all, yet.
