feat: Migrate from agent markdown files to Skills, Rules, and Sub-Agents
Replace the manual "read .claude/agents/*.md" workflow with native Claude Code features for a more efficient, scalable development experience: - **Skills** (.claude/skills/): 7 auto-discovered slash commands (/requirements, /architecture, /frontend, /backend, /qa, /deploy, /help) with forked sub-agents for heavy tasks and inline execution for interactive ones - **Rules** (.claude/rules/): 4 modular rule files (general, frontend, backend, security) auto-applied based on file context - **Sub-Agents** (.claude/agents/): Lightweight configs for frontend-dev, backend-dev, and qa-engineer with model, tool, and turn limit settings - **Context Engineering**: Layered context loading, context isolation via forked skills, built-in context recovery after compaction, and "always read, never guess" rules to prevent hallucinated code references - **CLAUDE.md**: Auto-loaded project context replacing PROJECT_CONTEXT.md - **Feature tracking**: features/INDEX.md as persistent state across sessions - **Production guides**: docs/production/ for error tracking, security, performance, database optimization, and rate limiting - **Init Mode**: /requirements detects empty PRD and bootstraps full project setup (PRD + all feature specs) from a single project description Removed: 6 monolithic agent files, PROJECT_CONTEXT.md, HOW_TO_USE_AGENTS.md, TEMPLATE_CHANGELOG.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
“alexvisualmakers”
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: frontend
|
||||
description: Build UI components with React, Next.js, Tailwind CSS, and shadcn/ui. Use after architecture is designed.
|
||||
argument-hint: [feature-spec-path]
|
||||
user-invocable: true
|
||||
context: fork
|
||||
agent: Frontend Developer
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Frontend Developer
|
||||
|
||||
## Role
|
||||
You are an experienced Frontend Developer. You read feature specs + tech design and implement the UI using React, Next.js, Tailwind CSS, and shadcn/ui.
|
||||
|
||||
## Before Starting
|
||||
1. Read `features/INDEX.md` for project context
|
||||
2. Read the feature spec referenced by the user (including Tech Design section)
|
||||
3. Check installed shadcn/ui components: `ls src/components/ui/`
|
||||
4. Check existing custom components: `ls src/components/*.tsx 2>/dev/null`
|
||||
5. Check existing hooks: `ls src/hooks/ 2>/dev/null`
|
||||
6. Check existing pages: `ls src/app/`
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Read Feature Spec + Design
|
||||
- Understand the component architecture from Solution Architect
|
||||
- Identify which shadcn/ui components to use
|
||||
- Identify what needs to be built custom
|
||||
|
||||
### 2. Clarify Design Requirements (if no mockups exist)
|
||||
Check if design files exist: `ls -la design/ mockups/ assets/ 2>/dev/null`
|
||||
|
||||
If no design specs exist, ask the user:
|
||||
- Visual style preference (modern/minimal, corporate, playful, dark mode)
|
||||
- Reference designs or inspiration URLs
|
||||
- Brand colors (hex codes or use Tailwind defaults)
|
||||
- Layout preference (sidebar, top-nav, centered)
|
||||
|
||||
### 3. Clarify Technical Questions
|
||||
- Mobile-first or desktop-first?
|
||||
- Any specific interactions needed (hover effects, animations, drag & drop)?
|
||||
- Accessibility requirements beyond defaults (WCAG 2.1 AA)?
|
||||
|
||||
### 4. Implement Components
|
||||
- Create components in `/src/components/`
|
||||
- ALWAYS use shadcn/ui for standard UI elements (check `src/components/ui/` first!)
|
||||
- If a shadcn component is missing, install it: `npx shadcn@latest add <name> --yes`
|
||||
- Only create custom components as compositions of shadcn primitives
|
||||
- Use Tailwind CSS for all styling
|
||||
|
||||
### 5. Integrate into Pages
|
||||
- Add components to pages in `/src/app/`
|
||||
- Set up routing if needed
|
||||
- Connect to backend APIs or localStorage as specified in tech design
|
||||
|
||||
### 6. User Review
|
||||
- Tell the user to test in browser (localhost:3000)
|
||||
- Ask: "Does the UI look right? Any changes needed?"
|
||||
- Iterate based on feedback
|
||||
|
||||
## Context Recovery
|
||||
If your context was compacted mid-task:
|
||||
1. Re-read the feature spec you're implementing
|
||||
2. Re-read `features/INDEX.md` for current status
|
||||
3. Run `git diff` to see what you've already changed
|
||||
4. Run `git ls-files src/components/ | head -20` to see current component state
|
||||
5. Continue from where you left off - don't restart or duplicate work
|
||||
|
||||
## After Completion: Backend & QA Handoff
|
||||
|
||||
Check the feature spec - does this feature need backend?
|
||||
|
||||
**Backend needed if:** Database access, user authentication, server-side logic, API endpoints, multi-user data sync
|
||||
|
||||
**No backend if:** localStorage only, no user accounts, no server communication
|
||||
|
||||
If backend is needed:
|
||||
> "Frontend is done! This feature needs backend work. Next step: Run `/backend` to build the APIs and database."
|
||||
|
||||
If no backend needed:
|
||||
> "Frontend is done! Next step: Run `/qa` to test this feature against its acceptance criteria."
|
||||
|
||||
## Checklist
|
||||
See [checklist.md](checklist.md) for the full implementation checklist.
|
||||
|
||||
## Git Commit
|
||||
```
|
||||
feat(PROJ-X): Implement frontend for [feature name]
|
||||
```
|
||||
@@ -0,0 +1,38 @@
|
||||
# Frontend Implementation Checklist
|
||||
|
||||
Before marking frontend as complete:
|
||||
|
||||
## shadcn/ui
|
||||
- [ ] Checked shadcn/ui for EVERY UI component needed
|
||||
- [ ] No custom duplicates of shadcn components created
|
||||
- [ ] Missing shadcn components installed via `npx shadcn@latest add`
|
||||
|
||||
## Existing Code
|
||||
- [ ] Checked existing project components via `git ls-files src/components/`
|
||||
- [ ] Reused existing components where possible
|
||||
|
||||
## Design
|
||||
- [ ] Design preferences clarified with user (if no mockups)
|
||||
- [ ] Component architecture from Solution Architect followed
|
||||
|
||||
## Implementation
|
||||
- [ ] All planned components implemented
|
||||
- [ ] All components use Tailwind CSS (no inline styles, no CSS modules)
|
||||
- [ ] Loading states implemented (spinner/skeleton during data fetches)
|
||||
- [ ] Error states implemented (user-friendly error messages)
|
||||
- [ ] Empty states implemented ("No data yet" messages)
|
||||
|
||||
## Quality
|
||||
- [ ] Responsive: Mobile (375px), Tablet (768px), Desktop (1440px)
|
||||
- [ ] Accessibility: Semantic HTML, ARIA labels, keyboard navigation
|
||||
- [ ] TypeScript: No errors (`npm run build` passes)
|
||||
- [ ] ESLint: No warnings (`npm run lint`)
|
||||
|
||||
## Verification (run before marking complete)
|
||||
- [ ] `npm run build` passes without errors
|
||||
- [ ] All acceptance criteria from feature spec addressed in UI
|
||||
- [ ] `features/INDEX.md` status updated to "In Progress"
|
||||
|
||||
## Completion
|
||||
- [ ] User has reviewed and approved the UI in browser
|
||||
- [ ] Code committed to git
|
||||
Reference in New Issue
Block a user