diff --git a/.cspellignore b/.cspellignore
index 67ca8d06c4..2699e760ce 100644
--- a/.cspellignore
+++ b/.cspellignore
@@ -53,6 +53,7 @@ retryable
mjml
autonumber
colorpicker
+cspellignore
datetimerangepickerfield
datetimerangepicker
inlinealert
@@ -62,6 +63,7 @@ mailpit
axllent
timestamptz
formatjs
+frontmatter
autoplay
authproxy
xact
diff --git a/spec/adr/.gitkeep b/spec/adr/.gitkeep
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/spec/adr/coding-guidelines-ssot.md b/spec/adr/coding-guidelines-ssot.md
new file mode 100644
index 0000000000..e3f8f1246d
--- /dev/null
+++ b/spec/adr/coding-guidelines-ssot.md
@@ -0,0 +1,34 @@
+# ADR: Coding Guidelines as Single Source of Truth
+
+- **Status:** Accepted
+- **Date:** 2026-03-13
+
+## Context
+
+The Comet coding guidelines currently live as hand-written Docusaurus pages in `docs/docs/9-coding-guidelines/` (14 files covering Git, TypeScript, React, NestJS, CSS, accessibility, and more). These docs are written for human consumption and use Docusaurus-specific syntax (admonitions, frontmatter, image references).
+
+AI agents have no structured access to these guidelines. The only way to make agents aware of coding standards is to duplicate the content into agent-consumable formats (Cursor rules, agent skills), which creates a maintenance burden and inevitable drift between the human docs and agent instructions.
+
+Both humans and agents need to follow the same guidelines, so maintaining two separate copies is unsustainable.
+
+## Decision
+
+Move the single source of truth for coding guidelines to `spec/standards/coding-guidelines/` as granular, tool-agnostic markdown files (one per topic, 14 files total). From these standards files, generate:
+
+1. **Docusaurus docs** in `docs/docs/9-coding-guidelines/` -- preserving the current file names, page structure, admonitions, and image references so the human-facing docs remain unchanged
+2. **An agent skill** at `.agents/skills/coding-guidelines/SKILL.md` -- giving AI agents access to the same guidelines as structured, actionable instructions
+
+The standards files use plain markdown with lightweight structured markers (HTML comments) for Docusaurus-specific elements like admonitions and images, keeping the source format portable and not tied to any particular rendering tool.
+
+## Alternatives Considered
+
+1. **Keep Docusaurus docs as the SSoT** -- Agents cannot consume Docusaurus syntax directly; would require manual duplication into agent-friendly formats, leading to drift.
+2. **Single large ADR or markdown file** -- Violates the purpose of ADRs (which capture decisions, not reference material) and would be too large to maintain or consume effectively.
+3. **Cursor rules only** -- Would give agents access but leave humans without rendered documentation; Cursor rules also have size and format constraints that make them unsuitable for 14 topics of guidelines.
+
+## Consequences
+
+- All changes to coding guidelines go through the standards files in `spec/standards/coding-guidelines/`.
+- The Docusaurus docs and agent skill become generated artifacts and must not be edited directly.
+- A generation step is needed to produce both the docs and the skill from the standards.
+- The generated docs must match the current docs as closely as possible to avoid disruption.
diff --git a/spec/specs/.gitkeep b/spec/specs/.gitkeep
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/spec/specs/coding-guidelines.md b/spec/specs/coding-guidelines.md
new file mode 100644
index 0000000000..824671de73
--- /dev/null
+++ b/spec/specs/coding-guidelines.md
@@ -0,0 +1,216 @@
+---
+summary: "Generate Docusaurus docs and agent skill from the coding-guidelines standards files"
+implemented: false
+---
+
+# Feature: Coding Guidelines Generation
+
+## Goal / Background
+
+The coding guidelines are maintained as tool-agnostic markdown files in `spec/standards/coding-guidelines/` (the single source of truth, per [ADR: Coding Guidelines as SSoT](../adr/coding-guidelines-ssot.md)). Two artifacts need to be generated from these standards:
+
+1. **Docusaurus docs** — human-readable pages in `docs/docs/9-coding-guidelines/`, preserving the current structure, formatting, and content as closely as possible
+2. **Agent skill** — a machine-readable skill at `.agents/skills/coding-guidelines/SKILL.md` that gives AI agents access to the same guidelines
+
+Both artifacts are generated; neither should be edited directly. All guideline changes go through the standards files.
+
+- **Jira:** N/A
+- **Figma:** N/A
+
+## Requirements & User Stories
+
+### Docusaurus docs generation
+
+- Each standards file maps to exactly one Docusaurus doc file with a specific filename, title, and optional `sidebar_position`
+- Structured markers in the standards files (``, ``) are transformed to their Docusaurus equivalents
+- Cross-file references (`(filename.md)`) are converted to Docusaurus inter-page links (`(./slug)`)
+- The generated output must match the current Docusaurus docs as closely as possible — the current docs serve as the reference/expected output
+- Images remain in `docs/docs/9-coding-guidelines/images/` and are not generated
+
+### Agent skill generation
+
+- The skill aggregates the guidelines into a single actionable document optimized for AI consumption
+- No Docusaurus syntax (admonitions, frontmatter, image references) appears in the skill
+- The skill uses plain markdown with clear structure and imperative instructions
+
+## Acceptance Criteria
+
+- [ ] A generation script (or documented manual process) can produce all 14 Docusaurus doc files from the 14 standards files
+- [ ] The generated Docusaurus docs match the current docs (same file names, page titles, section structure, admonitions, image references, code examples, cross-page links)
+- [ ] The agent skill file exists at `.agents/skills/coding-guidelines/SKILL.md` with valid YAML frontmatter
+- [ ] The agent skill contains all guideline topics in a format suitable for AI agents
+- [ ] `pnpm --filter comet-docs run lint` passes after generation
+- [ ] `pnpm exec cspell "spec/**"` passes
+
+## Implementation Plan
+
+### Step 1: Define the file mapping
+
+Each standards file maps to a Docusaurus doc with specific metadata:
+
+| Standards file | Docusaurus file | `title` | `sidebar_position` |
+| ----------------------- | ----------------------------------- | ----------------------------------------------- | ------------------ |
+| `index.md` | `index.md` | Coding Guidelines | _(none)_ |
+| `git.md` | `01-git-guidelines.md` | Git Guidelines | -5 |
+| `general.md` | `02-general.md` | General (all programming languages) | -5 |
+| `secure-development.md` | `03-secure-software-development.md` | Basic principles of secure software development | -5 |
+| `libraries.md` | `04-libraries-and-techniques.md` | Libraries and techniques | -5 |
+| `naming-conventions.md` | `05-naming-conventions.md` | Naming conventions | -5 |
+| `typescript.md` | `06-typescript.md` | Typescript | -5 |
+| `styling-css.md` | `07-styling-css.md` | Styling / CSS | -5 |
+| `api-nestjs.md` | `08-api-nestjs.md` | API (NestJS) | -5 |
+| `react.md` | `09-react.md` | React | -5 |
+| `kubernetes.md` | `10-kubernetes.md` | Kubernetes | -5 |
+| `cdn.md` | `11-cdn.md` | CDN | -5 |
+| `postgresql.md` | `12-postgresql.md` | PostgreSQL | _(none)_ |
+| `accessibility.md` | `13-accessibility.md` | Accessibility | _(none)_ |
+
+### Step 2: Transformation rules (standards → Docusaurus)
+
+Apply these transformations in order:
+
+#### 2a. Heading → Frontmatter
+
+Strip the top-level `# Heading` from each standards file. Replace it with Docusaurus YAML frontmatter using the `title` and `sidebar_position` values from the mapping table above.
+
+**Standards input:**
+
+```markdown
+# Git Guidelines
+
+## General
+```
+
+**Docusaurus output:**
+
+```markdown
+---
+title: Git Guidelines
+sidebar_position: -5
+---
+
+## General
+```
+
+For `index.md`, the frontmatter has only `title` (no `sidebar_position`).
+
+#### 2b. Admonitions
+
+Convert HTML comment markers to Docusaurus admonition syntax:
+
+- `` becomes `:::TYPE`
+- `` becomes `:::TYPE TITLE`
+- `` becomes `:::`
+
+The `TYPE` is one of: `tip`, `warning`, `caution`, `note`, `info`. The optional `TITLE` follows the type (e.g., `tip Good`, `warning Bad`).
+
+**Standards input:**
+
+```markdown
+
+
+Added margin to footer
+
+
+```
+
+**Docusaurus output:**
+
+```markdown
+:::warning Bad
+Added margin to footer
+:::
+```
+
+Preserve all content between the opening and closing markers, including blank lines and nested elements. Remove the blank line immediately after the opening marker and immediately before the closing marker to match Docusaurus conventions.
+
+#### 2c. Image references
+
+Convert image comments to markdown image syntax:
+
+`` becomes ``
+
+The `ALT_TEXT` is derived from the filename by removing the extension and converting to PascalCase (e.g., `activation-squashing.png` → `ActivationSquashing`, `can-i-use.png` → `CanIUse`).
+
+When the original Docusaurus doc included an italic caption below the image (e.g., `_Activation of squashing in MR_`), this caption text comes from the `DESCRIPTION` in the comment. The standards file should use the `caption` flag to indicate this: ``. When the `caption` flag is present, render the description as `_DESCRIPTION_` on the line immediately below the image.
+
+#### 2d. Cross-file references
+
+Convert internal markdown links from standards-file references to Docusaurus page slugs:
+
+| Standards reference | Docusaurus reference |
+| ------------------- | ------------------------------ |
+| `(kubernetes.md)` | `(./kubernetes)` |
+| `(libraries.md)` | `(./libraries-and-techniques)` |
+| `(typescript.md)` | `(./typescript)` |
+
+The slug is derived from the Docusaurus filename by stripping the numeric prefix and `.md` extension (e.g., `06-typescript.md` → `./typescript`).
+
+#### 2e. Preserved elements
+
+The following elements require no transformation and pass through as-is:
+
+- Standard markdown (headings, lists, bold, italic, links, code blocks)
+- ``, ``, ``, ``, etc.).
+- Color contrast: at least **4.5:1** for normal text, **3:1** for large text.
+- All interactive elements must be keyboard operable with visible focus indicators.
+- Images need meaningful `alt` text; use `alt=""` for decorative images.
+- Associate form inputs with `` (or `aria-label` / `aria-labelledby`).
+- Respect `prefers-reduced-motion`; avoid autoplay animations for users who have requested reduced motion.
diff --git a/spec/standards/coding-guidelines/api-nestjs.md b/spec/standards/coding-guidelines/api-nestjs.md
new file mode 100644
index 0000000000..f8a8cf5943
--- /dev/null
+++ b/spec/standards/coding-guidelines/api-nestjs.md
@@ -0,0 +1,188 @@
+# API (NestJS)
+
+## General
+
+For new requirements, always check the [documentation](https://docs.nestjs.com/) first. There are already established techniques or patterns for many common problems.
+
+> NestJS is agnostic in many ways, and one of them is communication. It provides wrappers (or allows us to create our own) for third-party libraries.
+
+See: [What is the NestJS Runtime - Trilon Consulting](https://trilon.io/blog/what-is-the-nestjs-runtime)
+
+## Logging
+
+- Only log **warnings and errors** by default.
+- Additional logs (for debugging/profiling) should be toggleable via flags/settings.
+
+
+
+**Recommendation:** Use the built-in [NestJS Logger](https://docs.nestjs.com/techniques/logger).
+
+
+
+## Services vs. Controller/Resolver
+
+- **Controller/Resolver:** Represent the HTTP or GraphQL layer.
+- **Service:** Represents the **business logic** layer.
+
+### Service Best Practices
+
+- Services should be **decoupled from the HTTP/GraphQL layer** (e.g., avoid using `InputTypes` directly).
+ - This allows them to be reused (e.g., in console jobs) without mocking types.
+- Prefer passing the entire **entity** rather than just the ID.
+- Services should be **easily testable**. ([Using MikroORM with NestJS framework](https://mikro-orm.io/docs/usage-with-nestjs#testing))
+- Use **Dependency Injection (DI)** to control access to services and enforce clear module boundaries/interfaces.
+
+### Service FAQs
+
+- **Is a service always required?**
+ No — don't create pass-through methods just for the sake of it.
+ Yes — if business logic is reused or the HTTP layer becomes messy.
+
+- **Can I create utility files?**
+ Yes, as long as they are **stateless helper functions**.
+ Do **not** consume other services or repositories within them.
+
+
+
+Give them specific names — avoid generic `utils` dump folders.
+
+
+
+### Access Control Lists (ACL) / Authorization Checks
+
+- Place ACL logic in a **dedicated ACL service** (e.g., `products.acl.service.ts`) or inline in the controller/resolver for specific permission checks.
+- **Do not** perform ACL checks in shared services: Console jobs, for instance, have no authenticated user and may lead to double-checking permissions.
+- ACLs should be **covered by unit tests**.
+
+## Avoid Using `process.env` Directly
+
+Directly accessing environment variables in the code has downsides:
+
+- Not testable (no dependency injection)
+- No central place to manage environment variables
+- No validation
+
+**Exception:** It's technically necessary in some cases, such as in app entry points (`main.ts`, `bootstrap.ts`).
+
+## Dependency Injection
+
+**Constructor-based** injection is preferred over **property-based** injection (see: [Documentation | NestJS - A progressive Node.js framework](https://docs.nestjs.com/providers#property-based-injection)).
+Use property injection only when technically necessary.
+
+## ORM / Database
+
+### Repository
+
+Prefer `repository.create` over `new Entity()` since `create` expects a complete data object.
+
+### Migrations
+
+Down migrations are not required – using `throw new Error("Unsupported")` is sufficient.
+
+We do not use rollbacks; issues are resolved with a new deployment.
+
+### Data Types
+
+- Prefer `type: "uuid"` for IDs. See [Prefer UUIDs for IDs](postgresql.md#prefer-uuids-for-ids).
+- Always use `columnType: text` for strings. Explanation: See [Don't Do This - PostgreSQL wiki.](https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_varchar.28n.29_by_default)
+- Prefer `jsonb` over `json`. Explanation: See [8.14. JSON Types](https://www.postgresql.org/docs/current/datatype-json.html)
+- For timestamps, always use `columnType: "timestamp with time zone"`.
+
+### DB Defaults
+
+Avoid using DB defaults as they are not available before inserting/updating. This also falsifies the types of the entity.
+
+
+
+```ts
+@Property({ default: false })
+@Field()
+visible: boolean;
+```
+
+
+
+
+
+```ts
+@Property()
+@Field()
+visible: boolean;
+```
+
+
+
+(if GQL Field → provide default value for InputType)
+
+
+
+```ts
+@Property()
+visible: boolean = false;
+```
+
+
+
+(if not a GQL Field)
+
+
+
+If you are using the Upsert-Pattern, you may use DB defaults **additionally**
+
+```ts
+@Field()
+@Property({
+ columnType: "timestamp with time zone",
+ onUpdate: () => new Date(),
+ defaultRaw: "now()", // fallback for upsert
+})
+updatedAt: Date = new Date();
+```
+
+
+
+## GraphQL
+
+### Enum Keys = Values
+
+Enum keys and values must be identical.
+
+
+
+```ts
+enum Category {
+ MAIN = "main"
+ SECONDARY = "secondary"
+}
+```
+
+
+
+
+
+```ts
+enum Category {
+ Main = "Main"
+ Secondary = "Secondary"
+}
+```
+
+
+
+Reason: Admin and Site only know the GraphQL schema, where the enum keys are used. Therefore, queries and mutations also send the keys. If the values differ from the keys, this causes API errors because the wrong values are used for the enum.
+
+Regarding naming conventions, see also [TypeScript | Enums](typescript.md).
+
+### TypeScript number vs GraphQL Int/Float
+
+TypeScript has only one number type, but GraphQL distinguishes between Int and Float, so the type must be specified manually, otherwise, Float is the less strict default.
+
+```ts
+class Product {
+ @Field(() => Int)
+ position: number;
+
+ @Field(() => Float)
+ price: number;
+}
+```
diff --git a/spec/standards/coding-guidelines/cdn.md b/spec/standards/coding-guidelines/cdn.md
new file mode 100644
index 0000000000..afb661c781
--- /dev/null
+++ b/spec/standards/coding-guidelines/cdn.md
@@ -0,0 +1,13 @@
+# CDN
+
+The caching strategy must always be controlled by the origin (i.e., the application itself). **There must be no dependency on the default settings of the CDN.**
+
+### Requirements
+
+- All GET requests (Site and API) must explicitly set a Cache-Control header (see [Cache-Control header - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control)).
+- Caching duration: The lifetime of assets should be chosen appropriately depending on the content (e.g., for static assets with [Cache Buster](https://www.keycdn.com/support/what-is-cache-busting): long validity with `immutable`; for API responses: short validity or `no-store`).
+- Comet: Header setting is already ensured for all routes.
+
+### Background
+
+Proper control of cache lifetime not only improves loading speed but also affects SEO (see e.g., [Serve static assets with an efficient cache policy | Lighthouse | Chrome for Developers](https://developer.chrome.com/docs/lighthouse/performance/uses-long-cache-ttl?hl=de)).
diff --git a/spec/standards/coding-guidelines/general.md b/spec/standards/coding-guidelines/general.md
new file mode 100644
index 0000000000..bfc7b34e24
--- /dev/null
+++ b/spec/standards/coding-guidelines/general.md
@@ -0,0 +1,148 @@
+# General (all programming languages)
+
+## Use Descriptive Naming
+
+The goal of names is to help developers understand the code without having to read the detailed implementation.
+
+Try to avoid comments as descriptions, as they may not always be up to date with the code.
+
+
+
+```ts
+// calculates the sum of all products in the cart and removes the discount
+const price = (c: C) => {
+ return c.prods.reduce((s, p) => s + p.price - p.disc, 0);
+};
+```
+
+
+
+
+
+```ts
+const getCartPriceWithDiscounts = (cart: Cart) => {
+ return cart.products.reduce((total, product) => total + product.price - product.discount, 0);
+};
+```
+
+
+
+### Boolean Naming
+
+The name should indicate that the variable is a boolean.
+
+
+
+```ts
+const error = true;
+```
+
+
+
+
+
+```ts
+const hasError = true;
+```
+
+
+
+
+
+Prefix with is/has/should (see: [Tips on naming boolean variables - Cleaner Code](https://dev.to/michi/tips-on-naming-boolean-variables-cleaner-code-35ig)).
+Not necessary for: loading, disabled ...
+
+
+
+### Affirmative Variables
+
+Try to name variables in an affirmative form (avoid negative naming of variables)
+
+
+
+```ts
+const isNotComplete = false; // !isComplete is usually better
+const isIncomplete = true; // could make sense if 'isComplete' is a known state of the object
+
+if (!isNotComplete) {
+} // hard to read
+```
+
+
+
+
+
+```ts
+const isComplete = true;
+```
+
+
+
+## Don't use Abbreviations
+
+Abbreviations make it harder read code. Even more for new Devs or Devs who are not regularly working on that project.
+
+> It's better to save time thinking than to save time typing.
+
+### Exceptions:
+
+- Well-known abbreviations such as protocols (HTML, CSS, TCP, IP, SSO, API, …)
+- Abbreviations coming from a 3rd party (API, Library, …)
+
+When using PascalCase or camelCase abbreviations must not violate it.
+
+
+
+GUIController
+UIElement
+
+
+
+
+
+GuiController
+UiElement
+
+
+
+## Don't use Exceptions as Flow Control
+
+
+
+```ts
+async function getFileName(fileId: string): string | undefined {
+ try {
+ const file = await fileService.findFileOrFail(fileId);
+ return file.name;
+ } catch (error) {
+ if (error.message === "FileNotFound") {
+ return undefined;
+ }
+ }
+}
+```
+
+
+
+
+
+```ts
+async function getFileName(fileId: string): string | undefined {
+ if (!(await fileService.checkIfFileExists(fileId))) {
+ return undefined;
+ }
+
+ const file = await fileService.findFileOrFail(fileId);
+ return file.name;
+}
+```
+
+
+
+### Why?
+
+Using exceptions as flow control is a considered anti-patterns. The reasons for this common consensus are manifold: For instance, an exception is basically a `GOTO` statement.
+
+A good question to ask yourself is: **"if you use exceptions for normal situations, how do you locate unusual (i.e. exceptional) situations?"**
+
+[Are exceptions as control flow considered a serious anti-pattern? If so, Why?](https://softwareengineering.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why)
diff --git a/spec/standards/coding-guidelines/git.md b/spec/standards/coding-guidelines/git.md
new file mode 100644
index 0000000000..2c9e5afdb0
--- /dev/null
+++ b/spec/standards/coding-guidelines/git.md
@@ -0,0 +1,260 @@
+# Git Guidelines
+
+## General
+
+- In principle, we follow the concept of [trunk-based development](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development).
+- We aim for a high level of quality in our source code.
+- The Git commit history should be clean and understandable to make it easier to trace changes.
+
+A clean Git history can be achieved in two ways:
+
+- **Recommended:** On merge request level **(requires [squashing](https://www.geeksforgeeks.org/git/git-squash/))**
+- On commit level
+
+## Merge Requests
+
+### Rules
+
+- One merge request per change (feature, fix, or refactoring)
+- If the `main` pipeline is red (i.e., not passing), nothing may be merged unless it contributes to fixing the issue (see also environments in [Kubernetes](kubernetes.md))
+
+### Goal
+
+Make the review process as easy as possible for the reviewer.
+
+### Possible measures:
+
+- Link the relevant JIRA ticket
+- Add the **Timr** time tracking entry
+- Generate the MR description (JIRA ticket + Timr) using the GitLab button in JIRA
+- Link the screen design
+- Attach screenshots or screen recordings
+- Keep merge requests as small as possible
+- Avoid unnecessary dependencies (only add them if absolutely necessary)
+- Do not combine multiple tasks in a single MR (e.g., bugfix and new feature in the same MR)
+
+### Squashing
+
+Squashing combines all commits of a merge request into a single commit during the merge process.
+
+
+
+The squash commit will include the title and description of the merge request.
+
+#### Advantages:
+
+- Improved integration between GitLab, Git, and IDEs
+ (Title, description, and links are included in the squash commit; the related MR can be more easily identified in the IDE)
+- Commit messages within the MR become irrelevant. Suggestions can be applied directly without needing amends or force-pushes.
+ Concerns can be addressed in individual commits during the review.
+- Title and description can be edited directly in GitLab, making it easier for reviewers or lead developers to adjust wording.
+
+#### Disadvantages:
+
+- Stacked MRs always cause conflicts (rebasing is required).
+- Individual commits of the MR are no longer visible in the `main` branch.
+ You need to navigate to the MR in GitLab to view them.
+
+#### Rules:
+
+- Squashing is the recommended default setting.
+- If a merge request has a messy commit history, it **must** be squashed.
+
+
+
+All dependent (stacked) MRs must then be rebased.
+
+
+
+- Even if the commit history is clean, squashing is still allowed.
+
+### Selecting Reviewers
+
+- All merge requests must go through peer review.
+- The project's lead developer should generally review every merge request in the project.
+- For infrastructure changes: always select someone from the **infra team**.
+- For styling changes: always select someone from the **styling focus group**.
+- A merge request can only be merged **after all reviewers have approved**.
+
+
+
+Always use **reviewers**, not approvers. The review system is better integrated into GitLab.
+
+
+
+### Conventions
+
+- Merge requests prefixed with `Draft:` should only be reviewed if a reviewer has been explicitly assigned.
+
+### Concerns
+
+- Concerns should always be resolved by the **reviewer** (exception: obvious things like typos).
+- A merge request may **only be merged once all concerns are resolved**.
+
+### Commits
+
+
+
+The following rules apply **if the merge request is _not_ squashed**
+
+Even if squashing is used, commit cleanliness is still important for easier reviews.
+
+
+
+- Commits should be **atomic** (i.e., the code should be in a runnable state).
+ Exception: if a CodeMod or CRUD generator is used, the generated changes should be in a **separate commit**, so they can be excluded from review.
+- Prefer multiple small commits (e.g., separate docs and feature work).
+- One commit per **logical change**.
+- Write **clear and descriptive commit messages**:
+ - Avoid vague messages like `fix`, `polish`, `wip`, or `another try`. These may be used temporarily, but must be cleaned up before merging.
+ - Start commit messages with a **capital letter**.
+- We recommend using **English** for all commit messages.
+
+#### Meaningful Commits for Suggestions
+
+When applying a suggestion, make sure to use a **meaningful commit message**.
+
+
+
+
+
+
+
+
+
+#### Tips for Writing Good Commit Messages
+
+Use the imperative
+
+
+
+Added margin to footer
+
+
+
+
+
+Add margin to footer
+
+
+
+Explain **what** and **why**, not **how**
+
+
+
+Add margin
+
+
+
+
+
+Add margin to nav items to prevent them from overlapping the logo
+
+
+
+`.
+
+It is important that the SVG file contains an `id`, which is then referenced via the hash parameter in the path.
+
+**You can use it like this:**
+
+
+
+```tsx
+
+
+```
+
+
+
+**SVG File:**
+
+
+
+```tsx
+
+ icon
+
+```
+
+
+
+
+
+```tsx
+import Icon from "../assets/icon.svg"
+
+...
+
+... ;
+};
+```
+
+
+
+**Explanation:** They are recreated on every render and can lead to performance issues. (See also [Hooks API Reference – React](https://legacy.reactjs.org/docs/hooks-reference.html#usecallback))
+
+
+
+```tsx
+const sortJobs = (a: Job, b: Job) => {
+ return a.createdAt - b.createdAt;
+};
+
+const Wrapper = styled.div`...`;
+
+const Foo = (jobs) => {
+ return ... ;
+};
+```
+
+
+
+## GraphQL
+
+Use a fragment to define the required data of a component (see [Colocating Fragments](https://www.apollographql.com/docs/react/data/fragments#colocating-fragments))
+
+
+
+
+
+```tsx
+function DisplayName({
+ user: { firstName, lastName }: GQLUserDetailQuery,
+}) {
+ return <>{firstName} {lastName}
+}
+```
+
+
+
+```tsx
+const userDetailQuery = gql`
+ query UserDetail($id: ID!) {
+ user(id: $id) {
+ firstName
+ lastName
+ }
+ }
+`;
+
+function UserDetail({ id }: { id: string }) {
+ const user = useQuery(userDetailQuery);
+ // ...
+ return (
+ <>
+
+ {blocks.map((block) => (
+
;
+
+export const List = styled.div`
+ display: flex;
+ flex-wrap: wrap;
+`;
+
+// Button.tsx
+export const ButtonBlock = styled.div`
+ width: 25%;
+`;
+```
+
+
+
+
+
+```tsx
+// List.tsx
+
+ {blocks.map((block) => (
+ -
+
+ ))}
+
;
+
+export const List = styled.div`
+ display: flex;
+ flex-wrap: wrap;
+`;
+
+export const Item = styled.div`
+ width: 25%;
+`;
+```
+
+
+
+### Recommendation: Empty Lines
+
+For better code readability, it is recommended to make a empty line between css and every form of selector:
+
+
+
+```tsx
+const ImageWrapper = styled.div`
+ display: inline-block;
+ max-height: 200px;
+ max-width: 200px;
+ cursor: pointer;
+ ${({ theme }) => theme.breakpoints.m.mediaQuery} {
+ max-width: 160px;
+ max-height: 160px;
+ }
+ ${({ theme }) => theme.breakpoints.l.mediaQuery} {
+ max-width: 200px;
+ max-height: 200px;
+ }
+ &:hover {
+ opacity: 0.5;
+ }
+`;
+```
+
+
+
+
+
+```tsx
+const ImageWrapper = styled.div`
+ display: inline-block;
+ max-height: 200px;
+ max-width: 200px;
+ cursor: pointer;
+
+ ${({ theme }) => theme.breakpoints.m.mediaQuery} {
+ max-width: 160px;
+ max-height: 160px;
+ }
+
+ ${({ theme }) => theme.breakpoints.l.mediaQuery} {
+ max-width: 200px;
+ max-height: 200px;
+ }
+
+ &:hover {
+ opacity: 0.5;
+ }
+`;
+```
+
+
+
+### Mobile First Approach
+
+When styling a site, block or component, always start with the mobile layout. [The Mobile First approach](https://css-tricks.com/how-to-develop-and-test-a-mobile-first-design-in-2021/) helps us to reach the majority of users and provides them with a good-looking page.
+
+### Inline Styles
+
+If possible, don't use inline styles, use Emotion or Styled Components instead.
+
+
+
+```tsx
+ handleDelete(key)} style={{ padding: "0 0 8px 8px" }}>
+```
+
+
+
+
+
+```tsx
+import { IconButton as MuiIconButton } from "@mui/material";
+
+const IconButton = styled(MuiIconButton)(() => ({
+ padding: "0 0 8px 8px",
+}));
+
+ handleDelete(key)} />;
+```
+
+
+
+or even better name the button after its function.
+
+
+
+```tsx
+import { IconButton } from "@mui/material";
+
+const DeleteButton = styled(IconButton)(() => ({
+ padding: "0 0 8px 8px",
+}));
+
+ handleDelete(key)} />;
+```
+
+
diff --git a/spec/standards/coding-guidelines/typescript.md b/spec/standards/coding-guidelines/typescript.md
new file mode 100644
index 0000000000..49a591a62b
--- /dev/null
+++ b/spec/standards/coding-guidelines/typescript.md
@@ -0,0 +1,97 @@
+# Typescript
+
+Everything from [Clean Code concepts adapted for TypeScript](https://github.com/labs42io/clean-code-typescript)
+
+## General
+
+Prefer using an options object instead of multiple parameters
+(Explanation: [Clean Code concepts adapted for TypeScript](https://github.com/labs42io/clean-code-typescript#function-arguments-2-or-fewer-ideally))
+
+
+
+```ts
+const getSortedJobs = (orderBy: string, includeSoftDeleted: boolean, limit: number): Job[] => {};
+
+getSortedJobs("createdAt", true, 20);
+```
+
+
+
+
+
+```ts
+const getSortedJobs = (options: { orderBy: string; includeSoftDeleted: boolean; limit: number }): Job[] => {};
+
+getSortedJobs({
+ orderBy: "createdAt",
+ includeSoftDeleted: true,
+ limit: 20,
+});
+```
+
+
+
+- Use named exports only (Exception: Default exports are allowed only if technically required)
+ **Reason:** They are harder to locate and refactor.
+
+- Use relative imports only for sibling or child files within a module (for anything else, use imports via @src)
+
+- Prefer async/await over callbacks
+
+- Prefer for...of loops
+ Supports all iterators, async/await, and control statements
+ (See: [Should one use for-of or forEach when iterating through an array?](https://stackoverflow.com/questions/50844095/should-one-use-for-of-or-foreach-when-iterating-through-an-array/50844413#50844413))
+
+- Use default arguments instead of short-circuiting or conditional logic
+
+
+
+```ts
+function createMicrobrewery(name) {
+ const breweryName = name || "Hipster Brew Co.";
+ // ...
+}
+```
+
+
+
+
+
+```ts
+function createMicrobrewery(name = "Hipster Brew Co.") {
+ // ...
+}
+```
+
+
+
+## 3rd Party NPM packages
+
+See [Libraries and Techniques](libraries.md)
+
+## Further Reading / Sources
+
+- [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)
+- [Clean Code concepts adapted for TypeScript – GitHub by labs42io](https://github.com/labs42io/clean-code-typescript#function-arguments-2-or-fewer-ideally)
+- [oida.dev | TypeScript, JavaScript, Rust](https://fettblog.eu/)
+
+## Naming Conventions
+
+### Enums
+
+Use `camelCase` for the **keys** and **values** of your enums.
+
+#### Example:
+
+```ts
+enum Direction {
+ north = "north",
+ northEast = "northEast",
+ east = "east",
+ southEast = "southEast",
+ south = "south",
+ southWest = "southWest",
+ west = "west",
+ northWest = "northWest",
+}
+```