feat: Add Claude skills, agents, adapt .gitignore, adapt pipeline.sh with different cache location

.claude/agents/feature-implementer.md

@@ -30,72 +30,6 @@ You implement features following the platform's established architecture and con
 - Keycloak OAuth2/JWT authentication
 - OpenAPI 3.0.3 for API specification
 
-## Critical Implementation Rules
-
-### 1. API-First Development
-- **ALWAYS** start by modifying the OpenAPI spec (`api/legalconsenthub.yml`)
-- Define request/response schemas with proper validation
-- Document all endpoints with descriptions and examples
-- After spec changes, regenerate clients:
-  - Frontend: `pnpm run api:generate`
-  - Backend: `./gradlew generate_legalconsenthub_server`
-- Never bypass the API spec - it is the source of truth
-
-### 2. Database Migrations
-- **NEVER auto-generate SQL** - all migrations are manual
-- Create Liquibase changesets in `legalconsenthub-backend/src/main/resources/db/changelog/`
-- Use descriptive changeset IDs with timestamps
-- Include rollback statements when possible
-- Test migrations on clean database before committing
-
-### 3. Data Mapping
-- **ALWAYS use mapper classes** for DTO ↔ Entity conversions
-- Place mappers in dedicated mapper packages
-- Never perform mapping in services or controllers
-- Keep mapping logic pure and testable
-- Use `@Mapper(componentModel = "spring")` for MapStruct
-
-### 4. Internationalization
-- **NO hardcoded UI strings** - use i18n for all user-facing text
-- Add translations to both `de.json` and `en.json`
-- Use descriptive, hierarchical keys (e.g., `applicationForm.validation.required`)
-- Test both languages before considering feature complete
-
-### 5. Multi-Tenancy
-- **ALWAYS consider organizationId** for data isolation
-- Filter queries by organizationId (except for global forms)
-- Forms with empty/null organizationId are "global" and visible to all
-- Validate organization access in service layer
-- Never expose data across organization boundaries
-
-### 6. Form Structure
-Understand the 3-level hierarchy:
-```
-ApplicationForm
-  └── Section (FormElementSection)
-       └── SubSection (FormElementSubSection)
-            └── FormElement (various types)
-```
-
-**Element Types:** SELECT, CHECKBOX, RADIOBUTTON, TEXTFIELD, TEXTAREA, SWITCH, RICH_TEXT, DATE, TABLE
-
-**Key Features:**
-- Visibility conditions (AND logic, reference-based)
-- Section spawning from templates
-- Clonable elements with reference generation
-- Table cross-references and row presets
-
-### 7. Code Organization
-- Order functions top-down by abstraction (public API first)
-- Keep related functionality cohesive
-- Extract complex logic into well-named private methods
-- Follow existing naming conventions in the codebase
-
-### 8. Roles and Security
-- Roles managed in Keycloak, not application database
-- Use role-based authorization at controller level
-- Available roles: CHIEF_EXECUTIVE_OFFICER, BUSINESS_DEPARTMENT, IT_DEPARTMENT, HUMAN_RESOURCES, HEAD_OF_WORKS_COUNCIL, WORKS_COUNCIL, EMPLOYEE
-
 ## Implementation Workflow
 
 When implementing a feature:
@@ -113,7 +47,7 @@ When implementing a feature:
    - Consider pagination, filtering, sorting if applicable
 
 3. **Database Layer**
-   - Not needed, will be done manually
+   - No migration needed, will be done manually by the user
 
 4. **Backend Implementation**
    - Generate API server code from spec
@@ -130,7 +64,7 @@ When implementing a feature:
    - Add composables for reusable logic
    - Implement i18n strings for both languages
    - Add client-side validation
-   - Write component tests
+   - Don't write any tests
 
 6. **PDF Export** (if form-related)
    - Update LaTeX template if new form elements added
@@ -144,10 +78,6 @@ When implementing a feature:
    - Ensure seed data reflects new feature structure
 
 8. **Quality Assurance**
-   - Test all CRUD operations
-   - Verify multi-tenancy isolation
-   - Check both German and English translations
-   - Test role-based access control
    - Verify API error handling
    - Test edge cases and validation rules