DEV Community: Shaharia Azam

Let Your AI Agent Use Slack: One CLI, No Slack App Needed

Shaharia Azam — Sun, 23 Aug 2026 14:44:36 +0000

Your AI agent can read your repo, run your tests, and open a pull request. Then it hits a wall. The context it needs is in Slack: the incident thread, the decision nobody wrote down, the "we changed the deploy order last week" message.

Getting an agent into Slack normally means building a Slack app, picking OAuth scopes, and waiting for an admin to approve it. That is a lot of work before the first useful message.

SlackCLI is a different path. It is a single open source binary that talks to Slack from your terminal, and every read command speaks JSON. If your agent can run a shell command, it can use Slack.

SlackCLI is an unofficial project. It is not affiliated with or supported by Slack Technologies.

Up and running in about a minute

brew tap shaharia-lab/tap
brew install slackcli

slackcli auth login-auto

login-auto opens a browser, you sign in to Slack the way you always do, and SlackCLI captures the session tokens for every workspace on that account. Nothing leaves your machine. Credentials land in ~/.config/slackcli/workspaces.json with file mode 0600.

Prefer a real bot token for a server or a CI job? That works too:

slackcli auth login --token=xoxb-your-token --workspace-name="My Team"

Now try something:

slackcli conversations unread

See it in action

Demo: https://github.com/shaharia-lab/slackcli#-see-it-in-action

Sign in, browse conversations, search the workspace, read a thread from a permalink, reply, react, read a Canvas as Markdown, and pipe --json into jq. All from the terminal.

Why a CLI is a good tool for an AI agent

Most agent frameworks are happiest when a tool is a plain command with plain output. SlackCLI is built exactly that way.

JSON everywhere. Every read command takes --json, so the agent gets structured data instead of screen scraping.
Clean streams. JSON goes to stdout. Spinners, warnings, and update notices go to stderr. A pipe carries only data.
Simple exit codes. 0 on success, 1 on failure. An empty search result is still a success, so check the data, not the exit code.
Links work as input. Anywhere the CLI wants a channel ID or a timestamp, you can paste a Slack permalink instead. A human drops a link in the prompt and the agent runs with it.
One static binary. No Python environment, no Node runtime, no server to keep alive.
Many workspaces at once. Add --workspace=automation-bot to any command to pick an identity on purpose.

Seven things an agent can do today

1. Catch up on what you missed

slackcli conversations unread --json | jq '[.unread_channels[] | {name, unread_count}]'

Feed that to a model and you have a morning digest.

2. Read a thread from a link

slackcli conversations read --permalink="$LINK" --json | jq -r '.messages[].text'

The JSON also carries a resolved users array, so user IDs are not opaque.

3. Search the workspace history

slackcli search messages "deploy failed" --in=engineering --limit=50 --json

All of Slack's own search operators work: in:, from:, before:, after:, has:, is:.

4. Find a channel or a person

slackcli search channels incident --json
slackcli search people "ada@example.com" --json

5. Reply where the conversation is happening

slackcli messages send --permalink="$LINK" --message="Root cause found, fix is in #4821"

Passing a permalink replies in that thread, so no ID juggling is needed.

6. Post a report humans actually want to read

slackcli messages send \
  --recipient-id=C1234567890 \
  --message="Nightly build report" \
  --blocks='[{"type":"markdown","text":"# Nightly build\n\n- [x] Build\n- [x] Tests\n- [ ] Deploy"}]'

Native Block Kit markdown and table blocks mean headings, task lists, code fences, and real tables instead of a wall of text.

7. Read a Canvas as Markdown

slackcli canvas read F1234567890 --json | jq -r '.markdown'

Team runbooks and specs often live in a Canvas. Now they are just Markdown your agent can read.

Wiring it into an agent

You do not need an SDK or an MCP server. Give the agent shell access and one short instruction block:

You can use the `slackcli` command to work with Slack.

Read commands (always add --json):
  slackcli conversations unread --json
  slackcli conversations read <channel-id|--permalink=URL> --json
  slackcli search messages "<query>" --in=<channel> --json
  slackcli canvas read <file-id> --json

Write commands (ask me first):
  slackcli messages send --permalink=<url> --message="<text>"
  slackcli messages react --permalink=<url> --emoji=<name>

Run `slackcli <group> --help` if you need the exact options.

That is the whole integration. A useful first prompt:

Read the last 50 messages in #incidents, find any unresolved issue from today, and draft a summary for me. Do not post it yet.

Because slackcli <group> --help prints the authoritative options for the installed version, an agent can discover the rest on its own.

Keep it safe

Slack access is real access, so a few rules are worth setting up front.

