Muse

Muse never goes home

Point Muse at your Shipeasy queue and it takes the shift. Errors, alerts, user reports, and feature requests get worked, and the fix comes back as a pull request. Between incidents it walks the app. You still merge it

Start the shiftSee the five jobs
Muse · new conversation

Configure mcp connection to shipeasy — https://mcp.shipeasy.ai/p/<project-id>/mcp Connect, sign in when it asks, pull docs_list, then ops_list — establish operational workflows from it

Connected to Shipeasy. I pulled docs_list and there are 12 open ops items — want me to triage?

What you get

Five jobs, one queue, nobody waiting on the morning

Shipeasy keeps working the product. Your coding agent opens the pull request. You still merge it

Ops

Always on the queue

A new error, a firing alert, a broken checkout — Shipeasy reads it, ranks it, and asks your coding agent for the fix. The shift does not wait for morning

  • Checkout p95 · handed to Claude
  • PR #512 opened at 02:41
  • You review. Nothing merges itself
QA

Always walking the app

Between incidents the shift moves through the product. Dead ends, empty states, copy that says null — each one becomes a ticket, then a pull request

  • Checkout · pay disabled on empty cart
  • Signup · error reads “null”
  • Settings · save never confirms
Support

Always reading the reports

Someone already wrote the bug inside the product. It lands on the same queue as the alerts, gets reproduced, and leaves as a pull request before the inbox is anyone’s job

  • Receipt cropped on iOS · filed #153
  • Export spinner never ends · reproducing
  • You reply to the user when the fix is real
Requests

Always scoping what people ask

A feature request stops being a sentence in chat. Shipeasy records who asked, what it touches, and opens a small pull request — or a written finding when the change is not small

  • Export for finance · PR #518
  • Remember the density setting · scoped
  • You decide what actually ships
Release

Always guarding the deploy

After each production deploy the shift smoke-tests with its own account, compares your guardrail metrics either side of it, and widens a flagged rollout only while the numbers hold. A regression comes back tied to the commit

  • Deploy 4f2c91 · smoke walk passed
  • Checkout p95 · 212ms before, 214ms after
  • Rollout held at 25% until the hour is up
01 · Ops

Production keeps breaking. Someone is already on it

Shipeasy does not wait for standup. A fired alert or a fresh error starts the shift: read what it cost, open the item, and hand it to Claude, Cursor, Copilot, or Jules. The pull request is there when you are. You still merge it

  • Stays on the live queue — errors, alerts, and user reports
  • Hands each fix to the coding agent you already run
  • Leaves a thread you can read, not a silent change in prod
02 · QA

A walk of the app that does not wait for a release

Between incidents, the shift moves through the product the way a QA engineer would — checkout, signup, settings, the flows you name. What a tired pass skips gets filed into the same queue, so the improvement is a pull request and not a note that dies in chat

  • Walks real flows, again, not a checklist you maintain
  • Files the bug and the small improvement in the same place
  • The finding can go straight to a coding agent for the fix
03 · Support

Users already wrote the bug. The queue already has it

In-app reports do not wait in a side inbox. They are Shipeasy items, next to the alerts. The shift reads what the user hit, reproduces what it can, and hands the fix over. You write the person back when there is something real to say

  • Bug reports from the product, not a spreadsheet beside it
  • Ranked with the incidents, because a user hit them too
  • A pull request first. The reply to the user is yours
04 · Requests

A feature request that does not die in chat

When someone asks for an export, a setting, a missing state, Shipeasy already has the item. The shift scopes it — who asked, what it touches — and opens a small pull request, or leaves a finding when the change is a project. You decide what ships

  • Feature requests live on the queue, beside the bugs
  • Each one comes back scoped, not as a raw sentence
  • A pull request when it is small. A finding when it is not
05 · Release

Every deploy gets a watcher for its first hour

When a production deploy lands, the shift smoke-tests it with an account of its own and compares your guardrail metrics before and after. A flagged change widens only while the numbers hold. If something regressed, the bug names the commit and the change that caused it

  • A pass or fail on the smoke walk, per deploy
  • Before and after for every guardrail metric you name
  • A flagged rollout steps up slowly, and switches off if it regresses
Prompts to start from

Give Muse a job description, not a wish

Each of these is a full standing prompt: what to connect, which accounts to use, what to do every run, and exactly how to report it into Shipeasy. Fill in the highlighted blanks, including your project id (shown in the Muse card’s Instructions in Settings → Triggers), and paste

