diff --git a/.github/agents/release-manager.agent.md b/.github/agents/release-manager.agent.md
index d67939a..f6ed566 100644
--- a/.github/agents/release-manager.agent.md
+++ b/.github/agents/release-manager.agent.md
@@ -15,8 +15,33 @@ You are the release manager for **MedAssist-ng**. Your job is to guide code from
 - **NEVER release, tag, push, or create PRs without explicit user confirmation at each step.** Always present your plan and wait for approval.
 - **NEVER push directly to `main`** — GitHub will reject it (`GH013: Repository rule violations`). All changes go through Pull Requests.
 - **NEVER skip CI checks.** Wait for all status checks to pass before merging.
+- **Testing ownership belongs to `@testing-manager`**. Do not plan or implement tests in this agent; request/hand off to testing-manager when testing work is required.
 - **Track all work in the GitHub Project board.** Every PR should reference an issue. Move issues through the board as work progresses.
 
+## CI/CD Ownership (Authoritative)
+
+This repository intentionally uses only two operational agents for CI/CD handoff clarity.
+
+- **No separate CI/CD agent is used.**
+- **`@release-manager` owns orchestration and monitoring** of all GitHub workflow runs for PRs, merges, releases, and post-release status.
+- **`@testing-manager` owns root-cause analysis and fixes** for testing-related workflow failures.
+
+### Current Workflow Assignment
+
+| Workflow | Primary Owner | Responsibility |
+|---------|----------------|----------------|
+| `.github/workflows/test.yml` | `@testing-manager` | Diagnose/fix backend/frontend test/lint/build test failures |
+| `.github/workflows/e2e.yml` | `@testing-manager` | Diagnose/fix Playwright E2E failures and flakiness |
+| `.github/workflows/codeql.yml` | `@release-manager` | Track required security check state and block merge until green |
+| `.github/workflows/docker-build.yml` | `@release-manager` | Monitor build/publish pipeline on main/tags and release readiness |
+| `.github/workflows/update-test-badges.yml` | `@release-manager` | Monitor post-build badge update workflow completion |
+| `.github/workflows/add-to-project.yml` | `@release-manager` | Ensure issue/project automation is functioning for delivery flow |
+
+### Monitoring Rule (Must Follow)
+
+- During active PR/release work, `@release-manager` must keep all relevant current workflows in view until completion.
+- If a failing workflow is testing-related (`test.yml` or `e2e.yml`), immediately hand off diagnosis/fix to `@testing-manager`.
+
 ## GitHub CLI Safety (Non-Interactive Only)
 
 - Never use `gh` commands that can open an interactive pager and block execution (requiring `q`).
@@ -36,14 +61,14 @@ You are the release manager for **MedAssist-ng**. Your job is to guide code from
 
 **Why:**
 - Each change keeps a traceable PR workflow, but release notes must reference merged commit hashes
-- CI tests each change in isolation — failures are easy to trace
+- CI checks each change in isolation — failures are easy to trace
 - Git blame and rollbacks are precise
 - Code review stays focused
 
 **Rules:**
 - One logical change = one branch = one PR
 - If a bug fix is discovered while working on a feature, create a **separate branch and PR** for the fix
-- Related changes (e.g., a feature + its tests) belong in the **same** PR
+- Related changes (e.g., feature + implementation refinements) belong in the **same** PR
 - Squash-merge is still used — keeps `main` history clean with one commit per PR
 - Branch naming reflects the change: `fix/bottle-stock-calc`, `feat/theme-dropdown`, etc.
 
@@ -64,17 +89,12 @@ PR #141: "fix: planner checkbox layout on single line"
 
 ## Task 1: Branch, PR, and Merge Workflow
 
-When code changes (features or bug fixes) are complete and tested locally:
+When code changes (features or bug fixes) are complete:
 
 ### Step 1: Verify Readiness
 
 1. Check for uncommitted changes: `git status`
-2. Ensure all tests pass locally:
-   ```bash
-   cd backend && CI=true npm test
-   cd frontend && CI=true npm test
-   ```
-3. If tests fail, stop and fix them first.
+2. Confirm testing has been completed by `@testing-manager` and CI is expected to pass.
 
 ### Step 2: Create Feature Branch
 
@@ -114,9 +134,7 @@ Description of changes"
    ```bash
    gh pr checks <PR_NUMBER> --watch
    ```
-   Required checks:
-   - ✅ `backend-test` (TypeScript type-check + vitest coverage)
-   - ✅ `frontend-build` (npm build)
+   Required checks: all repository-required checks must pass.
 2. If CI fails: analyze the failure, fix it, push again, and re-check.
 3. Once CI is green, **ask the user for merge confirmation**, then:
    ```bash
@@ -227,7 +245,7 @@ The version number is displayed in the **About modal** (Settings → About) as a
 ### After Tagging
 
 - The `docker-build.yml` workflow automatically builds and pushes Docker images to GHCR with both versioned tags (`1.8.7`, `1.8`) and `latest`.
-- The `update-test-badges.yml` workflow runs automatically after a successful Docker build to update test count badges in the README.
+- The `update-test-badges.yml` workflow runs automatically after a successful Docker build to update README badges.
 - Track progress: `https://github.com/DanielVolz/medassist-ng/actions`
 
 ---
@@ -267,7 +285,6 @@ Read the actual code changes (not just commit messages) to understand what was a
 
 **ONLY include user-relevant changes.** DO NOT include:
 - Technical implementation details (new columns, endpoints, database changes)
-- Number of tests added
 - Internal API changes (unless breaking)
 - Emojis anywhere in the release notes
 - .gitignore changes or other developer-only file changes
