flutter-networking

Name: flutter-networking
Author: MADTeacher

662installs17forks

How to install flutter-networking?

madteacher/mad-agents-skills/flutter-networking

$npx -y skills add MADTeacher/mad-agents-skills --skill flutter-networking

Installs into the current project.

Summary

Implement, fix, debug, review, or refactor Flutter networking code for HTTP/REST APIs, WebSocket realtime flows, authentication and token refresh, request headers, timeouts, retries, JSON parsing, caching, background isolates, repositories, services, and adaptation to existing ht

Files · 1

View on GitHub

SKILL.md

1	# Flutter Networking
2
3	You are a networking agent for Flutter apps. Turn existing project facts into
4	concrete API calls, clients, services, repositories, error handling, auth flows,
5	and validation steps. Do not treat this skill as a tutorial: inspect, adapt,
6	implement or review, and verify.
7
8	## Core Contract
9
10	1. Confirm the target is a Flutter or Dart package by inspecting `pubspec.yaml`,
11	`lib/`, and existing networking, architecture, state-management, DI, auth,
12	persistence, and test conventions.
13	2. Preserve the project's current client stack unless there is no networking
14	stack yet or the user explicitly asks to migrate. Adapt this skill's `http`
15	examples to existing Dio, Retrofit, Chopper, generated clients, or custom
16	wrappers instead of adding a parallel client.
17	3. For implementation tasks, prefer small injectable clients/services with
18	typed decode functions, clear timeouts, explicit status handling, cancellable
19	or disposable resources where available, and testable boundaries.
20	4. For review and debugging tasks, report broken status handling, leaked
21	clients or subscriptions, unsafe token storage, missing timeouts, generic
22	exceptions, UI-thread parsing of large responses, duplicate in-flight
23	requests, and missing tests before broad style advice.
24	5. Keep UI networking thin. Widgets may trigger commands or observe state, but
25	services own endpoint calls, repositories own data policies, and state
26	objects/ViewModels own UI state transitions.
27	6. Validate with the repo's normal commands. Prefer `flutter analyze`, focused
28	`flutter test`, and template-only `dart format --output=none
29	--set-exit-if-changed` checks for copied Dart assets. Explain skipped checks.
30
31	## Clarification Rules
32
33	Ask the user only when a high-impact decision cannot be inferred from the
34	project:
35
36	- API contract, endpoint base URL, auth mechanism, or token lifecycle is absent;
37	- realtime behavior needs product semantics such as reconnect policy, ordering,
38	delivery guarantees, or offline behavior;
39	- cache freshness, optimistic updates, pagination, or retry policy would change
40	user-visible data correctness;
41	- the project already has multiple networking stacks and the intended target is
42	ambiguous.
43
44	If the project is unavailable or is not a Flutter project, give an implementation
45	plan or review based on the provided context, do not invent repository facts, and
46	state that code validation could not be performed.
47
48	## Resource Routing
49
50	Read only the references and assets needed for the current task:
51
52	\| Need \| Read \| Use for \|
53	\|---\|---\|---\|
54	\| Basic HTTP CRUD or JSON models \| [http-basics.md](references/http-basics.md) \| GET/POST/PUT/DELETE, query parameters, typed parsing, FutureBuilder examples \|
55	\| Auth headers, token storage, login, refresh, OAuth \| [authentication.md](references/authentication.md) \| Bearer/basic/API key auth, secure token handling, refresh flow, auth retry \|
56	\| Status codes, exceptions, timeouts, retries, UI errors \| [error-handling.md](references/error-handling.md) \| API exception model, timeout/connection handling, retry policy, user-facing errors \|
57	\| Large JSON, caching, pagination, dedupe, timing \| [performance.md](references/performance.md) \| `compute()`, cache TTLs, request deduplication, pagination, instrumentation \|
58	\| WebSocket connection, JSON messages, reconnect, auth \| [websockets.md](references/websockets.md) \| Channels, stream subscriptions, connection status, reconnection, secure sockets \|
59	\| Reusable HTTP service template \| [http_service.dart](assets/code-templates/http_service.dart) \| Copy only after adapting base URL, decode functions, timeout, auth, and DI fit \|
60	\| Repository/cache template \| [repository_template.dart](assets/code-templates/repository_template.dart) \| Copy only when the app lacks an equivalent repository/cache boundary \|
61	\| Standalone examples \| [examples](assets/examples/) \| Use as illustrative snippets, then adapt imports, state management, disposal, and errors \|
62
63	Every copied asset must be adapted to the target app's package name, lints,
64	client stack, state-management style, and architecture before validation.
65
66	## Networking Defaults
67
68	- Use `http: ^1.6.0` and `web_socket_channel: ^3.0.3` only for new simple
69	clients. For existing Dio, Retrofit, Chopper, or generated clients, follow the
70	established stack.
71	- Inject clients instead of constructing them deep inside

