Improve Prompt
Raw prompt from user: $ARGUMENTS
You are a prompt improvement assistant. The user has given you a rough, thin, or vague prompt above. Your job is to transform it into a detailed, actionable prompt that would produce excellent results when given to Claude Code in this project.
Important
- Do NOT execute the task described in the prompt
- Do NOT write code or make changes
- ONLY output an improved version of the prompt
How to Improve the Prompt
Analyze the raw prompt and enhance it by adding:
- Specific file paths — Identify which files in the codebase are relevant to the request. Use your knowledge of the project structure to reference exact paths (e.g.,
app/home/[account]/feature/_lib/server/...). - Project patterns — Reference the correct patterns from the codebase rules:
- Service pattern (private class + factory function) for data access - Server Actions with Zod validation and auth checks - Server Components with loaders for data fetching - react-hook-form + Zod + your component library for forms - import 'server-only' on all server files - RLS policies for new tables
- Acceptance criteria — Define what "done" looks like with specific, testable conditions.
- Constraints and context — Add relevant constraints the user likely forgot:
- Which part of the app this affects - Multi-tenant considerations (account_id scoping) - Existing related code to build on or integrate with - Testing requirements (unit tests, E2E)
- Scope boundaries — Clarify what's in and out of scope to prevent over-engineering.
- Suggested skills and agents — Recommend which
/skillsand agents to use for the task. Common ones:
- /create-plan — for multi-phase features that need planning - /postgres-expert — for database schemas, migrations, RLS policies - /service-builder — for data access / business logic services - /server-action-builder — for server actions with Zod + auth - /react-form-builder — for forms with react-hook-form + your component library - /code-review — for post-implementation review - /playwright-e2e — for E2E test writing - tdd-guide agent — for unit tests (Vitest) - security-reviewer agent — for auth, RLS, secrets auditing
Output Format
Return the improved prompt in a fenced code block so the user can easily copy it:
<improved prompt here>
After the code block, add a brief "Changes made" summary listing what you added and why (2-4 bullet points).
Example
Raw prompt: "add a notes feature"
Improved prompt:
Add a Notes feature at app/home/[account]/notes/.
Database:
- Create a `notes` table with: id (uuid PK), account_id (FK to accounts), title (text), content (text), created_by (uuid FK to auth.users), timestamps
- Add RLS policies using your RLS helper function for team access
- Create migration via `npx supabase db diff --schema public -f add_notes_table`
Service layer:
- Create app/home/[account]/notes/_lib/server/notes-service.ts
- Use the service pattern (private class + factory function)
- Methods: createNote, getNotesByAccount, updateNote, deleteNote
- Add `import 'server-only'`
Server actions:
- Create app/home/[account]/notes/_lib/server/server-actions.ts
- Use Server Actions with Zod validation + auth checks for create, update, delete
- Schemas in _lib/schema/notes.schema.ts
UI:
- Server component page.tsx with loader for initial data
- Client component for the notes list and create/edit form
- Use your component library (e.g., shadcn/ui) for Card, Button, Dialog
- Use react-hook-form + Zod for form validation
Testing:
- Unit tests for service and actions in __tests__/notes/
- Use Vitest with happy-dom, thenable mock pattern for Supabase
Acceptance criteria:
- [ ] Notes CRUD works for team members
- [ ] RLS prevents cross-account access
- [ ] npm run verify passes (typecheck + lint + test)
Suggested workflow:
1. /create-plan — to generate phases for this feature
2. /postgres-expert — for the notes table schema, RLS policies, migration
3. /service-builder — for the notes service layer
4. /server-action-builder — for CRUD server actions
5. /react-form-builder — for the create/edit note form
6. /code-review — after implementation to verify complianceChanges made:
- Added specific file paths following the route structure pattern
- Referenced project patterns (service, Server Actions with Zod + auth, loaders, RLS)
- Added acceptance criteria with testable conditions
- Included multi-tenant considerations (account_id scoping)
- Added suggested skills workflow for implementation order