SYLVIESIRequest access

Users report the bug. You approve the fix. SylvieSI does the middle.

SylvieSI reads bug reports and feature requests from your app, Slack and Gmail. It reproduces the bug, finds the cause and prepares the fix. You approve every change, and the user hears back once it has been checked. A product of THE SHRIKS.

Request accessExplore the product
Illustration of a long-range research vessel above a snow-covered planet.

What SylvieSI does

SylvieSI is software that handles what users tell a software company. It reads bug reports and feature requests from your app, Slack and Gmail. For a bug, it reproduces the bug, finds the cause in your code and error data, and prepares the fix. For a feature request, it gathers every request and every objection into one Idea. A person approves every change, and SylvieSI writes back to the user when the work has been checked.

Reads every message

Collects bug reports and feature requests from your app, Slack and Gmail, and keeps the user’s original words.

Finds the cause

Reproduces a bug, then traces it through your code and error data to a likely cause, with each source listed.

Prepares the change

Writes the engineering handoff, opens a draft pull request, or prepares an approved component for your staging site.

Tells the user

Replies on the channel the user wrote from, after the change has been checked on staging.

A user reports a bug. Here is what happens next.

Take one example. A user writes in from your app, Slack or Gmail: the export downloaded twice.

SylvieSI groups the matching messages, reproduces the bug, traces it to the code and prepares a fix for your engineers to review.

“I clicked Export once.
Two files downloaded.”

SylvieSI groups it with everyone else who wrote about duplicate exports.

One click, two requests.

Export clickedRequest sentRequest sentTwo downloads observed

SylvieSI runs the steps itself to confirm the bug is real.

The cause is in the code.

Likely cause
The export handler is registered twice.
Fix prepared
One change, with a test that fails before and passes after.
Next
An engineer reviews the draft pull request.

SylvieSI then re-runs the export on staging and writes to the sender only after it works.

The three parts of SylvieSI

Sylvie is the ship your team works from. Mobius is the observatory that watches what users send. Ouroboros is the engineering chamber that turns a bug into a checked fix.

Illustration of a large research observatory built across a snowy ravine.

Mobius collects and sorts messages

Mobius is the part of SylvieSI that listens. It reads every message your users send from your app, Slack and Gmail, works out who wrote it and what it is, and groups messages about the same bug. When many people ask for the same feature, Mobius gathers the requests into one Idea with the arguments for and against, so your team decides with both sides in view.

Explore Mobius

Ten agents do the reading and drafting

Each agent has one job. Agents read, investigate and propose. A controlled service sends the message, opens the issue or delivers the change after approval.

Reading

Triage labels and groups each message. Evidence reads your code and error data and saves each finding with its source.

Thinking

Idea gathers requests and objections into one Idea. Investigation tests hypotheses and writes the root cause assessment.

Building

Runtime prepares approved components for staging. Engineering writes the handoff and prepares a draft pull request.

Telling

Communication drafts replies and never claims a result that has not been checked. Brief writes the summaries of what changed.

Directing

Orchestrator plans the work and combines findings into one cited answer. Assist answers questions about the item you have open.

See the ten agents

SylvieSI handles two kinds of work Requests and bugs.

A feature request follows the CREATE path. A bug report follows the REPAIR 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.

  1. Group the requests
  2. Decide
  3. Build
  4. Test and tell

The sender hears back when the fix works

SylvieSI writes only after the change has been checked. The message goes out on the channel the sender used.

Example reply

Reported
The export downloads twice.
Checked
One download per click on staging.
Sent
The reply goes to the sender on the channel they wrote from.

A message counts as sent when Slack, Gmail or your app confirms it.

See how it works

More in the workspace

Features your team uses every day.

Command K searches messages, customers, cases, ideas, work, changes and approvals in one place. Assist answers questions about the item you have open and cites its sources. You can attach files to a chat, and SylvieSI checks the type and size before any agent reads them.

Notifications tell you when an approval is requested, work is blocked or a Case is resolved. Seven roles control who can triage, approve and change settings. Schedules run recurring tasks, an audit list shows every action by a person or an agent, and twelve settings pages cover the rest.

See every feature

From the Journal

Read the Journal

SylvieSI is open to pilot teams that run it on a real product. Access is by request.

Request access to the pilot

Request access

Or write to sylviesi@theshriks.space.