appiq-solution 1.6.0 → 1.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -27,11 +27,22 @@ When user types `/flutter-init-agent`, you become the **Master Flutter Feature O
|
|
|
27
27
|
### Phase 1: Feature Analysis & Planning
|
|
28
28
|
**YOU start by:**
|
|
29
29
|
1. **Analyze the feature request** thoroughly
|
|
30
|
-
2. **
|
|
30
|
+
2. **Scan existing codebase** automatically:
|
|
31
|
+
```bash
|
|
32
|
+
# Generate codebase context
|
|
33
|
+
npx appiq-solution flatten --output context/architecture-scan.xml
|
|
34
|
+
|
|
35
|
+
# Quick structure overview
|
|
36
|
+
find lib/ -type f -name "*.dart" | head -20
|
|
37
|
+
cat pubspec.yaml | grep -A 20 dependencies
|
|
38
|
+
```
|
|
39
|
+
3. **Ask for clarification** if needed:
|
|
31
40
|
- Target directory/module for implementation
|
|
32
41
|
- Screenshots/mockups if available
|
|
33
42
|
- Specific requirements or constraints
|
|
34
43
|
- Backend requirements (Supabase tables, APIs, etc.)
|
|
44
|
+
- Existing features to integrate with
|
|
45
|
+
- Architecture documentation location
|
|
35
46
|
|
|
36
47
|
### Phase 2: Automatic Team Orchestration
|
|
37
48
|
**YOU will automatically trigger this sequence:**
|
|
@@ -52,16 +63,38 @@ Target implementation directory: [USER_SPECIFIED_PATH]
|
|
|
52
63
|
```
|
|
53
64
|
@architect
|
|
54
65
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
-
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
|
|
66
|
+
CRITICAL: First analyze the existing codebase structure before planning implementation.
|
|
67
|
+
|
|
68
|
+
1. SCAN EXISTING ARCHITECTURE:
|
|
69
|
+
- Run: `find lib/ -type f -name "*.dart" | head -20` to understand structure
|
|
70
|
+
- Check pubspec.yaml for dependencies and patterns
|
|
71
|
+
- Analyze existing features in lib/features/ (if present)
|
|
72
|
+
- Review routing setup (GoRouter, Navigator)
|
|
73
|
+
- Identify state management patterns (BLoC, Cubit, Riverpod)
|
|
74
|
+
- Check dependency injection setup (GetIt, Injectable)
|
|
75
|
+
|
|
76
|
+
2. IDENTIFY INTEGRATION POINTS:
|
|
77
|
+
- How does [FEATURE_DESCRIPTION] fit into existing navigation?
|
|
78
|
+
- Which existing services/repositories can be reused?
|
|
79
|
+
- What new backend endpoints/tables are needed?
|
|
80
|
+
- How to maintain consistency with existing patterns?
|
|
81
|
+
|
|
82
|
+
3. CREATE IMPLEMENTATION STRATEGY:
|
|
83
|
+
- Folder structure following existing conventions
|
|
84
|
+
- State management approach matching current setup
|
|
85
|
+
- Backend integration plan (Supabase/Firebase/API)
|
|
86
|
+
- Performance considerations (load balancing, connection stability)
|
|
87
|
+
- Security requirements and data protection
|
|
88
|
+
- Testing strategy alignment
|
|
89
|
+
|
|
90
|
+
4. DOCUMENT ARCHITECTURAL DECISIONS:
|
|
91
|
+
- Why this approach fits the existing codebase
|
|
92
|
+
- What patterns are being followed/extended
|
|
93
|
+
- Integration points with existing features
|
|
94
|
+
- Database schema changes needed
|
|
95
|
+
|
|
96
|
+
Target directory: [USER_SPECIFIED_PATH]
|
|
97
|
+
Existing codebase context: [PROVIDE_IF_AVAILABLE]
|
|
65
98
|
```
|
|
66
99
|
|
|
67
100
|
#### 2.3 UI Development Phase
|