Separate the identity. Give automation its own bot token workspace profile instead of copying your personal browser session onto a server.
Keep a human on writes. Reads are cheap and reversible. Posting is not. A simple "ask before sending" rule in the agent prompt goes a long way.
Treat the config as a secret. ~/.config/slackcli/workspaces.json and the browser profile hold live credentials. Do not commit them, sync them, or copy them around. slackcli auth logout clears both.
Refresh tokens without a window. Browser tokens expire with the session. slackcli auth login-auto --headless renews them in an unattended job once the profile has signed in once.
Watch the rate limits. Commands that resolve many users or channels make one API call per entity, which adds up on a large workspace.

Try it

brew tap shaharia-lab/tap
brew install slackcli
slackcli auth login-auto
slackcli conversations unread

SlackCLI is MIT licensed, built with Bun, and ships prebuilt binaries for macOS, Linux, and Windows. It has over 400 tests and a full user guide.

⭐ Star it on GitHub if it saves you a trip to the Slack tab, and tell me in the comments what you would want your agent to do in Slack. Feature requests start as an issue.

Agento, The Missing Dashboard for Claude Code

Shaharia Azam — Thu, 13 Aug 2026 10:05:39 +0000

Claude Code is the best terminal tool I have used in years, and it has a strange blind spot: it remembers everything and shows you nothing.

Every session you run gets written to a JSONL transcript under ~/.claude. Every prompt, every response, every tool call, every token count, every model switch, every sub-agent it spawned. Months of it. And the only window the CLI gives you into that archive is /cost, which tells you about the session you happen to be sitting in right now.

So you end up with a monthly invoice and no way to connect it to anything you could actually change. Which model is that number? Which project? Was the eight hour autonomous run worth what it cost? Is that skill you installed last week making things better or quietly doubling your tool errors?

The data to answer all of that is already on your disk. It is just unreadable. A week of serious use is hundreds of megabytes of nested JSON that nobody is going to open.

Agento reads it for you. It is a single Go binary, MIT licensed, free, and it runs entirely on your own machine. No account, no API key, no server, nothing uploaded. It reads ~/.claude, caches what it finds in a local SQLite file, and gives you a dashboard.

One note before the screenshots: everything shown here comes from a generated sample dataset, not from a real machine. Your numbers will look different anyway. What matters is which questions the dashboard can answer.

Two commands

brew install shaharia-lab/tap/agento
agento web

On Linux or Windows, grab the binary for your platform from GitHub Releases, put it on your PATH, and run the same command. It starts on port 8990 and opens your browser.

There is no configuration step. Agento authenticates through the Claude Code CLI you already have installed, so if claude runs in your terminal, Agento works. The first scan takes a while on a large history, because it is reading every transcript you own, and it runs in the background while you use the app with a progress counter. After that it updates incrementally.

The chart that changes how you think

Start with cost broken down by model, and put tokens broken down by model right next to it.

They rank the models in different orders. Often in completely opposite orders.

A cheap, high volume model can dominate every usage chart you look at and still be a rounding error on the bill. A premium model you reach for a handful of times a day can be most of what you actually pay. On the sample corpus I built for these screenshots, one backend accounted for the overwhelming majority of tokens and a small fraction of the cost.

That gap exists because "tokens" is not one thing. Fresh input, output, cache reads and cache writes bill at wildly different rates. Any tool that shows one token number and multiplies it by one price is telling you something untrue.

Agento splits the four apart and prices each one per assistant message, at the model that message used and the date it was sent. Not per session at the first model it saw. That distinction matters more than it sounds like it should, because a long session drifts across models and a rate can change mid month.

The practical rule: read the cost chart, not the token chart. Almost everyone instinctively reads the token chart.

Caching is most of the economics

The insights page leads with what prompt caching saved over the period: what the same work would have cost if every cached token had been billed as fresh input. It is explicitly labelled an estimate, because it prices a counterfactual, but the order of magnitude is not subtle.

Which means the habits that break caching are expensive habits, and they all look like good hygiene:

Killing a session and starting fresh because it feels cleaner
Restarting after every small change
Splitting one task across five short sessions instead of one long one

Every restart re-pays for context you already bought. Nobody thinks "I'll start a fresh session" is a spending decision. It is one.

There is a per model view of the same thing, which turns out to matter if you point Claude Code at a non-Anthropic backend. Some of them serve very little from cache, so context gets re-billed as fresh input on every turn. That is a model selection consideration with nothing to do with the model's headline price, and it is invisible until you see cache hit rate charted per model.

Is your delegation actually saving anything?

If you lean on sub-agents, this is the one to check.

Delegation is supposed to be a cost lever: the orchestrator runs on a strong model, the searching and reading and summarising goes somewhere cheap. But sub-agents inherit the parent's model unless you say otherwise, so it is entirely possible to believe you have routed the grunt work to a cheap model while every delegated run quietly uses the expensive one.

