Read the checked-in skill for the task at hand. Installation is optional for reading these files; see Work with AI for native skill discovery.

Read the relevant guideline for a rule-governed change. Keep procedures in the matching skill. When changing a convention, update its skill and supporting documentation in the same change.

These are Artemis-specific rules. The linked guidelines give reasons and exceptions; the skills give procedures.

• Transactions belong in repositories, not services or controllers. Do not use @Transactional, TransactionTemplate or PlatformTransactionManager there. server development
• Do not keep EntityManager or EntityManagerFactory fields in production code. Use Spring Data repositories; raw JDBC access is limited to core.config. server development
• Do not use FetchType.EAGER for @OneToOne, @OneToMany or @ManyToMany. Explicitly set @OneToOne to LAZY; do not grow FIELDS_ALLOWED_TO_FETCH_EAGERLY. database
• Do not fetch a lazy configuration through its parent entity, even with @EntityGraph or JOIN FETCH. A dependent configuration keeps the parent's key; the parent has no inverse @OneToOne field. Read it through its own repository. database
• Do not add @Lob or Hibernate second-level @Cache. Use Spring caching only with explicit eviction. database · caching
• Cross-node state goes through DistributedDataProvider, never direct Hazelcast or Redis access. Use getExpiringMap(name, ttl) for entries with a lifetime. distributed data
• Specify a locale for Java case conversion, including in tests. Use Locale.ROOT for machine values; keep Locale.ENGLISH only where the same login convention already applies. server development
• Jackson 3 uses tools.jackson; annotations remain com.fasterxml.jackson.annotation. Inject the configured JsonMapper in Spring beans; see the REST API guideline for other contexts.

• Use signal APIs. @Input, @Output, @ViewChild, @ViewChildren, @ContentChild and @ContentChildren are banned in application and test support code; ngOnChanges is banned. client development
• Use @if, @for and @switch, not structural directives. client development
• In production client TypeScript, do not copy objects with spread, Object.assign or structuredClone; use the repository's deep-clone helpers. Array spread and object rest are allowed. client development
• Use TUM UI and Tailwind. Do not add Bootstrap or ng-bootstrap. If TUM UI lacks a reusable feature, extend it; use PrimeNG only if that cannot reasonably be done in the same change, and explain the fallback in the PR. TUM UI
• Use semantic colour tokens, not primitive colours, Bootstrap classes or hand-written PrimeNG root classes. client theming

• Remove unreachable code, even when its only user is its own test. Required checks run on every PR: python3 supporting_scripts/check_dead_code.py and pnpm run dead-code:client. dead code
• Use client and server, not "frontend" or "backend". Use provider for a swappable distributed-data implementation and adapter for its glue. This also applies to commit messages and PR text. terminology

• The server uses Spring Boot 4.1 and Java 25; the client uses Angular 22. Use the Gradle wrapper, Node 24, and the pnpm version pinned in package.json (corepack enable). Exact versions live in gradle.properties, pnpm-workspace.yaml, and package.json.
• Server features live under src/main/java/de/tum/cit/aet/artemis/; the Angular application is under src/main/webapp/app/. Keep reusable TUM UI components in packages/tum-ui, with no imports from the Artemis application. Client tests are co-located; server tests are in src/test/java, Playwright tests in src/test/playwright.
• src/main/webapp/app/openapi/ is generated client code. Change the API source/generation input rather than hand-editing generated output.
• Before starting or stopping local services, identify the environment and who owns it. The E2E runners can kill processes on ports 8080, 9000 and 7921. Reuse a suitable running environment; do not stop unrelated services or run mutating tests against production.

• User-facing documentation belongs in documentation/docs/, grouped by audience. Tool-local READMEs stay beside their tools. Do not create a top-level docs/ directory.
• When writing documentation, follow the documentation guideline. Register new pages in the matching sidebar and link them from related pages.
• Do not commit plans, design specs or scratch notes. Keep working notes in the issue or PR; maintained documentation belongs on the documentation site.

• For Playwright locators, use data-testid first; never use styling classes. See E2E testing and write-tests.
• Do not edit src/main/webapp during an E2E run; hot reload can invalidate the test.
• pnpm run vitest:run -- <path> runs the whole suite. Use pnpm exec vitest run <path> for one file. See write-tests for the other test commands.

• Target develop; rebase to reduce noise. Follow CONTRIBUTING.md and the guidelines in documentation/docs/developer/guidelines/. Use .github/PULL_REQUEST_TEMPLATE.md, including the problem and solution, linked issue when applicable, checks run, screenshots for UI changes and documentation updates when relevant.
• PR titles use a backticked module followed by a colon, e.g. `Development`: Improve documentation. Allowed modules and the exact pattern are in .github/workflows/validate-pr-title.yml. Do not infer the format from squash-merge subjects, which omit the backticks.
• Commit subjects are concise and imperative, without backticks; wrap bodies near 72 characters.