Skip to content
skillsafebeta
← Report library
Purpose / Data analysis

Flutter Apply Architecture Best Practices Skill Security Audit

What the author says it does (original text)

Architects a Flutter application using the recommended layered approach (UI, Logic, Data). Use when structuring a new project or refactoring for scalability.

Independent security check

Security risks found

Files checked
1
Risks found
1
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

Example cache is not keyed by user ID and can return one user's profile for another request

Source references: 2
What we found

The example Repository stores only one `_cachedUser`. Once that cache is populated, `getUser(id)` returns it immediately without checking whether the cached user's ID matches the requested ID.

Why this matters

If the author or agent adopts this example in an application that queries multiple accounts, a shared Repository instance could show a later requester the previous user's name or any additional profile fields added to the model. It could also cause decisions to be made for the wrong account.

The example directly supports this risk, but only when one `UserRepository` instance is used to query different user IDs: once the cache is populated, the method returns the prior user without comparing the requested `id`. If copied into an app where the repository is shared across account or profile requests, it could display a previously queried user's data. This is instructional sample code, not proof that any app adopted it or exposed data. A user can ask the author to key the cache by ID or verify the cached user's ID before returning it.

SKILL.md:88In the instructionsOpen original file
  final ApiClient _apiClient;  User? _cachedUser;  Future<User> getUser(String id) async {    if (_cachedUser != null) return _cachedUser!;        final apiModel = await _apiClient.fetchUser(id);    _cachedUser = User(id: apiModel.id, name: apiModel.fullName); // Transform to Domain Model    return _cachedUser!;  }
Show 1 other places
SKILL.md:83In the instructionsOpen original file
// 2. Repository (Single source of truth, returns Domain Model)class UserRepository {  UserRepository({required ApiClient apiClient}) : _apiClient = apiClient;    final ApiClient _apiClient;  User? _cachedUser;  Future<User> getUser(String id) async {    if (_cachedUser != null) return _cachedUser!;        final apiModel = await _apiClient.fetchUser(id);    _cachedUser = User(id: apiModel.id, name: apiModel.fullName); // Transform to Domain Model    return _cachedUser!;  }
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

5 instruction sections

This Skill is a Flutter architecture guide. It separates the application into UI, data, and optional domain-logic layers, using ViewModels, Repositories, and Services to isolate presentation state, business logic, and external data access.

View source
SKILL.md:18In the instructionsOpen original file
Enforce strict Separation of Concerns by dividing the application into distinct layers. Never mix UI rendering with business logic or data fetching.
SKILL.md:23In the instructionsOpen original file
*   **Views:** Write reusable, lean widgets. Restrict logic in Views to UI-specific operations (e.g., animations, layout constraints, simple routing). Pass all required data from the ViewModel.*   **ViewModels:** Manage UI state and handle user interactions. Extend `ChangeNotifier` (or use `Listenable`) to expose state. Expose immutable state snapshots to the View. Inject Repositories into ViewModels via the constructor.
SKILL.md:26In the instructionsOpen original file
### Data LayerImplement the Repository pattern to isolate data access logic and create a single source of truth.*   **Services:** Create stateless classes to wrap external APIs (HTTP clients, local databases, platform plugins). Return raw API models or `Result` wrappers.*   **Repositories:** Consume one or more Services. Transform raw API models into clean Domain Models. Handle caching, offline synchronization, and retry logic. Expose Domain Models to ViewModels.

The new-feature workflow directs the agent to create or modify models, services, repositories, ViewModels, views, and dependency-injection registrations, then run unit tests and revise logic in response to failures.

View source
SKILL.md:59In the instructionsOpen original file
### Task Progress- [ ] **Step 1: Define Domain Models.** Create immutable data classes for the feature using `freezed` or `built_value`.- [ ] **Step 2: Implement Services.** Create or update Service classes to handle external API communication.- [ ] **Step 3: Implement Repositories.** Create the Repository to consume Services and return Domain Models.- [ ] **Step 4: Apply Conditional Logic (Domain Layer).**  - *If the feature requires complex data transformation or cross-repository logic:* Create a Use Case class.  - *If the feature is a simple CRUD operation:* Skip to Step 5.- [ ] **Step 5: Implement the ViewModel.** Create the ViewModel extending `ChangeNotifier`. Inject required Repositories/Use Cases. Expose immutable state and command methods.- [ ] **Step 6: Implement the View.** Create the UI widget. Use `ListenableBuilder` or `AnimatedBuilder` to listen to ViewModel changes.- [ ] **Step 7: Inject Dependencies.** Register the new Service, Repository, and ViewModel in the dependency injection container (e.g., `provider` or `get_it`).- [ ] **Step 8: Run Validator.** Execute unit tests for the ViewModel and Repository.
SKILL.md:68In the instructionsOpen original file
- [ ] **Step 7: Inject Dependencies.** Register the new Service, Repository, and ViewModel in the dependency injection container (e.g., `provider` or `get_it`).- [ ] **Step 8: Run Validator.** Execute unit tests for the ViewModel and Repository.  - *Feedback Loop:* Run tests -> Review failures -> Fix logic -> Re-run until passing.
Start here · InstructionsSKILL.md
flutter-apply-architecture-best-practices
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
Lines read
163
File checksum (to compare versions)
0f11f0c6eca2dc20042be4ef17e974bd113eb8be6b5ef1136b0c6e80dee881b8