You can only see this if the tool credits a sub-agent's tokens and cost to the model the sub-agent ran on, rather than to the model that delegated. Agento does, and it was a deliberate fix rather than an accident of design. Crediting delegated spend to the delegating model made the one chart that should answer "is delegation routing work to cheaper models?" structurally incapable of answering it. On the reference corpus, 18.3% of delegated tokens were being charted under the wrong model before that was corrected.

Are you getting faster, or just busier?

This is the part I find hardest to answer on instinct, and it is where the tool earns its keep.

The metrics worth watching, all shown against the equivalent preceding period so you read direction rather than magnitude:

Turns per session. How often you had to step in. Fewer turns for the same work means your prompts and agent definitions are carrying more weight.
Steps per turn and longest autonomous chain. How far the agent gets before it needs you. This is the number that distinguishes supervising from babysitting.
Tool calls per session and tool errors per 100 calls. The error rate is an early warning signal, and when it jumps it is almost never the model. It is a skill, a stale instruction, or a badly configured MCP server.
Active duration. More on this below.
Your own response time, charted next to how long you waited on Claude. That one is humbling.

Underneath sit breakdowns by tool, by skill, by plugin, by MCP server, by MCP tool and by sub-agent. That is how you find out which of your skills is burning the most tool calls, which is a very direct route to rewriting one and deleting another.

The insights page is marked experimental, and the app says so plainly, because several of the formulas are heuristics. The trends are informative even where the absolute numbers are arguable.

Four things that were harder than they look

Since this is dev.to, the implementation details are probably more interesting than the feature list. These are the four places where the obvious approach produces a number that is confidently wrong.

Duration has to mean active duration. Claude Code sessions are resumable, so the span from first event to last event counts every idle day in between. One session picked up after 28 days carried 82% of the dashboard's average duration figure: 476 minutes shown against a 17 minute median. So Agento sums the gaps between events and ignores any gap longer than a threshold you configure (10 minutes by default, adjustable from 1 to 240 because the right answer depends on how you work). The raw span is still stored and still shown as secondary context, because "first seen to last touched" answers a different, real question.

Pricing has to be effective dated, and honest about what it doesn't know. The catalog is editable from the Settings UI and ships with rates for several providers beyond Anthropic, because plenty of people point Claude Code at Kimi, GLM or Qwen. Cache creation is split by TTL, since the five minute and one hour tiers bill differently. Qwen tiers its pricing by context length, so a rate can carry bands. And a model with no published rate is reported as unknown rather than being quietly priced as something similar, so a partial total is disclosed as a floor instead of presented as complete. A deliberate zero, like a synthetic or embedding model, is a separate flag from an unknown one.

Cache hit rate needs exactly one definition. There used to be two in the codebase: cacheRead / (input + cacheRead), which pins near 100% and tells you nothing, and cacheRead / (cacheCreation + cacheRead), which sits around 74%. The one that survived counts the read share of every input side token, fresh input plus cache writes plus cache reads, because it is the only version under which a backend with no prompt caching scores 0 rather than being excused from the chart.

Activity charts have to bucket across a span. The heatmap counts a session in every hour between its start and its last activity, sharing its tokens out by overlap. The first version bucketed at the end timestamp, which quietly turned "activity by hour of day" into a map of when work stopped.

None of these are exotic. They are just the difference between a dashboard you can act on and a dashboard that looks plausible.

Drilling into one session

The dashboards tell you that something changed. To find out why, you open the session.

The list is searchable and filterable by project, model, date and cost, paged in SQL rather than in the browser so it stays usable at thousands of sessions. Every row carries the branch, the permission mode, and any pull requests that session touched.

Open one and you get the full transcript plus that session's own metrics, and a journey view: a step by step timeline of every message, tool call and result in order, with each sub-agent's steps nested underneath the Task call that spawned it.

That nesting is what makes a long autonomous run legible. When a four hour session costs three times what a similar one did, the journey view usually shows you which delegated branch went sideways in about a minute.

Privacy, since it's the obvious question

Claude Code transcripts contain your source code and your prompts. Any usage analytics tool that uploads them is a non-starter for most people and every company.

Agento is a single binary that runs on your machine. It reads ~/.claude, writes a SQLite cache to ~/.agento/agento.db, binds to 127.0.0.1 by default, and has no server component and no account. If there are projects you would rather keep out of the numbers entirely, you can hide them from all reporting in Settings, and hiding is not deleting, so unhiding is instant.

It also indexes multiple Claude config directories, which matters if you keep a work account and a personal account separate. Analytics reads the union of them; a given run targets exactly one.

The rest of it

The dashboards are the part I open every week, but Agento is a broader tool. It also does agent building with an explicit tool allowlist, persistent multi-chat conversations streamed over SSE, cron scheduled agent runs with job history, Telegram triggers, and in process MCP integrations for Google, GitHub, Slack, Jira and Confluence. All of it in the same binary. If that is more interesting to you than the analytics, the README covers it.

