Initial commit

This commit is contained in:
Daniel Alves Rösel
2026-04-02 18:47:14 +02:00
committed by GitHub
commit 90ad5e0260
94 changed files with 7797 additions and 0 deletions

14
.claude/commands/api.md Normal file
View File

@@ -0,0 +1,14 @@
Scaffold a new API endpoint. Read apps/backend/fastapi/server.py (or flask if BACKEND_MODE=flask) first.
From the arguments, determine:
- HTTP method and path (e.g. POST /items)
- Request/response shape
- Any DB or external service calls needed
Add the route to the appropriate server.py. Follow the existing structure:
- Use Pydantic models for FastAPI request/response schemas
- Use dotenv for any config
- Add proper status codes and error responses
- Keep business logic out of the route handler; extract to a helper if more than ~15 lines
If a new dependency is needed, add it to requirements.txt.

15
.claude/commands/build.md Normal file
View File

@@ -0,0 +1,15 @@
Read CLAUDE.md and AGENTS.md. Read the relevant existing code before making any changes.
Implement the feature or task described in the arguments end-to-end across the full stack as needed. Follow the code style rules in CLAUDE.md strictly:
- No redundant comments, no boilerplate, no fluff
- Pure functions preferred, side effects at boundaries
- Reuse what already exists in alveslib before writing new utilities
- Type all public interfaces
- Keep modules under 400 lines
After implementing, run a quick sanity check:
- If Python changed: check imports resolve correctly
- If Next.js changed: check TypeScript compiles (bun run typecheck)
- If docker-compose changed: verify YAML is valid
Do not create documentation files. Do not add emojis. Summarize what was done in one paragraph.

11
.claude/commands/page.md Normal file
View File

@@ -0,0 +1,11 @@
Scaffold a new Next.js App Router page. Read apps/webapp/src/app/layout.tsx and an existing page (e.g. apps/webapp/src/app/page.tsx) for context.
From the arguments, determine:
- Route path (maps to directory under apps/webapp/src/app/)
- Whether it needs auth (server component checking Supabase session)
- Whether it needs client interactivity (use client directive)
- Data it needs to fetch
Create the page file bare-bones with correct structure - no inline styles. Add any new strings to apps/webapp/src/locales/en/common.json. If a reusable component is needed, create it in apps/webapp/src/components/ without styling (styling is done last per CLAUDE.md).
If the page requires server actions, create an adjacent actions.ts file.

11
.claude/commands/plan.md Normal file
View File

@@ -0,0 +1,11 @@
Read CLAUDE.md and AGENTS.md to understand the project structure, then read the current state of the codebase.
Given the idea or feature described by the user (provided as arguments to this command, or ask if not given), produce a direct implementation plan:
1. Which parts of the scaffold to use (webapp, backend, worker, ml, src)
2. What files to create or modify and in what order
3. What dependencies to add to requirements.txt or package.json
4. Any services to enable in docker-compose.yml
5. Any env vars to add to .env.example
Be specific and concrete. No fluff. The plan should be immediately actionable by you or a developer.

View File

@@ -0,0 +1,10 @@
Run `git diff HEAD` (or `git diff HEAD~1` if nothing staged) to get recent changes.
Review the diff for:
1. Correctness - logic errors, off-by-ones, missing error handling
2. Code style - violations of CLAUDE.md tenets (redundancy, unclear names, noisy loops)
3. Security - exposed secrets, unvalidated input, CORS issues, SQL injection surface
4. Performance - N+1 queries, blocking I/O in async context, missing indices
5. Missing edge cases or TODOs that should be addressed before shipping
Be direct. List issues with file:line references where possible. Skip praise.

10
.claude/commands/ship.md Normal file
View File

@@ -0,0 +1,10 @@
Stage all meaningful changes and create a commit with a concise, accurate message following conventional commits format (feat:, fix:, refactor:, chore:, etc.).
Steps:
1. Run `git status` and `git diff` to understand what changed
2. Skip any generated files, lockfiles (unless intentional), secrets, or build artifacts
3. Stage the relevant changes with `git add`
4. Write a commit message: one-line summary (type: description), optional body if needed
5. Commit
Do not push unless explicitly asked. Do not amend existing commits. Report what was committed.