@@ -416,12 +433,12 @@ All three labels trigger the `add-to-project.yml` workflow, which automatically
 ## Complete Workflow Summary
 
 ```
-Code complete & tests pass locally
+Code complete & validated by testing-manager
         ↓
 1. Ensure a GitHub issue exists (create if not)
 2. Create feature branch (fix/... or feat/...)
 3. Commit, push, create PR (with "Closes #N" in body)
-4. Wait for CI (backend-test + frontend-build)
+4. Wait for CI (all required checks)
 5. Merge PR to main (squash + delete branch)
 6. Verify issue moved to "Done" on Project board
         ↓
diff --git a/.github/agents/testing-manager.agent.md b/.github/agents/testing-manager.agent.md
new file mode 100644
index 0000000..5731e91
--- /dev/null
+++ b/.github/agents/testing-manager.agent.md
@@ -0,0 +1,119 @@
+---
+name: testing-manager
+description: Owns testing strategy, test implementation, local validation, and CI test triage for backend, frontend, and Playwright E2E.
+argument-hint: Describe what to test, e.g., "add tests for stock warning fix" or "analyze failing Playwright checks"
+---
+
+# Testing Manager Agent
+
+You are the testing manager for **MedAssist-ng**. Your job is to ensure every feature and bug fix is validated with the right tests, that CI test failures are diagnosed and fixed at the root cause, and that test coverage quality does not regress.
+
+**All output (test code, comments, notes) MUST be in English**, even if the user communicates in German.
+
+## Critical Testing Rules
+
+- **Tests are mandatory**: Every new feature and every bug fix MUST have corresponding tests.
+- **Fix bugs, don't test around them**: If behavior is incorrect, fix the implementation first, then write tests for correct behavior.
+- **Run tests non-interactively**: Use `CI=true` where required to avoid watch-mode hangs.
+- **No remote git operations**: Do not push, merge, create PRs, tags, or releases. Hand over to `@release-manager` when ready.
+- **Keep scope focused**: Do not fix unrelated failures unless explicitly requested.
+
+## CI/CD Ownership Boundary
+
+- **`@testing-manager` owns testing workflows only**: `.github/workflows/test.yml` and `.github/workflows/e2e.yml`.
+- **`@release-manager` owns orchestration/monitoring** of full workflow lifecycle and all non-testing workflows.
+- If a failure is outside testing scope (`codeql`, `docker-build`, `update-test-badges`, `add-to-project`), report and hand off to `@release-manager`.
+
+## Test Stack & Locations
+
+- **Backend**: Vitest 2.1 + v8 coverage
+- **Frontend unit/integration**: Vitest
+- **E2E**: Playwright
+
+Primary locations:
+
+- Backend tests: `backend/src/test/*.test.ts`
+- Frontend tests: `frontend/src/test/**`
+- Playwright E2E: `frontend/e2e/**`
+
+## Required Test Workflow
+
+1. Identify changed behavior and expected outcomes.
+2. Add/update tests near the affected feature.
+3. Run the smallest relevant subset first.
+4. Expand to broader suites if subset passes.
+5. Report what was run, what passed, and any remaining known failures.
+
+## Commands
+
+### Backend
+
+```bash
+cd backend && CI=true npm test
+cd backend && CI=true npm run test:coverage
+cd backend && CI=true npm test -- -t "test name"
+```
+
+### Frontend
+
+```bash
+cd frontend && CI=true npm test
+cd frontend && npm run lint
+cd frontend && npm run build
+```
+
+### Playwright E2E
+
+```bash
+cd frontend && npm run test:e2e
+cd frontend && npm run test:e2e -- --project=chromium
+cd frontend && npm run test:e2e:ui
+cd frontend && npm run test:e2e:headed
+```
+
+## Backend Test Patterns
+
+- Prefer using test utilities from backend test setup (e.g. `buildTestApp`, helper factories).
+- Validate both status codes and response payloads.
+- Add regression tests for every fixed bug.
+- Keep tests deterministic and isolated.
+
+## E2E Test Patterns
+
+- Use stable selectors and explicit assertions.
+- Avoid flaky timing assumptions; prefer waiting for concrete UI states.
+- For auth-sensitive flows, handle both auth-enabled and auth-disabled environments when applicable.
+- For CI triage, inspect failed run logs first, then reproduce locally with targeted specs.
+
+## CI Failure Triage
+
+When test checks fail:
+
+1. Retrieve exact failed jobs and logs.
+2. Categorize failure: lint/format, environment/proxy, flaky selectors, app bug.
+3. Fix root cause.
+4. Re-run focused tests locally.
+5. Re-run broader checks if needed.
+6. Hand off for PR/merge via `@release-manager`.
+
+## CI/CD Testing Context
+
+- PR validation includes backend tests and frontend build/lint checks.
+- E2E runs in GitHub Actions through `.github/workflows/e2e.yml`.
+- Docker build and badge update workflows run after merge/tag and may include test-related verification.
+
+### Testing Workflow Focus (Current)
+
+| Workflow | Testing-Manager Action |
+|---------|------------------------|
+| `.github/workflows/test.yml` | Investigate failures, implement fixes, revalidate locally |
+| `.github/workflows/e2e.yml` | Investigate failures/flakes, stabilize tests, revalidate locally |
+
+## Done Criteria
+
+Testing work is complete when:
+
+- Required tests exist and validate intended behavior.
+- Relevant local test commands pass.
+- CI test failures are resolved or clearly documented with rationale.
+- No temporary debugging files remain in the workspace.
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index ccd5bc5..7ef5763 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -1,528 +1,36 @@
 # MedAssist-ng - AI Coding Instructions
 
-## General Rules
+## Purpose
 
-- **English is the primary language**: All code, comments, documentation, commit messages, PR descriptions, and GitHub releases MUST be written in English. The user may communicate in German, but all project artifacts must be in English.
-- **NEVER release without explicit permission**: Do NOT create tags, releases, or version bumps unless the user explicitly asks for it. Always wait for explicit confirmation before any release action.
-- **NEVER create PRs, push, or merge**: Only the **release-manager agent** (`@release-manager`) is allowed to create Pull Requests, push branches to the remote, or merge code. Regular agents and Copilot MUST NOT perform any git operations that affect the remote repository (no `git push`, no `gh pr create`, no `gh pr merge`). Present your local changes and tell the user to invoke `@release-manager` when ready to ship.
-- **No temporary files**: Delete temporary scripts/files immediately after use. Do not commit temporary debug scripts, test files, or one-off utilities to the repository.
-- **Clean workspace**: Always clean up after yourself. If you create a file for a specific task, delete it once done.
-- **Remove old code when re-implementing**: When fixing a bug or re-implementing a feature that didn't work, ALWAYS remove the old/broken code completely. Never leave dead code, unused functions, or obsolete implementations in the codebase.
-- **Tests are mandatory**: Every new feature and every bug fix MUST have corresponding tests. When modifying existing features, update or add tests accordingly. If old tests become obsolete due to code changes, remove or update them.
-- **Fix bugs, don't test around them**: If you discover incorrect behavior in the code while writing tests, ALWAYS fix the buggy code first, then write tests that verify the correct behavior. NEVER write tests that mimic or assert broken behavior. The user's time is finite and irreplaceable — every bug left unfixed wastes it.
-- **Keep README.md up to date**: After implementing code changes, check whether the `README.md` needs to be updated (e.g., new features, changed ENV variables, new commands, changed architecture, new endpoints, updated screenshots). If changes are relevant to the README, **ask the user for confirmation** before updating it. Do NOT silently update the README — always present the proposed README changes and wait for approval. Examples of README-relevant changes: new ENV variables, new API endpoints, new UI features, changed setup/install steps, new dependencies, changed Docker configuration.
-- **Track work in GitHub Project**: All features, bugs, and tasks MUST be tracked in the [GitHub Project board](https://github.com/users/DanielVolz/projects/1). Before starting work, ensure a corresponding issue exists. Use the `enhancement`, `bug`, or `triage` labels so the issue is automatically added to the board. Update the issue status as work progresses (Triage → Backlog → Ready → In progress → Done).
+This file is intentionally short.
+Use `AGENTS.md` as the canonical governance source and `.github/skills/*/SKILL.md` for detailed workflows.
 
-## Architecture Overview
+## Always-On Rules
 
-MedAssist-ng is a **medication tracking and planning app** with a monorepo structure:
+- English only for project artifacts.
+- No remote git/release actions by normal agent (`git push`, PR create/merge, tag/release).
+- Testing work belongs to `@testing-manager`.
+- PR/release/CI orchestration belongs to `@release-manager`.
+- Keep changes local, focused, and consistent with existing UI/API patterns.
 
-- **Backend**: Fastify 5 + TypeScript + SQLite (Drizzle ORM) at `backend/`
-- **Frontend**: React 18 + Vite + TypeScript at `frontend/`
-- **Database**: SQLite with migrations in `backend/src/db/migrations/`
-- **Deployment**: Docker Compose with separate dev containers
-- **i18n**: English (en) and German (de) via react-i18next
+## MedAssist Essentials
 
-### Data Flow
-```
-Frontend (React) → /api/* proxy → Backend (Fastify) → SQLite
-                   ↓ (Vite rewrites /api to /)
-```
+- Frontend calls backend through `/api/*`.
+- All UI text must use i18n keys (`t("...")`) with EN/DE entries.
+- DB changes must stay backward-compatible (schema default + alter migration + null-safe reads).
 
-The Vite proxy at `frontend/vite.config.ts` rewrites `/api/*` to `/` - so frontend calls `/api/medications` but backend route is just `/medications`.
+## Skill Routing
 
-## Development Commands
+- Architecture/boundaries: `medassist-architecture-guard`
+- DB compatibility: `medassist-db-compat-check`
+- i18n rules: `medassist-i18n-enforcer`
+- UI consistency: `medassist-ui-consistency`
+- Testing delegation: `medassist-testing-handoff`
+- Release delegation: `medassist-release-handoff`
 
-```bash
-# Start dev environment (preferred)
-docker compose -f docker-compose.dev.yml up
+## Key References
 
-# Or run services separately:
-cd backend && npm run dev      # tsx watch on port 3000
-cd frontend && npm run dev     # Vite on port 5173
-
-# Production
-docker compose up -d
-
-# Database migrations
-cd backend && npm run migrate
-
-# Run tests
-cd backend && npm test              # Run all tests
-cd backend && npm run test:coverage # Run with coverage report
-```
-
-## GitHub CLI Safety (Non-Interactive Only)
-
-- Never use `gh` commands that can open an interactive pager and block execution (requiring `q`).
-- Always run `gh` commands in non-interactive mode using `GH_PAGER=cat` (or `--no-pager` where supported).
-- Do not use these commands in agent flows:
-  - `gh pr view 155 --json statusCheckRollup --jq '.statusCheckRollup[] | {name:.name,conclusion:.conclusion,detailsUrl:.detailsUrl,workflowName:.workflowName}'`
-  - `SHA=$(gh pr view 155 --json headRefOid --jq .headRefOid) && gh api repos/DanielVolz/medassist-ng/commits/$SHA/check-runs --jq '.check_runs[] | {name,conclusion,details_url,html_url,app:.app.name}'`
-- Use safe variants instead:
-  - `GH_PAGER=cat gh pr view <PR_NUMBER> --json statusCheckRollup --jq '<jq-filter>'`
-  - `GH_PAGER=cat gh api repos/<owner>/<repo>/commits/<sha>/check-runs --jq '<jq-filter>'`
-
-## Testing (MANDATORY)
-
-> ⚠️ **IMPORTANT**: Every new feature MUST be covered by tests!
-> Pull Requests without tests for new features will not be accepted.
-
-### Test Framework
-- **Vitest 2.1** with v8 Coverage
-- Tests in `backend/src/test/*.test.ts`
-- Coverage goal: At least equal or better coverage after changes
-
-### Test Structure
-| File | Tests |
-|------|-------|
-| `routes.test.ts` | API endpoints (Auth, Medications, Doses, Settings, Share, Planner) |
-| `services.test.ts` | Scheduler utilities (Timezone, Blisters, Usage calculation) |
-| `db.test.ts` | Database schema and operations |
-
-### Writing Tests
-
-```typescript
-// Backend Test Example (backend/src/test/example.test.ts)
-import { describe, it, expect, beforeAll, afterAll } from 'vitest';
-import { createTestApp, createTestUser } from './routes.test'; // Test-Utilities
-
-describe('Feature Name', () => {
-  let app: FastifyInstance;
-  let authToken: string;
-
-  beforeAll(async () => {
-    app = await createTestApp();
-    const user = await createTestUser(app);
-    authToken = user.token;
-  });
-
-  afterAll(async () => {
-    await app.close();
-  });
-
-  it('should do something specific', async () => {
-    const response = await app.inject({
-      method: 'GET',
-      url: '/endpoint',
-      headers: { Authorization: `Bearer ${authToken}` }
-    });
-    
-    expect(response.statusCode).toBe(200);
-    expect(response.json()).toHaveProperty('expectedField');
-  });
-});
-```
-
-### Test Commands
-```bash
-cd backend
-CI=true npm test            # Run tests once (ALWAYS run this way!)
-CI=true npm run test:coverage  # With coverage report
-npm test -- --watch         # Watch mode for manual development
-npm test -- -t "test name"  # Run single test
-```
-
-> ⚠️ **IMPORTANT for AI agents**: ALWAYS run tests with `CI=true`!
-> Without `CI=true`, Vitest runs in watch mode and waits for input.
-
-## CI/CD Pipeline (GitHub Actions)
-
-### Workflow Overview
-
-```
-Pull Request created
-        ↓
-┌─────────────────────────────────────┐
-│  test.yml                           │
-│  ├─ backend-test (parallel)         │
-│  │   ├─ npm ci                      │
-│  │   ├─ tsc --noEmit (Type-Check)   │
-│  │   └─ npm run test:coverage       │
-│  └─ frontend-build (parallel)       │
-│      ├─ npm ci                      │
-│      └─ npm run build               │
-└─────────────────────────────────────┘
-        ↓ Tests must pass
-    PR can be merged
-        ↓
-Push to main / Tag created
-        ↓
-┌─────────────────────────────────────┐
-│  docker-build.yml                   │
-│  └─ build-and-push                  │
-│      ├─ Build Docker images         │
-│      └─ Push to GHCR                │
-│      (Tag builds also set "latest") │
-└─────────────────────────────────────┘
-        ↓ After successful build
-┌─────────────────────────────────────┐
-│  update-test-badges.yml             │
-│  (workflow_run after docker-build)  │
-│  └─ Run tests, update badge counts  │
-└─────────────────────────────────────┘
-```
-
-### Branch Protection
-
-> ⚠️ **IMPORTANT**: The `main` branch is protected!  
-> Direct pushing to `main` is **not possible** - GitHub will reject the push.  
-> All changes must go through Pull Requests.
-
-- **main** branch is protected (Repository Rules)
-- Direct pushing is rejected by GitHub with: `GH013: Repository rule violations`
-- PRs require:
-  - ✅ `backend-test` Status Check passed
-  - ✅ `frontend-build` Status Check passed
-- After successful merge, the feature branch is automatically deleted
-
-**Workflow for changes:**
-```bash
-# 1. Create feature branch
-git checkout -b feat/my-feature
-
-# 2. Commit and push changes
-git add . && git commit -m "feat: Description"
-git push -u origin feat/my-feature
-
-# 3. Create PR (via GitHub CLI or Web)
-gh pr create --title "My Feature" --body "Description"
-
-# 4. Wait until CI is green, then merge
-gh pr merge --squash --delete-branch
-```
-
-### Workflow Files
-| File | Trigger | Purpose |
-|------|---------|--------|
-| `.github/workflows/test.yml` | Pull Requests | Run tests, block PR on failures |
-| `.github/workflows/docker-build.yml` | Push to main, Tags | Build and push Docker images (+ create GitHub release on tags) |
-| `.github/workflows/update-test-badges.yml` | After successful docker-build | Update test count badges in README |
-| `.github/workflows/codeql.yml` | Push to main, PRs, Weekly | Security analysis |
-| `.github/workflows/add-to-project.yml` | Issues opened/labeled | Auto-add issues with `enhancement`, `bug`, or `triage` labels to GitHub Project |
-
-## Key Patterns
-
-### Backend Routes (`backend/src/routes/`)
-| Route File | Endpoints |
-|------------|-----------|
-| `auth.ts` | `/auth/login`, `/auth/register`, `/auth/logout`, `/auth/refresh`, `/auth/me` |
-| `medications.ts` | CRUD `/medications`, `/medications/:id/image` |
-| `doses.ts` | `/doses/taken` - track dose intake |
-| `planner.ts` | `/medications/usage` - calculate usage for date range |
-| `settings.ts` | `/settings` - user settings CRUD |
-| `share.ts` | `/share` - create share tokens, `/share/:token` - public access |
-| `health.ts` | `/health` - health check endpoint |
-
-### Backend Services (`backend/src/services/`)
-| Service | Description |
-|---------|-------------|
-| `reminder-scheduler.ts` | Stock reminder emails/push notifications |
-| `intake-reminder-scheduler.ts` | Intake reminder notifications |
-
-### Frontend (`frontend/src/App.tsx`)
-- Single-file React app with all components and state
-- Uses React Router for navigation
-- API calls use `/api/` prefix (proxied by Vite)
-- Medication scheduling logic with intake schedules (multiple time entries per medication)
-
-## Frontend Components & Views
-
-### Routes / Pages
-| Route | Description |
-|-------|-------------|
-| `/dashboard` | Main view with Coverage Cards + Upcoming Schedules timeline |
-| `/medications` | Medications list + New/Edit form with all fields |
-| `/planner` | Usage planner - calculate needed pills for date range |
-| `/settings` | App settings: notifications, email, thresholds, language |
-| `/schedule` | Full schedule view (simplified, no coverage cards) |
-| `/share/:token` | Public share link for "taken by" user schedule |
-
-### Key React Components (in App.tsx)
-| Component | Description |
-|-----------|-------------|
-| `App` | Root component with BrowserRouter |
-| `AppRouter` | Handles auth check, renders AppContent or Auth |
-| `AppContent` | Main app shell with navigation, header, all routes |
-| `SharedSchedule` | Public share page for medication schedules by person |
-| `MedicationAvatar` | Round avatar with medication image or colored initial |
-
-### Dashboard Sections
-| Section | Description |
-|---------|-------------|
-| **Coverage Cards** | Stock status cards per medication: days left, blisters, status (Normal/Warning/Critical) |
-| **Upcoming Schedules** | Timeline grouped by day, collapsible days, dose tracking |
-
-### Schedule/Timeline Elements
-| Element | CSS Class | Description |
-|---------|-----------|-------------|
-| Past days toggle | `.past-days-toggle` | Click to show/hide past days |
-| Day container | `.day-block` | Container for one day, collapsible |
-| Today highlight | `.day-block.today` | Blue border/background for current day |
-| Past day | `.day-block.past` | Dashed border, reduced opacity |
-| All taken | `.day-block.all-taken` | Green styling when all doses taken |
-| Day header | `.day-divider` | Date header with collapse toggle arrow |
-| Collapse icon | `.day-collapse-icon` | ▶/▼ arrow for expand/collapse |
-| Day summary | `.day-summary` | Shows "X/Y" doses taken or "✓ All taken" |
-| Medication row | `.time-row` | One medication's doses for that day |
-| Dose item | `.dose-item` | Individual dose with time, amount, take/undo button |
-| Dose taken | `.dose-item.taken` | Green background when dose is marked taken |
-| Dose overdue | `.dose-item.overdue` | Styling for past untaken doses |
-| Dose future | `.dose-item.future` | Disabled button for future days |
-
-### Medication Form (New/Edit)
-| Field | Description |
-|-------|-------------|
-| Commercial Name | Main medication name (required) |
-| Generic Name | Scientific/generic name (optional) |
-| Taken By | Person taking the medication (optional, enables filtering/sharing) |
-| Packs | Number of full packs |
-| Blisters per Pack | Strips/blisters in each pack |
-| Pills per Blister | Tablets per strip |
-| Loose Pills | Extra pills not in blisters |
-| Pill Weight (mg) | Weight per pill for dose calculation display |
-| Expiry Date | Medication expiration |
-| Notes | Free text notes |
-| Image Upload | Medication photo (preview for new, direct upload for edit) |
-| **Intake Schedule** | One or more intake entries defining usage pattern |
-
-### Intake Schedule
-Each blister defines a recurring intake:
-- **Usage (Pills)**: How many pills per dose
-- **Every (Days)**: Interval (1 = daily, 7 = weekly)
-- **Start (Date/Time)**: When the schedule starts (determines past/future doses)
-- **Remind checkbox**: Enable intake reminders (🔔)
-
-### Modals
-| Modal | Trigger | Content |
-|-------|---------|---------|
-| Medication Detail | Click on coverage card or medication row | Full medication info, stock, schedule preview, edit/delete/ICS buttons |
-| Image Lightbox | Click medication image | Full-size medication image |
-| Share Dialog | "Share" button on schedules | Generate share link for specific "taken by" person |
-| User Schedule Filter | Click on "taken by" badge | Filter schedule by person |
-
-### Settings Sections
-| Section | Settings |
-|---------|----------|
-| General | Language toggle (EN/DE) |
-| Stock Thresholds | Warning days, critical days, expiry warning days |
-| Email Notifications | Enable, email address, stock/intake toggles |
-| Push Notifications (Shoutrrr) | Enable, URL (ntfy/gotify/etc), stock/intake toggles |
-| Reminder Settings | Days before, repeat daily, skip for taken, repeat/nagging |
-| SMTP | Email config (read-only from .env) |
-
-### Settings ENV Defaults
-All user settings can be pre-configured via ENV variables (see `.env.example`).
-These are only used as **defaults when a new user is created**.
-Once a user saves settings in the app, their saved values take precedence over ENV.
-
-| ENV Variable | Setting | Default |
-|--------------|---------|---------|
-| `DEFAULT_EMAIL_ENABLED` | Email notifications | false |
-| `DEFAULT_SHOUTRRR_ENABLED` | Push notifications | false |
-| `DEFAULT_SHOUTRRR_URL` | ntfy/gotify URL | (empty) |
-| `DEFAULT_REPEAT_REMINDERS_ENABLED` | Nagging reminders | false |
-| `DEFAULT_REMINDER_REPEAT_INTERVAL_MINUTES` | Nag interval | 30 |
-| `DEFAULT_MAX_NAGGING_REMINDERS` | Max nags | 5 |
-| `DEFAULT_LOW_STOCK_DAYS` | Low stock threshold | 30 |
-| `DEFAULT_LANGUAGE` | UI language | en |
-
-## Database Schema (`backend/src/db/schema.ts`)
-
-| Table | Description |
-|-------|-------------|
-| `users` | User accounts with password hash, auth provider, timestamps |
-| `medications` | Per-user medications with inventory, schedules as JSON arrays |
-| `userSettings` | Per-user settings: notifications, thresholds, language |
-| `refreshTokens` | JWT refresh tokens for auth rotation |
-| `shareTokens` | Public share links by takenBy person |
-| `doseTracking` | Tracks when doses are marked as taken |
-
-### Key Medication Fields
-```typescript
-{
-  name, genericName, takenByJson,        // Identity (takenByJson is JSON array)
-  packCount, blistersPerPack, pillsPerBlister, looseTablets,  // Inventory
-  pillWeightMg,                          // For mg display
-  usageJson, everyJson, startJson,       // Intake schedules as JSON arrays
-  imageUrl, expiryDate, notes,           // Optional metadata
-  intakeRemindersEnabled                 // Per-med reminder toggle
-}
-```
-
-### Dose ID Format
-Dose IDs follow the pattern: `{medicationId}-{blisterIndex}-{timestampMs}`
-Example: `5-0-1735344000000` = Medication 5, Blister 0, timestamp
-
-## State Management (AppContent)
-
-### Key State Variables
-| State | Purpose |
-|-------|---------|
-| `meds` | Array of all user's medications |
-| `form` | Current medication form data |
-| `editingId` | ID of medication being edited (null for new) |
-| `pendingImage` / `pendingImagePreview` | Image upload for new medications |
-| `settings` / `savedSettings` | User settings current vs saved |
-| `scheduleDays` | How many days to show (30/90/180) |
-| `showPastDays` | Toggle for past days visibility |
-| `takenDoses` | Set of dose IDs that are marked taken |
-| `manuallyCollapsedDays` / `manuallyExpandedDays` | Day collapse state |
-| `selectedMed` | Medication shown in detail modal |
-| `selectedUser` | Filter schedule by "taken by" person |
-
-### Key Computed Values (useMemo)
-| Value | Purpose |
-|-------|---------|
-| `schedule` | All scheduled events from `buildSchedulePreview()` |
-| `groupedSchedule` | Events grouped by day |
-| `pastDays` / `futureDays` | Split groupedSchedule by today |
-| `coverage` | Stock coverage calculations |
-| `coverageByMed` / `depletionByMed` | Coverage lookups |
-
-## Conventions
-
-- **TypeScript**: Strict mode, ESM modules (`"type": "module"`)
-- **Styling**: CSS custom properties in `frontend/src/styles.css`, dark/light theme via `data-theme`
-- **API responses**: Return objects directly, Fastify serializes to JSON
-- **Environment**: Copy `.env.example` → `.env`, secrets must be 10+ chars
-- **i18n**: All UI text via `t('key')` function, translations in `frontend/src/i18n/*.json`
-- **UI Consistency**: Always use existing components for modals, buttons, and forms. For confirmation dialogs, use `ConfirmModal` component. Never create inline modals with custom button styling - all UI elements must match the existing design system. When adding new sections to existing components, ensure font sizes, spacing, margins, and button styles match exactly with other sections. Check existing CSS classes before creating new ones.
-
-## Database Schema Changes (IMPORTANT: Backward Compatibility!)
-
-> ⚠️ **CRITICAL**: The app MUST remain backward compatible with older databases!
-> Users upgrade their Docker containers but keep their existing DB.
-> The app must NOT crash if old columns are missing.
-
-### ⚠️ MANDATORY for EVERY New Feature
-
-**Before implementing ANY feature that touches user data or settings:**
-
-1. **Check if new DB columns are needed** - Does the feature require storing new data?
-2. **If YES → Follow ALL steps below** - Schema.ts + Drizzle migration + ALTER migration + NULL-safe code
-3. **NEVER skip the ALTER migration** - This is the #1 cause of production 500 errors!
-
-**Common mistake:** Adding a column to `schema.ts` and forgetting the ALTER migration in `client.ts`.
-The Drizzle migration only works for NEW databases. Existing production databases need the ALTER migration!
-
-### Schema Management with Drizzle Kit
-
-The database schema uses **Drizzle Kit** for migrations. There is a **single source of truth**:
-
-- **`backend/src/db/schema.ts`** - Drizzle ORM schema definitions (TypeScript)
-- **`backend/drizzle/`** - Generated SQL migrations (auto-generated from schema.ts)
-
-**DO NOT manually edit migration files!** They are generated from schema.ts.
-
-### Adding New Columns
-
-1. **Add to schema.ts** with DEFAULT value:
-   ```typescript
-   maxNaggingReminders: integer("max_nagging_reminders").notNull().default(5),
-   ```
-
-2. **Generate migration**:
-   ```bash
-   cd backend && npx drizzle-kit generate --name add_column_name
-   ```
-
-3. **Add backward-compatible ALTER migration** in `client.ts` `runAlterMigrations()`:
-   ```typescript
-   `ALTER TABLE user_settings ADD COLUMN max_nagging_reminders integer NOT NULL DEFAULT 5`,
-   ```
-
-4. **NULL-safe reading** in routes:
-   ```typescript
-   maxNaggingReminders: settings.maxNaggingReminders ?? 5,
-   ```
-
-### Rules for New Columns
-
-1. **ALWAYS with DEFAULT value**: New columns must have `NOT NULL DEFAULT <value>`
-2. **NULL-safe in code**: All queries must use `?? defaultValue` or `?? false`
-3. **Generate migration**: Run `npx drizzle-kit generate` after schema changes
-4. **Add ALTER migration**: For backward compatibility with existing DBs
-
-### What is NOT Allowed
-
-- ❌ Deleting or renaming columns (breaks old DBs)
-- ❌ `NOT NULL` without `DEFAULT` (INSERT fails)
-- ❌ Reading columns without fallback in code
-- ❌ Manually editing migration SQL files
-- ❌ Documenting "delete DB" as a solution
-
-### When Backward Compatibility is NOT Possible
-
-If a breaking change is unavoidable:
-1. **Explicitly communicate**: Document in release notes
-2. **Migration script**: Provide automatic upgrade script
-3. **Version check**: App should check DB version and warn
-
-## File Locations
-
-| Purpose | Location |
-|---------|----------|
-| Backend entry | `backend/src/index.ts` |
-| Database schema | `backend/src/db/schema.ts` |
-| Drizzle migrations | `backend/drizzle/*.sql` |
-| Drizzle config | `backend/drizzle.config.ts` |
-| Backend routes | `backend/src/routes/*.ts` |
-| Backend services | `backend/src/services/*.ts` |
-| Frontend app | `frontend/src/App.tsx` |
-| Frontend auth | `frontend/src/components/Auth.tsx` |
-| Styles | `frontend/src/styles.css` |
-| i18n English | `frontend/src/i18n/en.json` |
-| i18n German | `frontend/src/i18n/de.json` |
-| Docker prod | `docker-compose.yml` |
-| Docker dev | `docker-compose.dev.yml` |
-| Env template | `.env.example` |
-| Project setup | `docs/PROJECT_SETUP.md` |
-
-## GitHub Project Management
-
-All work is tracked in the [GitHub Project board](https://github.com/users/DanielVolz/projects/1) (Project ID: `PVT_kwHOADH82s4BO2OT`).
-
-### Board Columns (Status)
-| Column | Color | Description |
-|--------|-------|-------------|
-| Triage | Purple | New issues needing review |
-| Backlog | Green | Accepted, not yet started |
-| Ready | Blue | Ready to be picked up |
-| In progress | Yellow | Currently being worked on |
-| Done | Orange | Completed |
-
-### Custom Fields
-| Field | Options | Usage |
-|-------|---------|-------|
-| **Type** | Bug (red), Feature (green), Chore (gray), Documentation (blue) | Categorize the work |
-| **Priority** | High (red), Medium (orange), Low (yellow) | Set urgency |
-| **Size** | XS, S, M, L, XL | Estimate effort |
-
-### Agent Workflow for Issues
-
-1. **Before starting work**: Check the Project board for existing issues. If the task has no issue yet, create one:
-   ```bash
-   gh issue create --title "feat: description" --label enhancement
-   ```
-   Issues with `enhancement`, `bug`, or `triage` labels are **automatically added** to the Project board.
-
-2. **When starting work**: Move the issue to "In progress":
-   ```bash
-   # List items to find the item ID
-   gh project item-list 1 --owner DanielVolz
-   # Update status (use GraphQL for field updates)
-   ```
-
-3. **When work is done locally**: Leave in "In progress" and tell the user to invoke `@release-manager`.
-
-4. **After merge**: The issue moves to "Done" (via `closes #N` in PR body or manually).
-
-### Issue Labels
-| Label | Applied by | Purpose |
-|-------|-----------|--------|
-| `enhancement` | Feature request template | New features |
-| `bug` | Bug report template | Bug fixes |
-| `triage` | Both templates | Needs review |
-
-All three labels trigger the `add-to-project.yml` workflow, which automatically adds the issue to the Project board.
+- Canonical governance: `AGENTS.md`
+- Global engineering rules: see `AGENTS.md` (`Global Engineering Rules` section).
+- Project skills: `.github/skills/README.md`
+- Specialist agents: `.github/agents/testing-manager.agent.md`, `.github/agents/release-manager.agent.md`
diff --git a/.github/skills/README.md b/.github/skills/README.md
new file mode 100644
index 0000000..2759d15
--- /dev/null
+++ b/.github/skills/README.md
@@ -0,0 +1,28 @@
+# MedAssist Agent Skills
+
+This directory contains project skills for VS Code Copilot.
+
+Each skill lives in its own folder and must include a `SKILL.md` file.
+
+## Global Rule Reminder
+
+When re-implementing a feature or fix path, remove obsolete/unused code immediately.
+Do not leave dead code behind.
+Also follow the canonical global engineering rules in `AGENTS.md`.
+Use one governance source to avoid duplicated or conflicting policy text.
+
+## Skills
+
+- `medassist-karpathy-core` — enforce assumption clarity, simplicity, surgical diffs, and verifiable execution.
+- `medassist-architecture-guard` — enforce frontend/backend boundary and `/api/*` data-flow conventions.
+- `medassist-db-compat-check` — enforce backward-compatible SQLite/Drizzle schema changes.
+- `medassist-i18n-enforcer` — enforce translation-key-only UI copy with EN/DE parity.
+- `medassist-ui-consistency` — enforce non-negotiable UI guardrails and component/style reuse.
+- `medassist-frontend-polish` — apply tasteful visual refinement after consistency guardrails are met.
+- `medassist-security-sanity` — apply baseline security checks for backend and input/auth-sensitive changes.
+- `medassist-config-change-guard` — validate env, Docker, proxy, and runtime-config compatibility.
+- `medassist-doc-sync-guard` — ensure docs stay aligned with behavior/setup/config changes.
+- `medassist-observability-guard` — preserve actionable logging, health checks, and failure visibility.
+- `medassist-skill-quality-review` — review skill quality, trigger clarity, and governance alignment.
+- `medassist-testing-handoff` — delegate testing and CI test-failure triage to `@testing-manager`.
+- `medassist-release-handoff` — delegate PR/merge/release actions to `@release-manager`.
diff --git a/.github/skills/medassist-architecture-guard/SKILL.md b/.github/skills/medassist-architecture-guard/SKILL.md
new file mode 100644
index 0000000..2ae1b71
--- /dev/null
+++ b/.github/skills/medassist-architecture-guard/SKILL.md
@@ -0,0 +1,35 @@
+---
+name: medassist-architecture-guard
+description: Guard MedAssist architectural boundaries and route/data-flow conventions when changing backend or frontend code, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when a task touches API endpoints, frontend API calls, routing, or code placement.
+
+## Goals
+
+- Keep responsibilities in the correct layer.
+- Preserve MedAssist proxy and routing conventions.
+- Prevent architecture drift and cross-layer anti-patterns.
+
+## Required Checks
+
+1. Frontend network calls use `/api/*` paths.
+2. Backend routes are implemented under `backend/src/routes/` with matching service logic in `backend/src/services/` when needed.
+3. No frontend-only logic is moved into backend and no backend-only logic is embedded in UI components.
+4. Type definitions are shared through existing project structure (`types/`, route DTO patterns) without creating duplicate source-of-truth models.
+
+## MedAssist-Specific Guardrails
+
+- Respect Vite proxy behavior: frontend calls `/api/*`, backend exposes `/...` routes.
+- Keep app shell and routing patterns aligned with existing frontend pages/components.
+- Prefer minimal, local changes over broad restructures.
+
+## Response Format
+
+When this skill is used, summarize:
+
+- Which architectural checks were applied
+- Which files are affected
+- Any boundary risks found and how they were resolved
diff --git a/.github/skills/medassist-config-change-guard/SKILL.md b/.github/skills/medassist-config-change-guard/SKILL.md
new file mode 100644
index 0000000..6bf4156
--- /dev/null
+++ b/.github/skills/medassist-config-change-guard/SKILL.md
@@ -0,0 +1,43 @@
+---
+name: medassist-config-change-guard
+description: Validate MedAssist configuration changes across env vars, Docker compose, proxy settings, and runtime defaults, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when changes touch `.env`, Docker files, Vite proxy settings, runtime defaults, or app startup behavior.
+
+## Objective
+
+Prevent configuration drift and broken local/CI environments.
+
+## Required Checks
+
+1. New/changed config has safe defaults.
+2. Env changes are backward-compatible where feasible.
+3. Docker/dev runtime changes remain consistent across services.
+4. Frontend/backend URL/proxy conventions remain valid (`/api/*`).
+5. Documentation reflects configuration changes.
+
+## Files to Prioritize
+
+- `.env.example`
+- `docker-compose.yml`
+- `docker-compose.dev.yml`
+- `frontend/vite.config.ts`
+- Relevant package scripts and startup files
+
+## Anti-Patterns
+
+- Hidden required env vars with no defaults.
+- Inconsistent host/port/proxy settings across environments.
+- Config changes without doc updates.
+
+## Response Format
+
+Report:
+
+- Config files reviewed
+- Compatibility impact (none/low/high)
+- Required follow-up updates
+- Final readiness recommendation
diff --git a/.github/skills/medassist-db-compat-check/SKILL.md b/.github/skills/medassist-db-compat-check/SKILL.md
new file mode 100644
index 0000000..792570d
--- /dev/null
+++ b/.github/skills/medassist-db-compat-check/SKILL.md
@@ -0,0 +1,40 @@
+---
+name: medassist-db-compat-check
+description: Enforce backward-compatible database changes for MedAssist SQLite and Drizzle migrations, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill for any feature or fix that adds or reads persisted data.
+
+## Mandatory Sequence
+
+For every new persisted field/column:
+
+1. Add the column in `backend/src/db/schema.ts` with `NOT NULL DEFAULT <value>`.
+2. Generate migration with Drizzle Kit.
+3. Add matching `ALTER TABLE` logic in `backend/src/db/client.ts` inside `runAlterMigrations()`.
+4. Read values null-safe in routes/services (`?? defaultValue`).
+
+## Hard Rules
+
+- Never remove or rename existing columns.
+- Never add non-null columns without defaults.
+- Never read newly added fields without fallback.
+- Never manually edit generated Drizzle SQL migrations.
+
+## Verification Checklist
+
+- Schema update exists.
+- Generated migration exists.
+- Alter migration for existing DBs exists.
+- Runtime reads are fallback-safe.
+
+## Response Format
+
+Report these items explicitly:
+
+- New/changed columns
+- Added alter-migration statements
+- Null-safe read locations
+- Remaining migration risk (if any)
diff --git a/.github/skills/medassist-doc-sync-guard/SKILL.md b/.github/skills/medassist-doc-sync-guard/SKILL.md
new file mode 100644
index 0000000..9552b84
--- /dev/null
+++ b/.github/skills/medassist-doc-sync-guard/SKILL.md
@@ -0,0 +1,39 @@
+---
+name: medassist-doc-sync-guard
+description: Ensure MedAssist documentation stays aligned with behavior changes in APIs, configuration, setup, and operations, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when code changes alter behavior, setup steps, environment variables, user workflows, or operational commands.
+
+## Objective
+
+Keep docs consistent with actual product behavior and avoid stale setup/run guidance.
+
+## Required Checks
+
+1. If API behavior changed, verify relevant docs are updated.
+2. If ENV/config changed, update documented variables/defaults.
+3. If workflow/commands changed, update setup/run instructions.
+4. If user-facing behavior changed, update user-facing description.
+
+## Candidate Documentation Files
+
+- `README.md`
+- `docs/PROJECT_SETUP.md`
+- `docs/TECH_STACK.md`
+
+## Anti-Patterns
+
+- Shipping behavior changes without docs updates.
+- Updating docs with speculative/unverified commands.
+- Duplicating conflicting instructions across files.
+
+## Response Format
+
+Return:
+
+- Doc files that should change
+- Proposed update summary per file
+- Any intentionally skipped docs and reason
diff --git a/.github/skills/medassist-frontend-polish/SKILL.md b/.github/skills/medassist-frontend-polish/SKILL.md
new file mode 100644
index 0000000..ad5c317
--- /dev/null
+++ b/.github/skills/medassist-frontend-polish/SKILL.md
@@ -0,0 +1,67 @@
+---
+name: medassist-frontend-polish
+description: Improve frontend visual quality within the existing MedAssist design system, without introducing new themes, font stacks, or disruptive UI patterns, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when the user wants UI improvements, better styling, or a more polished frontend, but the feature must stay consistent with MedAssist product UX.
+
+## Scope
+
+This is the **visual enhancement skill**.
+It refines quality *within* existing product conventions.
+
+Apply `medassist-ui-consistency` rules first, then use this skill for tasteful polish.
+
+## Do Not Use This Skill For
+
+- Replacing base UI patterns/components with new ones.
+- New design-system direction, visual identity, or broad layout language changes.
+- Marketing/brand-experiment pages that intentionally break product conventions.
+
+## Objective
+
+Deliver production-grade visual refinement that feels intentionally designed while remaining fully consistent with existing MedAssist components, spacing, typography, and interaction patterns.
+
+## Strict Constraints
+
+- Reuse existing components and patterns first (`ConfirmModal`, `MedicationAvatar`, existing form/button/layout patterns).
+- Do not introduce new global theme systems, font families, or visual identity changes.
+- Do not invent new UX flows, pages, or interaction models unless explicitly requested.
+- Keep frontend text i18n-safe: use `t("...")` and EN/DE keys.
+- Respect accessibility and readability over decorative effects.
+
+## Allowed Enhancements
+
+- Better spacing rhythm and visual hierarchy.
+- Cleaner grouping, alignment, and density adjustments.
+- Improved states (hover, focus, disabled, loading) using existing style language.
+- Subtle transitions/micro-interactions that do not distract and do not change behavior.
+- Consistent empty/error/success presentation using existing UI conventions.
+
+## Not Allowed
+
+- Random aesthetic overhauls.
+- New color systems or hardcoded ad-hoc colors that break current theme tokens.
+- Heavy animation, parallax, or attention-stealing motion.
+- Typography experiments that diverge from current product style.
+- "Creative" layout changes that reduce usability or consistency.
+
+## Implementation Workflow
+
+1. Confirm `medassist-ui-consistency` guardrails are satisfied.
+2. Identify existing components and CSS patterns to reuse.
+3. Define the smallest visual changes that improve clarity and quality.
+4. Apply refinements in-place without changing core behavior.
+5. Validate consistency across neighboring views/components.
+6. Ensure i18n and accessibility are preserved.
+
+## Response Format
+
+When using this skill, report:
+
+- Reused components and style primitives
+- Specific polish improvements applied
+- Any trade-offs/constraints respected
+- Confirmation that no new design system or disruptive UX pattern was introduced
diff --git a/.github/skills/medassist-i18n-enforcer/SKILL.md b/.github/skills/medassist-i18n-enforcer/SKILL.md
new file mode 100644
index 0000000..c733fe7
--- /dev/null
+++ b/.github/skills/medassist-i18n-enforcer/SKILL.md
@@ -0,0 +1,31 @@
+---
+name: medassist-i18n-enforcer
+description: Enforce MedAssist i18n rules so UI copy is always translation-key based for English and German, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when changing frontend UI text, form labels, alerts, dialogs, or page content.
+
+## Rules
+
+- Do not hardcode new user-facing strings in React components.
+- Use translation keys via `t("...")`.
+- Add or update matching keys in:
+  - `frontend/src/i18n/en.json`
+  - `frontend/src/i18n/de.json`
+- Keep semantic key naming consistent with existing namespaces.
+
+## Validation
+
+1. Every new UI string has a key.
+2. English and German entries are both present.
+3. No fallback-to-English hardcoded text remains in JSX.
+
+## Response Format
+
+List:
+
+- New keys added
+- Files where keys were used
+- Any intentionally unchanged text and reason
diff --git a/.github/skills/medassist-karpathy-core/SKILL.md b/.github/skills/medassist-karpathy-core/SKILL.md
new file mode 100644
index 0000000..e69de29
diff --git a/.github/skills/medassist-observability-guard/SKILL.md b/.github/skills/medassist-observability-guard/SKILL.md
new file mode 100644
index 0000000..16438a1
--- /dev/null
+++ b/.github/skills/medassist-observability-guard/SKILL.md
@@ -0,0 +1,41 @@
+---
+name: medassist-observability-guard
+description: Ensure MedAssist changes preserve actionable logging, health checks, and clear operational error visibility, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when changes affect backend services, schedulers, integrations, startup flow, or failure handling.
+
+## Objective
+
+Maintain operational visibility so failures are detectable, diagnosable, and actionable.
+
+## Required Checks
+
+1. Critical paths keep clear error reporting.
+2. Health-check behavior remains intact and meaningful.
+3. Logs contain actionable context without leaking secrets.
+4. Errors are surfaced with enough detail for debugging.
+5. Silent failure paths are avoided.
+
+## MedAssist Focus Areas
+
+- `backend/src/index.ts`
+- `backend/src/routes/health.ts`
+- `backend/src/services/*`
+- Scheduler and notification flows
+
+## Anti-Patterns
+
+- Swallowed exceptions.
+- Generic logs with no context.
+- Missing visibility for background failures.
+
+## Response Format
+
+Return:
+
+- Observability touchpoints reviewed
+- Gaps found and suggested fixes
+- Operational risk level
diff --git a/.github/skills/medassist-release-handoff/SKILL.md b/.github/skills/medassist-release-handoff/SKILL.md
new file mode 100644
index 0000000..6a62f1e
--- /dev/null
+++ b/.github/skills/medassist-release-handoff/SKILL.md
@@ -0,0 +1,30 @@
+---
+name: medassist-release-handoff
+description: Enforce MedAssist release ownership by preventing remote git/release actions by normal agents and delegating to release-manager, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when a request includes branch push, PR creation, merge, tagging, release notes publishing, or release orchestration.
+
+## Ownership Rules
+
+- Remote git/release actions are owned by `@release-manager`.
+- Normal agent/Copilot must not perform:
+  - `git push`
+  - PR creation/merge
+  - tag/release creation
+
+## Required Behavior
+
+1. Perform local code edits only.
+2. Summarize local changes clearly.
+3. Provide handoff instruction to `@release-manager` for shipping steps.
+
+## Response Format
+
+When this skill applies, return:
+
+- "Release handoff required"
+- Delegate target: `@release-manager`
+- Shipping checklist (branch, PR, CI, merge, release)
diff --git a/.github/skills/medassist-security-sanity/SKILL.md b/.github/skills/medassist-security-sanity/SKILL.md
new file mode 100644
index 0000000..3ef63eb
--- /dev/null
+++ b/.github/skills/medassist-security-sanity/SKILL.md
@@ -0,0 +1,43 @@
+---
+name: medassist-security-sanity
+description: Apply baseline security checks to MedAssist code changes, especially for backend routes, auth flows, and input handling, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when a change touches backend routes, auth/session logic, file handling, imports/exports, or external input.
+
+## Objective
+
+Prevent common security regressions with fast, practical checks during implementation.
+
+## Required Checks
+
+1. Validate and sanitize external input at API boundaries.
+2. Enforce auth/authz server-side for protected actions.
+3. Ensure secrets/tokens are never hardcoded or logged.
+4. Avoid information leakage in error responses.
+5. Keep permission-sensitive operations explicit and auditable.
+
+## MedAssist Focus Areas
+
+- Route handlers in `backend/src/routes/`.
+- Auth-related code in `backend/src/plugins/` and auth routes.
+- Data import/export and sharing endpoints.
+- File/image upload and serving paths.
+
+## Anti-Patterns
+
+- Trusting frontend-only checks.
+- Accepting unchecked query/body/path input.
+- Returning raw internal errors to clients.
+- Weak defaults for sensitive operations.
+
+## Response Format
+
+Report:
+
+- Security-sensitive files reviewed
+- Findings by severity (critical/major/minor)
+- Concrete remediation actions
+- Residual risk (if any)
diff --git a/.github/skills/medassist-skill-quality-review/SKILL.md b/.github/skills/medassist-skill-quality-review/SKILL.md
new file mode 100644
index 0000000..5cf683c
--- /dev/null
+++ b/.github/skills/medassist-skill-quality-review/SKILL.md
@@ -0,0 +1,42 @@
+---
+name: medassist-skill-quality-review
+description: Review MedAssist skills for trigger quality, scope boundaries, and conflicts with AGENTS governance, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when creating or modifying any skill under `.github/skills/`.
+
+## Objective
+
+Keep skills discoverable, non-overlapping, and aligned with canonical governance in `AGENTS.md`.
+
+## Required Checks
+
+1. Frontmatter has clear `name` and specific `description` trigger language.
+2. Scope boundaries are explicit (`when to use` / `do not use`).
+3. No conflicts with `AGENTS.md` ownership rules.
+4. No policy duplication that can drift from canonical governance.
+5. References to related skills are explicit where workflows chain.
+
+## Quality Signals
+
+- Trigger phrases are concrete and task-shaped.
+- Instructions are concise, actionable, and deterministic.
+- Response format is clear and useful for downstream handoff.
+
+## Anti-Patterns
+
+- Vague descriptions that match everything.
+- Duplicate skills with overlapping responsibilities.
+- Contradictory ownership guidance.
+- Long policy blocks copied from other files.
+
+## Response Format
+
+Return:
+
+- Scope/trigger issues found
+- Overlap/conflict findings
+- Suggested minimal edits
+- Final pass/fail recommendation
diff --git a/.github/skills/medassist-testing-handoff/SKILL.md b/.github/skills/medassist-testing-handoff/SKILL.md
new file mode 100644
index 0000000..a8d116c
--- /dev/null
+++ b/.github/skills/medassist-testing-handoff/SKILL.md
@@ -0,0 +1,31 @@
+---
+name: medassist-testing-handoff
+description: Enforce MedAssist testing ownership by delegating test planning, execution, and CI test failure triage to testing-manager, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill whenever a task includes writing tests, running tests, or diagnosing test-related CI failures.
+
+## Ownership Rules
+
+- Test planning, implementation, and execution are owned by `@testing-manager`.
+- CI test-failure triage (`test.yml`, `e2e.yml`) is owned by `@testing-manager`.
+- Normal coding agent should hand off testing tasks instead of executing testing workflows directly.
+
+## Handoff Template
+
+Use this structure for delegation:
+
+1. Scope: feature/fix and affected files
+2. Expected behavior
+3. Suggested test layers (unit/integration/e2e)
+4. CI failure context (if applicable)
+
+## Response Format
+
+When triggered, output:
+
+- "Testing handoff required"
+- Delegate target: `@testing-manager`
+- Minimal handoff brief (scope + expected behavior)
diff --git a/.github/skills/medassist-ui-consistency/SKILL.md b/.github/skills/medassist-ui-consistency/SKILL.md
new file mode 100644
index 0000000..647ddd1
--- /dev/null
+++ b/.github/skills/medassist-ui-consistency/SKILL.md
@@ -0,0 +1,42 @@
+---
+name: medassist-ui-consistency
+description: Enforce non-negotiable MedAssist UI guardrails by reusing existing components, styles, and interaction patterns, including equivalent requests phrased in German.
+---
+
+# Skill Instructions
+
+Use this skill when implementing or editing UI flows, modals, buttons, forms, schedule views, or settings screens.
+
+## Scope
+
+This is the **guardrail skill** for UI work.
+Use it to enforce consistency and prevent design drift.
+
+Use `medassist-frontend-polish` only after these guardrails are satisfied.
+
+## Do Not Use This Skill For
+
+- Creative visual redesign requests where no product consistency constraints apply.
+- Marketing-style one-off pages outside MedAssist product UI conventions.
+
+## Rules
+
+- Reuse existing components (for example `ConfirmModal`, `MedicationAvatar`) before creating new primitives.
+- Keep spacing, typography, and button styles aligned with existing patterns.
+- Avoid custom inline modal/button patterns that diverge from project design.
+- Prefer extending existing CSS classes/styles instead of introducing parallel styling systems.
+
+## Decision Heuristics
+
+1. If an equivalent component exists, reuse it.
+2. If small variant is needed, extend existing styles minimally.
+3. If a new component is unavoidable, match existing naming and structure conventions.
+
+## Response Format
+
+Provide:
+
+- Reused components/styles
+- Any new UI element and why reuse was not possible
+- Consistency risks reviewed
+- Confirmation that `medassist-frontend-polish` constraints remain compatible (if polish work is also requested)