Try it on your own last thirty days

brew install shaharia-lab/tap/agento
agento web

You already have the data. It took me one evening of looking at mine to change five things about how I work, none of them dramatic, all of them compounding: keep sessions alive longer, compare models on cost rather than token volume, verify where delegated work actually goes, split long autonomous runs, and treat a rising tool error rate as a prompt bug rather than a model problem.

The repo is at github.com/shaharia-lab/agento. It is MIT licensed and free. If it turns out to be useful, a star genuinely helps other people find it.

I would be curious what surprises you in your own numbers. The cost versus tokens gap is the one that gets everybody.

Introducing Cora: A Powerful File Concatenation Tool for Developers

Shaharia Azam — Wed, 10 Jul 2024 15:41:51 +0000

In the world of software development, we often find ourselves dealing with multiple files that need to be combined for various reasons. Whether it's merging documentation, preparing training data for machine learning models, or consolidating code for review, the need to concatenate files is a common task. Enter Cora, a robust and flexible command-line tool designed to make file concatenation a breeze.

Project link: https://github.com/shaharia-lab/cora

What is Cora?

Cora, which stands for COncatenate and Read All, is an open-source Go application that simplifies the process of combining multiple files into a single output file. With its intuitive command-line interface and powerful features, Cora is set to become an essential tool in every developer's toolkit.

Key Features

Cora comes packed with features that set it apart from simple concatenation tools:

Recursive Directory Traversal: Cora can walk through directories recursively, allowing you to process entire project structures with ease.
Flexible File Selection: Use include and exclude patterns to precisely control which files are concatenated. This feature uses glob patterns, giving you powerful file matching capabilities.
Customizable Output: Add separators between files and prefixes before each file path in the output, making the resulting file more readable and organized.
Large File Handling: Cora is designed to handle large files efficiently, making it suitable for big data preprocessing tasks.
Debugging Mode: Enable debug logging to get detailed information about the concatenation process, which is invaluable for troubleshooting.

Difference between `cat` and `Cora`

While the cat command is indeed useful for simple file concatenation, Cora offers several advanced features that make it more powerful and flexible for complex scenarios.

Feature	`cat`	`cora`
Basic file concatenation	✅	✅
Recursive directory traversal	❌	✅
Flexible file selection (glob patterns)	❌	✅
Exclude patterns	❌	✅
Custom separators between files	❌	✅
File path prefixes in output	❌	✅
Built-in debugging mode	❌	✅
Cross-platform consistency	❌ (behavior may vary)	✅
Large file handling	✅ (but may require additional tools)	✅ (optimized)
Speed for simple concatenations	✅ (generally faster)	✅ (may have slight overhead)
Requires external tools for complex tasks	✅ (often used with find, xargs, etc.)	❌ (all-in-one solution)
Customizable output file	❌ (requires output redirection)	✅ (direct specification)
Part of standard Unix toolset	✅	❌ (requires installation)

Use Cases

Cora's versatility makes it suitable for a wide range of scenarios:

LLM Context Preparation: When working with Large Language Models, Cora can help you prepare comprehensive context by concatenating relevant code files or documentation.
Code Review: Merge multiple source files into a single document for easier review, especially useful for pull request reviews or security audits.
Documentation Generation: Combine multiple markdown files to create comprehensive project documentation or technical specifications.
Log Analysis: Concatenate multiple log files for comprehensive analysis while using exclude patterns to filter out irrelevant files.
Data Preprocessing: Merge multiple data files into a single file for easier processing in data analysis pipelines.

Getting Started with Cora

Installing Cora is straightforward. If you have Go installed, you can use the following command:

go install github.com/shaharia-lab/cora@latest

Once installed, you can start using Cora with a simple command:

cora -s /path/to/source -o output.txt -i "*.md" -e "*.tmp"

This command will concatenate all Markdown files from the specified source directory, excluding any .tmp files, and save the result to output.txt.

The Power of Open Source

Cora is not just a tool; it's an open-source project that welcomes contributions from the developer community. Whether you're interested in adding new features, improving performance, or fixing bugs, your contributions are valuable and appreciated.

Conclusion

In a world where data is increasingly distributed across multiple files and formats, tools like Cora become indispensable. Its combination of simplicity and power makes it suitable for both quick, one-off tasks and integration into complex data processing pipelines.

We invite you to try Cora for your file concatenation needs and experience the difference it can make in your workflow. Visit our GitHub repository to get started, and don't hesitate to share your feedback or contribute to the project.

Remember, in the world of development, small tools can make a big difference. Cora is here to simplify your file management tasks, allowing you to focus on what truly matters – building great software.

Happy coding!**