Template
refactor: rebuild template — Tailwind v4, Docker self-hosting, passkey auth
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
@@ -1,104 +1,58 @@
|
||||
---
|
||||
name: help
|
||||
description: Context-aware guide that tells you where you are in the workflow and what to do next. Use anytime you're unsure.
|
||||
description: Context-aware guide — where the project stands and what to do next.
|
||||
argument-hint: "optional question"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
# Project Help Guide
|
||||
# Help
|
||||
|
||||
You are a helpful project assistant. Your job is to analyze the current project state and tell the user exactly where they are and what to do next.
|
||||
Work out where the project actually stands, then say what to do next. Be concrete,
|
||||
be short.
|
||||
|
||||
## When Invoked
|
||||
## 1. Read the state
|
||||
|
||||
### Step 1: Analyze Current State
|
||||
1. `docs/PRD.md` — still the empty template, or filled in?
|
||||
2. `features/INDEX.md` — which features exist, at which status?
|
||||
3. For the active feature, check which sections its spec already has:
|
||||
Tech Design (`/architecture`), QA Test Results (`/qa`), Deployment (`/deploy`)
|
||||
4. Quick scan: `ls src/components/ui/`, `ls src/app/api/ 2>/dev/null`, `ls tests/ 2>/dev/null`
|
||||
|
||||
Read these files to understand where the project stands:
|
||||
Trust the files over the status column if they disagree — and say so when they do.
|
||||
|
||||
1. **Check PRD:** Read `docs/PRD.md`
|
||||
- Is it still the empty template? → Project not initialized yet
|
||||
- Is it filled out? → Project has been set up
|
||||
## 2. Name the next step
|
||||
|
||||
2. **Check Feature Index:** Read `features/INDEX.md`
|
||||
- No features listed? → No features created yet
|
||||
- Features exist? → Check their statuses
|
||||
| State | Next step |
|
||||
|-------|-----------|
|
||||
| PRD is the empty template | `/init` mit einer kurzen Beschreibung der Idee |
|
||||
| PRD filled, no features | `/write-spec` für das erste Feature |
|
||||
| Status Roadmap | `/write-spec PROJ-X` — Spec schreiben |
|
||||
| Status Planned | `/architecture PROJ-X` — technisches Design |
|
||||
| Status Architected | `/frontend PROJ-X` — UI bauen |
|
||||
| Frontend done, needs a server side | `/backend PROJ-X` |
|
||||
| Implemented, no QA section | `/qa PROJ-X` |
|
||||
| Status Approved | `/deploy PROJ-X` |
|
||||
| Everything deployed | `/write-spec` für das nächste Feature aus der PRD-Roadmap |
|
||||
|
||||
3. **Check Feature Specs:** For each feature in INDEX.md, check if:
|
||||
- Tech Design section exists (added by /architecture)
|
||||
- QA Test Results section exists (added by /qa)
|
||||
- Deployment section exists (added by /deploy)
|
||||
## 3. Answer the question, if there was one
|
||||
|
||||
4. **Check Codebase:** Quick scan of what's been built
|
||||
- `ls src/components/*.tsx 2>/dev/null` → Custom components
|
||||
- `ls src/app/api/ 2>/dev/null` → API routes
|
||||
- `ls src/components/ui/` → Installed shadcn components
|
||||
If the user asked something specific, answer that **first**, then show the status.
|
||||
Common ones: which skills exist, how to add a feature, how to customize the
|
||||
template (CLAUDE.md, `.claude/rules/`, `.claude/skills/`), how deployment works
|
||||
(Docker Compose, `scripts/update.sh` — no Vercel).
|
||||
|
||||
### Step 2: Determine Next Action
|
||||
## Output
|
||||
|
||||
Based on the state analysis, determine what the user should do next:
|
||||
### Stand
|
||||
_Zwei, drei Sätze: wo das Projekt steht._
|
||||
|
||||
**If PRD is empty template:**
|
||||
> Your project hasn't been initialized yet.
|
||||
> Run `/init` with a description of what you want to build.
|
||||
> Example: `/init I want to build a task management app for small teams`
|
||||
### Features
|
||||
_Tabelle aus INDEX.md._
|
||||
|
||||
**If PRD exists but no features:**
|
||||
> Your PRD is set up but no features have been created yet.
|
||||
> Run `/write-spec` to create your first feature specification.
|
||||
### Nächster Schritt
|
||||
_Der eine wichtigste Schritt, mit dem exakten Kommando._
|
||||
|
||||
**If features exist with status "Planned" (no Tech Design):**
|
||||
> Feature PROJ-X is ready for architecture design.
|
||||
> Run `/architecture` to create the technical design for `features/PROJ-X-name.md`
|
||||
### Sonst möglich
|
||||
_Kurze Liste weiterer sinnvoller Aktionen._
|
||||
|
||||
**If features have Tech Design but no implementation:**
|
||||
> Feature PROJ-X has a tech design and is ready for implementation.
|
||||
> Run `/frontend` to build the UI for `features/PROJ-X-name.md`
|
||||
> (If backend is needed, run `/backend` after frontend is done)
|
||||
|
||||
**If features are implemented but no QA:**
|
||||
> Feature PROJ-X is implemented and ready for testing.
|
||||
> Run `/qa` to test `features/PROJ-X-name.md` against its acceptance criteria.
|
||||
|
||||
**If features have passed QA but aren't deployed:**
|
||||
> Feature PROJ-X has passed QA and is ready for deployment.
|
||||
> Run `/deploy` to deploy to production.
|
||||
|
||||
**If all features are deployed:**
|
||||
> All current features are deployed! You can:
|
||||
> - Run `/write-spec` to spec out a new feature
|
||||
> - Check `docs/PRD.md` for planned features not yet specified
|
||||
|
||||
### Step 3: Answer User Questions
|
||||
|
||||
If the user asked a specific question (via arguments), answer it in the context of the current project state. Common questions:
|
||||
|
||||
- "What skills are available?" → List all available skills with brief descriptions
|
||||
- "How do I add a new feature?" → Explain `/write-spec` workflow (or `/init` if the project isn't set up yet)
|
||||
- "How do I customize this template?" → Point to CLAUDE.md, rules/, skills/
|
||||
- "What's the project structure?" → Explain the directory layout
|
||||
- "How do I deploy?" → Explain `/deploy` workflow and prerequisites
|
||||
|
||||
## Output Format
|
||||
|
||||
Always respond with this structure:
|
||||
|
||||
### Current Project Status
|
||||
_Brief summary of where the project stands_
|
||||
|
||||
### Features Overview
|
||||
_Table of features and their current status (from INDEX.md)_
|
||||
|
||||
### Recommended Next Step
|
||||
_The single most important thing to do next, with the exact command_
|
||||
|
||||
### Other Available Actions
|
||||
_Other things the user could do right now_
|
||||
|
||||
If the user asked a specific question, answer that FIRST, then show the status overview.
|
||||
|
||||
## Important
|
||||
- Be concise and actionable
|
||||
- Always give the exact command to run
|
||||
- Reference specific file paths
|
||||
- Don't explain the framework architecture in detail unless asked
|
||||
- Focus on: "Here's where you are, here's what to do next"
|
||||
Give exact commands and real file paths. Do not explain the framework unless asked.
|
||||
|
||||
Reference in New Issue
Block a user