mirror of
https://github.com/velocitatem/cvfs.git
synced 2026-05-31 08:43:37 +00:00
Initial commit
This commit is contained in:
14
.claude/commands/api.md
Normal file
14
.claude/commands/api.md
Normal 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
15
.claude/commands/build.md
Normal 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
11
.claude/commands/page.md
Normal 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
11
.claude/commands/plan.md
Normal 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.
|
||||
10
.claude/commands/review.md
Normal file
10
.claude/commands/review.md
Normal 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
10
.claude/commands/ship.md
Normal 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.
|
||||
Reference in New Issue
Block a user