What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and studies how hiding already works. In a codebase like lobsters/lobsters (Rails on Ruby 4.0.0 per .ruby-version, RSpec under spec/), users can hide individual stories through HiddenStory (app/models/hidden_story.rb) with hide_story_for_user / unhide_story_for_user, and Story.not_hidden_by / Comment.not_on_story_hidden_by filter those rows. User has has_many :hidings but there is no mute-user association that drops another author's stories and comments everywhere. Settings live in SettingsController and the /settings UI.
It adds a mute model (or equivalent join) from muter to muted user, migrations, and scopes so home, newest, story and comment listings omit muted authors for the signed-in viewer. It exposes mute/unmute actions and a mute list on the settings page, reusing the app's auth and CSRF patterns. It does not reuse HiddenStory for whole users, because that table keys on story_id.
It adds RSpec request or model specs beside existing hide/settings examples: muting hides that user's stories and comments from the muter's feeds, unmute restores them, and the settings mute list shows the muted username. It runs bundle exec rspec, using the project's SQLite setup from the Gemfile unless the suite says otherwise.
Last, it opens a pull request that links the Linear issue, lists migration, model, controller, settings views and specs, and points reviewers at the RSpec transcript.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Muting Users to a Rails App. Let a signed-in user mute another user so their stories and comments are hidden from them everywhere, with a mute list in settings.\" Do the work in this repository, add tests for it, run bundle exec rspec, and open a pull request that links back to the issue.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request on its own branch. The description contrasts story-level HiddenStory with the new user mute, shows where feeds filter muted authors and where settings list mutes. The Linear issue is linked.
The transcript keeps bundle exec rspec (and any migration steps) with full output. A broken scope that hides everyone or nobody fails in that log before merge.
Before merging, a reviewer checks that mutes are per-viewer only, that moderators still see content when required, that unique constraints prevent duplicate mutes and that the new specs fail if the feed scopes skip the mute join.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Lobsters-scale feed scopes touch stories, comments and settings together; a wrong join is only obvious under RSpec with fixtures. In a Rush sandbox the agent runs bundle exec rspec on an isolated database and keeps every failure, so the mute feature is proven without loading a reviewer's local SQLite file.
A Linear label becomes a reviewable social feature PR. Several Rails issues can run in parallel sandboxes under the key's max_concurrent limit, each with its own branch and transcript.
Frequently asked questions
Is this the same as hiding a story?
No. HiddenStory hides one story. Muting hides that author's stories and comments from the muter everywhere until unmute. The agent keeps both features.
Can I mute a moderator?
The agent follows product rules already in the app for blocks or similar. If none exist, the PR states whether staff accounts can be muted and reviewers can tighten it.
Does the muted user get notified?
Not in the basic issue. Mute is private to the muter unless a follow-up asks for notifications.
Where is the mute list?
On the settings page (SettingsController / /settings), listing muted usernames with an unmute control, matching how Lobsters already centralises account preferences.