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

flutter-media

Skill16 starsChanged 3 months agoBSD-3-ClauseView on GitHub

Implement Flutter camera capture, audio/video recording and playback, livestreams, calls, and screen sharing. Use for media resources, tracks, permissions, and interruptions; route text-only realtime transport to flutter-networking and native bridges to flutter-platform-integration.

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    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. Very specific:

    Read pubspec.yaml, the lockfile, SDK constraints, current adapters/controllers, native configuration, and tests.

    line 12
  2. Distinctive:

    Use the current SDK's supported facilities before adding another player, audio-session owner, signaling stack, or provider.

    line 18
  3. Distinctive:

    Read verification before claiming capture, playback, live delivery, or target compatibility.

    line 28
  4. Distinctive:

    Document parsing/PDF editing, generic file management/sharing, and text-only chat are outside this skill.

    line 46

≈ “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 Media

Deliver media behavior that respects the user's intent, the resolved player or capture SDK, and each target's lifecycle. Preserve existing packages and architecture. Installing this skill requires no provider account, server key, room, stream URL, or camera/microphone access.

Establish the media contract

Read pubspec.yaml, the lockfile, SDK constraints, current adapters/controllers, native configuration, and tests. Establish:

  • Capture, recorded-file playback, live viewing, broadcasting, or interactive calling; an image-buffer stream is not an encoded broadcast.
  • Source and output, format/codec, target platforms, permissions, foreground/background requirements, and intended behavior on interruption or exit.
  • For live sessions, service ownership, participant identity, host/viewer permissions, and what proves actual remote media delivery.

Use the current SDK's supported facilities before adding another player, audio-session owner, signaling stack, or provider. Inspect version-specific native/browser requirements instead of copying setup or API names from a newer release. Keep secrets in the authorized service boundary, not in Flutter or logs.

Read the relevant mode

  • Capture and recording: camera, microphone, media picking, transforms, encoded outputs, and recovery.
  • Playback and streaming: audio/video controllers, source switching, buffering, HLS/live viewing, and browser constraints.
  • Audio interruptions and routing: focus, session activation, user pause intent, calls, and output-device changes.
  • Live broadcasting: preview, going live, host/viewer authority, delivery stages, and ending a broadcast.
  • Realtime calls and screen sharing: participants/tracks, reconnect, device selection, capture consent, and screen-share setup.

Read verification before claiming capture, playback, live delivery, or target compatibility. Read several mode references only when the task crosses their boundaries.

Keep ownership explicit

Give each controller, track, subscription, renderer, temporary file, and session one lifecycle owner. Invalidate abandoned asynchronous work; release resources returned by stale successful initialization instead of only ignoring its UI update. Handle cleanup failures explicitly and follow SDK-specific ordering for exclusive hardware acquisition. Do not reopen capture or resume audio merely because the app or connection resumes.

Model permission denial, initialization, ready/live, interruption/reconnection, terminal error, user stop, and disposal as distinct outcomes where relevant. Keep permission prompts and media effects outside widget build. Stop only resources this feature owns; protect user-authored and retained recordings from disposable-test cleanup.

Close the evidence loop

For an implementation or a tool-free plan, explicitly identify the resolved package/Flutter/native contract checks and existing SDK responsibilities before adding lifecycle, focus, or recovery handlers. A package being present does not establish who already owns those effects. At the affected boundary, state the stop/leave cleanup and the focused acceptance checks, including the native or two-endpoint scenario still needed. Label unavailable inspection and execution as pending; do not substitute a list of fake tests for the media behavior they cannot prove.

Neighbor boundaries

  • Networking owns ordinary HTTP/WebSocket/SSE messages and upload transport; this skill owns audio/video capture, playback, and media sessions.
  • Platform integration owns custom native bridges/plugins; background execution owns OS continuation/scheduling when required. Pair them only when that boundary changes.
  • Authentication/security own identity lifecycle and wider threat audits. Media integration still respects service-enforced publish permissions and confidential credentials.
  • Device testing operates concrete targets; performance owns measured jank/latency/memory diagnosis. UI design owns visual art direction.
  • Document parsing/PDF editing, generic file management/sharing, and text-only chat are outside this skill. Media capture does not authorize uploading or publishing its output.

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.