devendra-skill-package 1.0.2

package/.github/skills/boiler-project-generator/scripts/react.js

@@ -0,0 +1,32 @@
+const { execSync } = require('node:child_process');
+
+function getFlag(name) {
+  const idx = process.argv.indexOf(name);
+  if (idx === -1) return null;
+  return process.argv[idx + 1] || null;
+}
+
+if (process.argv.includes('--help') || process.argv.includes('-h')) {
+  console.log('Usage: node react.js <projectName> <language> [--template <name>]');
+  process.exit(0);
+}
+
+const projectName = getFlag('--project') || process.argv[2] || 'my-react-app';
+const language = getFlag('--language') || process.argv[3] || 'javascript';
+const template = getFlag('--template');
+
+console.log('Creating React project...');
+
+try {
+  execSync(
+    language === 'typescript'
+      ? `npx create-react-app ${projectName} --template typescript`
+      : `npx create-react-app ${projectName}`,
+    { stdio: 'inherit' }
+  );
+} catch (err) {
+  console.error('React project creation failed:', err.message);
+  process.exit(2);
+}
+
+console.log('React project ready!');

package/.github/skills/clean-architecture-generator/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: clean-architecture-generator
+description: Enforce Clean Architecture with vertical feature slicing across React Native, React (web), Angular, and Flutter. Detects which platform the target project is, then detects the project's actual state-management/HTTP-client/storage/navigation/DI stack before generating any code — never assumes a fixed stack. Use when starting a new project, adding a new feature, scaffolding a new screen/page/component/widget, use case, repository, DI wiring, or any layer artifact under Clean Architecture. Enforces folder structure, naming conventions, dependency rules, and platform-appropriate patterns. Trigger phrases: new feature, scaffold feature, add screen, add page, add use case, add repository, clean architecture, vertical slice.
+---
+
+## Purpose
+
+Scaffold and enforce Clean Architecture (vertical feature slice: `domain/` → `data/` →
+`presentation/`, plus DI wiring) on whichever of the four supported platforms the target project
+actually is — React Native, React (web), Angular, or Flutter. The layering and dependency rules are
+identical across all four; the concrete folder names, DI mechanism, state pattern, and file naming
+are platform-specific and come from a per-platform reference file, never invented inline.
+
+**This skill never assumes a fixed tech stack.** It detects the platform first, then detects the
+project's actual state-management/HTTP-client/storage/navigation/DI libraries by reading the repo.
+A per-platform default is only used when the project is greenfield (nothing detected) — and it is
+always logged as a default, never silently treated as a requirement.
+
+## Supported Platforms
+
+| Platform | Detection signal | Reference file |
+|---|---|---|
+| React Native | `package.json` has `react-native` dependency | `references/platform-react-native.md` |
+| React (web) | `package.json` has `react` + `react-dom`, no `react-native` | `references/platform-react.md` |
+| Angular | `angular.json` at repo root | `references/platform-angular.md` |
+| Flutter | `pubspec.yaml` with a `flutter:` SDK entry | `references/platform-flutter.md` |
+
+## When to Use
+
+- Starting a new project on any of the four platforms above
+- Adding a new feature folder (a vertical slice: `domain/` + `data/` + `presentation/` + DI wiring)
+- Creating any layer artifact: entity, use case, repository, API client/data source, DTO/model,
+  mapper, state slice/store/bloc, screen/page/component/widget, hook, DI container/provider
+- Reviewing or fixing an existing file that may violate layer boundaries or naming conventions
+- Setting up the app's state store, navigation/routing, or security layer
+
+Do **not** use this skill for platforms outside the four above (e.g. plain Node.js backend
+services, native Android/iOS in Kotlin/Swift, Vue) — it has no reference file for them and
+generating from memory for an unsupported platform is exactly the kind of assumption this skill
+exists to avoid. If asked for one of those, say so explicitly rather than approximating from the
+closest supported platform.
+
+---
+
+## STOP — READ REFERENCE FILES BEFORE ANY CODE
+
+Always read, in this order:
+
+```
+.github/skills/clean-architecture-generator/references/architecture-core.md
+.github/skills/clean-architecture-generator/references/platform-[detected-platform].md
+```
+
+- `architecture-core.md` — the layers, the dependency rule, universal naming, universal
+  anti-patterns. Applies on every platform, always read first.
+- Exactly **one** `platform-*.md` file — the concrete folder tree, DI mechanism, state/HTTP/
+  storage/navigation patterns, platform-specific naming, and platform-specific anti-patterns for
+  the platform detected in Phase 0. Never read more than one platform file for a single artifact —
+  if the repo genuinely contains more than one platform (see Phase 0, Multi-Platform Repos), each
+  artifact is generated against the one platform file matching where it will actually live.
+
+---
+
+## Phase 0 — Platform Detection
+
+Run before anything else, every time this skill is invoked in a repo it hasn't already confirmed
+the platform for in the current session.
+
+1. Check for `pubspec.yaml` at the repo root (or the target sub-package root in a monorepo) with a
+   `flutter:` entry under `dependencies` → **Flutter**.
+2. Check for `angular.json` at the repo root (or target sub-package root) → **Angular**.
+3. Check `package.json`:
+   - `dependencies`/`devDependencies` contains `react-native` → **React Native**. Also check
+     `app.json`/`app.config.*` for an `expo` key or `expo` dependency and note Expo vs. bare — the
+     clean-architecture layering is identical either way, but it affects native-module
+     availability, which the platform file's Security Rules may depend on.
+   - `dependencies` contains `react` + `react-dom`, and **not** `react-native` → **React (web)**.
+     Then run the Sub-Variant Detection table at the top of `platform-react.md` (Next.js/CRA/Vite).
+4. **Multi-platform repos**: if more than one signal matches (e.g. an Nx/Turborepo monorepo with
+   both `apps/mobile` running React Native and `apps/web` running React), list every candidate
+   app/package found and ask the user which one this request targets — never guess which one based
+   on repo-root proximity or file recency.
+5. **No signal matches**: ask the user which of the four supported platforms this is — never guess
+   and never fall back to a default platform.
+
+State the detected (or user-confirmed) platform before proceeding, and load exactly that one
+`platform-*.md` file for the remainder of this request.
+
+---
+
+## Phase 1 — Stack Fingerprint Detection
+
+Each platform file has a "Stack Fingerprint Defaults" table listing, per concern (state
+management, HTTP client, storage, navigation, DI mechanism, test runner), what to search for in the
+target repo and what default applies only if nothing is found. Run that table now:
+
+1. For each row, search the target repo using the "Detect first" column's patterns — dependency
+   manifests (`package.json`/`pubspec.yaml`) first, then a grep across existing source for the
+   literal usage patterns listed (e.g. `createSlice(`, `Dio(`, `@ngrx/store`).
+2. If a row's pattern is found, that is the project's real stack for that concern — use it for
+   every artifact generated in this request, and do not substitute the platform file's default.
+3. If a row's pattern is not found anywhere in the repo, the project is greenfield for that
+   concern — apply the platform file's labeled default, and say so explicitly (e.g. "No state
+   management library detected — applying default: Redux Toolkit + RTK Query").
+4. Never mix two different libraries for the same concern within one feature (e.g. do not add
+   Riverpod to a Flutter feature that already uses Bloc elsewhere in the same app) — if the repo
+   has genuinely inconsistent choices across features, ask which one this new feature should follow
+   rather than picking silently.
+
+Record the resolved fingerprint (state lib, HTTP client, storage, navigation, DI mechanism) and use
+it consistently for every file generated in the rest of this request.
+
+---
+
+## Execution Steps
+
+### Step 1 — Identify the artifact type
+
+| Request | Artifact(s) to create |
+|---------|----------------------|
+| New feature | Full vertical slice: `domain/`, `data/`, `presentation/`, DI wiring, tests, public API surface (per platform file) |
+| New screen / page / widget | One presentation file (see platform file's Naming Extensions for the exact term and suffix) + a state entry if it fetches data |
+| New use case | Domain use case file + repository contract update if a new repository method is needed |
+| New repository | Domain repository contract (interface/abstract class — platform-specific, never `I`-prefix on Angular/Flutter) + data-layer implementation |
+| New API call | Data-layer API client/data source + DTO/model + mapper |
+| New state concern | Whatever the resolved fingerprint's state library uses (slice+thunk+selectors, a Bloc, an RxJS store service, etc. — see platform file) |
+| New DI wiring | Whatever the resolved fingerprint's DI mechanism uses (manual container, Angular providers array, get_it registration, Riverpod provider — see platform file) |
+
+### Step 2 — Confirm platform + fingerprint
+
+If Phase 0/Phase 1 haven't run yet in this session for this repo, run them now. Otherwise reuse the
+already-confirmed platform and fingerprint — do not re-detect on every single artifact within the
+same request.
+
+### Step 3 — Apply naming conventions
+
+Read `architecture-core.md`'s Universal Naming Conventions table, then the platform file's Naming
+Extensions table. Derive all file and symbol names before writing any code.
+
+### Step 4 — Verify dependency rules
+
+Read `architecture-core.md`'s Dependency Rule section, plus the platform file's Dependency Rules
+detail (if it adds any, e.g. a monorepo `packages/*` structure). Confirm the file being created is
+in the correct layer and will only import from allowed layers.
+
+### Step 5 — Apply the correct pattern
+
+Read the platform file's code patterns for the artifact type, using the resolved fingerprint from
+Phase 1 (the project's real state/HTTP/storage/navigation library, not necessarily the platform
+file's labeled default). Do not invent variations on the pattern shown.
+
+### Step 6 — Check anti-patterns
+
+Read `architecture-core.md`'s Universal Anti-Patterns, then the platform file's platform-specific
+anti-patterns. Reject any pattern that appears in either list before emitting code.
+
+### Step 7 — Expose the public API surface (platform-conditional)
+
+- **React Native / React / Angular**: every new public artifact must be exported from its layer's
+  `index.ts` and the feature's root `index.ts` barrel (Angular: from the feature's `.providers.ts`/
+  `.routes.ts` where relevant — Angular features are consumed via routes, not a barrel import).
+- **Flutter**: Dart apps typically import feature files directly rather than through a barrel — do
+  not invent a barrel-export file unless the target project already uses one (check for an existing
+  `lib/features/[feature]/[feature].dart` library-export file before deciding either way).
+
+### Step 8 — Register in the composition root
+
+- **React Native / React**: add the reducer/slice to the app store and spread the DI container into
+  `extraArgument`, in the platform file's `app/state/store.ts`.
+- **Angular**: register the feature's providers array on its lazy route in `app.routes.ts` (or the
+  feature's `NgModule`, if the target project is NgModule-based).
+- **Flutter**: call the feature's `init[Feature]Dependencies()` from `app/di/injection_container.dart`'s
+  `init()`, and add the feature's route to `app/routing/app_router.dart`.
+
+---
+
+## Dependency Rule (summary — full detail in architecture-core.md)
+
+```
+domain/          ← imports nothing from data/, presentation/, or any framework
+data/            ← implements own domain/ contracts + infrastructure SDKs
+presentation/    ← imports own domain/ + own data/ only through DI, never directly
+core/ (infra)    ← never imports from features/*
+features/[x]/    ← self-contained; consumed by others only through its public surface
+app/ (bootstrap) ← imports all features/*, orchestration only
+```
+
+---
+
+## Strict Rules
+
+1. `domain/` layer: zero framework imports on every platform — pure language code only.
+2. UI code (screen/page/component/widget) never calls the HTTP client, DB, or any SDK directly —
+   always through a use case → repository.
+3. Never import from `features/` inside `core/`/shared infra.
+4. Loading/state status is always an explicit union/enum/sealed-class (`'idle' | 'loading' |
+   'succeeded' | 'failed'`, or the platform's equivalent) — never a bare `boolean`.
+5. Follow the resolved fingerprint's DI mechanism exactly as the platform file documents it — manual
+   container (RN/React), framework DI via abstract-class token (Angular), or `get_it`/Riverpod
+   provider (Flutter). Never port one platform's DI mechanism onto another.
+6. Never import a sub-path of a feature from outside that feature.
+7. Never use an untyped escape hatch (`any`, `dynamic`) to skip modeling a type.
+8. Never hardcode configuration values (URLs, keys, timeouts) in a component/service file.
+9. See the loaded platform file for additional platform-specific strict rules (storage/security
+   rules differ meaningfully between mobile, web, and Angular/Flutter).
+
+---
+
+## Output Format
+
+For each artifact created, report using the platform file's actual naming convention (this is a
+shape, not literal text — substitute the real file names):
+
+```
+Platform: <detected platform>  (Sub-variant: <if applicable>)
+Stack fingerprint: state=<detected-or-default> http=<detected-or-default> storage=<detected-or-default> nav=<detected-or-default> di=<detected-or-default>
+
+Created:
+  <platform-appropriate paths for each generated file>
+
+Updated:
+  <composition-root files touched, e.g. store.ts / app.routes.ts / injection_container.dart>
+
+Dependency check: PASS — no layer boundary violations detected
+```
+
+If any fingerprint field used a default rather than a detected value, state that explicitly, e.g.
+`state=Redux Toolkit (default — none detected in repo)`.
+
+---
+
+## Example
+
+See the "Worked Example" section at the end of each platform file for a fully worked "add a
+watchlist feature" example in that platform's own naming convention and file layout.

package/.github/skills/clean-architecture-generator/references/architecture-core.md

@@ -0,0 +1,126 @@
+# Architecture Core — Platform-Agnostic Rules
+
+These rules apply **regardless of platform** (React Native, React, Angular, Flutter). They define
+what "Clean Architecture with vertical feature slicing" means independent of any specific framework,
+state-management library, or HTTP client. Read this file first, always. Then read exactly one
+`platform-*.md` file for the concrete implementation of these rules on the detected platform.
+
+---
+
+## The Three Layers (every feature has exactly these)
+
+```
+features/[feature-name]/
+├── domain/          ← business rules. Zero framework imports. Pure language code only.
+│   ├── entities/        one file per business object
+│   ├── repositories/    interfaces/contracts only — no implementation
+│   └── usecases/        one class per business operation
+│
+├── data/            ← implements the domain contracts using real infrastructure
+│   ├── dtos/             raw shapes exactly as the API/DB returns them
+│   ├── mappers/          pure functions: DTO → domain entity
+│   ├── repositories/     concrete classes implementing the domain interfaces
+│   └── (api/datasources/config — platform-specific subfolder, see platform file)
+│
+└── presentation/    ← UI framework code. Never talks to the network/DB/storage directly.
+    ├── screens|pages|views/   one per user-visible view
+    ├── components|widgets/    reusable UI pieces local to this feature
+    ├── state/                 whatever state mechanism the platform/project uses
+    └── (hooks/navigation/routing — platform-specific, see platform file)
+```
+
+A feature also owns a **DI wiring point** (a container, a provider registration, a module — the
+concrete mechanism is platform-specific, see the platform file) that supplies concrete `data/`
+implementations to `domain/` use cases, and supplies use cases to `presentation/`.
+
+---
+
+## The Dependency Rule (never violated, on any platform)
+
+```
+domain/          ← imports nothing from data/, presentation/, or any UI/HTTP/storage framework
+data/            ← imports own domain/ (to implement its contracts) + infrastructure SDKs
+presentation/    ← imports own domain/ (types/use cases) + own data/ only through DI, never directly
+core/ (infra)    ← shared infrastructure; NEVER imports from features/*
+features/[x]/    ← self-contained; another feature may only import [x]'s public barrel/export
+app/ (bootstrap) ← imports all features/*, orchestration only, zero business logic
+```
+
+**Why this exists:** `domain/` encodes business rules that must survive a framework migration,
+a state-library swap, or an HTTP-client change untouched. If `domain/` imports React, Redux, Axios,
+Angular's `HttpClient`, or Flutter's `Dio`, that guarantee is broken. This is the one rule that does
+not change no matter which platform file you load next.
+
+---
+
+## Universal Naming Conventions
+
+These names are the same concept on every platform; only the file-casing convention differs
+(see the platform file's "Naming Extensions" section for the platform's casing rules).
+
+| Artifact | What it is | Platform file governs |
+|---|---|---|
+| Entity | A plain business object, no framework types inside | casing/file suffix |
+| Repository interface/contract | Abstract description of a data operation, no implementation | whether it's a TS `interface`, a TS `abstract class`, or a Dart `abstract class` — **not interchangeable, see platform file** |
+| Repository implementation | Concrete class implementing the contract, calls the real HTTP client/DB | suffix (`Impl`, `.impl.ts`, etc.) |
+| Use case | One class per business operation, depends only on a repository contract | casing/file suffix |
+| DTO | Raw API/DB response shape — belongs in `data/`, never `domain/` | casing/file suffix; some platforms call this a "Model" instead (see platform file) |
+| Mapper | Pure function converting a DTO to a domain entity | naming prefix (`mapTo…`, etc.) |
+| Test file | Test for any of the above | suffix convention (`.test.ts`, `.spec.ts`, `_test.dart`) |
+
+**Do not guess a platform's casing convention from this table.** Each platform has an actual
+official or de-facto style guide (Effective Dart, Angular style guide, etc.) — the platform file
+states the real convention, not an invented one.
+
+---
+
+## Universal Anti-Patterns (blocking on every platform)
+
+Treat any of the following as a blocking error, on any platform. Fix before emitting code.
+The platform file adds platform-specific anti-patterns on top of this list — it never removes
+or contradicts an item here.
+
+### Layer boundary violations
+
+- **Never** call the HTTP client, database, or any infrastructure SDK directly from UI code
+  (`presentation/`) — it always goes through a use case → repository.
+- **Never** put business logic inside a UI component/screen/page/widget — it belongs in a use case.
+- **Never** put a DTO/Model type in `domain/` — DTOs/Models live in `data/`, domain entities live
+  in `domain/entities/`.
+- **Never** share one feature's state (store/slice/service/bloc — whatever the platform calls it)
+  between two features — each feature owns its own state.
+- **Never** import from `features/` inside `core/` (or the platform's equivalent shared-infra root).
+- **Never** import a sub-path of a feature from outside that feature — always go through the
+  feature's public barrel/export.
+
+### Language-level
+
+- **Never** use an untyped escape hatch (`any` in TypeScript, `dynamic` in Dart) to avoid modeling
+  a type properly — use a specific type or the platform's safe-unknown equivalent.
+- **Never** suppress a compiler/linter error about a type mismatch without a documented reason.
+
+### General
+
+- **Never** add features or files beyond what was asked.
+- **Never** hardcode configuration values (URLs, keys, timeouts) inside a component or service file
+  — they belong in the feature's `data/config/` or the shared infra config module.
+- **Never** leave mock/fixture data reachable from a production code path — mock files are dev/test
+  only.
+
+---
+
+## How This File Relates to the Platform Files
+
+1. This file (`architecture-core.md`) defines the layers, the dependency rule, and the rules that
+   hold regardless of platform.
+2. `SKILL.md` Phase 0 detects which platform the target project is (or asks, if ambiguous) and which
+   platform file to load.
+3. `SKILL.md` Phase 1 detects the project's **actual** state-management/HTTP/storage/navigation/DI
+   stack by reading the repo — never assumes a fixed stack. Only when the project is greenfield
+   (nothing detected) does the platform file's labeled default apply.
+4. The platform file then supplies: the concrete folder tree, the concrete DI mechanism, the
+   concrete state/HTTP/storage/navigation code patterns, platform-specific naming, and
+   platform-specific anti-patterns.
+
+Never generate code from this file alone — it has no concrete syntax. Always pair it with exactly
+one platform file.