florian.wilde/code-vorlage
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

refactor: rebuild template — Tailwind v4, Docker self-hosting, passkey auth

Browse Source 
Toolchain fixes (all previously broken):
- npm run lint: next lint was removed in Next 16 -> eslint with flat config
- .eslintrc.json was ignored by ESLint 9 -> eslint.config.mjs
- npm test / test:e2e exited 1 with no tests -> passWithNoTests
- Vitest scanned tests/ and would have run Playwright specs -> scoped to src/
- Playwright targeted Mobile Safari while docs installed only chromium
- reuseExistingServer silently tested a foreign server on :3000 -> E2E_PORT
- 11 high-severity vulns -> npm audit fix
- deny rule Read(**/.env*) also blocked .env.example -> precise patterns

Stack changes:
- Tailwind v3 -> v4 (CSS-first, no tailwind.config.ts, tw-animate-css)
- shadcn regenerated for v4; 33 components -> 6 core, bundled radix-ui
- Supabase removed entirely; data layer is now chosen per project
- Vercel removed; Docker Compose self-hosting with scripts/update.sh
- Better Auth + passkey plugin as the binding auth standard
- ThemeProvider and Sonner mounted; dark mode and toasts now actually work

Workflow system:
- Sub-agents wired: /frontend, /backend, /qa delegate to .claude/agents
- Checklists folded into their SKILL.md; one file per skill
- Rules rewritten: DB-agnostic backend, passkey security, v4 frontend
- Spec language settled as German, skill instructions English
This commit is contained in:
Florian Wilde
2026-08-09 00:48:50 +02:00
parent a8b196e92b
commit b0c4e9e9b9
101 changed files with 3651 additions and 7695 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/refine/SKILL.md
+64 -78
View File
@@ -1,113 +1,99 @@
---
name: refine
description: Always use when the user wants to discuss an exsiting feature or specification. Open an existing feature spec to improve, extend, or fundamentally challenge it. Pass the feature ID as argument (e.g. /refine PROJ-2).
description: Reopen an existing feature spec to improve, extend or fundamentally challenge it. Pass the feature ID.
argument-hint: "PROJ-X"
user-invocable: true
---
# Feature Spec Refiner
# Refine
## Role
You are an experienced Product Manager reviewing a live spec. Your job is to improve, extend, or fundamentally challenge the spec based on what the user tells you.
You are a product manager reviewing a live spec. Improve it, extend it, or challenge
it — depending on what brought the user back.
## Before Starting
1. Read the feature spec `features/PROJ-X-*.md` — understand the full current state
2. Read `features/INDEX.md` — understand dependencies, status, and context
3. Read `docs/PRD.md` — keep the project vision in mind
## Before starting
**If no argument was provided** (no PROJ-X ID given):
> "Which feature spec would you like to refine?" — list all existing features from INDEX.md.
1. Read `features/PROJ-X-*.md` — the full current state
2. Read `features/INDEX.md` — status and dependencies
3. Read `docs/PRD.md` — keep the vision in view
**If the PROJ-X ID doesn't exist**: tell the user and list existing features.
**No argument given:** ask which spec, listing the features from INDEX.md.
**Unknown ID:** say so and list what exists.
## Opening Question (ALWAYS ask this first)
> "What brought you back to this spec?"
## Always open with this
This answer determines everything. Listen carefully — it will tell you which of the three paths to take.
> "Was bringt dich zurück zu dieser Spec?"
## Three Paths
The answer decides the path.
### Path 1: Something Changed
*Trigger: "scope changed", "we got user feedback", "business logic is different", "stakeholder changed the requirements"*
## Three paths
Run a targeted interview on the affected areas only:
- What specifically changed?
- Which user stories are affected?
- Which acceptance criteria need to be updated or removed?
- Do any edge cases change?
- Do dependencies change?
- Does the Out of Scope section need updating? (something previously excluded is now included, or vice versa)
### Path 1 — Something changed
*"Scope hat sich geändert", "wir haben Nutzerfeedback", "die Anforderung ist anders"*
### Path 2: Implementation Revealed Gaps
*Trigger: "during implementation we found...", "the backend doesn't support...", "we didn't think about X scenario"*
Targeted interview on the affected areas only: what exactly changed, which user
stories and criteria are affected, which edge cases shift, whether dependencies
move, and whether Out of Scope needs updating in either direction.
Focus on making the spec tighter:
- What specific scenario was missing?
- Should this become a new acceptance criterion or edge case?
- Does this change any existing criteria?
- Are there related gaps we should close now while we're here?
### Path 2 — Implementation revealed a gap
*"Bei der Umsetzung kam raus, dass…", "an den Fall haben wir nicht gedacht"*
### Path 3: Fundamental Challenge
*Trigger: "I'm not sure this feature is right", "maybe we should rethink this", "this might actually be two features"*
Tighten the spec: which scenario was missing, does it become a new acceptance
criterion or an edge case, does it invalidate an existing criterion, and are there
adjacent gaps worth closing now.
Challenge the entire spec from first principles:
- What assumption is being questioned?
- Is the user story still the right framing?
- Should this feature be split? If so, what are the two features?
- Should it be merged with another feature?
- What would the absolute minimal version of this feature look like?
- What moves to Out of Scope as a result of this challenge?
### Path 3 — Fundamental challenge
*"Ich bin nicht sicher, ob das Feature so richtig ist", "das sind vielleicht zwei Features"*
If the feature should be split: create the new spec file using the `/write-spec` workflow, and update `features/INDEX.md` accordingly.
Challenge from first principles: which assumption is in doubt, is the user story
still the right framing, should this split or merge, what is the minimal version,
and what moves to Out of Scope as a result.
## The Grill Me Principle
Same as in `/init` and `/write-spec`:
- **One question at a time** — never list multiple questions
- **Always provide a recommended answer** — the user confirms or corrects it
- **Follow the conversation** — don't follow a fixed script
- **Explore codebase first** if it can answer a question
- **Stop when you have full clarity** on what needs to change
If it should split: create the new spec via the `/write-spec` workflow and update
`features/INDEX.md`.
## After the Interview: Update the Spec
## Grill Me principle
Make the changes to `features/PROJ-X-*.md`. After saving, re-read the file to verify the changes are present.
One question at a time, always with a recommendation, following the conversation
rather than a script. Read the codebase before asking anything it can answer. Stop
when the change is fully clear.
### Maintain the Decision Log and Open Questions
## Update the spec
**Close resolved Open Questions:**
For any `- [ ]` items in Open Questions that are now answered, mark them as `- [x]` and add a brief resolution note:
Edit `features/PROJ-X-*.md`, then re-read it to verify the change landed.
**Close resolved open questions** — mark `- [x]` with the resolution:
```
- [x] Should we support bulk delete? → No, deferred to P1 (2026-05-19)
- [x] Sollen wir Massenlöschen unterstützen? → Nein, verschoben auf P1 (2026-08-09)
```
**Log new decisions:**
Any decision made during this refinement session belongs in the Decision Log. Add to the relevant sub-section (Product or Technical) with rationale and date. Decisions made here are often the most important — they reflect real-world feedback changing the original plan.
**Log new decisions** in the Entscheidungslog with rationale and date. Decisions
made here matter most — they are reality correcting the original plan.
**Add new Open Questions:**
If the refinement surfaced questions that couldn't be resolved now, add them as `- [ ]` items.
**Add new open questions** as `- [ ]` if anything stays unresolved.
## Update Tracking Files
- Update `features/INDEX.md` if status or dependencies changed
- Update `docs/PRD.md` if the roadmap is affected
## Update tracking
## Checklist Before Completion
- [ ] Opening question asked and path determined
- [ ] All interview questions resolved
- [ ] Spec file updated and verified (re-read after editing)
- [ ] Out of Scope updated if scope boundaries changed
- [ ] Resolved Open Questions marked as `- [x]` with resolution note
- [ ] New decisions logged in Decision Log with rationale
- [ ] New Open Questions added if anything remains unresolved
- [ ] `features/INDEX.md` updated if status or dependencies changed
- [ ] `docs/PRD.md` updated if roadmap affected
- [ ] User has reviewed the changes
- `features/INDEX.md` if status or dependencies changed
- `docs/PRD.md` if the roadmap is affected
## Wrap up
- [ ] Opening question asked, path identified
- [ ] Interview resolved
- [ ] Spec updated and re-read to verify
- [ ] Out of Scope adjusted if boundaries moved
- [ ] Resolved questions marked `- [x]` with a note
- [ ] New decisions logged with rationale
- [ ] INDEX.md / PRD updated where affected
- [ ] User reviewed the changes
## Handoff
Depends on the path taken:
- Path 1 or 2: "Spec updated. Continue with the next step in your workflow."
- Path 3 (split): "New spec created for PROJ-X. Run `/architecture` to design the technical approach."
## Git Commit
- Path 1 or 2 → "Spec aktualisiert. Mach mit deinem nächsten Workflow-Schritt weiter."
- Path 3 with a split → "Neue Spec für PROJ-Y angelegt. Nächster Schritt: `/architecture`."
## Commit
```
feat(PROJ-X): Refine feature specification — [reason]
```
feat(PROJ-X): Refine feature specification — [brief reason]
```