Slack automation that keeps track of the work
Put the update together once, then let your saved workflow handle the next one. Include the source links and keep track of what’s already been posted.
Build your Slack workflowChoose the sources
Include a repository in the channel preview.
Published releases only
Already handled items excluded
The second run matters, too.
Save which releases you’ve already posted in the package, then try running it again with the same releases.
This example assumes the first message was sent and its release IDs were saved successfully.
release_104
release_105What if the message sends but saving progress fails? Decide how the package should check for a previous post before trying again. Saving progress alone won’t prevent every duplicate.
Get your release digest running.
- Connect the accounts
Choose repositories and a channel your accounts can access. Kody doesn’t expand your Slack permissions.
- Review one message
Return a preview first. Check the time window, source links, and exclusions, then approve one test send.
- Give the package a schedule
After testing retries and empty results, add a package-owned job. Use run history to investigate connection and service failures.
Already using Slack MCP?
Direct Slack MCP access can give one agent the service’s tools. A Kody package adds your saved selection rules, other services’ data, and saved progress.
Connecting Slack as an integration and adding a remote MCP server are separate setups. Choose the connection your workflow needs.
Read the Slack connection guide ↗Try it with your Slack channel.
Connect your agent to Kody, then use this prompt to start building the package.
Connect your agentCreate a Kody package for a GitHub release digest in Slack. Ask me for repositories and a channel. Start with a preview, include release links, store progress with the package, and explain duplicate handling around failed writes. Don’t post or enable a schedule until I approve the preview.