User message
Keep the sender’s words: the original message, who sent it, and where in the product they were.
How a user message becomes a checked change
SylvieSI reads what users send, sorts it into bugs and feature requests, prepares the change and tells the user when it is done. A person approves every change.
Ten steps from message to reply
1. A message arrives
From your app, Slack or Gmail, with the sender identified and the original words kept.
2. Messages are sorted
Each one is labeled a bug, a feature request, a question or feedback. Duplicates are grouped.
3. A Case or an Idea is opened
A bug becomes a Case. Repeated requests become an Idea.
4. The bug is reproduced
SylvieSI runs the steps to check whether the bug is real.
5. The cause is assessed
Error data, code and recent changes produce one of four results, each with its sources.
6. Work is prepared
A Linear issue with a full handoff, or a branch and a draft pull request.
7. A person approves
The approval names one exact change.
8. The fix is checked
SylvieSI re-runs the failing step on staging and confirms the deployment.
9. The sender is told
The reply goes out on the original channel and counts as sent when the channel confirms it.
10. The Case closes or re-opens
A new matching message proposes a re-open. The earlier outcome stays.
“The export downloaded twice.”
A message can arrive from your app, Slack or Gmail. SylvieSI identifies the sender, sorts the message and groups it with matching ones.
Reproduction
Try it again. SylvieSI runs the steps to see whether the bug is real.
Error data and code
Look for the cause. Error data and recent code changes show where to look. A lead is not yet a cause.
Confirmed bug
Every matching message is attached to one Case, ready for investigation.
Feature requests and bug reports
Each follows its own path. Both end with a message to the sender.
From a request to a delivered feature
Mobius gathers every request for the same need and lists the arguments for and against building it. A person chooses to build, defer, decline or hand the request to engineering, and writes down why. For a simple read-only feature, SylvieSI prepares an approved component for staging, tests it in a real browser and then writes to everyone who asked.
- Understand the request
- A person decides
- Choose the delivery path
- Test and deliver
From a bug report to a checked fix
SylvieSI groups the bug reports and reproduces the bug. It traces the bug through error data and code and states how certain the result is. It sends a handoff to Linear or opens a draft pull request, and a person merges. SylvieSI then re-runs the failing step on staging and writes to everyone who reported the bug.
- Confirm the bug
- Find the cause
- Prepare the fix
- Check and tell
A person approves every change
Before anything runs, a person sees the exact change, the environment, who it reaches, the risk and how to undo it.
Investigate and propose
Agents read, test and suggest the work.
Approve the exact change
A person approves. If the change is edited, the approval stops applying.
Carry it out
A controlled service performs the approved action.
Replies go out after the check
“We reproduced the duplicate download. A fix is being reviewed.”
Updates go out on the channel the sender used. SylvieSI says a bug is fixed only after the fix has been checked.
How a Case ends
Each Case ends with an outcome and the checks behind it.
Fixed
The failing step works on staging, the fixed build is deployed, and the sender has been told.
Needs more work
A test passed but the bug remains. The remaining work has an owner.
Cannot be determined
The cause could not be found with the information available. SylvieSI lists what is missing and what to check next.
Request access to the pilot
Tell us how bugs and requests reach your engineers today.
Request access ↗