mirror of
https://github.com/Significant-Gravitas/AutoGPT.git
synced 2026-04-08 03:00:28 -04:00
Refactors the Claude Code skills for a cleaner, more intuitive dev loop. ### Changes 🏗️ - **`/pr-review` (new)**: Actual code review skill — reads the PR diff, fetches existing comments to avoid duplicates, and posts inline GitHub comments with structured feedback (Blockers / Should Fix / Nice to Have / Nit) covering correctness, security, code quality, architecture, and testing. - **`/pr-address` (was `/babysit-pr`)**: Addresses review comments and monitors CI until green. Renamed from `/babysit-pr` to `/pr-address` to better reflect its purpose. Handles bot-specific feedback (autogpt-reviewer, sentry, coderabbitai) and loops until all comments are addressed and CI is green. - **`/backend-check` + `/frontend-check` → `/check`**: Unified into a single `/check` skill that auto-detects whether backend (Python) or frontend (TypeScript) code changed and runs the appropriate formatting, linting, type checking, and tests. Shared code quality rules applied to both. - **`/code-style` enhanced**: Now covers both Python and TypeScript/React. Added learnings from real PR work: lazy `%s` logging, TOCTOU awareness, SSE protocol rules (`data:` vs `: comment`), FastAPI `Security()` vs `Depends()`, Redis pipeline atomicity, error path sanitization, mock target rules after refactoring. - **`/worktree` fixed**: Normal `git worktree` is now the default (was branchlet-first). Branchlet moved to optional section. All paths derived from `git rev-parse --show-toplevel`. - **`/pr-create`, `/openapi-regen`, `/new-block` cleaned up**: Reference `/check` and `/code-style` instead of duplicating instructions. ### Checklist 📋 #### For code changes: - [x] I have clearly listed my changes in the PR description - [x] I have made a test plan - [x] I have tested my changes according to the test plan: - [x] Verified all skill files parse correctly (valid YAML frontmatter) - [x] Verified skill auto-detection triggers updated in descriptions - [x] Verified old backend-check and frontend-check directories removed - [x] Verified pr-review and pr-address directories created with correct content
4.0 KiB
4.0 KiB
CLAUDE.md - Frontend
This file provides guidance to Claude Code when working with the frontend.
Essential Commands
# Install dependencies
pnpm i
# Generate API client from OpenAPI spec
pnpm generate:api
# Start development server
pnpm dev
# Run E2E tests
pnpm test
# Run Storybook for component development
pnpm storybook
# Build production
pnpm build
# Format and lint
pnpm format
# Type checking
pnpm types
Pre-completion Checks (MANDATORY)
After making any code changes in the frontend, you MUST run the following commands in order before reporting work as done, creating commits, or opening PRs:
pnpm format— auto-fix formatting issuespnpm lint— check for lint errors; fix any that appearpnpm types— check for type errors; fix any that appear
Do NOT skip these steps. If any command reports errors, fix them and re-run until clean. Only then may you consider the task complete. If typing keeps failing, stop and ask the user.
Code Style
- Fully capitalize acronyms in symbols, e.g.
graphID,useBackendAPI - Use function declarations (not arrow functions) for components/handlers
- No
dark:Tailwind classes — the design system handles dark mode - Use Next.js
<Link>for internal navigation — never raw<a>tags - No
anytypes unless the value genuinely can be anything - No linter suppressors (
// @ts-ignore,// eslint-disable) — fix the actual issue - File length — keep files under ~200 lines; extract sub-components or hooks into their own files when a file grows beyond this
- Function/component length — keep render functions and hooks under ~50 lines; extract named helpers or sub-components when they grow longer
Architecture
- Framework: Next.js 15 App Router (client-first approach)
- Data Fetching: Type-safe generated API hooks via Orval + React Query
- State Management: React Query for server state, co-located UI state in components/hooks
- Component Structure: Separate render logic (
.tsx) from business logic (use*.tshooks) - Workflow Builder: Visual graph editor using @xyflow/react
- UI Components: shadcn/ui (Radix UI primitives) with Tailwind CSS styling
- Icons: Phosphor Icons only
- Feature Flags: LaunchDarkly integration
- Error Handling: ErrorCard for render errors, toast for mutations, Sentry for exceptions
- Testing: Playwright for E2E, Storybook for component development
Environment Configuration
.env.default (defaults) → .env (user overrides)
Feature Development
See @CONTRIBUTING.md for complete patterns. Quick reference:
- Pages: Create in
src/app/(platform)/feature-name/page.tsx- Extract component logic into custom hooks grouped by concern, not by component. Each hook should represent a cohesive domain of functionality (e.g., useSearch, useFilters, usePagination) rather than bundling all state into one useComponentState hook.
- Put each hook in its own
.tsfile
- Put each hook in its own
- Put sub-components in local
components/folder - Component props should be
type Props = { ... }(not exported) unless it needs to be used outside the component
- Extract component logic into custom hooks grouped by concern, not by component. Each hook should represent a cohesive domain of functionality (e.g., useSearch, useFilters, usePagination) rather than bundling all state into one useComponentState hook.
- Components: Structure as
ComponentName/ComponentName.tsx+useComponentName.ts+helpers.ts- Use design system components from
src/components/(atoms, molecules, organisms) - Never use
src/components/__legacy__/*
- Use design system components from
- Data fetching: Use generated API hooks from
@/app/api/__generated__/endpoints/- Regenerate with
pnpm generate:api - Pattern:
use{Method}{Version}{OperationName}
- Regenerate with
- Styling: Tailwind CSS only, use design tokens, Phosphor Icons only
- Testing: Add Storybook stories for new components, Playwright for E2E
- Code conventions:
- Use function declarations (not arrow functions) for components/handlers
- Do not use
useCallbackoruseMemounless asked to optimise a given function - Do not type hook returns, let Typescript infer as much as possible
- Never type with
anyunless a variable/attribute can ACTUALLY be of any type - avoid index and barrel files