Security audit
Security checks for vulnerabilities and agentic risk
This Flutter skill is a coherent documentation-style helper with disclosed preference storage and no hidden execution or exfiltration behavior.
Install only if you want Flutter-specific coding guidance. Be aware that it may remember stated Flutter preferences in its scoped config file and may suggest project-mutating maintenance commands, but the artifact tells the agent to confirm destructive actions by default.
Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.
- The `use_build_context_synchronously` lint catches `context` after a gap. It does NOT catch a controller write, an animation start, or a `ScaffoldMessenger` call — those need the same guard with no warning.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
flutter clean # DESTRUCTIVE: deletes build/, forces a full rebuild
rm ios/Podfile.lock # DESTRUCTIVE: re-resolves every pod
rm pubspec.lock # DESTRUCTIVE: re-resolves every package (dependencies.md)
The manifest describes a Flutter-focused skill for widgets, layout, state management, navigation, performance, testing, and store release issues. This file instead defines a full data-layer guide covering HTTP clients, token refresh, secure storage, databases, caching, offline queues, file downloads/uploads, and certificate pinning, which materially exceeds the manifest's described operational scope.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- Every permission has three states worth distinguishing: not yet asked, denied (can ask again), permanently denied (must send the user to Settings). Code that only checks granted-or-not leaves users stuck with no path forward.
- Ask in context, right before the feature needs it, with a preceding explanation screen when the reason is not obvious. A permission requested at launch is the most-denied permission.
- iOS requires a purpose string in `Info.plist` for every permission; a missing one is an immediate crash on first use, not a denial — and App Review rejects vague strings.
- Android splits permissions by API level (notifications became a runtime permission on Android 13, storage access was reworked into scoped storage). Test on both an old and a current OS version.
- Permissions can be revoked while the app is backgrounded: re-check on resume, do not cache the granted state across sessions (`state.md`).
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- Every permission has three states worth distinguishing: not yet asked, denied (can ask again), permanently denied (must send the user to Settings). Code that only checks granted-or-not leaves users stuck with no path forward.
- Ask in context, right before the feature needs it, with a preceding explanation screen when the reason is not obvious. A permission requested at launch is the most-denied permission.
- iOS requires a purpose string in `Info.plist` for every permission; a missing one is an immediate crash on first use, not a denial — and App Review rejects vague strings.
- Android splits permissions by API level (notifications became a runtime permission on Android 13, storage access was reworked into scoped storage). Test on both an old and a current OS version.
- Permissions can be revoked while the app is backgrounded: re-check on resume, do not cache the granted state across sessions (`state.md`).
The manifest emphasizes Flutter app construction and debugging concerns such as widgets, rendering, rebuilds, routing, tests, and release packaging. Guidance on certificate pinning, secret extraction risks, and request-body logging controls introduces security architecture capabilities that are not clearly necessary from the declared purpose alone.
Line L27 states that an in-app language switch means storing the choice and explicitly passing a locale, which assumes language handling but does not explicitly frame user language selection as opt-in or user-controlled policy. Because SQP-3 covers language or locale policy violations, this is a mild concern where the guidance could be interpreted as enforcing locale behavior without an explicit user-choice statement.
No suspicious patterns detected.