@lenne.tech/cli 1.2.0 → 1.3.0

package/build/templates/claude-skills/building-stories-with-tdd/SKILL.md

@@ -1,265 +0,0 @@
----
-name: building-stories-with-tdd
-version: 1.2.0
-description: Expert for building user stories using Test-Driven Development (TDD) with NestJS and @lenne.tech/nest-server. Implements new features by creating story tests first in tests/stories/, then uses generating-nest-servers skill to develop code until all tests pass. Ensures high code quality and security compliance. Use in projects with @lenne.tech/nest-server in package.json dependencies (supports monorepos with projects/*, packages/*, apps/* structure).
----
-
-# Story-Based Test-Driven Development Expert
-
-You are an expert in Test-Driven Development (TDD) for NestJS applications using @lenne.tech/nest-server. You help developers implement new features by first creating comprehensive story tests, then iteratively developing the code until all tests pass.
-
-## When to Use This Skill
-
-**✅ ALWAYS use this skill for:**
-- Implementing new API features using Test-Driven Development
-- Creating story tests for user stories or requirements
-- Developing new functionality in a test-first approach
-- Ensuring comprehensive test coverage for new features
-- Iterative development with test validation
-
-## Related Skills
-
-**🔄 Works closely with:**
-- `generating-nest-servers` skill - For code implementation (modules, objects, properties)
-- `using-lt-cli` skill - For Git operations and project initialization
-
-**When to use which:**
-- Building new features with TDD? → Use this skill (building-stories-with-tdd)
-- Direct NestJS work without TDD? → Use `generating-nest-servers` skill
-- Git operations? → Use `using-lt-cli` skill
-
----
-
-## 🚨 GOLDEN RULES: API-First Testing 🚨
-
-**READ THIS BEFORE WRITING ANY TEST!**
-
-### Rule 1: Test Through API Only
-
-**Tests MUST go through REST/GraphQL interfaces using TestHelper. Direct Service or Database access in test logic makes tests WORTHLESS.**
-
-**Why this rule is absolute:**
-- **Security**: Direct Service calls bypass authentication, authorization, guards, decorators
-- **Reality**: Tests must verify what actual users experience through the API
-- **Worthless**: Tests bypassing the API cannot catch real bugs in the security layer
-
-**✅ ALWAYS:**
-- Use `testHelper.rest()` for REST endpoints
-- Use `testHelper.graphQl()` for GraphQL operations
-- Test the complete chain: API → Guards → Service → Database
-
-**❌ NEVER:**
-- Call Services directly: `userService.create()` ❌
-- Query DB in tests: `db.collection('users').findOne()` ❌
-- Mock Controllers/Resolvers ❌
-
-**🔓 Only Exception: Setup/Cleanup**
-- Setting roles: `db.collection('users').updateOne({ _id: id }, { $set: { roles: ['admin'] } })` ✅
-- Setting verified: `db.collection('users').updateOne({ _id: id }, { $set: { verified: true } })` ✅
-- Cleanup: `db.collection('entities').deleteMany({ createdBy: userId })` ✅
-
-### Rule 2: Verify Before Assuming
-
-**NEVER assume endpoints, methods, or properties exist - ALWAYS verify by reading the actual code!**
-
-**✅ BEFORE writing tests:**
-- Read Controller files to verify endpoints exist
-- Read Resolver files to verify GraphQL operations exist
-- Read existing tests to understand patterns
-- Document what you verified with file references
-
-**✅ BEFORE implementing:**
-- Read Service files to verify method signatures
-- Read Model files to verify properties and types
-- Read CrudService base class to understand inherited methods
-- Check actual code, don't assume!
-
-**❌ NEVER:**
-- Assume an endpoint exists without reading the controller ❌
-- Assume a method signature without reading the service ❌
-- Guess property names without reading the model ❌
-
-**Full details in Steps 1, 2, and 4 below.**
-
----
-
-## Core TDD Workflow - The Seven Steps
-
-**📖 Complete workflow details: `workflow.md`**
-
-**Process:** Step 1 (Analysis) → Step 2 (Create Test) → Step 3 (Run Tests) → [Step 3a: Fix Tests if needed] → Step 4 (Implement) → Step 5 (Validate) → Step 5a (Quality Check) → Step 5b (Final Validation)
-
----
-
-### Step 1: Story Analysis & Validation
-**📖 Details: `workflow.md` → Step 1**
-
-- Read story, verify existing API structure (read Controllers/Resolvers)
-- Document what exists vs what needs creation
-- Ask for clarification if ambiguous (use AskUserQuestion)
-
-### Step 2: Create Story Test
-**📖 Details: `workflow.md` → Step 2**
-
-**🚨 CRITICAL: Test through API only - NEVER direct Service/DB access!**
-
-- ✅ Use `testHelper.rest()` or `testHelper.graphQl()`
-- ❌ NEVER call Services directly or query DB in test logic
-- 🔓 Exception: Direct DB access ONLY for setup/cleanup (roles, verified status)
-
-**Test Data Rules (parallel execution):**
-1. Emails MUST end with `@test.com` (use: `user-${Date.now()}-${Math.random().toString(36).substring(2, 8)}@test.com`)
-2. Never reuse data across test files
-3. Only delete entities created in same test file
-4. Implement complete cleanup in `afterAll`
-
-### Step 3: Run Tests & Analyze
-**📖 Details: `workflow.md` → Step 3**
-
-```bash
-npm test  # Or: npm test -- tests/stories/your-story.story.test.ts
-```
-
-**Decide:** Test bugs → Step 3a | Implementation missing → Step 4
-
-### Step 3a: Fix Test Errors
-**📖 Details: `workflow.md` → Step 3a**
-
-Fix test logic/errors. NEVER "fix" by removing security. Return to Step 3 after fixing.
-
-### Step 4: Implement/Extend API Code
-**📖 Details: `workflow.md` → Step 4**
-
-**Use `generating-nest-servers` skill for:** Module/object creation, understanding existing code
-
-**Critical Rules:**
-1. **Property Descriptions:** Format as `ENGLISH (GERMAN)` when user provides German comments
-2. **ServiceOptions:** Only pass what's needed (usually just `currentUser`), NOT all options
-3. **Guards:** DON'T add `@UseGuards(AuthGuard(...))` - automatically activated by `@Roles()`
-4. **Database indexes:** Define in @UnifiedField decorator (see `database-indexes.md`)
-
-### Step 5: Validate & Iterate
-**📖 Details: `workflow.md` → Step 5**
-
-```bash
-npm test
-```
-
-✅ All pass → Step 5a | ❌ Fail → Return to Step 3
-
-### Step 5a: Code Quality & Refactoring Check
-**📖 Details: `workflow.md` → Step 5a**
-
-Review: Code quality (`code-quality.md`), Database indexes (`database-indexes.md`), Security (`security-review.md`). Run tests after changes.
-
-### Step 5b: Final Validation
-**📖 Details: `workflow.md` → Step 5b**
-
-Run all tests, verify quality checks, generate final report. DONE! 🎉
-
-## 🔄 Handling Existing Tests When Modifying Code
-
-**📖 Complete details: `handling-existing-tests.md`**
-
-**When your changes break existing tests:**
-- Intentional change? → Update tests + document why
-- Unclear? → Investigate with git (`git show HEAD`, `git diff`), fix to satisfy both old & new tests
-
-**Remember:** Existing tests document expected behavior - preserve backward compatibility!
-
----
-
-## ⛔ CRITICAL: GIT COMMITS
-
-**🚨 NEVER create git commits unless explicitly requested by the developer.**
-
-Your responsibility:
-- ✅ Create/modify files, run tests, provide comprehensive report
-- ❌ **NEVER commit to git without explicit request**
-
-You may remind in final report: "Implementation complete - review and commit when ready."
-
----
-
-## 🚨 CRITICAL SECURITY RULES
-
-**📖 Complete details: `security-review.md`**
-
-### ⛔ NEVER:
-- Remove/weaken `@Restricted()` or `@Roles()` decorators
-- Modify `securityCheck()` to bypass security
-- Add `@UseGuards(AuthGuard(...))` manually (automatically activated by `@Roles()`)
-
-### ✅ ALWAYS:
-- Analyze existing security before writing tests
-- Create appropriate test users with correct roles
-- Test with least-privileged users
-- Ask before changing ANY security decorator
-
-**When tests fail due to security:** Create proper test users with appropriate roles, NEVER remove security decorators.
-
-## Code Quality Standards
-
-**📖 Complete details: `code-quality.md`**
-
-**Must follow:**
-- File organization, naming conventions, import statements from existing code
-- Error handling and validation patterns
-- Use @lenne.tech/nest-server first, add packages as last resort
-
-**Test quality:**
-- 80-100% coverage, self-documenting, independent, repeatable, fast
-
-**🚨 NEVER use `declare` keyword** - it prevents decorators from working!
-
-## Autonomous Execution
-
-**Work autonomously:** Create tests, run tests, fix code, iterate Steps 3-5, use nest-server-generator skill
-
-**Only ask when:** Story ambiguous, security changes needed, new packages, architectural decisions, persistent failures
-
-## Final Report
-
-When all tests pass, provide comprehensive report including:
-- Story name, tests created (location, count, coverage)
-- Implementation summary (modules/objects/properties created/modified)
-- Test results (all passing, scenarios summary)
-- Code quality (patterns followed, security preserved, dependencies, refactoring, indexes)
-- Security review (auth/authz, validation, data exposure, ownership, injection prevention, errors, security tests)
-- Files modified (with changes description)
-- Next steps (recommendations)
-
-## Common Patterns
-
-**📖 Complete patterns and examples: `examples.md` and `reference.md`**
-
-**Study existing tests first!** Common patterns:
-- Create test users via `/auth/signin`, set roles/verified via DB
-- REST requests: `testHelper.rest('/api/...', { method, payload, token, statusCode })`
-- GraphQL queries: `testHelper.graphQl({ name, type, arguments, fields }, { token })`
-- Test organization: `describe` blocks for Happy Path, Error Cases, Edge Cases
-
-## Integration with generating-nest-servers
-
-**During Step 4 (Implementation), use `generating-nest-servers` skill for:**
-- Module creation (`lt server module`)
-- Object creation (`lt server object`)
-- Adding properties (`lt server addProp`)
-- Understanding existing code (Services, Controllers, Resolvers, Models, DTOs)
-
-**Best Practice:** Invoke skill for NestJS component work rather than manual editing.
-
-## Remember
-
-1. Tests first, code second - write tests before implementation
-2. Iterate until green - all tests must pass
-3. Security review mandatory - check before final tests
-4. Refactor before done - extract common functionality
-5. Security is sacred - never compromise for passing tests
-6. Quality over speed - good tests and clean code
-7. Ask when uncertain - clarify early
-8. Autonomous execution - work independently, report comprehensively
-9. Match existing patterns - equivalent implementation
-10. Clean up test data - comprehensive cleanup in afterAll
-
-**Goal:** Deliver fully tested, high-quality, maintainable, secure features that integrate seamlessly with existing codebase.

package/build/templates/claude-skills/building-stories-with-tdd/code-quality.md

@@ -1,276 +0,0 @@
----
-name: story-tdd-code-quality
-version: 1.0.0
-description: Code quality and refactoring guidelines for Test-Driven Development
----
-
-# Code Quality & Refactoring Check
-
-## Table of Contents
-- [1. Check for Code Duplication](#1-check-for-code-duplication)
-- [2. Extract Common Functionality](#2-extract-common-functionality)
-- [3. Consolidate Similar Code Paths](#3-consolidate-similar-code-paths)
-- [4. Review for Consistency](#4-review-for-consistency)
-- [5. Refactoring Decision Tree](#5-refactoring-decision-tree)
-- [6. Run Tests After Refactoring](#6-run-tests-after-refactoring)
-- [7. When to Skip Refactoring](#7-when-to-skip-refactoring)
-- [Quick Code Quality Checklist](#quick-code-quality-checklist)
-
-**BEFORE marking the task as complete, perform a code quality review!**
-
-Once all tests are passing, analyze your implementation for code quality issues.
-
----
-
-## 1. Check for Code Duplication
-
-**Identify redundant code patterns:**
-- Repeated logic in multiple methods
-- Similar code blocks with minor variations
-- Duplicated validation logic
-- Repeated data transformations
-- Multiple similar helper functions
-
-**Example of code duplication:**
-
-```typescript
-// ❌ BAD: Duplicated validation logic
-async createProduct(input: ProductInput) {
-  if (!input.name || input.name.trim().length === 0) {
-    throw new BadRequestException('Name is required');
-  }
-  if (!input.price || input.price <= 0) {
-    throw new BadRequestException('Price must be positive');
-  }
-  // ... create product
-}
-
-async updateProduct(id: string, input: ProductInput) {
-  if (!input.name || input.name.trim().length === 0) {
-    throw new BadRequestException('Name is required');
-  }
-  if (!input.price || input.price <= 0) {
-    throw new BadRequestException('Price must be positive');
-  }
-  // ... update product
-}
-
-// ✅ GOOD: Extracted to reusable function
-private validateProductInput(input: ProductInput) {
-  if (!input.name || input.name.trim().length === 0) {
-    throw new BadRequestException('Name is required');
-  }
-  if (!input.price || input.price <= 0) {
-    throw new BadRequestException('Price must be positive');
-  }
-}
-
-async createProduct(input: ProductInput) {
-  this.validateProductInput(input);
-  // ... create product
-}
-
-async updateProduct(id: string, input: ProductInput) {
-  this.validateProductInput(input);
-  // ... update product
-}
-```
-
----
-
-## 2. Extract Common Functionality
-
-**Look for opportunities to create helper functions:**
-- Data transformation logic
-- Validation logic
-- Query building
-- Response formatting
-- Common calculations
-
-**Example of extracting common functionality:**
-
-```typescript
-// ❌ BAD: Repeated price calculation logic
-async createOrder(input: OrderInput) {
-  let totalPrice = 0;
-  for (const item of input.items) {
-    const product = await this.productService.findById(item.productId);
-    totalPrice += product.price * item.quantity;
-  }
-  // ... create order
-}
-
-async estimateOrderPrice(items: OrderItem[]) {
-  let totalPrice = 0;
-  for (const item of items) {
-    const product = await this.productService.findById(item.productId);
-    totalPrice += product.price * item.quantity;
-  }
-  return totalPrice;
-}
-
-// ✅ GOOD: Extracted to reusable helper
-private async calculateOrderTotal(items: OrderItem[]): Promise<number> {
-  let totalPrice = 0;
-  for (const item of items) {
-    const product = await this.productService.findById(item.productId);
-    totalPrice += product.price * item.quantity;
-  }
-  return totalPrice;
-}
-
-async createOrder(input: OrderInput) {
-  const totalPrice = await this.calculateOrderTotal(input.items);
-  // ... create order
-}
-
-async estimateOrderPrice(items: OrderItem[]) {
-  return this.calculateOrderTotal(items);
-}
-```
-
----
-
-## 3. Consolidate Similar Code Paths
-
-**Identify code paths that can be unified:**
-- Methods with similar logic but different parameters
-- Conditional branches that can be combined
-- Similar error handling patterns
-
-**Example of consolidating code paths:**
-
-```typescript
-// ❌ BAD: Similar methods with duplicated logic
-async findProductsByCategory(category: string) {
-  return this.find({
-    where: { category },
-    relations: ['reviews', 'supplier'],
-    order: { createdAt: 'DESC' },
-  });
-}
-
-async findProductsBySupplier(supplierId: string) {
-  return this.find({
-    where: { supplierId },
-    relations: ['reviews', 'supplier'],
-    order: { createdAt: 'DESC' },
-  });
-}
-
-async findProductsByPriceRange(minPrice: number, maxPrice: number) {
-  return this.find({
-    where: { price: Between(minPrice, maxPrice) },
-    relations: ['reviews', 'supplier'],
-    order: { createdAt: 'DESC' },
-  });
-}
-
-// ✅ GOOD: Unified method with flexible filtering
-async findProducts(filters: {
-  category?: string;
-  supplierId?: string;
-  priceRange?: { min: number; max: number };
-}) {
-  const where: any = {};
-
-  if (filters.category) {
-    where.category = filters.category;
-  }
-
-  if (filters.supplierId) {
-    where.supplierId = filters.supplierId;
-  }
-
-  if (filters.priceRange) {
-    where.price = Between(filters.priceRange.min, filters.priceRange.max);
-  }
-
-  return this.find({
-    where,
-    relations: ['reviews', 'supplier'],
-    order: { createdAt: 'DESC' },
-  });
-}
-```
-
----
-
-## 4. Review for Consistency
-
-**Ensure consistent patterns throughout your implementation:**
-- Naming conventions match existing codebase
-- Error handling follows project patterns
-- Return types are consistent
-- Similar operations use similar approaches
-
----
-
-## 5. Refactoring Decision Tree
-
-```
-Code duplication detected?
-    │
-    ├─► Used in 2+ places?
-    │   │
-    │   ├─► YES: Extract to private method
-    │   │   │
-    │   │   └─► Used across multiple services?
-    │   │       │
-    │   │       ├─► YES: Consider utility class/function
-    │   │       └─► NO: Keep as private method
-    │   │
-    │   └─► NO: Leave as-is (don't over-engineer)
-    │
-    └─► Complex logic block?
-        │
-        ├─► Hard to understand?
-        │   └─► Extract to well-named method
-        │
-        └─► Simple and clear?
-            └─► Leave as-is
-```
-
----
-
-## 6. Run Tests After Refactoring
-
-**CRITICAL: After any refactoring:**
-
-```bash
-npm test
-```
-
-**Ensure:**
-- ✅ All tests still pass
-- ✅ No new failures introduced
-- ✅ Code is more maintainable
-- ✅ No functionality changed
-
----
-
-## 7. When to Skip Refactoring
-
-**Don't refactor if:**
-- Code is used in only ONE place
-- Extraction would make code harder to understand
-- The duplication is coincidental, not conceptual
-- Time constraints don't allow for safe refactoring
-
-**Remember:**
-- **Working code > Perfect code**
-- **Refactor only if it improves maintainability**
-- **Always run tests after refactoring**
-
----
-
-## Quick Code Quality Checklist
-
-Before marking complete:
-
-- [ ] **No obvious code duplication**
-- [ ] **Common functionality extracted to helpers**
-- [ ] **Consistent patterns throughout**
-- [ ] **Code follows existing patterns**
-- [ ] **Proper error handling**
-- [ ] **Tests still pass after refactoring**