بنقرة واحدة
create-nx-library
Use when the user asks to create a new Nx library in this workspace.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when the user asks to create a new Nx library in this workspace.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when writing or editing an Angular component in this workspace — presentational (ui) or container components. Covers the clean component rules: dumb ui components, thin containers, and where logic must not go.
Use whenever writing, editing, running, or fixing a Vitest spec (`*.spec.ts`) in this workspace — signal stores, `rxMethod`s, `computed`s, presentational and container components, mocks/spies, or pure utils. ESPECIALLY reach for this the moment a test involves anything async (`rxMethod`, HTTP, a timer) or a signal-driven effect, because this app is zoneless and the usual `fakeAsync`/`tick` recipe silently does not work here. If you find yourself about to import `fakeAsync`, `tick`, or reach for `zone.js`, stop and read this first. Also reach for this when you're chasing 100% Vitest coverage.
Use when the user asks to add state management or create a store for a feature in this Angular workspace.
Use when adding or changing any state in this Angular workspace — creating a signal store, deciding whether state belongs in a local or root store, or wiring an async load. Always applies when state is introduced, not only when refactoring existing stores.
Use whenever writing or editing an Angular `computed()` or `effect()` — including signal-based derivations inside `signalStore` (`withComputed`), component `computed`s, and any `effect`. Applies even for one-line derivations.
| name | create-nx-library |
| description | Use when the user asks to create a new Nx library in this workspace. |
When creating a new library, keep our architecture intact:
libs/<scope>/, domain logic
under libs/<scope>/domain, presentational components under
libs/<scope>/ui, and utilities shared across the workspace under
libs/shared.tags in the new project.json using BOTH a scope
and a type tag:
scope: is the area the library belongs to, e.g. scope:dogs,
scope:about or scope:shared.type: is the kind of library: type:container, type:domain,
type:ui or type:util.type:container may depend on
type:domain, type:ui and type:util; a type:domain may only depend
on type:util; a scope:dogs library may only depend on scope:dogs and
scope:shared.nx run-many -t lint (or the affected variant) to
confirm no module boundary rule is violated.{
"name": "dogs-ui",
"tags": ["type:ui", "scope:dogs"]
}