| name | flutter-explain-codebase |
| description | Explains a Flutter project codebase in a structured, developer-friendly way, including architecture, state management, data flow, navigation, dependencies, risks, and prioritized next actions. |
| license | MIT |
| metadata | {"version":"0.1.0","owner":"mdazadhossain95"} |
Explain Flutter Codebase
Purpose
Use this skill to analyze and explain an existing Flutter codebase quickly and clearly for onboarding, handoff, debugging, and planning refactors.
Activation
Activate when the user asks to explain a Flutter app, module, architecture, folder structure, or how parts of the codebase work together.
Inputs
Collect minimal context before analysis:
- Scope: whole project, feature folder, or specific files.
- Goal: onboarding, debugging, architecture review, refactor planning, performance review.
- Depth: quick, standard, or deep explanation.
If user gives no scope, default to project-level explanation.
Analysis Workflow
Follow this order:
- Project map
- Identify main folders and responsibilities.
- Summarize app entry points and bootstrapping.
- Architecture
- Determine architecture style (layered, feature-first, mixed).
- Map core boundaries: presentation, domain/logic, data, shared/core.
- State management
- Identify state solution(s): Riverpod, Bloc/Cubit, GetX, Provider, setState, others.
- Explain where each is used and why.
- Flag inconsistent or mixed usage hotspots.
- Navigation and app flow
- Explain routing setup and screen transitions.
- Summarize primary user journey paths.
- Data flow and integrations
- Trace data path from UI event to repository/service and back.
- Explain API clients, DTO/model mapping, caching, and persistence.
- Note authentication and push integration points if present.
- Dependencies and cross-cutting concerns
- Highlight important packages and what each is used for.
- Explain logging, error handling, dependency injection, config/env handling.
- Quality and risks
- Identify likely tech debt areas, coupling, duplication, and test gaps.
- Identify potential runtime-risk points (null handling, async race, network assumptions).
- Actionable next steps
- Provide prioritized recommendations (high impact first).
- Include low-risk quick wins and medium-term refactors.
Output Format
Return explanation in this structure:
- Codebase Overview
- Folder/Module Map
- Architecture Summary
- State Management Summary
- Navigation and User Flow
- Data and Integration Flow
- Dependency Notes
- Risks and Gaps
- Recommended Next Steps
Keep it practical and concrete. Reference real files/symbols when available.
Behavior Rules
- Prefer facts from code over assumptions.
- If evidence is missing, state assumptions explicitly.
- Avoid generic advice without tying it to observed structure.
- For deep explanations, include call-path examples.
- For quick mode, keep to high-signal architecture and flow.
Optional Modes
- Quick mode: high-level map + top 5 findings.
- Standard mode: full structure above.
- Deep mode: include feature-by-feature walkthrough and targeted refactor plan.
Validation Checklist
Before final response, verify:
- Scope is clear.
- Architecture and state management are identified.
- Data and navigation flow are explained.
- Risks are concrete and actionable.
- Next steps are prioritized.
