Use when starting a mobile task that could be Flutter or native - decide from the existing app, platform-specific needs, and the analiz task
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Flutter is the default for cross-platform mobile; native (SwiftUI / Jetpack Compose) is chosen when a task needs deep platform integration or the app is already native. Decide at the start — you cannot half-migrate an app mid-task.
Core principle: The existing app's stack wins by default. Only greenfield apps or the analiz task's direction open the choice.
digraph m {
"App already single-stack?" [shape=diamond];
"Follow the app's stack" [shape=box];
"Needs deep platform integration?" [shape=diamond];
"Native (SwiftUI / Compose)" [shape=box];
"Flutter (default)" [shape=box];
"App already single-stack?" -> "Follow the app's stack" [label="yes"];
"App already single-stack?" -> "Needs deep platform integration?" [label="greenfield"];
"Needs deep platform integration?" -> "Native (SwiftUI / Compose)" [label="yes"];
"Needs deep platform integration?" -> "Flutter (default)" [label="no"];
}
Never introduce a second UI stack into a single-stack app. A Flutter app that "needs one native screen" embeds it via a platform view (PlatformView/AndroidView/UiKitView) or talks to it through a MethodChannel/Pigeon — it does not gain a parallel SwiftUI module on your initiative. Going the other way (a native app needing a Flutter module) is Flutter add-to-app, not a rewrite. Flag genuine cross-stack needs in a task comment for the architect.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
The English summary is being prepared. Showing the original description.
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
The English summary is being prepared. Showing the original description.
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
The English summary is being prepared. Showing the original description.
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
The English summary is being prepared. Showing the original description.
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
The English summary is being prepared. Showing the original description.
Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
The English summary is being prepared. Showing the original description.