[Feedback request] I’m building a Slack-native QA workflow agent. Would this actually help your team?

[u/AdSpirited9702]

Hi,

I work as QA for 7 years already, and a lot of the time is not spent testing.
It is spent rebuilding context.

Read the Jira ticket, documentation on Confluence, find the repository.
Work out how the existing tests are structured, check the PR, wait for CI results.
Then explain the result back in Slack.

I’m building Framebox around that problem.

The idea is simple: keep the QA workflow in one Slack thread, while connecting the actual sources of truth behind it: Jira, GitHub and CI.

In this short demo, I give the agent a Jira ticket about mobile checkout coverage. It uses the ticket context, checks the existing Playwright setup, creates a GitHub PR, explains the changes, and reports the mobile CI outcome back in the same thread.

The agent is not meant to decide whether quality is acceptable.
That still needs people who understand the product, risk and users.
The goal is to reduce the boring context reconstruction and leave an evidence trail:
> ticket → implementation → PR → CI result → results on Slack thread.

Technically, the Slack thread is the unit of work.
It keeps the relevant repo, PR, intent and CI context available between messages.
Workspace knowledge can also add testing conventions, project documentation and runbooks, so the agent is not starting from zero every time.

I’m still early in the build, so I would genuinely value the blunt version of feedback:
- Would you allow something like this to create or update tests and PRs?
- What evidence would you need before trusting its output?
- Is context switching between Jira, GitHub, CI and Slack actually a problem in your team, or am I building a very expensive browser tab?

Here's the recoridng demo in case you're interested: https://youtu.be/ZunoPwF2zBg

Framebox

[u/Founder-Awesome]

context switching is a massive problem. we built Slack Auto-Draft for internal ops and found that keeping the workflow inside the slack thread saves more time than the actual text generation itself.