@lenne.tech/cli 1.2.0 → 1.3.0

package/build/templates/claude-skills/generating-nest-servers/declare-keyword-warning.md

@@ -1,133 +0,0 @@
----
-name: nest-server-generator-declare-keyword
-version: 1.0.0
-description: Critical warning about using the declare keyword in TypeScript classes
----
-
-# 🚨 CRITICAL: NEVER USE `declare` KEYWORD FOR PROPERTIES
-
-## Table of Contents
-- [WRONG - Using `declare`](#-wrong---using-declare)
-- [CORRECT - Without `declare`](#-correct---without-declare)
-- [Why This Matters](#why-this-matters)
-- [When You Might Be Tempted to Use `declare`](#when-you-might-be-tempted-to-use-declare)
-- [Correct Approach Instead](#correct-approach-instead)
-- [Examples](#examples)
-- [Remember](#remember)
-
-**⚠️ IMPORTANT RULE: DO NOT use the `declare` keyword when defining properties in classes!**
-
-The `declare` keyword in TypeScript signals that a property is only a type declaration without a runtime value. This prevents decorators from being properly applied and overridden.
-
----
-
-## ❌ WRONG - Using `declare`
-
-```typescript
-export class ProductCreateInput extends ProductInput {
-  declare name: string;  // ❌ WRONG - Decorator won't be applied!
-  declare price: number; // ❌ WRONG - Decorator won't be applied!
-}
-```
-
----
-
-## ✅ CORRECT - Without `declare`
-
-```typescript
-export class ProductCreateInput extends ProductInput {
-  @UnifiedField({ description: 'Product name' })
-  name: string;  // ✅ CORRECT - Decorator works properly
-
-  @UnifiedField({ description: 'Product price' })
-  price: number; // ✅ CORRECT - Decorator works properly
-}
-```
-
----
-
-## Why This Matters
-
-1. **Decorators require actual properties**: `@UnifiedField()`, `@Restricted()`, and other decorators need actual property declarations to attach metadata
-2. **Override behavior**: When extending classes, using `declare` prevents decorators from being properly overridden
-3. **Runtime behavior**: `declare` properties don't exist at runtime, breaking the decorator system
-
----
-
-## When You Might Be Tempted to Use `declare`
-
-- ❌ When extending a class and wanting to change a decorator
-- ❌ When TypeScript shows "property is declared but never used"
-- ❌ When dealing with inheritance and property redefinition
-
----
-
-## Correct Approach Instead
-
-Use the `override` keyword (when appropriate) but NEVER `declare`:
-
-```typescript
-export class ProductCreateInput extends ProductInput {
-  // ✅ Use override when useDefineForClassFields is enabled
-  override name: string;
-
-  // ✅ Apply decorators directly - they will override parent decorators
-  @UnifiedField({ description: 'Product name', isOptional: false })
-  override price: number;
-}
-```
-
----
-
-## Examples
-
-### ❌ WRONG - Using declare
-
-```typescript
-// This will BREAK decorator functionality
-export class AddressInput extends Address {
-  declare street: string;
-  declare city: string;
-  declare zipCode: string;
-}
-```
-
-### ✅ CORRECT - Without declare
-
-```typescript
-// This works properly
-export class AddressInput extends Address {
-  @UnifiedField({ description: 'Street' })
-  street: string;
-
-  @UnifiedField({ description: 'City' })
-  city: string;
-
-  @UnifiedField({ description: 'Zip code' })
-  zipCode: string;
-}
-```
-
-### ✅ CORRECT - With override
-
-```typescript
-// This also works when extending decorated properties
-export class AddressInput extends Address {
-  @UnifiedField({ description: 'Street', isOptional: false })
-  override street: string;
-
-  @UnifiedField({ description: 'City', isOptional: false })
-  override city: string;
-
-  @UnifiedField({ description: 'Zip code', isOptional: true })
-  override zipCode?: string;
-}
-```
-
----
-
-## Remember
-
-**`declare` = no decorators = broken functionality!**
-
-Always use actual property declarations with decorators, optionally with the `override` keyword when extending classes.

package/build/templates/claude-skills/generating-nest-servers/description-management.md

@@ -1,226 +0,0 @@
----
-name: nest-server-generator-description-management
-version: 1.0.0
-description: Guidelines for consistent description management across all generated components
----
-
-# 🚨 CRITICAL: Description Management
-
-## Table of Contents
-- [Step 1: ALWAYS Extract Descriptions from User Input](#-step-1-always-extract-descriptions-from-user-input)
-- [Step 2: Format Descriptions Correctly](#-step-2-format-descriptions-correctly)
-- [Step 3: Apply Descriptions EVERYWHERE (Most Critical!)](#-step-3-apply-descriptions-everywhere-most-critical)
-- [Common Mistakes to AVOID](#-common-mistakes-to-avoid)
-- [Verification Checklist](#-verification-checklist)
-- [If You Forget](#-if-you-forget)
-- [Quick Reference](#quick-reference)
-
-**⚠️ COMMON MISTAKE:** Descriptions are often applied inconsistently or only partially. You MUST follow this process for EVERY component.
-
----
-
-## 🔍 Step 1: ALWAYS Extract Descriptions from User Input
-
-**BEFORE generating ANY code, scan the user's specification for description hints:**
-
-1. **Look for comments after `//`**:
-   ```
-   Module: Product
-   - name: string // Product name
-   - price: number // Produktpreis
-   - stock?: number // Current stock level
-   ```
-
-2. **Extract ALL comments** and store them for each property
-3. **Identify language** (English or German)
-
----
-
-## 📝 Step 2: Format Descriptions Correctly
-
-**Rule**: `"ENGLISH_DESCRIPTION (DEUTSCHE_BESCHREIBUNG)"`
-
-### Processing Logic
-
-| User Input | Language | Formatted Description |
-|------------|----------|----------------------|
-| `// Product name` | English | `'Product name'` |
-| `// Produktname` | German | `'Product name (Produktname)'` |
-| `// Straße` | German | `'Street (Straße)'` |
-| `// Postleizahl` (typo) | German | `'Postal code (Postleitzahl)'` |
-| (no comment) | - | Create meaningful English description |
-
-### ⚠️ CRITICAL - Preserving Original Text
-
-**1. Fix spelling errors ONLY:**
-- ✅ Correct typos: `Postleizahl` → `Postleitzahl` (missing 't')
-- ✅ Fix character errors: `Starße` → `Straße` (wrong character)
-- ✅ Correct English typos: `Prodcut name` → `Product name`
-
-**2. DO NOT change the wording:**
-- ❌ NEVER rephrase: `Straße` → `Straßenname` (NO!)
-- ❌ NEVER expand: `Produkt` → `Produktbezeichnung` (NO!)
-- ❌ NEVER improve: `Name` → `Full name` (NO!)
-- ❌ NEVER translate differently: `Name` → `Title` (NO!)
-
-**3. Why this is critical:**
-- User comments may be **predefined terms** from requirements
-- External systems may **reference these exact terms**
-- Changing wording breaks **external integrations**
-
-### Examples
-
-```
-✅ CORRECT:
-// Straße → 'Street (Straße)'  (only translated)
-// Starße → 'Street (Straße)'  (typo fixed, then translated)
-// Produkt → 'Product (Produkt)'  (keep original word)
-// Strasse → 'Street (Straße)'  (ss→ß corrected, then translated)
-
-❌ WRONG:
-// Straße → 'Street name (Straßenname)'  (changed wording!)
-// Produkt → 'Product name (Produktname)'  (added word!)
-// Name → 'Full name (Vollständiger Name)'  (rephrased!)
-```
-
-**Rule Summary**: Fix typos, preserve wording, translate accurately.
-
----
-
-## ✅ Step 3: Apply Descriptions EVERYWHERE (Most Critical!)
-
-**🚨 YOU MUST apply the SAME description to ALL of these locations:**
-
-### For Module Properties
-
-**1. Model file** (`<module>.model.ts`):
-```typescript
-@UnifiedField({ description: 'Product name (Produktname)' })
-name: string;
-```
-
-**2. Create Input** (`<module>-create.input.ts`):
-```typescript
-@UnifiedField({ description: 'Product name (Produktname)' })
-name: string;
-```
-
-**3. Update Input** (`<module>.input.ts`):
-```typescript
-@UnifiedField({ description: 'Product name (Produktname)' })
-name?: string;
-```
-
-### For SubObject Properties
-
-**1. Object file** (`<object>.object.ts`):
-```typescript
-@UnifiedField({ description: 'Street (Straße)' })
-street: string;
-```
-
-**2. Object Create Input** (`<object>-create.input.ts`):
-```typescript
-@UnifiedField({ description: 'Street (Straße)' })
-street: string;
-```
-
-**3. Object Update Input** (`<object>.input.ts`):
-```typescript
-@UnifiedField({ description: 'Street (Straße)' })
-street?: string;
-```
-
-### For Object/Module Type Decorators
-
-Apply descriptions to the class decorators as well:
-
-```typescript
-@ObjectType({ description: 'Address information (Adressinformationen)' })
-export class Address { ... }
-
-@InputType({ description: 'Address information (Adressinformationen)' })
-export class AddressInput { ... }
-
-@ObjectType({ description: 'Product entity (Produkt-Entität)' })
-export class Product extends CoreModel { ... }
-```
-
----
-
-## ⛔ Common Mistakes to AVOID
-
-1. ❌ **Partial application**: Descriptions only in Models, not in Inputs
-2. ❌ **Inconsistent format**: German-only in some places, English-only in others
-3. ❌ **Missing descriptions**: No descriptions when user provided comments
-4. ❌ **Ignoring Object inputs**: Forgetting to add descriptions to SubObject Input files
-5. ❌ **Wrong format**: Using `(ENGLISH)` instead of `ENGLISH (DEUTSCH)`
-6. ❌ **Changing wording**: Rephrasing user's original terms
-7. ❌ **Adding words**: Expanding user's terminology
-
----
-
-## ✅ Verification Checklist
-
-After generating code, ALWAYS verify:
-
-- [ ] All user comments/descriptions extracted from specification
-- [ ] All descriptions follow format: `"ENGLISH (DEUTSCH)"` or `"ENGLISH"`
-- [ ] Model properties have descriptions
-- [ ] Create Input properties have SAME descriptions
-- [ ] Update Input properties have SAME descriptions
-- [ ] Object properties have descriptions
-- [ ] Object Input properties have SAME descriptions
-- [ ] Class-level `@ObjectType()` and `@InputType()` have descriptions
-- [ ] NO German-only descriptions (must be translated)
-- [ ] NO inconsistencies between files
-- [ ] Original wording preserved (only typos fixed)
-
----
-
-## 🔄 If You Forget
-
-**If you generate code and realize descriptions are missing or inconsistent:**
-
-1. **STOP** - Don't continue with other phases
-2. **Go back** and add/fix ALL descriptions
-3. **Verify** using the checklist above
-4. **Then continue** with remaining phases
-
-**Remember**: Descriptions are NOT optional "nice-to-have" - they are MANDATORY for:
-- API documentation (Swagger/GraphQL)
-- Code maintainability
-- Developer experience
-- Bilingual projects (German/English teams)
-
----
-
-## Quick Reference
-
-### Format Rules
-
-```
-English input    → 'Product name'
-German input     → 'Product name (Produktname)'
-No input         → Create meaningful description
-Typo input       → Fix typo, then translate
-Mixed input      → Standardize to 'ENGLISH (DEUTSCH)'
-```
-
-### Application Checklist
-
-For **each property**:
-- [ ] Model file
-- [ ] Create Input file
-- [ ] Update Input file
-
-For **each class**:
-- [ ] @ObjectType() decorator
-- [ ] @InputType() decorator (if applicable)
-
-### Remember
-
-- **Consistency is critical** - Same description everywhere
-- **Preserve wording** - Only fix typos, never rephrase
-- **Bilingual format** - Always use "ENGLISH (DEUTSCH)" for German terms
-- **Verification** - Check all files before proceeding