@ngocbaongo/ai-agent-init 1.0.1 → 1.2.0
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.
- package/package.json +4 -2
- package/templates/ai_bootstrap.md +13 -9
- package/templates/rules_android.md +51 -0
- package/templates/rules_dotnet.md +47 -0
- package/templates/rules_java_spring.md +50 -0
- package/templates/rules_php_laravel.md +55 -0
- package/templates/rules_react_native.md +52 -0
- package/templates/rules_rust.md +49 -0
- package/templates/rules_swift.md +60 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ngocbaongo/ai-agent-init",
|
|
3
|
-
"version": "1.0
|
|
3
|
+
"version": "1.2.0",
|
|
4
4
|
"description": "Bootstrap any project with AI-agent-ready documentation and conventions. Run once, let the AI do the rest.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai-agent",
|
|
@@ -21,7 +21,9 @@
|
|
|
21
21
|
"bugs": {
|
|
22
22
|
"url": "https://github.com/ngocbaomobile/ai-agent-init/issues"
|
|
23
23
|
},
|
|
24
|
-
"bin":
|
|
24
|
+
"bin": {
|
|
25
|
+
"ai-agent-init": "bin/cli.js"
|
|
26
|
+
},
|
|
25
27
|
"files": [
|
|
26
28
|
"bin/",
|
|
27
29
|
"templates/"
|
|
@@ -16,15 +16,19 @@ Scan the project root directory and determine:
|
|
|
16
16
|
- The **existing folder structure** (top-level directories and their apparent purpose)
|
|
17
17
|
|
|
18
18
|
**Detection signals to look for:**
|
|
19
|
-
| File/Folder Found | Tech Stack |
|
|
20
|
-
|
|
21
|
-
| `pubspec.yaml` | Flutter / Dart |
|
|
22
|
-
| `requirements.txt` / `pyproject.toml` / `setup.py` | Python |
|
|
23
|
-
| `package.json`
|
|
24
|
-
| `
|
|
25
|
-
| `
|
|
26
|
-
| `
|
|
27
|
-
|
|
|
19
|
+
| File/Folder Found | Tech Stack | Template |
|
|
20
|
+
|---|---|---|
|
|
21
|
+
| `pubspec.yaml` | Flutter / Dart | `rules_flutter.md` |
|
|
22
|
+
| `requirements.txt` / `pyproject.toml` / `setup.py` | Python | `rules_python.md` |
|
|
23
|
+
| `package.json` + `react-native` dependency | React Native | `rules_react_native.md` |
|
|
24
|
+
| `package.json` (no react-native) | Node.js / TypeScript | `rules_nodejs.md` |
|
|
25
|
+
| `go.mod` | Go | `rules_go.md` |
|
|
26
|
+
| `Cargo.toml` | Rust | `rules_rust.md` |
|
|
27
|
+
| `build.gradle` / `settings.gradle` + Kotlin | Android / Kotlin | `rules_android.md` |
|
|
28
|
+
| `*.xcodeproj` / `*.xcworkspace` / `Package.swift` | iOS / Swift | `rules_swift.md` |
|
|
29
|
+
| `pom.xml` / `build.gradle` + Spring Boot | Java / Spring Boot | `rules_java_spring.md` |
|
|
30
|
+
| `composer.json` + Laravel | PHP / Laravel | `rules_php_laravel.md` |
|
|
31
|
+
| `*.csproj` / `*.sln` | .NET / C# | `rules_dotnet.md` |
|
|
28
32
|
|
|
29
33
|
---
|
|
30
34
|
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Android / Kotlin — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for an Android/Kotlin project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: Kotlin
|
|
8
|
+
- UI Framework: [Jetpack Compose / XML Views — detect from build.gradle and source files]
|
|
9
|
+
- Architecture: MVVM with Android Architecture Components
|
|
10
|
+
- DI: [Hilt / Koin — detect from build.gradle]
|
|
11
|
+
- Async: Kotlin Coroutines + Flow
|
|
12
|
+
- Networking: [Retrofit + OkHttp — detect from build.gradle]
|
|
13
|
+
- Local DB: [Room — detect from build.gradle]
|
|
14
|
+
|
|
15
|
+
## Folder Structure (Feature-based)
|
|
16
|
+
```
|
|
17
|
+
app/src/main/
|
|
18
|
+
├── java/<package>/
|
|
19
|
+
│ ├── core/ # Shared base classes, utils, DI setup
|
|
20
|
+
│ ├── data/ # Repositories (impl), DTOs, data sources, Room DAOs
|
|
21
|
+
│ ├── domain/ # Use cases, repository interfaces, domain models
|
|
22
|
+
│ ├── presentation/ # ViewModels, Composables/Fragments, UI state
|
|
23
|
+
│ │ └── <feature>/
|
|
24
|
+
│ │ ├── <Feature>ViewModel.kt
|
|
25
|
+
│ │ ├── <Feature>Screen.kt (Compose) or <Feature>Fragment.kt
|
|
26
|
+
│ │ └── <Feature>UiState.kt
|
|
27
|
+
│ └── di/ # Hilt modules
|
|
28
|
+
└── res/ # Layouts (XML), drawables, strings
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Naming Conventions
|
|
32
|
+
- Files/Classes: `PascalCase`
|
|
33
|
+
- Functions/variables/properties: `camelCase`
|
|
34
|
+
- Constants: `UPPER_SNAKE_CASE` (companion object) or `camelCase` (top-level val)
|
|
35
|
+
- Composable functions: `PascalCase` (treated as components)
|
|
36
|
+
- ViewModels: `FeatureNameViewModel`
|
|
37
|
+
- UI State: `FeatureNameUiState` (sealed class or data class)
|
|
38
|
+
|
|
39
|
+
## Code Conventions
|
|
40
|
+
- Use `StateFlow` / `SharedFlow` for ViewModel → UI communication
|
|
41
|
+
- Use `sealed class` for UiState (Loading, Success, Error)
|
|
42
|
+
- Inject dependencies via constructor (with Hilt `@Inject`)
|
|
43
|
+
- Use `viewModelScope` for coroutines in ViewModels
|
|
44
|
+
- Never access Android context inside ViewModels — pass data only
|
|
45
|
+
- Use `data class` for all model/DTO types
|
|
46
|
+
|
|
47
|
+
## What NOT To Do
|
|
48
|
+
- Do NOT do network calls or DB access on the main thread
|
|
49
|
+
- Do NOT put business logic in Activities/Fragments/Composables
|
|
50
|
+
- Do NOT use `GlobalScope` for coroutines
|
|
51
|
+
- Do NOT use `LiveData` for new code — prefer `StateFlow`
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# .NET / C# — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a .NET/C# project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: C# 12 / .NET 8+
|
|
8
|
+
- Framework: [ASP.NET Core Web API / Blazor / MAUI — detect from .csproj]
|
|
9
|
+
- ORM: [Entity Framework Core / Dapper — detect from .csproj]
|
|
10
|
+
- Architecture: [Clean Architecture / Minimal API / MVC — detect from folder structure]
|
|
11
|
+
- DI: Built-in Microsoft.Extensions.DependencyInjection
|
|
12
|
+
|
|
13
|
+
## Folder Structure (Clean Architecture)
|
|
14
|
+
```
|
|
15
|
+
src/
|
|
16
|
+
├── <AppName>.API/ # ASP.NET Core project (controllers, middleware, DI setup)
|
|
17
|
+
├── <AppName>.Application/ # Use cases, commands/queries (MediatR), DTOs, interfaces
|
|
18
|
+
├── <AppName>.Domain/ # Entities, value objects, domain events, interfaces
|
|
19
|
+
└── <AppName>.Infrastructure/ # EF Core, repositories (impl), external services
|
|
20
|
+
tests/
|
|
21
|
+
├── <AppName>.UnitTests/
|
|
22
|
+
└── <AppName>.IntegrationTests/
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Naming Conventions
|
|
26
|
+
- Classes/Interfaces/Records: `PascalCase`
|
|
27
|
+
- Interfaces: `IPascalCase` (e.g., `IUserRepository`)
|
|
28
|
+
- Methods/Properties: `PascalCase`
|
|
29
|
+
- Private fields: `_camelCase` (underscore prefix)
|
|
30
|
+
- Local variables/parameters: `camelCase`
|
|
31
|
+
- Constants: `PascalCase` (C# convention, not UPPER_SNAKE_CASE)
|
|
32
|
+
- Async methods: suffix with `Async` (e.g., `GetUserByIdAsync`)
|
|
33
|
+
|
|
34
|
+
## Code Conventions
|
|
35
|
+
- Use `record` for immutable DTOs and value objects
|
|
36
|
+
- Use MediatR pattern (Commands/Queries/Handlers) for application layer
|
|
37
|
+
- Use `ILogger<T>` for logging — never `Console.WriteLine`
|
|
38
|
+
- Use `async/await` throughout — never `.Result` or `.Wait()` on tasks
|
|
39
|
+
- Use `CancellationToken` as last parameter in all async methods
|
|
40
|
+
- Use primary constructors (C# 12) for cleaner dependency injection
|
|
41
|
+
- Use `FluentValidation` for command/query validation
|
|
42
|
+
|
|
43
|
+
## What NOT To Do
|
|
44
|
+
- Do NOT use `.Result` or `.Wait()` on Tasks — causes deadlocks in ASP.NET Core
|
|
45
|
+
- Do NOT use `static` mutable state — use DI with appropriate lifetimes
|
|
46
|
+
- Do NOT expose EF Core entities directly in API responses — use DTOs/records
|
|
47
|
+
- Do NOT catch `Exception` broadly — catch specific exception types
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Java / Spring Boot — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a Java/Spring Boot project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: Java 17+ / Kotlin
|
|
8
|
+
- Framework: Spring Boot 3.x
|
|
9
|
+
- Build Tool: [Maven (pom.xml) / Gradle (build.gradle) — detect from root files]
|
|
10
|
+
- ORM: [Spring Data JPA + Hibernate — detect from pom.xml/build.gradle]
|
|
11
|
+
- Database: [PostgreSQL / MySQL / H2 — detect from application.properties]
|
|
12
|
+
- Security: [Spring Security — detect from dependencies]
|
|
13
|
+
|
|
14
|
+
## Architecture
|
|
15
|
+
Layered architecture (standard Spring Boot):
|
|
16
|
+
```
|
|
17
|
+
src/main/java/<package>/
|
|
18
|
+
├── controller/ # REST controllers (@RestController)
|
|
19
|
+
├── service/ # Business logic (@Service)
|
|
20
|
+
├── repository/ # Data access (@Repository, JPA interfaces)
|
|
21
|
+
├── entity/ # JPA entities (@Entity)
|
|
22
|
+
├── dto/ # Data Transfer Objects (request/response bodies)
|
|
23
|
+
├── config/ # Spring configuration classes (@Configuration)
|
|
24
|
+
├── exception/ # Custom exceptions + global exception handler
|
|
25
|
+
└── util/ # Utility/helper classes
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Naming Conventions
|
|
29
|
+
- Classes: `PascalCase`
|
|
30
|
+
- Methods/variables: `camelCase`
|
|
31
|
+
- Constants: `UPPER_SNAKE_CASE`
|
|
32
|
+
- Packages: `lowercase.dot.separated`
|
|
33
|
+
- Controllers: `FeatureNameController`
|
|
34
|
+
- Services: `FeatureNameService` + `FeatureNameServiceImpl`
|
|
35
|
+
- Repositories: `FeatureNameRepository`
|
|
36
|
+
- DTOs: `FeatureNameRequest`, `FeatureNameResponse`
|
|
37
|
+
|
|
38
|
+
## Code Conventions
|
|
39
|
+
- Use constructor injection (never field injection with `@Autowired`)
|
|
40
|
+
- Use `@Slf4j` (Lombok) for logging — never `System.out.println`
|
|
41
|
+
- Use `@Valid` + Bean Validation annotations on DTOs
|
|
42
|
+
- Use `ResponseEntity<T>` for REST controller return types
|
|
43
|
+
- Handle exceptions globally with `@ControllerAdvice`
|
|
44
|
+
- Use Lombok (`@Data`, `@Builder`, `@RequiredArgsConstructor`) to reduce boilerplate
|
|
45
|
+
|
|
46
|
+
## What NOT To Do
|
|
47
|
+
- Do NOT use field injection (`@Autowired` on fields)
|
|
48
|
+
- Do NOT put business logic in controllers
|
|
49
|
+
- Do NOT expose JPA entities directly as API response — use DTOs
|
|
50
|
+
- Do NOT use `Optional.get()` without checking `isPresent()` — use `orElseThrow()`
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# PHP / Laravel — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a Laravel project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: PHP 8.2+
|
|
8
|
+
- Framework: Laravel 11.x
|
|
9
|
+
- ORM: Eloquent
|
|
10
|
+
- Frontend: [Blade / Inertia.js (Vue/React) / Livewire — detect from composer.json and resources/]
|
|
11
|
+
- Queue: [Laravel Queues with Redis/Database — detect from .env or config/queue.php]
|
|
12
|
+
- Auth: [Laravel Sanctum / Passport / Breeze / Jetstream — detect from composer.json]
|
|
13
|
+
|
|
14
|
+
## Folder Structure (Laravel convention)
|
|
15
|
+
```
|
|
16
|
+
app/
|
|
17
|
+
├── Http/
|
|
18
|
+
│ ├── Controllers/ # Request handling
|
|
19
|
+
│ ├── Requests/ # Form Request validation classes
|
|
20
|
+
│ ├── Resources/ # API Resources (JSON transformers)
|
|
21
|
+
│ └── Middleware/
|
|
22
|
+
├── Models/ # Eloquent models
|
|
23
|
+
├── Services/ # Business logic (custom, not Laravel default)
|
|
24
|
+
├── Repositories/ # Data access abstraction (if used)
|
|
25
|
+
├── Jobs/ # Queue jobs
|
|
26
|
+
├── Events/ & Listeners/
|
|
27
|
+
└── Providers/
|
|
28
|
+
database/
|
|
29
|
+
├── migrations/
|
|
30
|
+
├── seeders/
|
|
31
|
+
└── factories/
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Naming Conventions
|
|
35
|
+
- Controllers: `PascalCase` + `Controller` suffix (e.g., `UserController`)
|
|
36
|
+
- Models: Singular `PascalCase` (e.g., `User`, `OrderItem`)
|
|
37
|
+
- Migrations: `snake_case` with timestamp prefix
|
|
38
|
+
- Form Requests: `StoreFeatureNameRequest`, `UpdateFeatureNameRequest`
|
|
39
|
+
- Jobs: `PascalCase` + verb (e.g., `SendWelcomeEmail`, `ProcessOrder`)
|
|
40
|
+
- Variables/methods: `camelCase`
|
|
41
|
+
- DB columns/table names: `snake_case`
|
|
42
|
+
|
|
43
|
+
## Code Conventions
|
|
44
|
+
- Use Form Request classes for all validation — never validate in controllers directly
|
|
45
|
+
- Use API Resources for all JSON responses — never return raw Eloquent models
|
|
46
|
+
- Use Services for business logic that spans multiple models
|
|
47
|
+
- Use Eloquent relationships instead of manual joins where possible
|
|
48
|
+
- Use Laravel's built-in helpers (`cache()`, `queue()`, `event()`) over manual instantiation
|
|
49
|
+
- Always use database migrations — never modify the DB schema directly
|
|
50
|
+
|
|
51
|
+
## What NOT To Do
|
|
52
|
+
- Do NOT put business logic in controllers — use Services
|
|
53
|
+
- Do NOT use `DB::raw()` without parameterized bindings (SQL injection risk)
|
|
54
|
+
- Do NOT use `env()` outside of config files — use `config()` helper instead
|
|
55
|
+
- Do NOT disable CSRF protection on routes that modify data
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# React Native — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a React Native project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: TypeScript (strict mode)
|
|
8
|
+
- Framework: React Native [with Expo / bare workflow — detect from app.json or package.json]
|
|
9
|
+
- Navigation: [React Navigation v6 / Expo Router — detect from package.json]
|
|
10
|
+
- State Management: [Zustand / Redux Toolkit / Jotai / Context API — detect from package.json]
|
|
11
|
+
- Styling: [StyleSheet / NativeWind / Tamagui — detect from package.json]
|
|
12
|
+
- Networking: [Axios / React Query / SWR — detect from package.json]
|
|
13
|
+
|
|
14
|
+
## Folder Structure
|
|
15
|
+
```
|
|
16
|
+
src/
|
|
17
|
+
├── app/ # Screens / Expo Router routes
|
|
18
|
+
├── components/ # Reusable UI components
|
|
19
|
+
│ ├── common/ # Generic (Button, Text, Input, etc.)
|
|
20
|
+
│ └── <feature>/ # Feature-specific components
|
|
21
|
+
├── hooks/ # Custom React hooks
|
|
22
|
+
├── stores/ # State management (Zustand/Redux)
|
|
23
|
+
├── services/ # API calls, external services
|
|
24
|
+
├── utils/ # Pure utility functions
|
|
25
|
+
├── types/ # Shared TypeScript types/interfaces
|
|
26
|
+
├── constants/ # App-wide constants, theme tokens
|
|
27
|
+
└── assets/ # Images, fonts, icons
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Naming Conventions
|
|
31
|
+
- Files: `PascalCase.tsx` for components, `camelCase.ts` for hooks/utils
|
|
32
|
+
- Components: `PascalCase` (e.g., `UserProfileCard`)
|
|
33
|
+
- Hooks: `useFeatureName` (e.g., `useAuthState`)
|
|
34
|
+
- Screens: `FeatureNameScreen.tsx`
|
|
35
|
+
- Types/Interfaces: `PascalCase` (e.g., `UserProfile`, `ApiResponse<T>`)
|
|
36
|
+
- Constants: `UPPER_SNAKE_CASE`
|
|
37
|
+
|
|
38
|
+
## Code Conventions
|
|
39
|
+
- Enable `strict: true` in `tsconfig.json`
|
|
40
|
+
- Components must be functional — no class components
|
|
41
|
+
- Extract business logic into custom hooks or services, not inside components
|
|
42
|
+
- Use `React.memo()` for components that receive stable props but render frequently
|
|
43
|
+
- Always type component props with an explicit interface (`interface Props {}`)
|
|
44
|
+
- Use `const` arrow functions for components: `const MyComponent = () => {}`
|
|
45
|
+
- Use `StyleSheet.create()` for styles — avoid inline style objects in render
|
|
46
|
+
|
|
47
|
+
## What NOT To Do
|
|
48
|
+
- Do NOT use `any` type — use `unknown` with type guards
|
|
49
|
+
- Do NOT mix navigation logic inside UI components — use navigation hooks
|
|
50
|
+
- Do NOT use `useEffect` for data fetching — use React Query / SWR instead
|
|
51
|
+
- Do NOT hardcode colors/spacing — use theme tokens from constants/
|
|
52
|
+
- Do NOT use platform-specific code without `Platform.OS` checks
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Rust — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a Rust project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: Rust (stable toolchain)
|
|
8
|
+
- Build Tool: Cargo
|
|
9
|
+
- Async Runtime: [Tokio / async-std / None — detect from Cargo.toml]
|
|
10
|
+
- Web Framework: [Axum / Actix-web / Warp — detect from Cargo.toml]
|
|
11
|
+
- ORM/DB: [SQLx / Diesel / SeaORM — detect from Cargo.toml]
|
|
12
|
+
- Error Handling: [thiserror / anyhow — detect from Cargo.toml]
|
|
13
|
+
|
|
14
|
+
## Workspace Structure
|
|
15
|
+
```
|
|
16
|
+
src/
|
|
17
|
+
├── main.rs # Binary entry point
|
|
18
|
+
├── lib.rs # Library entry point (if dual crate)
|
|
19
|
+
├── domain/ # Business logic, domain models
|
|
20
|
+
├── infrastructure/ # DB, external services, adapters
|
|
21
|
+
├── api/ # HTTP handlers, routes
|
|
22
|
+
└── config.rs # Configuration structs
|
|
23
|
+
tests/ # Integration tests
|
|
24
|
+
benches/ # Benchmarks (if any)
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Naming Conventions
|
|
28
|
+
- Files/modules: `snake_case.rs`
|
|
29
|
+
- Types/Structs/Enums/Traits: `PascalCase`
|
|
30
|
+
- Functions/variables/fields: `snake_case`
|
|
31
|
+
- Constants: `UPPER_SNAKE_CASE`
|
|
32
|
+
- Lifetimes: short, lowercase (`'a`, `'buf`)
|
|
33
|
+
- Macros: `snake_case!`
|
|
34
|
+
|
|
35
|
+
## Code Conventions
|
|
36
|
+
- Use `thiserror` for library errors, `anyhow` for application errors
|
|
37
|
+
- Prefer `?` operator for error propagation over `.unwrap()`
|
|
38
|
+
- Use `clippy` and `rustfmt` — run `cargo clippy` and `cargo fmt` before committing
|
|
39
|
+
- Prefer owned types in public APIs; use references internally where possible
|
|
40
|
+
- Use `#[derive(Debug, Clone, PartialEq)]` on all domain structs/enums
|
|
41
|
+
- Write doc comments (`///`) for all public items
|
|
42
|
+
- Use `mod.rs` sparingly — prefer inline `mod` declarations in parent files
|
|
43
|
+
|
|
44
|
+
## What NOT To Do
|
|
45
|
+
- Do NOT use `.unwrap()` or `.expect()` in production code paths (only in tests/examples)
|
|
46
|
+
- Do NOT use `unsafe` without a detailed safety comment explaining why it's sound
|
|
47
|
+
- Do NOT use `std::sync::Mutex` in async code — use `tokio::sync::Mutex`
|
|
48
|
+
- Do NOT clone excessively to avoid borrow checker issues — redesign the ownership instead
|
|
49
|
+
- Do NOT use global mutable state (`static mut`)
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Swift / iOS — Rules & Conventions Template
|
|
2
|
+
|
|
3
|
+
> AI Agent: Use this file as reference to fill in `docs/ai/rules.md` for a Swift/iOS project.
|
|
4
|
+
> Adapt every section to match what you actually observe in the codebase.
|
|
5
|
+
|
|
6
|
+
## Tech Stack
|
|
7
|
+
- Language: Swift 5.9+
|
|
8
|
+
- Platform: iOS 16+ / macOS 13+
|
|
9
|
+
- UI Framework: [SwiftUI / UIKit / Both — detect from source files]
|
|
10
|
+
- Architecture: [MVVM / MVC / TCA (The Composable Architecture) / VIPER — detect from folder structure]
|
|
11
|
+
- Package Manager: [Swift Package Manager (SPM) / CocoaPods — detect from Package.swift or Podfile]
|
|
12
|
+
- Networking: [URLSession / Alamofire / Moya — detect from Package.swift or Podfile]
|
|
13
|
+
- Async: [async/await / Combine / Completion handlers — detect from code style]
|
|
14
|
+
|
|
15
|
+
## Architecture
|
|
16
|
+
[Detect and describe. Common patterns:]
|
|
17
|
+
- **MVVM + SwiftUI**: Views observe ViewModels via @StateObject / @ObservedObject / @Observable
|
|
18
|
+
- **TCA**: Store, Reducer, Action, State pattern from pointfreeco/swift-composable-architecture
|
|
19
|
+
- **VIPER**: View, Interactor, Presenter, Entity, Router — common in older UIKit projects
|
|
20
|
+
|
|
21
|
+
## Folder Structure (SwiftUI MVVM example)
|
|
22
|
+
```
|
|
23
|
+
<AppName>/
|
|
24
|
+
├── App/ # App entry point, main scene
|
|
25
|
+
├── Features/ # One folder per feature
|
|
26
|
+
│ └── <Feature>/
|
|
27
|
+
│ ├── Views/
|
|
28
|
+
│ ├── ViewModels/
|
|
29
|
+
│ └── Models/
|
|
30
|
+
├── Core/ # Shared utilities, extensions, services
|
|
31
|
+
│ ├── Network/
|
|
32
|
+
│ ├── Storage/
|
|
33
|
+
│ └── Extensions/
|
|
34
|
+
└── Resources/ # Assets, fonts, localization strings
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Naming Conventions
|
|
38
|
+
- Files: `PascalCase.swift`
|
|
39
|
+
- Types/Classes/Structs/Enums: `PascalCase`
|
|
40
|
+
- Functions/variables/properties: `camelCase`
|
|
41
|
+
- Constants: `camelCase` (Swift style, not UPPER_SNAKE_CASE)
|
|
42
|
+
- Protocols: `PascalCase`, often suffixed with `-able`, `-ing`, or `-Delegate`
|
|
43
|
+
- View files: `FeatureNameView.swift`
|
|
44
|
+
- ViewModel files: `FeatureNameViewModel.swift`
|
|
45
|
+
|
|
46
|
+
## Code Conventions
|
|
47
|
+
- Prefer `struct` over `class` for value semantics (models, view models where possible)
|
|
48
|
+
- Use `@Observable` macro (iOS 17+) or `ObservableObject` for view models
|
|
49
|
+
- Use Swift Concurrency (`async/await`, `Task`, `Actor`) over Combine for new code
|
|
50
|
+
- Keep Views "dumb" — no business logic inside View body
|
|
51
|
+
- Use `private` access control by default; only expose what's necessary
|
|
52
|
+
- Prefer `let` over `var` wherever possible
|
|
53
|
+
- Handle errors explicitly — never use `try!` or `as!` in production code
|
|
54
|
+
- Use `#Preview` macro for SwiftUI previews
|
|
55
|
+
|
|
56
|
+
## What NOT To Do
|
|
57
|
+
- Do NOT use force unwrap (`!`) or force cast (`as!`) — use `guard let` or `if let`
|
|
58
|
+
- Do NOT put network calls or business logic directly in Views
|
|
59
|
+
- Do NOT use global singletons unless absolutely necessary (prefer dependency injection)
|
|
60
|
+
- Do NOT ignore `@MainActor` requirements for UI updates
|