agentleFS
thienqothienqo/flutter-skills/skills/flutter-authentication/SKILL.md

flutter-authentication

Skill16 starsChanged 2 months agoBSD-3-ClauseView on GitHub

Implement, repair, or review Flutter user authentication and session lifecycle, including OAuth or OIDC redirects, PKCE, token refresh, logout, account switching, passkeys, and device re-authentication. Use when sign-in identity or session behavior is the task; route broad threat audits to flutter-security and request transport to flutter-networking.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Treat authentication as a protocol and account-state lifecycle spanning the identity provider, trusted backend, platform redirect surface, …

    line 8
  2. Distinctive:

    Do not add an SDK, client registration, redirect association, secret placeholder, account, or backend merely because the skill is selected.

    line 10
  3. Very specific:

    Read pubspec.yaml, SDK constraints, sign-in entrypoints, provider and backend contract, registered clients and redirects, deep-link …

    line 14
  4. Distinctive:

    Read OAuth, OIDC, and redirects for browser authorization, PKCE, state, nonce, callback ownership, deep links, and provider errors.

    line 20
  5. Distinctive:

    Read sessions and account state for token ownership, coordinated refresh, expiry, logout, revocation, account switching, startup …

    line 21
  6. Distinctive:

    Read passkeys and device re-authentication for relying-party challenges, platform associations, passkey lifecycle, biometrics, and local …

    line 22

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Flutter Authentication

Treat authentication as a protocol and account-state lifecycle spanning the identity provider, trusted backend, platform redirect surface, local session owner, and application UI. Preserve the project's provider, backend, SDK, router, storage, and state management unless migration is requested.

Do not add an SDK, client registration, redirect association, secret placeholder, account, or backend merely because the skill is selected.

Preflight

Read pubspec.yaml, SDK constraints, sign-in entrypoints, provider and backend contract, registered clients and redirects, deep-link handling, token and account storage, refresh coordination, navigation guards, logout behavior, flavors, platform associations, and tests. Distinguish authentication, session state, authorization, and device-local re-authentication.

Native and web Flutter clients are public clients and cannot keep a reusable client secret. For OAuth or OIDC, use the established authorization-code flow with PKCE and an external user-agent where the provider supports it. Validate redirect ownership and correlate the response using state and, for OIDC, nonce as applicable. Never trust a redirect merely because its scheme matches.

Load references conditionally

  • Read OAuth, OIDC, and redirects for browser authorization, PKCE, state, nonce, callback ownership, deep links, and provider errors.
  • Read sessions and account state for token ownership, coordinated refresh, expiry, logout, revocation, account switching, startup restoration, and offline behavior.
  • Read passkeys and device re-authentication for relying-party challenges, platform associations, passkey lifecycle, biometrics, and local authorization gates.

Boundaries

  • flutter-security owns threat modeling and broad hardening; this skill implements correct identity and session behavior.
  • flutter-networking owns HTTP mechanics, interceptors, and generic retry; this skill defines authentication refresh and account semantics.
  • flutter-navigation owns route and back-stack correctness; this skill defines authenticated, unauthenticated, callback, and re-authentication states.
  • flutter-persistence owns storage mechanics; this skill defines credential sensitivity, account isolation, expiry, and deletion lifecycle.
  • flutter-platform-integration owns custom native credential APIs or redirect mechanics when an existing plugin cannot satisfy them.

Verification

Use a fake identity adapter for deterministic state transitions and an authorized non-production provider for end-to-end proof. Cover success, cancellation, denial, malformed or replayed callback, state and nonce mismatch, expired access token, concurrent refresh, refresh failure, revoked session, offline startup, logout, account switch, process restart, and platform link ownership.

For passkeys or device credentials, exercise real supported devices and cancellation or lockout behavior. State which provider, client type, platform, account state, redirect, storage, and backend checks were actually observed. A successful login screen or locally decoded token does not prove callback integrity, server authorization, refresh safety, revocation, or logout cleanup.

Sources

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.