lg-file-generator
Generates structured Flutter code templates for services, screens, and models following clean architecture.
Install
mkdir -p .claude/skills/lg-file-generator && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13874" && unzip -o skill.zip -d .claude/skills/lg-file-generator && rm skill.zipInstalls to .claude/skills/lg-file-generator
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Generates well-structured Dart/Flutter files from templates. Creates screens, services, models, widgets, and test files following LG architecture patterns and SOLID principles.Key capabilities
- →Generate Dart/Flutter screen files
- →Generate Dart/Flutter service files
- →Generate Dart/Flutter data model files
- →Generate Dart/Flutter reusable widget files
- →Generate Dart/Flutter unit test files
- →Generate feature module directories
How it works
The skill generates Dart/Flutter source files from templates, ensuring consistent code structure, imports, documentation, and adherence to architecture patterns.
Inputs & outputs
When to use lg-file-generator
- →Create a new screen widget
- →Generate a new service class
- →Scaffold architecture-compliant flutter files
About this skill
Liquid Galaxy Dart File Generator
Overview
This skill generates Dart/Flutter source files that follow the established Liquid Galaxy architecture patterns. It ensures consistent code structure, proper imports, documentation, and adherence to SOLID/DRY principles across all generated files.
Announce at start: "I'm using the lg-file-generator skill to create [File Type]: [Name]."
File Types & Templates
1. Screen (StatefulWidget)
Path pattern: lib/screens/<feature>_screen.dart
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
/// [FeatureName] Screen
///
/// ARCHITECTURE: This screen follows the Controller pattern.
/// It reads state from Provider services and renders the phone UI.
/// No SSH, KML, or API logic should live here — delegate to services.
class FeatureNameScreen extends StatefulWidget {
const FeatureNameScreen({super.key});
@override
State<FeatureNameScreen> createState() => _FeatureNameScreenState();
}
class _FeatureNameScreenState extends State<FeatureNameScreen> {
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Feature Name'),
),
body: const Center(
child: Text('Feature Name Screen'),
),
);
}
}
2. Service (ChangeNotifier)
Path pattern: lib/services/<service_name>_service.dart
import 'package:flutter/foundation.dart';
/// [ServiceName] Service
///
/// ARCHITECTURE: Follows the Service-Repository pattern.
/// Holds state, manages SSH/API communication, and notifies listeners.
/// Registered as a Provider in main.dart.
class ServiceNameService with ChangeNotifier {
bool _isLoading = false;
bool get isLoading => _isLoading;
String? _error;
String? get error => _error;
// TODO: Add service-specific state fields
Future<void> initialize() async {
_isLoading = true;
_error = null;
notifyListeners();
try {
// TODO: Initialization logic
} catch (e) {
_error = e.toString();
} finally {
_isLoading = false;
notifyListeners();
}
}
@override
void dispose() {
// TODO: Cleanup resources (close SSH connections, cancel timers)
super.dispose();
}
}
3. Data Model
Path pattern: lib/models/<model_name>.dart
/// [ModelName] Model
///
/// Represents a [description] entity.
/// Includes JSON serialization for API integration
/// and KML conversion for Liquid Galaxy visualization.
class ModelName {
final String id;
final String name;
// TODO: Add model-specific fields (latitude, longitude, etc.)
const ModelName({
required this.id,
required this.name,
});
/// Create from JSON (API response)
factory ModelName.fromJson(Map<String, dynamic> json) {
return ModelName(
id: json['id']?.toString() ?? '',
name: json['name']?.toString() ?? '',
);
}
/// Convert to JSON
Map<String, dynamic> toJson() => {
'id': id,
'name': name,
};
/// Convert to KML-compatible map for lg-kml-writer
Map<String, dynamic> toKmlMap() => {
'name': name,
// 'latitude': latitude,
// 'longitude': longitude,
// 'description': description,
};
@override
String toString() => 'ModelName(id: $id, name: $name)';
}
4. Reusable Widget
Path pattern: lib/widgets/<widget_name>.dart
import 'package:flutter/material.dart';
/// [WidgetName] Widget
///
/// A reusable UI component for [purpose].
/// Follows the composition-over-inheritance principle.
class WidgetName extends StatelessWidget {
final String title;
// TODO: Add widget parameters
const WidgetName({
super.key,
required this.title,
});
@override
Widget build(BuildContext context) {
return Container(
padding: const EdgeInsets.all(16),
child: Text(title),
);
}
}
5. Unit Test
Path pattern: test/<feature>_test.dart
import 'package:flutter_test/flutter_test.dart';
void main() {
group('FeatureName', () {
test('should do X when Y', () {
// Arrange
// Act
// Assert
expect(true, isTrue);
});
test('should handle error gracefully', () {
// Arrange
// Act
// Assert
});
});
}
6. Feature Module
Path pattern: lib/modules/<module_name>/
A module is a self-contained feature directory:
lib/modules/<module_name>/
├── screens/
│ └── <module>_screen.dart
├── services/
│ └── <module>_service.dart
├── models/
│ └── <module>_model.dart
├── widgets/
│ └── <module>_widget.dart
└── README.md (brief feature docs)
Generation Rules
- Naming: Use
snake_casefor files,PascalCasefor classes,camelCasefor variables. - Imports: Always use relative imports within the package. Group imports: dart, package, local.
- Documentation: Every public class and method gets a
///doc comment. - Architecture comment: Every file gets an
ARCHITECTURE:comment explaining its role. - const constructors: Use
constwherever possible for widget constructors. - Null safety: All generated code must be null-safe. No
!operator without justification. - Tests: For every service or model generated, also generate a corresponding test file.
Post-Generation Checklist
- File created in correct directory
- Imports are correct and complete
- Class name matches file name convention
- Doc comments present on all public members
-
flutter analyzepasses with zero issues - Corresponding test file created (for services/models)
- Provider registered in
main.dart(for services)
⛔️ Student Interaction — MANDATORY
After generating each file, STOP and explain to the student:
- What was generated and why each section exists.
- How the file fits into the LG architecture (which layer, which pattern).
- Ask: "Can you explain what this file does in your own words?"
- If the student cannot explain, link to lg-learning-resources (.agent/skills/lg-learning-resources/SKILL.md) for the relevant topic.
DO NOT auto-generate the next file until the student confirms understanding.
Reference Links
- Lucia's LG Master App (architecture reference): https://github.com/LiquidGalaxyLAB/LG-Master-Web-App
- Dart effective style: https://dart.dev/effective-dart/style
- Flutter widget catalog: https://docs.flutter.dev/ui/widgets
- For deeper study → lg-learning-resources (.agent/skills/lg-learning-resources/SKILL.md)
Handoff
After file generation, return to the calling workflow or use lg-exec (.agent/skills/lg-exec/SKILL.md) for implementation.
🔗 Skill Chain
After the file is generated and the student can explain its role in the architecture, automatically offer the next stage:
"File generated and wired into the project! Now let's execute the implementation plan and build out the feature. Ready to start coding? 🚀"
If student says "ready" → activate .agent/skills/lg-exec/SKILL.md.
When not to use it
- →When the user does not understand the generated file's role
Limitations
- →The skill requires the student to confirm understanding of the generated file before proceeding.
- →The skill generates files following specific Liquid Galaxy architecture patterns.
- →The skill requires every public class and method to have a `///` doc comment.
How it compares
This skill automates the creation of architecture-compliant Dart/Flutter files with proper documentation and imports, unlike manually creating each file and ensuring adherence to standards.
Compared to similar skills
lg-file-generator side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| lg-file-generator (this skill) | 0 | 5mo | Review | Intermediate |
| flutter-development | 1,555 | 5mo | No flags | Intermediate |
| flutter-expert | 73 | 4mo | No flags | Advanced |
| flutter | 13 | 4mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by AshishYesale7
View all by AshishYesale7 →You might also like
flutter-development
aj-geddes
Build beautiful cross-platform mobile apps with Flutter and Dart. Covers widgets, state management with Provider/BLoC, navigation, API integration, and material design.
flutter-expert
sickn33
Master Flutter development with Dart 3, advanced widgets, and multi-platform deployment. Handles state management, animations, testing, and performance optimization for mobile, web, desktop, and embedded platforms. Use PROACTIVELY for Flutter architecture, UI implementation, or cross-platform features.
flutter
alinaqi
Flutter development with Riverpod state management, Freezed, go_router, and mocktail testing
mobile-developer
sickn33
Develop React Native, Flutter, or native mobile apps with modern architecture patterns. Masters cross-platform development, native integrations, offline sync, and app store optimization. Use PROACTIVELY for mobile features, cross-platform code, or app optimization.
stac-quickstart
StacDev
Help initialize and validate a Stac-enabled Flutter project and ship a first server-driven screen. Use when users ask to set up Stac CLI, run stac init/build/deploy, verify project prerequisites, or troubleshoot first-run setup and missing configuration files.
webf-native-plugins
openwebf
Install WebF native plugins to access platform capabilities like sharing, payment, camera, geolocation, and more. Use when building features that require native device APIs beyond standard web APIs.