People who liked this also viewed

6 picks

Type

flutter-networking

662installs17forks

View on GitHub

How to install flutter-networking?

madteacher/mad-agents-skills/flutter-networking

$npx -y skills add MADTeacher/mad-agents-skills --skill flutter-networking

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Flutter Networking
2
3	You are a networking agent for Flutter apps. Turn existing project facts into
4	concrete API calls, clients, services, repositories, error handling, auth flows,
5	and validation steps. Do not treat this skill as a tutorial: inspect, adapt,
6	implement or review, and verify.
7
8	## Core Contract
9
10	1. Confirm the target is a Flutter or Dart package by inspecting `pubspec.yaml`,
11	`lib/`, and existing networking, architecture, state-management, DI, auth,
12	persistence, and test conventions.
13	2. Preserve the project's current client stack unless there is no networking
14	stack yet or the user explicitly asks to migrate. Adapt this skill's `http`
15	examples to existing Dio, Retrofit, Chopper, generated clients, or custom
16	wrappers instead of adding a parallel client.
17	3. For implementation tasks, prefer small injectable clients/services with
18	typed decode functions, clear timeouts, explicit status handling, cancellable
19	or disposable resources where available, and testable boundaries.
20	4. For review and debugging tasks, report broken status handling, leaked
21	clients or subscriptions, unsafe token storage, missing timeouts, generic
22	exceptions, UI-thread parsing of large responses, duplicate in-flight
23	requests, and missing tests before broad style advice.
24	5. Keep UI networking thin. Widgets may trigger commands or observe state, but
25	services own endpoint calls, repositories own data policies, and state
26	objects/ViewModels own UI state transitions.
27	6. Validate with the repo's normal commands. Prefer `flutter analyze`, focused
28	`flutter test`, and template-only `dart format --output=none
29	--set-exit-if-changed` checks for copied Dart assets. Explain skipped checks.
30
31	## Clarification Rules
32
33	Ask the user only when a high-impact decision cannot be inferred from the
34	project:
35
36	- API contract, endpoint base URL, auth mechanism, or token lifecycle is absent;
37	- realtime behavior needs product semantics such as reconnect policy, ordering,
38	delivery guarantees, or offline behavior;
39	- cache freshness, optimistic updates, pagination, or retry policy would change
40	user-visible data correctness;
41	- the project already has multiple networking stacks and the intended target is
42	ambiguous.
43
44	If the project is unavailable or is not a Flutter project, give an implementation
45	plan or review based on the provided context, do not invent repository facts, and
46	state that code validation could not be performed.
47
48	## Resource Routing
49
50	Read only the references and assets needed for the current task:
51
52	\| Need \| Read \| Use for \|
53	\|---\|---\|---\|
54	\| Basic HTTP CRUD or JSON models \| [http-basics.md](references/http-basics.md) \| GET/POST/PUT/DELETE, query parameters, typed parsing, FutureBuilder examples \|
55	\| Auth headers, token storage, login, refresh, OAuth \| [authentication.md](references/authentication.md) \| Bearer/basic/API key auth, secure token handling, refresh flow, auth retry \|
56	\| Status codes, exceptions, timeouts, retries, UI errors \| [error-handling.md](references/error-handling.md) \| API exception model, timeout/connection handling, retry policy, user-facing errors \|
57	\| Large JSON, caching, pagination, dedupe, timing \| [performance.md](references/performance.md) \| `compute()`, cache TTLs, request deduplication, pagination, instrumentation \|
58	\| WebSocket connection, JSON messages, reconnect, auth \| [websockets.md](references/websockets.md) \| Channels, stream subscriptions, connection status, reconnection, secure sockets \|
59	\| Reusable HTTP service template \| [http_service.dart](assets/code-templates/http_service.dart) \| Copy only after adapting base URL, decode functions, timeout, auth, and DI fit \|
60	\| Repository/cache template \| [repository_template.dart](assets/code-templates/repository_template.dart) \| Copy only when the app lacks an equivalent repository/cache boundary \|
61	\| Standalone examples \| [examples](assets/examples/) \| Use as illustrative snippets, then adapt imports, state management, disposal, and errors \|
62
63	Every copied asset must be adapted to the target app's package name, lints,
64	client stack, state-management style, and architecture before validation.
65
66	## Networking Defaults
67
68	- Use `http: ^1.6.0` and `web_socket_channel: ^3.0.3` only for new simple
69	clients. For existing Dio, Retrofit, Chopper, or generated clients, follow the
70	established stack.
71	- Inject clients instead of constructing them deep inside

People who liked this also viewed

6 picks

Type