@lenne.tech/cli 1.0.1 → 1.1.0

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

@@ -0,0 +1,303 @@
+---
+name: generating-nest-servers
+version: 1.1.0
+description: PRIMARY expert for ALL NestJS and @lenne.tech/nest-server tasks. ALWAYS use this skill when working in projects with @lenne.tech/nest-server in package.json dependencies (supports monorepos with projects/*, packages/*, apps/* structure), or when asked about NestJS modules, services, controllers, resolvers, models, objects, tests, server creation, debugging, or any NestJS/nest-server development task. Handles lt server commands, security analysis, test creation, and all backend development. ALWAYS reads CrudService base class before working with Services.
+---
+
+# NestJS Server Development Expert
+
+You are the **PRIMARY expert** for NestJS backend development and the @lenne.tech/nest-server framework. This skill handles **ALL NestJS-related tasks**, from analysis to creation to debugging:
+
+## When to Use This Skill
+
+**✅ ALWAYS use this skill for:**
+
+### Analysis & Understanding
+- 📖 Analyzing existing NestJS code structure
+- 🔍 Understanding how modules, services, controllers work
+- 📊 Reviewing project architecture
+- 🗺️ Mapping relationships between modules
+- 📝 Reading and explaining NestJS code
+- 🔎 Finding specific implementations (controllers, services, etc.)
+
+### Running & Debugging
+- 🚀 Starting the NestJS server (`npm start`, `npm run dev`)
+- 🐛 Debugging server issues and errors
+- 🧪 Running tests (`npm test`)
+- 📋 Checking server logs and output
+- ⚙️ Configuring environment variables
+- 🔧 Troubleshooting build/compile errors
+
+### Creation & Modification
+- ✨ Creating new modules with `lt server module`
+- 🎨 Creating new objects with `lt server object`
+- ➕ Adding properties with `lt server addProp`
+- 🏗️ Creating a new server with `lt server create`
+- ♻️ Modifying existing code (services, controllers, resolvers)
+- 🔗 Adding relationships between modules
+- 📦 Managing dependencies and imports
+
+### Testing & Validation
+- ✅ Creating API tests for controllers/resolvers
+- 🧪 Running and fixing failing tests
+- 🎯 Testing endpoints manually
+- 📊 Validating data models and schemas
+- 🔐 Testing authentication and permissions
+
+### General NestJS Tasks
+- 💬 Answering NestJS/nest-server questions
+- 📚 Explaining framework concepts
+- 🏛️ Discussing architecture decisions
+- 🛠️ Recommending best practices
+- 🔄 Refactoring existing code
+
+**🎯 Rule: If it involves NestJS or @lenne.tech/nest-server in ANY way, use this skill!**
+
+## Related Skills
+
+**🔄 Works closely with:**
+- `building-stories-with-tdd` skill - For building user stories with Test-Driven Development
+- `using-lt-cli` skill - For Git operations and Fullstack initialization
+
+**When to use which:**
+- Building features with TDD workflow? → Use `building-stories-with-tdd` skill (it will use this skill for implementation)
+- Need Git operations? → Use `using-lt-cli` skill
+- Direct NestJS work? → Use this skill
+
+---
+
+## 🚨 CRITICAL SECURITY RULES - READ FIRST
+
+**Before you start ANY work, understand these NON-NEGOTIABLE rules:**
+
+### ⛔ NEVER Do This:
+1. **NEVER remove or weaken `@Restricted()` decorators**
+2. **NEVER change `@Roles()` decorators** to more permissive roles
+3. **NEVER modify `securityCheck()` logic** to bypass security
+4. **NEVER remove class-level `@Restricted(RoleEnum.ADMIN)`**
+
+### ✅ ALWAYS Do This:
+1. **ALWAYS analyze permissions BEFORE writing tests**
+2. **ALWAYS test with the LEAST privileged user** who is authorized
+3. **ALWAYS adapt tests to security requirements**, never vice versa
+4. **ALWAYS ask developer for approval** before changing ANY security decorator
+
+**📖 Complete security rules with all details, examples, and testing strategies: `security-rules.md`**
+
+## 🚨 CRITICAL: NEVER USE `declare` KEYWORD FOR PROPERTIES
+
+**⚠️ DO NOT use the `declare` keyword when defining properties in classes!**
+
+```typescript
+// ❌ WRONG
+declare name: string;  // Decorator won't work!
+
+// ✅ CORRECT
+@UnifiedField({ description: 'Product name' })
+name: string;  // Decorator works properly
+```
+
+**Why**: `declare` prevents decorators from being applied, breaking the decorator system.
+
+**📖 Complete explanation and correct patterns: `declare-keyword-warning.md`**
+
+## 🚨 CRITICAL: DESCRIPTION MANAGEMENT
+
+**⚠️ Descriptions must be applied consistently to EVERY component.**
+
+**Quick 3-Step Process:**
+1. Extract descriptions from user's `// comments`
+2. Format: `'English text'` or `'English (Deutsch)'` for German input
+3. Apply EVERYWHERE: Model, CreateInput, UpdateInput, Objects, Class-level decorators
+
+**📖 Complete formatting rules, examples, and verification checklist: `description-management.md`**
+
+---
+
+## Core Responsibilities
+
+This skill handles **ALL** NestJS server development tasks, including:
+
+### Simple Tasks (Single Commands)
+- Creating a single module with `lt server module`
+- Creating a single object with `lt server object`
+- Adding properties with `lt server addProp`
+- Creating a new server with `lt server create`
+- Starting the server with `npm start` or `npm run dev`
+- Running tests with `npm test`
+
+### Complex Tasks (Multiple Components)
+When you receive a complete structure specification, you will:
+
+1. **Parse and analyze** the complete structure (modules, models, objects, properties, relationships)
+2. **Create a comprehensive todo list** breaking down all tasks
+3. **Generate all components** in the correct order (objects first, then modules)
+4. **Handle inheritance** properly (Core and custom parent classes)
+5. **Manage descriptions** (translate German to English, add originals in parentheses)
+6. **Create API tests** for all controllers and resolvers
+7. **Verify functionality** and provide a summary with observations
+
+### Analysis Tasks
+When analyzing existing code:
+
+1. **Explore the project structure** to understand the architecture
+2. **Read relevant files** (modules, services, controllers, models)
+3. **Identify patterns** and conventions used in the project
+4. **Explain findings** clearly and concisely
+5. **Suggest improvements** when appropriate
+
+### Debugging Tasks
+When debugging issues:
+
+1. **Read error messages and logs** carefully
+2. **Identify the root cause** by analyzing relevant code
+3. **Check configuration** (environment variables, config files)
+4. **Test hypotheses** by examining related files
+5. **Provide solutions** with code examples
+
+**Remember:** For ANY task involving NestJS or @lenne.tech/nest-server, use this skill!
+
+## 📚 Understanding the Framework
+
+**📖 Complete framework guide: `framework-guide.md`**
+
+**Critical Rules:**
+- [ ] Read CrudService before modifying any Service (`node_modules/@lenne.tech/nest-server/src/core/common/services/crud.service.ts`)
+- [ ] NEVER blindly pass all serviceOptions to other Services (only pass `currentUser`)
+- [ ] Check if CrudService already provides needed functionality (create, find, findOne, update, delete, pagination)
+
+## Configuration File & Commands
+
+**📖 Complete guide: `configuration.md`**
+
+**Quick Command Reference:**
+```bash
+# Create complete module
+lt server module --name Product --controller Rest|GraphQL|Both|auto
+
+# Create SubObject
+lt server object --name Address
+
+# Add properties
+lt server addProp --type Module --element User
+
+# New project
+lt server create <server-name>
+```
+
+**Essential Property Flags:**
+- `--prop-name-X / --prop-type-X` - Name and type (string|number|boolean|ObjectId|Json|Date|bigint)
+- `--prop-nullable-X` / `--prop-array-X` - Modifiers
+- `--prop-enum-X / --prop-schema-X / --prop-reference-X` - Complex types
+
+## Prerequisites Check
+
+**Setup:**
+```bash
+lt --version  # Check CLI installation
+npm install -g @lenne.tech/cli  # If needed
+ls src/server/modules  # Verify project structure
+```
+
+**Creating New Server:**
+```bash
+lt server create <server-name>
+```
+
+**Post-creation verification:** Check `src/config.env.ts` for replaced secrets and correct database URIs.
+
+## Understanding the Specification Format
+
+**📖 Complete reference and examples: `reference.md` and `examples.md`**
+
+**Quick Type Reference:**
+- Basic: `string`, `number`, `boolean`, `Date`, `bigint`, `Json`
+- Arrays: `type[]` → add `--prop-array-X true`
+- Optional: `property?: type` → add `--prop-nullable-X true`
+- References: `User` → use `--prop-type-X ObjectId --prop-reference-X User`
+- Embedded: `Address` → use `--prop-schema-X Address`
+- Enums: `ENUM (VAL1, VAL2)` → use `--prop-enum-X PropertyNameEnum`
+
+## Workflow Process
+
+**📖 Complete details: `workflow-process.md`**
+
+**7-Phase Workflow:**
+1. Analysis & Planning → Parse spec, create todo list
+2. SubObject Creation → Create in dependency order
+3. Module Creation → Create with all properties
+4. Inheritance Handling → Update extends, CreateInput must include parent fields
+5. **Description Management** ⚠️ **CRITICAL** → Extract from comments, format as "ENGLISH (DEUTSCH)", apply everywhere
+6. Enum File Creation → Manual creation in `src/server/common/enums/`
+7. API Test Creation → **MANDATORY:** Analyze permissions first, use least privileged user, test failures
+
+**Critical Testing Rules:**
+- ✅ Test via REST/GraphQL using TestHelper (NEVER direct Service tests)
+- ✅ Analyze @Roles decorators BEFORE writing tests
+- ✅ Use appropriate user role (not admin when S_USER works)
+- ✅ Test unauthorized access failures (401/403)
+
+## Property Ordering
+
+**ALL properties must be in alphabetical order** in Model, Input, and Output files. Verify and reorder after generating.
+
+## Verification Checklist
+
+**📖 Complete checklist: `verification-checklist.md`**
+
+**Essential Checks:**
+- [ ] All components created with descriptions (Model + CreateInput + UpdateInput)
+- [ ] Properties in alphabetical order
+- [ ] Permission analysis BEFORE writing tests
+- [ ] Least privileged user used in tests
+- [ ] Security validation tests (401/403 failures)
+- [ ] All tests pass
+
+## Error Handling
+
+**Common Issues:**
+- **TypeScript errors** → Add missing imports manually
+- **CreateInput validation fails** → Check parent's CreateInput for required fields
+- **Tests fail with 403** → Check @Roles decorator, use appropriate user role (not admin when S_USER works)
+- **Security tests not failing** → Verify @Roles and securityCheck() logic, fix model/controller if needed
+
+## Phase 8: Pre-Report Quality Review
+
+**📖 Complete process: `quality-review.md`**
+
+**7 Steps:**
+1. Identify all changes (git)
+2. Test management (analyze existing tests, create new, follow patterns)
+3. Compare with existing code (consistency)
+4. Critical analysis (style, structure, quality)
+5. Automated optimizations (imports, properties, formatting)
+6. Pre-report testing (build, lint, all tests must pass)
+7. Final verification (complete checklist)
+
+**Critical:** Understand TestHelper, analyze existing tests first, use appropriate user roles, all tests must pass.
+
+## Final Report
+
+After completing all tasks, provide:
+1. Summary of created components (SubObjects, Objects, Modules, enums, tests)
+2. Observations about data structure
+3. Test results (all passing)
+4. Next steps
+
+## Best Practices
+
+1. Create dependencies first (SubObjects before Modules)
+2. Check for circular dependencies
+3. Test incrementally, commit after major components
+4. Use appropriate controller types (Rest/GraphQL/Both)
+5. Validate required fields in tests
+6. Document complex relationships
+
+## Working with This Skill
+
+When receiving a specification:
+1. Parse completely, ask clarifying questions
+2. Create detailed todo list
+3. Execute systematically following workflow
+4. Verify each step, report progress
+5. Provide comprehensive summary

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/configuration.md

@@ -4,6 +4,12 @@ version: 1.0.0
 description: Complete guide to lt.config.json configuration file
 ---
 
+# Configuration Guide
+
+## Table of Contents
+- [Configuration File (lt.config.json)](#configuration-file-ltconfigjson)
+- [Command Syntax Reference](#command-syntax-reference)
+
 ## Configuration File (lt.config.json)
 
 The lenne.tech CLI supports project-level configuration via `lt.config.json` files. This allows you to set default values for commands, eliminating the need for repeated CLI parameters or interactive prompts.

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/declare-keyword-warning.md

@@ -6,6 +6,15 @@ description: Critical warning about using the declare keyword in TypeScript clas
 
 # 🚨 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.

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/description-management.md

@@ -6,6 +6,15 @@ description: Guidelines for consistent description management across all generat
 
 # 🚨 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.
 
 ---

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/examples.md

@@ -6,6 +6,13 @@ description: Complete examples for generating NestJS server structures from spec
 
 # NestJS Server Generator Examples
 
+## Table of Contents
+- [Example 1: Library Management System](#example-1-library-management-system)
+- [Example 2: Hotel Booking System (Minimal)](#example-2-hotel-booking-system-minimal)
+- [Key Patterns Demonstrated](#key-patterns-demonstrated)
+- [Best Practices from Examples](#best-practices-from-examples)
+- [Quality Review Workflow Example](#quality-review-workflow-example)
+
 ## Example 1: Library Management System
 
 This example demonstrates all features:

package/build/templates/claude-skills/generating-nest-servers/framework-guide.md

@@ -0,0 +1,259 @@
+---
+name: nest-server-generator-framework
+version: 1.0.0
+description: Complete guide to @lenne.tech/nest-server framework - CrudService base class, ServiceOptions handling, patterns for Service inheritance, and best practices for working with the framework
+---
+
+# 📚 Understanding the @lenne.tech/nest-server Framework
+
+## Table of Contents
+- [Core Service Base Class: CrudService](#core-service-base-class-crudservice)
+- [CRITICAL: ServiceOptions When Calling Other Services](#-critical-serviceoptions-when-calling-other-services)
+- [Framework Patterns](#framework-patterns)
+- [Key Takeaways](#key-takeaways)
+
+## Core Service Base Class: CrudService
+
+**IMPORTANT**: Before working with Services, ALWAYS read this file to understand the base functionality:
+
+```
+node_modules/@lenne.tech/nest-server/src/core/common/services/crud.service.ts
+```
+
+**Why this is critical:**
+- Almost ALL Services extend `CrudService<Model>`
+- CrudService provides base CRUD operations (create, find, update, delete)
+- Understanding CrudService prevents reinventing the wheel
+- Shows patterns for handling permissions, filtering, and pagination
+
+**When to read CrudService:**
+1. ✅ Before creating a new Service
+2. ✅ When implementing custom Service methods
+3. ✅ When debugging Service behavior
+4. ✅ When writing tests for Services
+5. ✅ When questions arise about Service functionality
+
+**What CrudService provides:**
+- `create(input, options)` - Create new document
+- `find(filterArgs)` - Find multiple documents
+- `findOne(filterArgs)` - Find single document
+- `findAndCount(filterArgs)` - Find with total count (pagination)
+- `update(id, input, options)` - Update document
+- `delete(id, options)` - Delete document
+- Permission handling via `options.roles`
+- Query filtering and population
+- Pagination support
+
+**Example Service that extends CrudService:**
+```typescript
+@Injectable()
+export class ProductService extends CrudService<Product> {
+  constructor(
+    @InjectModel(Product.name) protected readonly productModel: Model<ProductDocument>,
+    protected readonly configService: ConfigService,
+  ) {
+    super({ configService, mainDbModel: productModel, mainModelConstructor: Product });
+  }
+
+  // Custom methods can be added here
+  // Base CRUD methods are inherited from CrudService
+}
+```
+
+**Action Items:**
+- [ ] Read CrudService before modifying any Service
+- [ ] Check if CrudService already provides the needed functionality
+- [ ] Only add custom methods if CrudService doesn't cover the use case
+- [ ] Follow CrudService patterns for consistency
+
+---
+
+## 🚨 CRITICAL: ServiceOptions When Calling Other Services
+
+**NEVER blindly pass all ServiceOptions when calling another Service!**
+
+When a Service method calls another Service, you must carefully analyze which options to pass:
+
+### ❌ WRONG - Blindly passing all options
+
+```typescript
+async createOrder(input: CreateOrderInput, serviceOptions: ServiceOptions) {
+  // ❌ BAD: Passes ALL serviceOptions without checking
+  const product = await this.productService.findOne({ id: input.productId }, serviceOptions);
+
+  // ❌ BAD: inputType might be wrong for userService
+  const user = await this.userService.findOne({ id: input.userId }, serviceOptions);
+}
+```
+
+### ✅ CORRECT - Selectively passing required options
+
+```typescript
+async createOrder(input: CreateOrderInput, serviceOptions: ServiceOptions) {
+  // ✅ GOOD: Only pass currentUser (needed for permissions)
+  const product = await this.productService.findOne(
+    { id: input.productId },
+    { currentUser: serviceOptions.currentUser }
+  );
+
+  // ✅ GOOD: Only set inputType if different Input class is needed
+  const user = await this.userService.findOne(
+    { id: input.userId },
+    {
+      currentUser: serviceOptions.currentUser,
+      inputType: UserInput // Only if specific Input class needed (e.g., UserInput, UserInputCreate)
+    }
+  );
+
+  // ✅ ALSO GOOD: Don't pass inputType if not needed
+  const category = await this.categoryService.findOne(
+    { id: input.categoryId },
+    { currentUser: serviceOptions.currentUser } // No inputType - use default
+  );
+}
+```
+
+### Why this is critical
+
+- **inputType** specifies which Input class (DTO) to use for validation (e.g., `UserInput`, `UserInputCreate`)
+- The inputType from outer service might be wrong for inner service call
+- **roles** might need to be different for the called service
+- **Other options** (limit, skip, etc.) might not apply to the inner call
+- Blindly passing options can cause **incorrect permission checks** or **wrong validation**
+- Can lead to **unexpected behavior** in nested service calls
+
+### Analysis Checklist Before Passing ServiceOptions
+
+1. **Analyze current serviceOptions:**
+   ```typescript
+   // What's in serviceOptions right now?
+   // - currentUser? (usually needed)
+   // - inputType? (which Input class: UserInput, UserInputCreate, etc.?)
+   // - roles? (are these the right roles?)
+   // - other options? (limit, skip, populate, etc.)
+   ```
+
+2. **Check target Service requirements:**
+   - What does the target Service method need?
+   - Read the target Service method signature
+   - Check what permissions/validations it performs
+   - Understand which Input class (inputType) is appropriate
+
+3. **Pass only required options:**
+   ```typescript
+   // Build options object with only what's needed
+   const targetOptions: ServiceOptions = {
+     currentUser: serviceOptions.currentUser, // Usually needed
+     // inputType: Only set if specific Input class is needed (e.g., UserInput, UserInputCreate)!
+     // roles: Only if different roles are needed
+     // Don't include: limit, skip, etc. unless specifically needed
+   };
+   ```
+
+### Common Patterns
+
+- **Reading data for validation**: Usually only need `currentUser` (no inputType needed)
+- **Creating related entities**: May need different Input class as inputType (e.g., `UserInputCreate` instead of `UserInput`)
+- **Admin operations**: May need to override `roles` or set specific Input class (only if necessary)
+- **Nested CRUD operations**: Carefully consider each option - often only currentUser needed
+
+### Action Items
+
+- [ ] Before calling another Service, analyze current serviceOptions
+- [ ] Determine which options the target Service actually needs
+- [ ] Only pass required options (usually just currentUser)
+- [ ] Only set inputType if a specific Input class (DTO) is needed (e.g., UserInput, UserInputCreate)
+- [ ] NEVER blindly pass all serviceOptions
+
+---
+
+## Framework Patterns
+
+### Service Inheritance Pattern
+
+All Services follow this pattern:
+
+```typescript
+@Injectable()
+export class YourService extends CrudService<YourModel> {
+  constructor(
+    @InjectModel(YourModel.name) protected readonly yourModel: Model<YourModelDocument>,
+    protected readonly configService: ConfigService,
+    // Inject other services if needed
+    private readonly otherService: OtherService,
+  ) {
+    super({
+      configService,
+      mainDbModel: yourModel,
+      mainModelConstructor: YourModel
+    });
+  }
+
+  // Add custom methods here
+  async customMethod(input: SomeInput, serviceOptions?: ServiceOptions) {
+    // Your custom logic
+    // Can call base methods: this.create(), this.find(), etc.
+    // Can call other services with proper ServiceOptions handling
+  }
+}
+```
+
+### Controller/Resolver Pattern
+
+Controllers and Resolvers use Services:
+
+```typescript
+@Controller('api/products')
+export class ProductController {
+  constructor(private readonly productService: ProductService) {}
+
+  @Get()
+  @Roles(RoleEnum.S_USER)
+  async getProducts(@CurrentUser() user: User) {
+    return this.productService.find({ currentUser: user });
+  }
+
+  @Post()
+  @Roles(RoleEnum.S_USER)
+  async createProduct(
+    @Body() input: ProductCreateInput,
+    @CurrentUser() user: User
+  ) {
+    return this.productService.create(input, { currentUser: user });
+  }
+}
+```
+
+### Permission Handling Pattern
+
+```typescript
+// In Model
+export class Product extends CoreModel {
+  securityCheck(user: User, force?: boolean) {
+    if (force || user?.hasRole(RoleEnum.ADMIN)) {
+      return this; // Admin sees all
+    }
+    if (!equalIds(user, this.createdBy)) {
+      return undefined; // Non-creator gets nothing
+    }
+    return this; // Creator sees own products
+  }
+}
+
+// In Service
+async customMethod(input: Input, serviceOptions?: ServiceOptions) {
+  // CrudService automatically applies securityCheck
+  const results = await this.find({ currentUser: serviceOptions.currentUser });
+  // Only products passing securityCheck are returned
+}
+```
+
+---
+
+## Key Takeaways
+
+1. **Always read CrudService first** - Understand what's already provided
+2. **Never blindly pass ServiceOptions** - Analyze and pass only what's needed
+3. **Follow framework patterns** - Inherit from CrudService, use proper decorators
+4. **Understand permission flow** - securityCheck + serviceOptions.currentUser + @Roles
+5. **inputType is the Input CLASS** - Not an enum, but the actual DTO class (e.g., UserInput, UserInputCreate)

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/quality-review.md

@@ -6,6 +6,15 @@ description: Comprehensive quality review guidelines before creating final repor
 
 # Phase 8: Pre-Report Quality Review
 
+## Table of Contents
+- [Step 1: Identify All Changes](#step-1-identify-all-changes)
+- [Step 2: Test Management](#step-2-test-management)
+- [Step 3: Compare with Existing Code](#step-3-compare-with-existing-code)
+- [Step 4: Critical Analysis](#step-4-critical-analysis)
+- [Step 5: Automated Optimizations](#step-5-automated-optimizations)
+- [Step 6: Pre-Report Testing](#step-6-pre-report-testing)
+- [Step 7: Final Verification](#step-7-final-verification)
+
 **CRITICAL**: Before creating the final report, you MUST perform a comprehensive quality review:
 
 ## Step 1: Identify All Changes

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/reference.md

@@ -6,6 +6,22 @@ description: Quick reference for ALL NestJS server development - from simple sin
 
 # NestJS Server Development Quick Reference
 
+## Table of Contents
+- [Scope](#scope)
+- [Specification Syntax](#specification-syntax)
+- [Execution Workflow](#execution-workflow)
+- [Command Quick Reference](#command-quick-reference)
+- [Description Format](#description-format)
+- [Inheritance Handling](#inheritance-handling)
+- [Enum File Template](#enum-file-template)
+- [API Test Template](#api-test-template)
+- [Common Patterns](#common-patterns)
+- [Troubleshooting](#troubleshooting)
+- [Verification Checklist](#verification-checklist)
+- [File Structure](#file-structure)
+- [Best Practices Summary](#best-practices-summary)
+- [Quick Start](#quick-start)
+
 ## Scope
 
 **This skill handles ALL NestJS server development tasks:**

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/security-rules.md

@@ -6,6 +6,19 @@ description: Critical security and test coverage rules for NestJS development
 
 # 🚨 CRITICAL SECURITY RULES
 
+## Table of Contents
+- [NEVER Do This](#-never-do-this)
+- [ALWAYS Do This](#-always-do-this)
+- [Permission Hierarchy (Specific Overrides General)](#-permission-hierarchy-specific-overrides-general)
+- [Rule 1: NEVER Weaken Security for Test Convenience](#rule-1-never-weaken-security-for-test-convenience)
+- [Rule 2: Understanding Permission Hierarchy](#rule-2-understanding-permission-hierarchy)
+- [Rule 3: Adapt Tests to Security, Not Vice Versa](#rule-3-adapt-tests-to-security-not-vice-versa)
+- [Rule 4: Test with Least Privileged User](#rule-4-test-with-least-privileged-user)
+- [Rule 5: Create Appropriate Test Users](#rule-5-create-appropriate-test-users)
+- [Rule 6: Comprehensive Test Coverage](#rule-6-comprehensive-test-coverage)
+- [Quick Security Checklist](#quick-security-checklist)
+- [Security Decision Protocol](#security-decision-protocol)
+
 **Before you start ANY work, understand these NON-NEGOTIABLE rules.**
 
 ---