Use cases

Each use case below starts a session from the browser, Slack or the API, and ends with a pull request or a report you review.

Fix a bug from an issueCopy Anchor Link

1. Copy the issue's title, error and steps to reproduce into a task.
2. Pick the repository and an agent that knows how to run its tests.
3. Say what done means: a test that reproduces the bug and now passes.
4. Review the pull request. Add publish to approvals if you want to see the diff before it opens.

Fix issue #212: "Export fails for reports with no rows".
Error: TypeError: Cannot read properties of undefined (reading 'length') at src/export/csv.ts:41.
Add a test that exports an empty report, then fix the code. Done when npm test passes.

Upgrade a dependencyCopy Anchor Link

Give one package and one target version per session. Name the checks to run. The sandbox reaches a package registry only if an admin allowed it (Network access).

Upgrade express from 4 to 5 in services/web. Follow the official migration guide.
Fix type errors and failing tests. Don't upgrade anything else.

Review a pull requestCopy Anchor Link

Agents can review code and post comments through a GitHub MCP server that runs on your Pistis server, so the sandbox still holds no token (MCP servers). Gate the tool that posts comments if you want to read the review first.

Review pull request #41 in acme/api. Check the retry logic for off-by-one errors and missing tests.
Post your findings as one review comment. Don't approve or merge.

Triage from SlackCopy Anchor Link

Mention the bot in the thread where a problem was reported. The agent can read logs, run the failing command and reply in the thread. Anyone in the thread can add details. See Slack.

@pistis the nightly job failed with "connection reset" at 02:14. Run scripts/check-db.sh and tell us what you find. Don't change anything.

Run the software factoryCopy Anchor Link

Turn issues into pull requests without starting each session by hand. Pistis doesn't watch your issue tracker itself. A small script or a CI job calls the HTTP API:

1. When an issue gets a label such as agent, your CI job creates a session with POST /sessions. It sets meta.repo and meta.agent, and uses the issue number as requestId, so a repeated event can't start a second session.
2. It sends the issue text as the task with POST /sessions/:id/messages.
3. The agent works, and publish waits for approval if you gated it.
4. The agent opens the pull request. Your usual review and CI run on it.
5. A person merges. Pistis never merges for you.

To have the agent react to CI, it can wait for a webhook with wait_for, and your CI posts the result to the webhook URL.