What the agent does
The run starts from the repository URL in resources: the agent clones it into its own cloud sandbox and reads the app the way a new Flutter maintainer would. In an app like simplezhli/flutter_deer, pubspec.yaml pins Flutter >=3.19.0, Dart SDK >=3.4.0 <4.0.0, and version 1.3.3+22. Persistence today goes through sp_util 2.0.3, which wraps platform preferences; lib/main.dart awaits SpUtil.getInstance() before runApp, and MyApp sets themeMode: provider.getThemeMode().
Theme support already has a home. lib/setting/provider/theme_provider.dart maps stored strings System, Light and Dark onto ThemeMode, writes them with SpUtil.putString(Constant.theme, …), and builds light and dark ThemeData in getTheme. lib/setting/page/theme_page.dart is the "夜间模式" screen with three rows, and lib/setting/page/setting_page.dart links to it from a ClickItem titled 夜间模式. The issue still asks for a setting with system, light and dark options saved with shared_preferences and applied at startup, so the agent tightens that path rather than inventing a second theme system.
The agent adds the shared_preferences package the issue names, points ThemeProvider at it for the AppTheme key from lib/res/constant.dart, and keeps the same three ThemeMode values so the existing ThemePage labels keep working. Startup in main.dart still reads the provider before the first frame, so a choice survives process death. Chinese copy on the settings rows can stay; the behaviour is what the issue measures.
Proving it means widget tests next to the ones under test/setting/. setting_accessibility_test.dart already pumps ThemePage inside MyApp for tap-target and contrast guidelines. The agent adds a test that selects Dark, rebuilds from a fresh SharedPreferences load, and asserts themeMode is ThemeMode.dark, plus a case for System. Then it runs flutter analyze and flutter test.
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 a Dark Theme Setting to a Flutter App. Add a theme setting with system, light and dark options on the settings screen, saved with shared_preferences and applied at startup.\" Do the work in this repository, add tests for it, run flutter analyze and flutter test, 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. Its diff updates pubspec.yaml for shared_preferences, adjusts theme_provider.dart and startup wiring in main.dart as needed, and adds a widget test under test/setting/. The description quotes the issue and links back to it.
The checks on the pull request run flutter analyze and flutter test. A reviewer reads the diff for three things: system, light and dark are all selectable, the choice is read back after a simulated restart, and ThemePage remains reachable from SettingPage. Unrelated shop, order and goods screens stay untouched.
The session read keeps the record behind the pull request: pub get, analyze and the test output. Anyone who questions a themeMode assertion can open the trajectory and see the exact flutter test command.
Run it on every Linear issue labelled agent
The Project's automation turns the label into the run. In the console, add an automation with a Linear trigger on linear.issue.labeled filtered to the agent label and this prompt; each labelled Flutter UX issue starts its own run in its own sandbox and opens its own pull request.
If the automation is not wanted, a small server can do the same: receive Linear's issue webhook, put the issue text into input, and POST to /o/{org}/sessions with the Flutter repository in resources. A run.completed webhook on the API key posts the pull request when analyze and tests have finished.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
On a laptop this job needs a Flutter SDK that matches pubspec.yaml, platform toolchains for the targets you care about, and a clean flutter pub get before tests will resolve Provider and SpUtil. Each run on Rush boots its own sandbox with that already in reach, runs analyze and the widget tests itself, and keeps every command and its output.
Theme and settings tickets often arrive in bunches during a release polish. Labelling them starts one sandbox per issue, so dark theme, locale and cache-clear work do not serialize on a single developer machine.
Frequently asked questions
Flutter Deer already has a night mode screen. What is left to do?
The screen and ThemeProvider exist and persist through sp_util. The issue names shared_preferences and asks for tests that prove system, light and dark survive startup. The agent aligns storage with that package and adds those tests without replacing the settings UI.
Does the agent rewrite every dark color token?
No. getTheme already switches Colours.dark_* values for dark mode. The change is about selection, persistence and tests, not a redesign of lib/res/.
Which Flutter version does the sandbox use?
One that satisfies flutter: ">=3.19.0" and the Dart SDK bound in pubspec.yaml. The agent reads those constraints before running analyze.
Are integration_test driver scripts required?
Not for this issue. Widget tests under test/setting/ are enough to prove themeMode persistence; test_driver/setting/ stays as it is unless the issue asks for a driver run.