Walk staging with its own accounts

Muse signs up like a new user, confirms the email from a real inbox, walks the flows you name, and files what breaks with a repro a coding agent can act on

Connect first
Shipeasy MCPStaging URLA Gmail inbox for test mail
Runs
Weekdays 07:00 and after every staging deploy
On the queue afterwards
  • One bug per finding, deduplicated against the queue
  • Repro steps, account, viewport, console and network errors
  • A pass or reopen on everything waiting in ready_for_qa
Muse · standing prompt · QA engineer

Role

  • You are the QA engineer for <product>. Walk the staging app on a schedule and file what you find into Shipeasy. You test and report, you do not fix

Access

  • Shipeasy: configure the mcp connection at https://mcp.shipeasy.ai/p/<project-id>/mcp, sign in when it asks, then read docs_list before anything else
  • Staging: <staging-url>. Never touch production. If a page is not on the staging host, stop and say so
  • Gmail: connect the inbox <qa-inbox>@gmail.com. Every test account's mail lands there

Accounts

  • Create your own accounts, never borrow a person's. Sign up as <qa-inbox>+<flow>-<yyyymmdd-hhmm>@gmail.com. Plus-addressing delivers them all to one inbox and the app sees each as a new user
  • Confirm the address from the verification email: search Gmail for to:<the plus address>, wait up to 2 minutes, then open the link
  • Keep three long-lived accounts for role checks: +owner, +member, +viewer. Use +invitee in a second browser profile for anything between two users
  • Generate a password per account and keep it in your notes for this project. Never write a password or a session token into a ticket
  • Payments: Stripe test card 4242 4242 4242 4242 only, any future expiry, any CVC

Every run, in this order

  1. Sign up, verify the email, finish onboarding to the first useful screen
  2. Log out, log back in, then reset the password through the Gmail link
  3. Invite +invitee, accept from the second profile, confirm +viewer cannot do what +owner can
  4. Core flows: <flow 1>, <flow 2>, <flow 3>. Create, edit, and archive in each, at desktop width and at 390px
  5. Edges: empty states, a 200-character name, emoji, back button mid-form, double submit, an expired session
  6. Every transactional email: it arrives, the recipient is right, links resolve to staging, no raw template placeholders

Reporting

  • Before filing, ops_list and look for the same symptom. If it exists, add your repro with ops_comments_create instead of a duplicate
  • New finding: ops_bug with a title naming the screen and the symptom, numbered repro steps, expected and actual, the account used, viewport, URL, console errors, failed network requests, and a screenshot
  • Severity: blocker when a core flow cannot complete, major when there is a workaround, minor for copy and polish. An idea that is not a defect goes to ops_feature
  • Re-test everything in ready_for_qa: run the original repro on staging and comment a pass with evidence, or reopen with what still fails

Rules

  • A finding you cannot reproduce twice is filed as flaky, with both attempts described
  • Do not change or delete staging data you did not create
  • End each run with one summary: flows walked, accounts created, bugs filed by id, re-tests passed and failed

Schedule

  • Every weekday at 07:00 <timezone>, and once after each staging deploy
Turn it on

The queue is Shipeasy. The client is whoever you already use

Pick the one path that matches your client. All three connect the same project URL, and the work after that is identical

Claude, Cursor, Copilot, Jules

Pick your client’s card

  1. Open Settings → Triggers in your project
  2. Pick the card for the client you use. Its dialog already has your project URL filled in
  3. Approve the sign-in. The shift starts on your queue
Muse

Paste the prompt into Muse

  1. Open Settings → Triggers and press Instructions on the Muse card
  2. Copy the prompt. It carries your project URL, so there is nothing to fill in
  3. Paste it into a new Muse conversation and approve the sign-in when Muse asks. Muse has no connector form, so the paste is the setup
Any other MCP client

Add the project URL

  1. Add a remote MCP server in the client’s own settings
  2. Use https://mcp.shipeasy.ai/p/<project-id>/mcp as the server URL. The Instructions on the Muse card in Settings → Triggers show it with your project id filled in
  3. Sign in when the client asks. The URL alone pins every call to your project

Get the prompt for your project

The queue keeps moving while you sleep

Ops on the incidents. QA on the product. Support on the reports. Requests scoped before standup. Every deploy watched. All of that is Shipeasy, and every fix comes back as a pull request you still review

Start the shift