Initial commit: Linear-integrated autonomous coding agent with Initializer Bis support
This commit is contained in:
681
prompts/app_spec.txt
Normal file
681
prompts/app_spec.txt
Normal file
@@ -0,0 +1,681 @@
|
||||
<project_specification>
|
||||
<project_name>Claude.ai Clone - AI Chat Interface</project_name>
|
||||
|
||||
<overview>
|
||||
Build a fully functional clone of claude.ai, Anthropic's conversational AI interface. The application should
|
||||
provide a clean, modern chat interface for interacting with Claude via the API, including features like
|
||||
conversation management, artifact rendering, project organization, multiple model selection, and advanced
|
||||
settings. The UI should closely match claude.ai's design using Tailwind CSS with a focus on excellent
|
||||
user experience and responsive design.
|
||||
</overview>
|
||||
|
||||
<technology_stack>
|
||||
<api_key>
|
||||
You can use an API key located at /tmp/api-key for testing. You will not be allowed to read this file, but you can reference it in code.
|
||||
</api_key>
|
||||
<frontend>
|
||||
<framework>React with Vite</framework>
|
||||
<styling>Tailwind CSS (via CDN)</styling>
|
||||
<state_management>React hooks and context</state_management>
|
||||
<routing>React Router for navigation</routing>
|
||||
<markdown>React Markdown for message rendering</markdown>
|
||||
<code_highlighting>Syntax highlighting for code blocks</code_highlighting>
|
||||
<port>Only launch on port {frontend_port}</port>
|
||||
</frontend>
|
||||
<backend>
|
||||
<runtime>Node.js with Express</runtime>
|
||||
<database>SQLite with better-sqlite3</database>
|
||||
<api_integration>Claude API for chat completions</api_integration>
|
||||
<streaming>Server-Sent Events for streaming responses</streaming>
|
||||
</backend>
|
||||
<communication>
|
||||
<api>RESTful endpoints</api>
|
||||
<streaming>SSE for real-time message streaming</streaming>
|
||||
<claude_api>Integration with Claude API using Anthropic SDK</claude_api>
|
||||
</communication>
|
||||
</technology_stack>
|
||||
|
||||
<prerequisites>
|
||||
<environment_setup>
|
||||
- Repository includes .env with VITE_ANTHROPIC_API_KEY configured
|
||||
- Frontend dependencies pre-installed via pnpm
|
||||
- Backend code goes in /server directory
|
||||
- Install backend dependencies as needed
|
||||
</environment_setup>
|
||||
</prerequisites>
|
||||
|
||||
<core_features>
|
||||
<chat_interface>
|
||||
- Clean, centered chat layout with message bubbles
|
||||
- Streaming message responses with typing indicator
|
||||
- Markdown rendering with proper formatting
|
||||
- Code blocks with syntax highlighting and copy button
|
||||
- LaTeX/math equation rendering
|
||||
- Image upload and display in messages
|
||||
- Multi-turn conversations with context
|
||||
- Message editing and regeneration
|
||||
- Stop generation button during streaming
|
||||
- Input field with auto-resize textarea
|
||||
- Character count and token estimation
|
||||
- Keyboard shortcuts (Enter to send, Shift+Enter for newline)
|
||||
</chat_interface>
|
||||
|
||||
<artifacts>
|
||||
- Artifact detection and rendering in side panel
|
||||
- Code artifact viewer with syntax highlighting
|
||||
- HTML/SVG preview with live rendering
|
||||
- React component preview
|
||||
- Mermaid diagram rendering
|
||||
- Text document artifacts
|
||||
- Artifact editing and re-prompting
|
||||
- Full-screen artifact view
|
||||
- Download artifact content
|
||||
- Artifact versioning and history
|
||||
</artifacts>
|
||||
|
||||
<conversation_management>
|
||||
- Create new conversations
|
||||
- Conversation list in sidebar
|
||||
- Rename conversations
|
||||
- Delete conversations
|
||||
- Search conversations by title/content
|
||||
- Pin important conversations
|
||||
- Archive conversations
|
||||
- Conversation folders/organization
|
||||
- Duplicate conversation
|
||||
- Export conversation (JSON, Markdown, PDF)
|
||||
- Conversation timestamps (created, last updated)
|
||||
- Unread message indicators
|
||||
</conversation_management>
|
||||
|
||||
<projects>
|
||||
- Create projects to group related conversations
|
||||
- Project knowledge base (upload documents)
|
||||
- Project-specific custom instructions
|
||||
- Share projects with team (mock feature)
|
||||
- Project settings and configuration
|
||||
- Move conversations between projects
|
||||
- Project templates
|
||||
- Project analytics (usage stats)
|
||||
</projects>
|
||||
|
||||
<model_selection>
|
||||
- Model selector dropdown with the following models:
|
||||
- Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) - default
|
||||
- Claude Haiku 4.5 (claude-haiku-4-5-20251001)
|
||||
- Claude Opus 4.1 (claude-opus-4-1-20250805)
|
||||
- Model capabilities display
|
||||
- Context window indicator
|
||||
- Model-specific pricing info (display only)
|
||||
- Switch models mid-conversation
|
||||
- Model comparison view
|
||||
</model_selection>
|
||||
|
||||
<custom_instructions>
|
||||
- Global custom instructions
|
||||
- Project-specific custom instructions
|
||||
- Conversation-specific system prompts
|
||||
- Custom instruction templates
|
||||
- Preview how instructions affect responses
|
||||
</custom_instructions>
|
||||
|
||||
<settings_preferences>
|
||||
- Theme selection (Light, Dark, Auto)
|
||||
- Font size adjustment
|
||||
- Message density (compact, comfortable, spacious)
|
||||
- Code theme selection
|
||||
- Language preferences
|
||||
- Accessibility options
|
||||
- Keyboard shortcuts reference
|
||||
- Data export options
|
||||
- Privacy settings
|
||||
- API key management
|
||||
</settings_preferences>
|
||||
|
||||
<advanced_features>
|
||||
- Temperature control slider
|
||||
- Max tokens adjustment
|
||||
- Top-p (nucleus sampling) control
|
||||
- System prompt override
|
||||
- Thinking/reasoning mode toggle
|
||||
- Multi-modal input (text + images)
|
||||
- Voice input (optional, mock UI)
|
||||
- Response suggestions
|
||||
- Related prompts
|
||||
- Conversation branching
|
||||
</advanced_features>
|
||||
|
||||
<collaboration>
|
||||
- Share conversation via link (read-only)
|
||||
- Export conversation formats
|
||||
- Conversation templates
|
||||
- Prompt library
|
||||
- Share artifacts
|
||||
- Team workspaces (mock UI)
|
||||
</collaboration>
|
||||
|
||||
<search_discovery>
|
||||
- Search across all conversations
|
||||
- Filter by project, date, model
|
||||
- Prompt library with categories
|
||||
- Example conversations
|
||||
- Quick actions menu
|
||||
- Command palette (Cmd/Ctrl+K)
|
||||
</search_discovery>
|
||||
|
||||
<usage_tracking>
|
||||
- Token usage display per message
|
||||
- Conversation cost estimation
|
||||
- Daily/monthly usage dashboard
|
||||
- Usage limits and warnings
|
||||
- API quota tracking
|
||||
</usage_tracking>
|
||||
|
||||
<onboarding>
|
||||
- Welcome screen for new users
|
||||
- Feature tour highlights
|
||||
- Example prompts to get started
|
||||
- Quick tips and best practices
|
||||
- Keyboard shortcuts tutorial
|
||||
</onboarding>
|
||||
|
||||
<accessibility>
|
||||
- Full keyboard navigation
|
||||
- Screen reader support
|
||||
- ARIA labels and roles
|
||||
- High contrast mode
|
||||
- Focus management
|
||||
- Reduced motion support
|
||||
</accessibility>
|
||||
|
||||
<responsive_design>
|
||||
- Mobile-first responsive layout
|
||||
- Touch-optimized interface
|
||||
- Collapsible sidebar on mobile
|
||||
- Swipe gestures for navigation
|
||||
- Adaptive artifact display
|
||||
- Progressive Web App (PWA) support
|
||||
</responsive_design>
|
||||
</core_features>
|
||||
|
||||
<database_schema>
|
||||
<tables>
|
||||
<users>
|
||||
- id, email, name, avatar_url
|
||||
- created_at, last_login
|
||||
- preferences (JSON: theme, font_size, etc.)
|
||||
- custom_instructions
|
||||
</users>
|
||||
|
||||
<projects>
|
||||
- id, user_id, name, description, color
|
||||
- custom_instructions, knowledge_base_path
|
||||
- created_at, updated_at
|
||||
- is_archived, is_pinned
|
||||
</projects>
|
||||
|
||||
<conversations>
|
||||
- id, user_id, project_id, title
|
||||
- model, created_at, updated_at, last_message_at
|
||||
- is_archived, is_pinned, is_deleted
|
||||
- settings (JSON: temperature, max_tokens, etc.)
|
||||
- token_count, message_count
|
||||
</conversations>
|
||||
|
||||
<messages>
|
||||
- id, conversation_id, role (user/assistant/system)
|
||||
- content, created_at, edited_at
|
||||
- tokens, finish_reason
|
||||
- images (JSON array of image data)
|
||||
- parent_message_id (for branching)
|
||||
</messages>
|
||||
|
||||
<artifacts>
|
||||
- id, message_id, conversation_id
|
||||
- type (code/html/svg/react/mermaid/text)
|
||||
- title, identifier, language
|
||||
- content, version
|
||||
- created_at, updated_at
|
||||
</artifacts>
|
||||
|
||||
<shared_conversations>
|
||||
- id, conversation_id, share_token
|
||||
- created_at, expires_at, view_count
|
||||
- is_public
|
||||
</shared_conversations>
|
||||
|
||||
<prompt_library>
|
||||
- id, user_id, title, description
|
||||
- prompt_template, category, tags (JSON)
|
||||
- is_public, usage_count
|
||||
- created_at, updated_at
|
||||
</prompt_library>
|
||||
|
||||
<conversation_folders>
|
||||
- id, user_id, project_id, name, parent_folder_id
|
||||
- created_at, position
|
||||
</conversation_folders>
|
||||
|
||||
<conversation_folder_items>
|
||||
- id, folder_id, conversation_id
|
||||
</conversation_folder_items>
|
||||
|
||||
<usage_tracking>
|
||||
- id, user_id, conversation_id, message_id
|
||||
- model, input_tokens, output_tokens
|
||||
- cost_estimate, created_at
|
||||
</usage_tracking>
|
||||
|
||||
<api_keys>
|
||||
- id, user_id, key_name, api_key_hash
|
||||
- created_at, last_used_at
|
||||
- is_active
|
||||
</api_keys>
|
||||
</tables>
|
||||
</database_schema>
|
||||
|
||||
<api_endpoints_summary>
|
||||
<authentication>
|
||||
- POST /api/auth/login
|
||||
- POST /api/auth/logout
|
||||
- GET /api/auth/me
|
||||
- PUT /api/auth/profile
|
||||
</authentication>
|
||||
|
||||
<conversations>
|
||||
- GET /api/conversations
|
||||
- POST /api/conversations
|
||||
- GET /api/conversations/:id
|
||||
- PUT /api/conversations/:id
|
||||
- DELETE /api/conversations/:id
|
||||
- POST /api/conversations/:id/duplicate
|
||||
- POST /api/conversations/:id/export
|
||||
- PUT /api/conversations/:id/archive
|
||||
- PUT /api/conversations/:id/pin
|
||||
- POST /api/conversations/:id/branch
|
||||
</conversations>
|
||||
|
||||
<messages>
|
||||
- GET /api/conversations/:id/messages
|
||||
- POST /api/conversations/:id/messages
|
||||
- PUT /api/messages/:id
|
||||
- DELETE /api/messages/:id
|
||||
- POST /api/messages/:id/regenerate
|
||||
- GET /api/messages/stream (SSE endpoint)
|
||||
</messages>
|
||||
|
||||
<artifacts>
|
||||
- GET /api/conversations/:id/artifacts
|
||||
- GET /api/artifacts/:id
|
||||
- PUT /api/artifacts/:id
|
||||
- DELETE /api/artifacts/:id
|
||||
- POST /api/artifacts/:id/fork
|
||||
- GET /api/artifacts/:id/versions
|
||||
</artifacts>
|
||||
|
||||
<projects>
|
||||
- GET /api/projects
|
||||
- POST /api/projects
|
||||
- GET /api/projects/:id
|
||||
- PUT /api/projects/:id
|
||||
- DELETE /api/projects/:id
|
||||
- POST /api/projects/:id/knowledge
|
||||
- GET /api/projects/:id/conversations
|
||||
- PUT /api/projects/:id/settings
|
||||
</projects>
|
||||
|
||||
<sharing>
|
||||
- POST /api/conversations/:id/share
|
||||
- GET /api/share/:token
|
||||
- DELETE /api/share/:token
|
||||
- PUT /api/share/:token/settings
|
||||
</sharing>
|
||||
|
||||
<prompts>
|
||||
- GET /api/prompts/library
|
||||
- POST /api/prompts/library
|
||||
- GET /api/prompts/:id
|
||||
- PUT /api/prompts/:id
|
||||
- DELETE /api/prompts/:id
|
||||
- GET /api/prompts/categories
|
||||
- GET /api/prompts/examples
|
||||
</prompts>
|
||||
|
||||
<search>
|
||||
- GET /api/search/conversations?q=query
|
||||
- GET /api/search/messages?q=query
|
||||
- GET /api/search/artifacts?q=query
|
||||
- GET /api/search/prompts?q=query
|
||||
</search>
|
||||
|
||||
<folders>
|
||||
- GET /api/folders
|
||||
- POST /api/folders
|
||||
- PUT /api/folders/:id
|
||||
- DELETE /api/folders/:id
|
||||
- POST /api/folders/:id/items
|
||||
- DELETE /api/folders/:id/items/:conversationId
|
||||
</folders>
|
||||
|
||||
<usage>
|
||||
- GET /api/usage/daily
|
||||
- GET /api/usage/monthly
|
||||
- GET /api/usage/by-model
|
||||
- GET /api/usage/conversations/:id
|
||||
</usage>
|
||||
|
||||
<settings>
|
||||
- GET /api/settings
|
||||
- PUT /api/settings
|
||||
- GET /api/settings/custom-instructions
|
||||
- PUT /api/settings/custom-instructions
|
||||
</settings>
|
||||
|
||||
<claude_api>
|
||||
- POST /api/claude/chat (proxy to Claude API)
|
||||
- POST /api/claude/chat/stream (streaming proxy)
|
||||
- GET /api/claude/models
|
||||
- POST /api/claude/images/upload
|
||||
</claude_api>
|
||||
</api_endpoints_summary>
|
||||
|
||||
<ui_layout>
|
||||
<main_structure>
|
||||
- Three-column layout: sidebar (conversations), main (chat), panel (artifacts)
|
||||
- Collapsible sidebar with resize handle
|
||||
- Responsive breakpoints: mobile (single column), tablet (two column), desktop (three column)
|
||||
- Persistent header with project/model selector
|
||||
- Bottom input area with send button and options
|
||||
</main_structure>
|
||||
|
||||
<sidebar_left>
|
||||
- New chat button (prominent)
|
||||
- Project selector dropdown
|
||||
- Search conversations input
|
||||
- Conversations list (grouped by date: Today, Yesterday, Previous 7 days, etc.)
|
||||
- Folder tree view (collapsible)
|
||||
- Settings gear icon at bottom
|
||||
- User profile at bottom
|
||||
</sidebar_left>
|
||||
|
||||
<main_chat_area>
|
||||
- Conversation title (editable inline)
|
||||
- Model selector badge
|
||||
- Message history (scrollable)
|
||||
- Welcome screen for new conversations
|
||||
- Suggested prompts (empty state)
|
||||
- Input area with formatting toolbar
|
||||
- Attachment button for images
|
||||
- Send button with loading state
|
||||
- Stop generation button
|
||||
</main_chat_area>
|
||||
|
||||
<artifacts_panel>
|
||||
- Artifact header with title and type badge
|
||||
- Code editor or preview pane
|
||||
- Tabs for multiple artifacts
|
||||
- Full-screen toggle
|
||||
- Download button
|
||||
- Edit/Re-prompt button
|
||||
- Version selector
|
||||
- Close panel button
|
||||
</artifacts_panel>
|
||||
|
||||
<modals_overlays>
|
||||
- Settings modal (tabbed interface)
|
||||
- Share conversation modal
|
||||
- Export options modal
|
||||
- Project settings modal
|
||||
- Prompt library modal
|
||||
- Command palette overlay
|
||||
- Keyboard shortcuts reference
|
||||
</modals_overlays>
|
||||
</ui_layout>
|
||||
|
||||
<design_system>
|
||||
<color_palette>
|
||||
- Primary: Orange/amber accent (#CC785C claude-style)
|
||||
- Background: White (light mode), Dark gray (#1A1A1A dark mode)
|
||||
- Surface: Light gray (#F5F5F5 light), Darker gray (#2A2A2A dark)
|
||||
- Text: Near black (#1A1A1A light), Off-white (#E5E5E5 dark)
|
||||
- Borders: Light gray (#E5E5E5 light), Dark gray (#404040 dark)
|
||||
- Code blocks: Monaco editor theme
|
||||
</color_palette>
|
||||
|
||||
<typography>
|
||||
- Sans-serif system font stack (Inter, SF Pro, Roboto, system-ui)
|
||||
- Headings: font-semibold
|
||||
- Body: font-normal, leading-relaxed
|
||||
- Code: Monospace (JetBrains Mono, Consolas, Monaco)
|
||||
- Message text: text-base (16px), comfortable line-height
|
||||
</typography>
|
||||
|
||||
<components>
|
||||
<message_bubble>
|
||||
- User messages: Right-aligned, subtle background
|
||||
- Assistant messages: Left-aligned, no background
|
||||
- Markdown formatting with proper spacing
|
||||
- Inline code with bg-gray-100 background
|
||||
- Code blocks with syntax highlighting
|
||||
- Copy button on code blocks
|
||||
</message_bubble>
|
||||
|
||||
<buttons>
|
||||
- Primary: Orange/amber background, white text, rounded
|
||||
- Secondary: Border style with hover fill
|
||||
- Icon buttons: Square with hover background
|
||||
- Disabled state: Reduced opacity, no pointer events
|
||||
</buttons>
|
||||
|
||||
<inputs>
|
||||
- Rounded borders with focus ring
|
||||
- Textarea auto-resize
|
||||
- Placeholder text in gray
|
||||
- Error states in red
|
||||
- Character counter
|
||||
</inputs>
|
||||
|
||||
<cards>
|
||||
- Subtle border or shadow
|
||||
- Rounded corners (8px)
|
||||
- Padding: p-4 to p-6
|
||||
- Hover state: slight shadow increase
|
||||
</cards>
|
||||
</components>
|
||||
|
||||
<animations>
|
||||
- Smooth transitions (150-300ms)
|
||||
- Fade in for new messages
|
||||
- Slide in for sidebar
|
||||
- Typing indicator animation
|
||||
- Loading spinner for generation
|
||||
- Skeleton loaders for content
|
||||
</animations>
|
||||
</design_system>
|
||||
|
||||
<key_interactions>
|
||||
<message_flow>
|
||||
1. User types message in input field
|
||||
2. Optional: Attach images via button
|
||||
3. Click send or press Enter
|
||||
4. Message appears in chat immediately
|
||||
5. Typing indicator shows while waiting
|
||||
6. Response streams in word by word
|
||||
7. Code blocks render with syntax highlighting
|
||||
8. Artifacts detected and rendered in side panel
|
||||
9. Message complete, enable regenerate option
|
||||
</message_flow>
|
||||
|
||||
<artifact_flow>
|
||||
1. Assistant generates artifact in response
|
||||
2. Artifact panel slides in from right
|
||||
3. Content renders (code with highlighting or live preview)
|
||||
4. User can edit artifact inline
|
||||
5. "Re-prompt" button to iterate with Claude
|
||||
6. Download or copy artifact content
|
||||
7. Full-screen mode for detailed work
|
||||
8. Close panel to return to chat focus
|
||||
</artifact_flow>
|
||||
|
||||
<conversation_management>
|
||||
1. Click "New Chat" to start fresh conversation
|
||||
2. Conversations auto-save with first message
|
||||
3. Auto-generate title from first exchange
|
||||
4. Click title to rename inline
|
||||
5. Drag conversations into folders
|
||||
6. Right-click for context menu (pin, archive, delete, export)
|
||||
7. Search filters conversations in real-time
|
||||
8. Click conversation to switch context
|
||||
</conversation_management>
|
||||
</key_interactions>
|
||||
|
||||
<implementation_steps>
|
||||
<step number="1">
|
||||
<title>Setup Project Foundation and Database</title>
|
||||
<tasks>
|
||||
- Initialize Express server with SQLite database
|
||||
- Set up Claude API client with streaming support
|
||||
- Create database schema with migrations
|
||||
- Implement authentication endpoints
|
||||
- Set up basic CORS and middleware
|
||||
- Create health check endpoint
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="2">
|
||||
<title>Build Core Chat Interface</title>
|
||||
<tasks>
|
||||
- Create main layout with sidebar and chat area
|
||||
- Implement message display with markdown rendering
|
||||
- Add streaming message support with SSE
|
||||
- Build input area with auto-resize textarea
|
||||
- Add code block syntax highlighting
|
||||
- Implement stop generation functionality
|
||||
- Add typing indicators and loading states
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="3">
|
||||
<title>Conversation Management</title>
|
||||
<tasks>
|
||||
- Create conversation list in sidebar
|
||||
- Implement new conversation creation
|
||||
- Add conversation switching
|
||||
- Build conversation rename functionality
|
||||
- Implement delete with confirmation
|
||||
- Add conversation search
|
||||
- Create conversation grouping by date
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="4">
|
||||
<title>Artifacts System</title>
|
||||
<tasks>
|
||||
- Build artifact detection from Claude responses
|
||||
- Create artifact rendering panel
|
||||
- Implement code artifact viewer
|
||||
- Add HTML/SVG live preview
|
||||
- Build artifact editing interface
|
||||
- Add artifact versioning
|
||||
- Implement full-screen artifact view
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="5">
|
||||
<title>Projects and Organization</title>
|
||||
<tasks>
|
||||
- Create projects CRUD endpoints
|
||||
- Build project selector UI
|
||||
- Implement project-specific custom instructions
|
||||
- Add folder system for conversations
|
||||
- Create drag-and-drop organization
|
||||
- Build project settings panel
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="6">
|
||||
<title>Advanced Features</title>
|
||||
<tasks>
|
||||
- Add model selection dropdown
|
||||
- Implement temperature and parameter controls
|
||||
- Build image upload functionality
|
||||
- Create message editing and regeneration
|
||||
- Add conversation branching
|
||||
- Implement export functionality
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="7">
|
||||
<title>Settings and Customization</title>
|
||||
<tasks>
|
||||
- Build settings modal with tabs
|
||||
- Implement theme switching (light/dark)
|
||||
- Add custom instructions management
|
||||
- Create keyboard shortcuts
|
||||
- Build prompt library
|
||||
- Add usage tracking dashboard
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="8">
|
||||
<title>Sharing and Collaboration</title>
|
||||
<tasks>
|
||||
- Implement conversation sharing with tokens
|
||||
- Create public share view
|
||||
- Add export to multiple formats
|
||||
- Build prompt templates
|
||||
- Create example conversations
|
||||
</tasks>
|
||||
</step>
|
||||
|
||||
<step number="9">
|
||||
<title>Polish and Optimization</title>
|
||||
<tasks>
|
||||
- Optimize for mobile responsiveness
|
||||
- Add command palette (Cmd+K)
|
||||
- Implement comprehensive keyboard navigation
|
||||
- Add onboarding flow
|
||||
- Create accessibility improvements
|
||||
- Performance optimization and caching
|
||||
</tasks>
|
||||
</step>
|
||||
</implementation_steps>
|
||||
|
||||
<success_criteria>
|
||||
<functionality>
|
||||
- Streaming chat responses work smoothly
|
||||
- Artifact detection and rendering accurate
|
||||
- Conversation management intuitive and reliable
|
||||
- Project organization clear and useful
|
||||
- Image upload and display working
|
||||
- All CRUD operations functional
|
||||
</functionality>
|
||||
|
||||
<user_experience>
|
||||
- Interface matches claude.ai design language
|
||||
- Responsive on all device sizes
|
||||
- Smooth animations and transitions
|
||||
- Fast response times and minimal lag
|
||||
- Intuitive navigation and workflows
|
||||
- Clear feedback for all actions
|
||||
</user_experience>
|
||||
|
||||
<technical_quality>
|
||||
- Clean, maintainable code structure
|
||||
- Proper error handling throughout
|
||||
- Secure API key management
|
||||
- Optimized database queries
|
||||
- Efficient streaming implementation
|
||||
- Comprehensive testing coverage
|
||||
</technical_quality>
|
||||
|
||||
<design_polish>
|
||||
- Consistent with claude.ai visual design
|
||||
- Beautiful typography and spacing
|
||||
- Smooth animations and micro-interactions
|
||||
- Excellent contrast and accessibility
|
||||
- Professional, polished appearance
|
||||
- Dark mode fully implemented
|
||||
</design_polish>
|
||||
</success_criteria>
|
||||
</project_specification>
|
||||
448
prompts/app_spec_mistral_extensible.txt
Normal file
448
prompts/app_spec_mistral_extensible.txt
Normal file
@@ -0,0 +1,448 @@
|
||||
<project_specification>
|
||||
<project_name>Claude.ai Clone - Multi-Provider Support (Mistral + Extensible)</project_name>
|
||||
|
||||
<overview>
|
||||
This specification adds Mistral AI model support AND creates an extensible provider architecture
|
||||
that makes it easy to add additional AI providers (OpenAI, Gemini, etc.) in the future.
|
||||
This uses the "Open/Closed Principle" - open for extension, closed for modification.
|
||||
|
||||
All changes are additive and backward-compatible. Existing Claude functionality remains unchanged.
|
||||
</overview>
|
||||
|
||||
<safety_requirements>
|
||||
<critical>
|
||||
- DO NOT modify existing Claude API integration code directly
|
||||
- DO NOT change existing model selection logic for Claude models
|
||||
- DO NOT modify existing database schema without safe migrations
|
||||
- DO NOT break existing conversations or messages
|
||||
- All new code must be in separate files/modules when possible
|
||||
- Test thoroughly before marking issues as complete
|
||||
- Maintain backward compatibility at all times
|
||||
- Refactor Claude code to use BaseProvider WITHOUT changing functionality
|
||||
</critical>
|
||||
</safety_requirements>
|
||||
|
||||
<architecture_design>
|
||||
<provider_pattern>
|
||||
Create an abstract provider interface that all AI providers implement:
|
||||
- BaseProvider (abstract class/interface) - defines common interface
|
||||
- ClaudeProvider (existing code refactored to extend BaseProvider)
|
||||
- MistralProvider (new, extends BaseProvider)
|
||||
- OpenAIProvider (future, extends BaseProvider - easy to add)
|
||||
- GeminiProvider (future, extends BaseProvider - easy to add)
|
||||
</provider_pattern>
|
||||
|
||||
<benefits>
|
||||
- Easy to add new providers without modifying existing code
|
||||
- Consistent interface across all providers
|
||||
- Isolated error handling per provider
|
||||
- Unified model selection UI
|
||||
- Shared functionality (streaming, error handling, logging)
|
||||
- Future-proof architecture
|
||||
</benefits>
|
||||
</architecture_design>
|
||||
|
||||
<new_features>
|
||||
<feature_provider_architecture>
|
||||
<title>Extensible Provider Architecture (Foundation)</title>
|
||||
<description>
|
||||
Create a provider abstraction layer that allows easy addition of multiple AI providers.
|
||||
This is the foundation that makes adding OpenAI, Gemini, etc. trivial in the future.
|
||||
|
||||
BaseProvider abstract class should define:
|
||||
- sendMessage(messages, options) -> Promise<response>
|
||||
- streamMessage(messages, options) -> AsyncGenerator<chunk>
|
||||
- getModels() -> Promise<array> of available models
|
||||
- validateApiKey(key) -> Promise<boolean>
|
||||
- getCapabilities() -> object with provider capabilities
|
||||
- getName() -> string (provider name: 'claude', 'mistral', 'openai', etc.)
|
||||
- getDefaultModel() -> string (default model ID for this provider)
|
||||
|
||||
ProviderRegistry should:
|
||||
- Register all available providers
|
||||
- Provide list of all providers
|
||||
- Check which providers are configured (have API keys)
|
||||
- Enable/disable providers
|
||||
|
||||
ProviderFactory should:
|
||||
- Create provider instances based on model ID or provider name
|
||||
- Handle provider selection logic
|
||||
- Route requests to correct provider
|
||||
</description>
|
||||
<priority>1</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create server/providers/BaseProvider.js (abstract base class)
|
||||
- Refactor existing Claude code to server/providers/ClaudeProvider.js (extends BaseProvider)
|
||||
- Create server/providers/ProviderRegistry.js (manages all providers)
|
||||
- Create server/providers/ProviderFactory.js (creates provider instances)
|
||||
- Update existing routes to use ProviderFactory instead of direct Claude calls
|
||||
- Keep all provider code in server/providers/ directory
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Verify Claude still works after refactoring to use BaseProvider
|
||||
2. Test that ProviderFactory creates ClaudeProvider correctly
|
||||
3. Test that ProviderRegistry lists Claude provider
|
||||
4. Verify error handling works correctly
|
||||
5. Test that adding a mock provider is straightforward
|
||||
6. Verify no regression in existing Claude functionality
|
||||
</test_steps>
|
||||
</feature_provider_architecture>
|
||||
|
||||
<feature_mistral_provider>
|
||||
<title>Mistral Provider Implementation</title>
|
||||
<description>
|
||||
Implement MistralProvider extending BaseProvider. This should:
|
||||
- Implement all BaseProvider abstract methods
|
||||
- Handle Mistral-specific API calls (https://api.mistral.ai/v1/chat/completions)
|
||||
- Support Mistral streaming (Server-Sent Events)
|
||||
- Handle Mistral-specific error codes and messages
|
||||
- Provide Mistral model list:
|
||||
* mistral-large-latest (default)
|
||||
* mistral-medium-latest
|
||||
* mistral-small-latest
|
||||
* mistral-7b-instruct
|
||||
- Manage Mistral API authentication
|
||||
- Return responses in unified format (same as Claude)
|
||||
</description>
|
||||
<priority>2</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create server/providers/MistralProvider.js
|
||||
- Extend BaseProvider class
|
||||
- Implement Mistral API integration using fetch or axios
|
||||
- Register in ProviderRegistry
|
||||
- Use same response format as ClaudeProvider for consistency
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Test MistralProvider.sendMessage() works with valid API key
|
||||
2. Test MistralProvider.streamMessage() works
|
||||
3. Test MistralProvider.getModels() returns correct models
|
||||
4. Test error handling for invalid API key
|
||||
5. Test error handling for API rate limits
|
||||
6. Verify it integrates with ProviderFactory
|
||||
7. Verify responses match expected format
|
||||
</test_steps>
|
||||
</feature_mistral_provider>
|
||||
|
||||
<feature_unified_model_selector>
|
||||
<title>Unified Model Selector (All Providers)</title>
|
||||
<description>
|
||||
Update model selector to dynamically load models from all registered providers.
|
||||
The selector should:
|
||||
- Query all providers for available models via GET /api/models
|
||||
- Group models by provider (Claude, Mistral, etc.)
|
||||
- Display provider badges/icons next to model names
|
||||
- Show which provider each model belongs to
|
||||
- Filter models by provider (optional toggle)
|
||||
- Show provider-specific capabilities (streaming, images, etc.)
|
||||
- Only show models from providers with configured API keys
|
||||
- Handle providers gracefully (show "Configure API key" if not set)
|
||||
</description>
|
||||
<priority>2</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create API endpoint: GET /api/models (returns all models from all providers)
|
||||
- Update frontend ModelSelector component to handle multiple providers
|
||||
- Add provider grouping/filtering in UI
|
||||
- Show provider badges/icons next to model names
|
||||
- Group models by provider with collapsible sections
|
||||
- Show provider status (configured/not configured)
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Verify model selector shows Claude models (existing functionality)
|
||||
2. Verify model selector shows Mistral models (if key configured)
|
||||
3. Test grouping by provider works
|
||||
4. Test filtering by provider works
|
||||
5. Verify provider badges display correctly
|
||||
6. Test that providers without API keys show "Configure" message
|
||||
7. Verify selecting a model works for both providers
|
||||
</test_steps>
|
||||
</feature_unified_model_selector>
|
||||
|
||||
<feature_provider_settings>
|
||||
<title>Multi-Provider API Key Management</title>
|
||||
<description>
|
||||
Create unified API key management that supports multiple providers. Users should be able to:
|
||||
- Manage API keys for each provider separately (Claude, Mistral, OpenAI, etc.)
|
||||
- See which providers are available
|
||||
- See which providers are configured (have API keys)
|
||||
- Test each provider's API key independently
|
||||
- Enable/disable providers (hide models if key not configured)
|
||||
- See provider status indicators (configured/not configured/error)
|
||||
- Update or remove API keys for any provider
|
||||
- See usage statistics per provider
|
||||
</description>
|
||||
<priority>2</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create server/routes/providers.js with unified provider management
|
||||
- Update settings UI to show provider cards (one per provider)
|
||||
- Each provider card has:
|
||||
* Provider name and logo/icon
|
||||
* API key input field (masked)
|
||||
* "Test Connection" button
|
||||
* Status indicator (green/yellow/red)
|
||||
* Enable/disable toggle
|
||||
- Store keys in api_keys table with key_name = 'claude_api_key', 'mistral_api_key', etc.
|
||||
- Use same encryption method for all providers
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Configure Claude API key (verify existing functionality still works)
|
||||
2. Configure Mistral API key
|
||||
3. Verify both keys are stored separately
|
||||
4. Test each provider's "Test Connection" button
|
||||
5. Remove one key and verify only that provider's models are hidden
|
||||
6. Verify provider status indicators update correctly
|
||||
7. Test that disabling a provider hides its models
|
||||
</test_steps>
|
||||
</feature_provider_settings>
|
||||
|
||||
<feature_database_provider_support>
|
||||
<title>Database Support for Multiple Providers (Future-Proof)</title>
|
||||
<description>
|
||||
Update database schema to support multiple providers in a future-proof way.
|
||||
This should:
|
||||
- Add provider field to conversations table (TEXT, default: 'claude')
|
||||
- Add provider field to messages/usage_tracking (TEXT, default: 'claude')
|
||||
- Use TEXT field (not ENUM) to allow easy addition of new providers without schema changes
|
||||
- Migration should be safe, idempotent, and backward compatible
|
||||
- All existing records default to 'claude' provider
|
||||
- Add indexes for performance on provider queries
|
||||
</description>
|
||||
<priority>1</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create migration: server/migrations/add_provider_support.sql
|
||||
- Use TEXT field (not ENUM) for provider name (allows 'claude', 'mistral', 'openai', etc.)
|
||||
- Default all existing records to 'claude'
|
||||
- Add indexes on provider columns for performance
|
||||
- Make migration idempotent (can run multiple times safely)
|
||||
- Create rollback script if needed
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Backup existing database
|
||||
2. Run migration script
|
||||
3. Verify all existing conversations have provider='claude'
|
||||
4. Verify all existing messages have provider='claude' (via usage_tracking)
|
||||
5. Create new conversation with Mistral provider
|
||||
6. Verify provider='mistral' is saved correctly
|
||||
7. Query conversations by provider (test index performance)
|
||||
8. Verify existing Claude conversations still work
|
||||
9. Test rollback script if needed
|
||||
</test_steps>
|
||||
</feature_database_provider_support>
|
||||
|
||||
<feature_unified_chat_endpoint>
|
||||
<title>Unified Chat Endpoint (Works with Any Provider)</title>
|
||||
<description>
|
||||
Update chat endpoints to use ProviderFactory, making them work with any provider.
|
||||
The endpoint should:
|
||||
- Accept provider or model ID in request
|
||||
- Use ProviderFactory to get correct provider
|
||||
- Route request to appropriate provider
|
||||
- Return unified response format
|
||||
- Handle provider-specific errors gracefully
|
||||
- Support streaming for all providers that support it
|
||||
</description>
|
||||
<priority>1</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Update POST /api/chat to use ProviderFactory
|
||||
- Update POST /api/chat/stream to use ProviderFactory
|
||||
- Extract provider from model ID or accept provider parameter
|
||||
- Route to correct provider instance
|
||||
- Return unified response format
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Test POST /api/chat with Claude model (verify no regression)
|
||||
2. Test POST /api/chat with Mistral model
|
||||
3. Test POST /api/chat/stream with Claude (verify streaming still works)
|
||||
4. Test POST /api/chat/stream with Mistral
|
||||
5. Test error handling for invalid provider
|
||||
6. Test error handling for missing API key
|
||||
</test_steps>
|
||||
</feature_unified_chat_endpoint>
|
||||
</new_features>
|
||||
|
||||
<future_extensibility>
|
||||
<openai_provider_example>
|
||||
<title>How to Add OpenAI in the Future</title>
|
||||
<description>
|
||||
To add OpenAI support later, simply follow these steps (NO changes to existing code needed):
|
||||
|
||||
1. Create server/providers/OpenAIProvider.js extending BaseProvider
|
||||
2. Implement OpenAI API calls (https://api.openai.com/v1/chat/completions)
|
||||
3. Register in ProviderRegistry: ProviderRegistry.register('openai', OpenAIProvider)
|
||||
4. That's it! OpenAI models will automatically appear in model selector.
|
||||
|
||||
Example OpenAIProvider structure:
|
||||
- Extends BaseProvider
|
||||
- Implements sendMessage() using OpenAI API
|
||||
- Implements streamMessage() for streaming support
|
||||
- Returns models: gpt-4, gpt-3.5-turbo, etc.
|
||||
- Handles OpenAI-specific authentication and errors
|
||||
</description>
|
||||
</openai_provider_example>
|
||||
|
||||
<other_providers>
|
||||
<note>
|
||||
Same pattern works for any AI provider:
|
||||
- Google Gemini (GeminiProvider)
|
||||
- Cohere (CohereProvider)
|
||||
- Any other AI API that follows similar patterns
|
||||
Just create a new Provider class extending BaseProvider and register it.
|
||||
</note>
|
||||
</other_providers>
|
||||
</future_extensibility>
|
||||
|
||||
<implementation_notes>
|
||||
<code_structure>
|
||||
server/
|
||||
providers/
|
||||
BaseProvider.js # Abstract base class (NEW)
|
||||
ClaudeProvider.js # Refactored Claude (extends BaseProvider)
|
||||
MistralProvider.js # New Mistral (extends BaseProvider)
|
||||
ProviderRegistry.js # Manages all providers (NEW)
|
||||
ProviderFactory.js # Creates provider instances (NEW)
|
||||
routes/
|
||||
providers.js # Unified provider management (NEW)
|
||||
chat.js # Updated to use ProviderFactory
|
||||
migrations/
|
||||
add_provider_support.sql # Database migration (NEW)
|
||||
</code_structure>
|
||||
|
||||
<safety_guidelines>
|
||||
- Refactor Claude code to use BaseProvider WITHOUT changing functionality
|
||||
- All providers are isolated - errors in one don't affect others
|
||||
- Database changes are backward compatible (TEXT field, not ENUM)
|
||||
- Existing conversations default to 'claude' provider
|
||||
- Test Claude thoroughly after refactoring
|
||||
- Use feature flags if needed to enable/disable providers
|
||||
- Log all provider operations separately for debugging
|
||||
</safety_guidelines>
|
||||
|
||||
<error_handling>
|
||||
- Each provider handles its own errors
|
||||
- Provider errors should NOT affect other providers
|
||||
- Show user-friendly error messages
|
||||
- Log errors with provider context
|
||||
- Don't throw unhandled exceptions
|
||||
</error_handling>
|
||||
</implementation_notes>
|
||||
|
||||
<database_changes>
|
||||
<safe_migrations>
|
||||
<migration_1>
|
||||
<description>Add provider support (TEXT field for extensibility)</description>
|
||||
<sql>
|
||||
-- Add provider column to conversations (TEXT allows any provider name)
|
||||
-- Default to 'claude' for backward compatibility
|
||||
ALTER TABLE conversations
|
||||
ADD COLUMN provider TEXT DEFAULT 'claude';
|
||||
|
||||
-- Add provider column to usage_tracking
|
||||
ALTER TABLE usage_tracking
|
||||
ADD COLUMN provider TEXT DEFAULT 'claude';
|
||||
|
||||
-- Add indexes for performance
|
||||
CREATE INDEX IF NOT EXISTS idx_conversations_provider
|
||||
ON conversations(provider);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_usage_tracking_provider
|
||||
ON usage_tracking(provider);
|
||||
</sql>
|
||||
<rollback>
|
||||
-- Rollback script (use with caution - may cause data issues)
|
||||
DROP INDEX IF EXISTS idx_conversations_provider;
|
||||
DROP INDEX IF EXISTS idx_usage_tracking_provider;
|
||||
-- Note: SQLite doesn't support DROP COLUMN easily
|
||||
-- Would need to recreate table without provider column
|
||||
</rollback>
|
||||
<note>
|
||||
Using TEXT instead of ENUM allows adding new providers (OpenAI, Gemini, etc.)
|
||||
without database schema changes in the future. This is future-proof.
|
||||
</note>
|
||||
</migration_1>
|
||||
</safe_migrations>
|
||||
|
||||
<data_integrity>
|
||||
- All existing conversations default to provider='claude'
|
||||
- All existing messages default to provider='claude'
|
||||
- Migration is idempotent (can run multiple times safely)
|
||||
- No data loss during migration
|
||||
- Existing queries continue to work
|
||||
</data_integrity>
|
||||
</database_changes>
|
||||
|
||||
<api_endpoints>
|
||||
<new_endpoints>
|
||||
- GET /api/models - Get all models from all configured providers
|
||||
- GET /api/providers - Get list of available providers and their status
|
||||
- POST /api/providers/:provider/key - Set API key for specific provider
|
||||
- POST /api/providers/:provider/test - Test provider API key
|
||||
- GET /api/providers/:provider/status - Get provider configuration status
|
||||
- DELETE /api/providers/:provider/key - Remove provider API key
|
||||
</new_endpoints>
|
||||
|
||||
<updated_endpoints>
|
||||
- POST /api/chat - Updated to use ProviderFactory (works with any provider)
|
||||
* Accepts: { model: 'model-id', messages: [...], ... }
|
||||
* Provider is determined from model ID or can be specified
|
||||
- POST /api/chat/stream - Updated to use ProviderFactory (streaming for any provider)
|
||||
* Same interface, works with any provider that supports streaming
|
||||
</updated_endpoints>
|
||||
</api_endpoints>
|
||||
|
||||
<dependencies>
|
||||
<backend>
|
||||
- No new dependencies required (use native fetch for Mistral API)
|
||||
- Optional: @mistralai/mistralai (only if provides significant value)
|
||||
- Keep dependencies minimal to avoid conflicts
|
||||
</backend>
|
||||
</dependencies>
|
||||
|
||||
<testing_requirements>
|
||||
<regression_tests>
|
||||
- Verify all existing Claude functionality still works
|
||||
- Test that existing conversations load correctly
|
||||
- Verify Claude model selection still works
|
||||
- Test Claude API endpoints are unaffected
|
||||
- Verify database queries for Claude still work
|
||||
- Test Claude streaming still works
|
||||
</regression_tests>
|
||||
|
||||
<integration_tests>
|
||||
- Test switching between Claude and Mistral models
|
||||
- Test conversations with different providers
|
||||
- Test error handling doesn't affect other providers
|
||||
- Test migration doesn't break existing data
|
||||
- Test ProviderFactory routes correctly
|
||||
- Test unified model selector with multiple providers
|
||||
</integration_tests>
|
||||
|
||||
<extensibility_tests>
|
||||
- Verify adding a mock provider is straightforward
|
||||
- Test that ProviderFactory correctly routes to providers
|
||||
- Verify provider isolation (errors don't propagate)
|
||||
- Test that new providers automatically appear in UI
|
||||
</extensibility_tests>
|
||||
</testing_requirements>
|
||||
|
||||
<success_criteria>
|
||||
<functionality>
|
||||
- Claude functionality works exactly as before (no regression)
|
||||
- Mistral models appear in selector and work correctly
|
||||
- Users can switch between Claude and Mistral seamlessly
|
||||
- API key management works for both providers
|
||||
- Database migration is safe and backward compatible
|
||||
</functionality>
|
||||
|
||||
<extensibility>
|
||||
- Adding a new provider (like OpenAI) requires only creating one new file
|
||||
- No changes needed to existing code when adding providers
|
||||
- Provider architecture is documented and easy to follow
|
||||
- Code is organized and maintainable
|
||||
</extensibility>
|
||||
</success_criteria>
|
||||
</project_specification>
|
||||
403
prompts/app_spec_theme_customization.txt
Normal file
403
prompts/app_spec_theme_customization.txt
Normal file
@@ -0,0 +1,403 @@
|
||||
<project_specification>
|
||||
<project_name>Claude.ai Clone - Advanced Theme Customization</project_name>
|
||||
|
||||
<overview>
|
||||
This specification adds advanced theme customization features to the Claude.ai clone application.
|
||||
Users will be able to customize accent colors, font sizes, message spacing, and choose from
|
||||
preset color themes. All changes are additive and backward-compatible with existing theme functionality.
|
||||
|
||||
The existing light/dark mode toggle remains unchanged and functional.
|
||||
</overview>
|
||||
|
||||
<safety_requirements>
|
||||
<critical>
|
||||
- DO NOT modify existing light/dark mode functionality
|
||||
- DO NOT break existing theme persistence
|
||||
- DO NOT change existing CSS classes without ensuring backward compatibility
|
||||
- All new theme options must be optional (defaults should match current behavior)
|
||||
- Test thoroughly to ensure existing themes still work
|
||||
- Maintain backward compatibility at all times
|
||||
- New theme preferences should be stored separately from existing theme settings
|
||||
</critical>
|
||||
</safety_requirements>
|
||||
|
||||
<new_features>
|
||||
<feature_6_theme_customization>
|
||||
<title>Advanced Theme Customization</title>
|
||||
<description>
|
||||
Add advanced theme customization options. Users should be able to:
|
||||
- Customize accent colors (beyond just light/dark mode)
|
||||
- Choose from preset color themes (blue, green, purple, orange)
|
||||
- Adjust font size globally (small, medium, large)
|
||||
- Adjust message spacing (compact, comfortable, spacious)
|
||||
- Preview theme changes before applying
|
||||
- Save custom theme preferences
|
||||
|
||||
The customization interface should be intuitive and provide real-time preview
|
||||
of changes before they are applied. All preferences should persist across sessions.
|
||||
</description>
|
||||
<priority>3</priority>
|
||||
<category>style</category>
|
||||
<implementation_approach>
|
||||
- Create a new "Appearance" or "Theme" section in settings
|
||||
- Add accent color picker with preset options (blue, green, purple, orange)
|
||||
- Add font size slider/selector (small, medium, large)
|
||||
- Add message spacing selector (compact, comfortable, spacious)
|
||||
- Implement preview functionality that shows changes in real-time
|
||||
- Store theme preferences in localStorage or backend (user preferences)
|
||||
- Apply theme using CSS custom properties (CSS variables)
|
||||
- Ensure theme works with both light and dark modes
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Open settings menu
|
||||
2. Navigate to "Appearance" or "Theme" section
|
||||
3. Select a different accent color (e.g., green)
|
||||
4. Verify accent color changes are visible in preview
|
||||
5. Adjust font size slider to "large"
|
||||
6. Verify font size changes in preview
|
||||
7. Adjust message spacing option to "spacious"
|
||||
8. Verify spacing changes in preview
|
||||
9. Click "Preview" to see changes applied temporarily
|
||||
10. Click "Apply" to save changes permanently
|
||||
11. Verify changes persist after page refresh
|
||||
12. Test with both light and dark mode
|
||||
13. Test reset to default theme
|
||||
14. Verify existing conversations display correctly with new theme
|
||||
</test_steps>
|
||||
</feature_6_theme_customization>
|
||||
|
||||
<feature_accent_colors>
|
||||
<title>Accent Color Customization</title>
|
||||
<description>
|
||||
Allow users to customize the accent color used throughout the application.
|
||||
This includes:
|
||||
- Primary button colors
|
||||
- Link colors
|
||||
- Focus states
|
||||
- Active states
|
||||
- Selection highlights
|
||||
- Progress indicators
|
||||
|
||||
Preset options:
|
||||
- Blue (default, matches Claude.ai)
|
||||
- Green
|
||||
- Purple
|
||||
- Orange
|
||||
|
||||
Users should be able to see a preview of each color before applying.
|
||||
</description>
|
||||
<priority>3</priority>
|
||||
<category>style</category>
|
||||
<implementation_approach>
|
||||
- Define accent colors as CSS custom properties
|
||||
- Create color palette for each preset (light and dark variants)
|
||||
- Add color picker UI component in settings
|
||||
- Update all accent color usages to use CSS variables
|
||||
- Ensure colors have proper contrast ratios for accessibility
|
||||
- Store selected accent color in user preferences
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Open theme settings
|
||||
2. Select "Green" accent color
|
||||
3. Verify buttons, links, and highlights use green
|
||||
4. Switch to dark mode and verify green accent still works
|
||||
5. Test all preset colors (blue, green, purple, orange)
|
||||
6. Verify color persists after refresh
|
||||
7. Test accessibility (contrast ratios)
|
||||
</test_steps>
|
||||
</feature_accent_colors>
|
||||
|
||||
<feature_font_size>
|
||||
<title>Global Font Size Adjustment</title>
|
||||
<description>
|
||||
Allow users to adjust the global font size for better readability.
|
||||
Options:
|
||||
- Small (12px base)
|
||||
- Medium (14px base, default)
|
||||
- Large (16px base)
|
||||
|
||||
Font size should scale proportionally across all text elements:
|
||||
- Message text
|
||||
- UI labels
|
||||
- Input fields
|
||||
- Buttons
|
||||
- Sidebar text
|
||||
</description>
|
||||
<priority>3</priority>
|
||||
<category>style</category>
|
||||
<implementation_approach>
|
||||
- Use CSS rem units for all font sizes
|
||||
- Set base font size on root element
|
||||
- Create font size presets (small, medium, large)
|
||||
- Add font size selector in settings
|
||||
- Store preference in user settings
|
||||
- Ensure responsive design still works with different font sizes
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Open theme settings
|
||||
2. Select "Small" font size
|
||||
3. Verify all text is smaller throughout the app
|
||||
4. Select "Large" font size
|
||||
5. Verify all text is larger throughout the app
|
||||
6. Verify layout doesn't break with different font sizes
|
||||
7. Test with long messages to ensure wrapping works
|
||||
8. Verify preference persists after refresh
|
||||
</test_steps>
|
||||
</feature_font_size>
|
||||
|
||||
<feature_message_spacing>
|
||||
<title>Message Spacing Customization</title>
|
||||
<description>
|
||||
Allow users to adjust the spacing between messages and within message bubbles.
|
||||
Options:
|
||||
- Compact: Minimal spacing (for users who prefer dense layouts)
|
||||
- Comfortable: Default spacing (current behavior)
|
||||
- Spacious: Increased spacing (for better readability)
|
||||
|
||||
This affects:
|
||||
- Vertical spacing between messages
|
||||
- Padding within message bubbles
|
||||
- Spacing between message elements (avatar, text, timestamp)
|
||||
</description>
|
||||
<priority>3</priority>
|
||||
<category>style</category>
|
||||
<implementation_approach>
|
||||
- Define spacing scale using CSS custom properties
|
||||
- Create spacing presets (compact, comfortable, spacious)
|
||||
- Apply spacing to message containers and bubbles
|
||||
- Add spacing selector in settings
|
||||
- Store preference in user settings
|
||||
- Ensure spacing works well with different font sizes
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Open theme settings
|
||||
2. Select "Compact" spacing
|
||||
3. Verify messages are closer together
|
||||
4. Select "Spacious" spacing
|
||||
5. Verify messages have more space between them
|
||||
6. Test with long conversations to ensure scrolling works
|
||||
7. Verify spacing preference persists after refresh
|
||||
8. Test with different font sizes to ensure compatibility
|
||||
</test_steps>
|
||||
</feature_message_spacing>
|
||||
|
||||
<feature_theme_preview>
|
||||
<title>Theme Preview Functionality</title>
|
||||
<description>
|
||||
Allow users to preview theme changes before applying them permanently.
|
||||
The preview should:
|
||||
- Show a sample conversation with the new theme applied
|
||||
- Update in real-time as settings are changed
|
||||
- Allow users to cancel and revert to previous theme
|
||||
- Show both light and dark mode previews if applicable
|
||||
|
||||
Users should be able to:
|
||||
- See preview immediately when changing settings
|
||||
- Click "Apply" to save changes
|
||||
- Click "Cancel" to discard changes
|
||||
- Click "Reset" to return to default theme
|
||||
</description>
|
||||
<priority>3</priority>
|
||||
<category>functional</category>
|
||||
<implementation_approach>
|
||||
- Create preview component showing sample conversation
|
||||
- Apply theme changes temporarily to preview
|
||||
- Store original theme state for cancel functionality
|
||||
- Update preview in real-time as settings change
|
||||
- Only persist changes when "Apply" is clicked
|
||||
- Show clear visual feedback for preview vs. applied state
|
||||
</implementation_approach>
|
||||
<test_steps>
|
||||
1. Open theme settings
|
||||
2. Change accent color to green
|
||||
3. Verify preview updates immediately
|
||||
4. Change font size to large
|
||||
5. Verify preview updates with new font size
|
||||
6. Click "Cancel" and verify changes are reverted
|
||||
7. Make changes again and click "Apply"
|
||||
8. Verify changes are saved and applied to actual interface
|
||||
9. Test preview with both light and dark mode
|
||||
</test_steps>
|
||||
</feature_theme_preview>
|
||||
</new_features>
|
||||
|
||||
<implementation_notes>
|
||||
<code_structure>
|
||||
frontend/
|
||||
components/
|
||||
ThemeSettings.jsx # New theme customization UI (NEW)
|
||||
ThemePreview.jsx # Preview component (NEW)
|
||||
styles/
|
||||
theme-variables.css # CSS custom properties for themes (NEW)
|
||||
accent-colors.css # Accent color definitions (NEW)
|
||||
hooks/
|
||||
useTheme.js # Updated to handle new theme options
|
||||
utils/
|
||||
themeStorage.js # Theme preference persistence (NEW)
|
||||
</code_structure>
|
||||
|
||||
<css_architecture>
|
||||
Use CSS custom properties (CSS variables) for all theme values:
|
||||
- --accent-color-primary
|
||||
- --accent-color-hover
|
||||
- --font-size-base
|
||||
- --message-spacing-vertical
|
||||
- --message-padding
|
||||
|
||||
This allows easy theme switching without JavaScript manipulation.
|
||||
</css_architecture>
|
||||
|
||||
<storage_approach>
|
||||
Store theme preferences in:
|
||||
- localStorage for client-side persistence
|
||||
- Or backend user preferences table if available
|
||||
|
||||
Structure:
|
||||
{
|
||||
accentColor: 'blue' | 'green' | 'purple' | 'orange',
|
||||
fontSize: 'small' | 'medium' | 'large',
|
||||
messageSpacing: 'compact' | 'comfortable' | 'spacious',
|
||||
theme: 'light' | 'dark' (existing)
|
||||
}
|
||||
</storage_approach>
|
||||
|
||||
<safety_guidelines>
|
||||
- Keep existing theme functionality intact
|
||||
- Default values should match current behavior
|
||||
- Use feature detection for new theme features
|
||||
- Gracefully degrade if CSS custom properties not supported
|
||||
- Test with existing conversations and UI elements
|
||||
- Ensure accessibility standards are maintained
|
||||
</safety_guidelines>
|
||||
</implementation_notes>
|
||||
|
||||
<ui_components>
|
||||
<theme_settings_panel>
|
||||
<description>Settings panel for theme customization</description>
|
||||
<sections>
|
||||
- Accent Color: Radio buttons or color swatches for preset colors
|
||||
- Font Size: Slider or dropdown (small, medium, large)
|
||||
- Message Spacing: Radio buttons (compact, comfortable, spacious)
|
||||
- Preview: Live preview of theme changes
|
||||
- Actions: Apply, Cancel, Reset buttons
|
||||
</sections>
|
||||
</theme_settings_panel>
|
||||
|
||||
<theme_preview>
|
||||
<description>Preview component showing sample conversation</description>
|
||||
<elements>
|
||||
- Sample user message
|
||||
- Sample AI response
|
||||
- Shows current accent color
|
||||
- Shows current font size
|
||||
- Shows current spacing
|
||||
- Updates in real-time
|
||||
</elements>
|
||||
</theme_preview>
|
||||
</ui_components>
|
||||
|
||||
<css_custom_properties>
|
||||
<accent_colors>
|
||||
Define CSS variables for each accent color preset:
|
||||
--accent-blue: #2563eb;
|
||||
--accent-green: #10b981;
|
||||
--accent-purple: #8b5cf6;
|
||||
--accent-orange: #f59e0b;
|
||||
|
||||
Each should have hover, active, and focus variants.
|
||||
</accent_colors>
|
||||
|
||||
<font_sizes>
|
||||
Define base font sizes:
|
||||
--font-size-small: 0.75rem; (12px)
|
||||
--font-size-medium: 0.875rem; (14px, default)
|
||||
--font-size-large: 1rem; (16px)
|
||||
</font_sizes>
|
||||
|
||||
<spacing>
|
||||
Define spacing scales:
|
||||
--spacing-compact: 0.5rem;
|
||||
--spacing-comfortable: 1rem; (default)
|
||||
--spacing-spacious: 1.5rem;
|
||||
</spacing>
|
||||
</css_custom_properties>
|
||||
|
||||
<api_endpoints>
|
||||
<if_backend_storage>
|
||||
If storing preferences in backend:
|
||||
- GET /api/user/preferences - Get user theme preferences
|
||||
- PUT /api/user/preferences - Update user theme preferences
|
||||
- GET /api/user/preferences/theme - Get theme preferences only
|
||||
</if_backend_storage>
|
||||
|
||||
<note>
|
||||
If using localStorage only, no API endpoints needed.
|
||||
Backend storage is optional but recommended for multi-device sync.
|
||||
</note>
|
||||
</api_endpoints>
|
||||
|
||||
<accessibility_requirements>
|
||||
- All accent colors must meet WCAG AA contrast ratios (4.5:1 for text)
|
||||
- Font size changes must not break screen reader compatibility
|
||||
- Theme settings must be keyboard navigable
|
||||
- Color choices should not be the only way to convey information
|
||||
- Provide high contrast mode option if possible
|
||||
</accessibility_requirements>
|
||||
|
||||
<testing_requirements>
|
||||
<regression_tests>
|
||||
- Verify existing light/dark mode toggle still works
|
||||
- Verify existing theme persistence still works
|
||||
- Test that default theme matches current behavior
|
||||
- Verify existing conversations display correctly
|
||||
- Test that all UI elements are styled correctly
|
||||
</regression_tests>
|
||||
|
||||
<feature_tests>
|
||||
- Test each accent color preset
|
||||
- Test each font size option
|
||||
- Test each spacing option
|
||||
- Test theme preview functionality
|
||||
- Test theme persistence (localStorage/backend)
|
||||
- Test theme reset to defaults
|
||||
- Test theme with both light and dark modes
|
||||
- Test theme changes in real-time
|
||||
</feature_tests>
|
||||
|
||||
<compatibility_tests>
|
||||
- Test with different browsers (Chrome, Firefox, Safari, Edge)
|
||||
- Test with different screen sizes (responsive design)
|
||||
- Test with long conversations
|
||||
- Test with different message types (text, code, artifacts)
|
||||
- Test accessibility with screen readers
|
||||
</compatibility_tests>
|
||||
</testing_requirements>
|
||||
|
||||
<success_criteria>
|
||||
<functionality>
|
||||
- Users can customize accent colors from preset options
|
||||
- Users can adjust global font size (small, medium, large)
|
||||
- Users can adjust message spacing (compact, comfortable, spacious)
|
||||
- Theme preview shows changes in real-time
|
||||
- Theme preferences persist across sessions
|
||||
- Existing light/dark mode functionality works unchanged
|
||||
- All theme options work together harmoniously
|
||||
</functionality>
|
||||
|
||||
<user_experience>
|
||||
- Theme customization is intuitive and easy to use
|
||||
- Preview provides clear feedback before applying changes
|
||||
- Changes apply smoothly without flickering
|
||||
- Settings are easy to find and access
|
||||
- Reset to defaults is easily accessible
|
||||
</user_experience>
|
||||
|
||||
<technical>
|
||||
- Code is well-organized and maintainable
|
||||
- CSS custom properties are used consistently
|
||||
- Theme preferences are stored reliably
|
||||
- No performance degradation with theme changes
|
||||
- Backward compatibility is maintained
|
||||
</technical>
|
||||
</success_criteria>
|
||||
</project_specification>
|
||||
304
prompts/coding_prompt.md
Normal file
304
prompts/coding_prompt.md
Normal file
@@ -0,0 +1,304 @@
|
||||
## YOUR ROLE - CODING AGENT
|
||||
|
||||
You are continuing work on a long-running autonomous development task.
|
||||
This is a FRESH context window - you have no memory of previous sessions.
|
||||
|
||||
You have access to Linear for project management via MCP tools. Linear is your
|
||||
single source of truth for what needs to be built and what's been completed.
|
||||
|
||||
### STEP 1: GET YOUR BEARINGS (MANDATORY)
|
||||
|
||||
Start by orienting yourself:
|
||||
|
||||
```bash
|
||||
# 1. See your working directory
|
||||
pwd
|
||||
|
||||
# 2. List files to understand project structure
|
||||
ls -la
|
||||
|
||||
# 3. Read the project specification to understand what you're building
|
||||
cat app_spec.txt
|
||||
|
||||
# 4. Read the Linear project state
|
||||
cat .linear_project.json
|
||||
|
||||
# 5. Check recent git history
|
||||
git log --oneline -20
|
||||
```
|
||||
|
||||
Understanding the `app_spec.txt` is critical - it contains the full requirements
|
||||
for the application you're building.
|
||||
|
||||
### STEP 2: CHECK LINEAR STATUS
|
||||
|
||||
Query Linear to understand current project state. The `.linear_project.json` file
|
||||
contains the `project_id` and `team_id` you should use for all Linear queries.
|
||||
|
||||
1. **Find the META issue** for session context:
|
||||
Use `mcp__linear__list_issues` with the project ID from `.linear_project.json`
|
||||
and search for "[META] Project Progress Tracker".
|
||||
Read the issue description and recent comments for context from previous sessions.
|
||||
|
||||
2. **Count progress:**
|
||||
Use `mcp__linear__list_issues` with the project ID to get all issues, then count:
|
||||
- Issues with status "Done" = completed
|
||||
- Issues with status "Todo" = remaining
|
||||
- Issues with status "In Progress" = currently being worked on
|
||||
|
||||
3. **Check for in-progress work:**
|
||||
If any issue is "In Progress", that should be your first priority.
|
||||
A previous session may have been interrupted.
|
||||
|
||||
### STEP 3: START SERVERS (IF NOT RUNNING)
|
||||
|
||||
If `init.sh` exists, run it:
|
||||
```bash
|
||||
chmod +x init.sh
|
||||
./init.sh
|
||||
```
|
||||
|
||||
Otherwise, start servers manually and document the process.
|
||||
|
||||
### STEP 4: VERIFICATION TEST (CRITICAL!)
|
||||
|
||||
**MANDATORY BEFORE NEW WORK:**
|
||||
|
||||
The previous session may have introduced bugs. Before implementing anything
|
||||
new, you MUST run verification tests.
|
||||
|
||||
Use `mcp__linear__list_issues` with the project ID and status "Done" to find 1-2
|
||||
completed features that are core to the app's functionality.
|
||||
|
||||
Test these through the browser using Puppeteer:
|
||||
- Navigate to the feature
|
||||
- Verify it still works as expected
|
||||
- Take screenshots to confirm
|
||||
|
||||
**If you find ANY issues (functional or visual):**
|
||||
- Use `mcp__linear__update_issue` to set status back to "In Progress"
|
||||
- Add a comment explaining what broke
|
||||
- Fix the issue BEFORE moving to new features
|
||||
- This includes UI bugs like:
|
||||
* White-on-white text or poor contrast
|
||||
* Random characters displayed
|
||||
* Incorrect timestamps
|
||||
* Layout issues or overflow
|
||||
* Buttons too close together
|
||||
* Missing hover states
|
||||
* Console errors
|
||||
|
||||
### STEP 5: SELECT NEXT ISSUE TO WORK ON
|
||||
|
||||
Use `mcp__linear__list_issues` with the project ID from `.linear_project.json`:
|
||||
- Filter by `status`: "Todo"
|
||||
- Sort by priority (1=urgent is highest)
|
||||
- `limit`: 5
|
||||
|
||||
Review the highest-priority unstarted issues and select ONE to work on.
|
||||
|
||||
### STEP 6: CLAIM THE ISSUE
|
||||
|
||||
Before starting work, use `mcp__linear__update_issue` to:
|
||||
- Set the issue's `status` to "In Progress"
|
||||
|
||||
This signals to any other agents (or humans watching) that this issue is being worked on.
|
||||
|
||||
### STEP 7: IMPLEMENT THE FEATURE
|
||||
|
||||
Read the issue description for test steps and implement accordingly:
|
||||
|
||||
1. Write the code (frontend and/or backend as needed)
|
||||
2. Test manually using browser automation (see Step 8)
|
||||
3. Fix any issues discovered
|
||||
4. Verify the feature works end-to-end
|
||||
|
||||
### STEP 8: VERIFY WITH BROWSER AUTOMATION
|
||||
|
||||
**CRITICAL:** You MUST verify features through the actual UI.
|
||||
|
||||
Use browser automation tools:
|
||||
- `mcp__puppeteer__puppeteer_navigate` - Start browser and go to URL
|
||||
- `mcp__puppeteer__puppeteer_screenshot` - Capture screenshot
|
||||
- `mcp__puppeteer__puppeteer_click` - Click elements
|
||||
- `mcp__puppeteer__puppeteer_fill` - Fill form inputs
|
||||
|
||||
**DO:**
|
||||
- Test through the UI with clicks and keyboard input
|
||||
- Take screenshots to verify visual appearance
|
||||
- Check for console errors in browser
|
||||
- Verify complete user workflows end-to-end
|
||||
|
||||
**DON'T:**
|
||||
- Only test with curl commands (backend testing alone is insufficient)
|
||||
- Use JavaScript evaluation to bypass UI (no shortcuts)
|
||||
- Skip visual verification
|
||||
- Mark issues Done without thorough verification
|
||||
|
||||
### STEP 9: UPDATE LINEAR ISSUE (CAREFULLY!)
|
||||
|
||||
After thorough verification:
|
||||
|
||||
1. **Add implementation comment** using `mcp__linear__create_comment`:
|
||||
```markdown
|
||||
## Implementation Complete
|
||||
|
||||
### Changes Made
|
||||
- [List of files changed]
|
||||
- [Key implementation details]
|
||||
|
||||
### Verification
|
||||
- Tested via Puppeteer browser automation
|
||||
- Screenshots captured
|
||||
- All test steps from issue description verified
|
||||
|
||||
### Git Commit
|
||||
[commit hash and message]
|
||||
```
|
||||
|
||||
2. **Update status** using `mcp__linear__update_issue`:
|
||||
- Set `status` to "Done"
|
||||
|
||||
**ONLY update status to Done AFTER:**
|
||||
- All test steps in the issue description pass
|
||||
- Visual verification via screenshots
|
||||
- No console errors
|
||||
- Code committed to git
|
||||
|
||||
### STEP 10: COMMIT YOUR PROGRESS
|
||||
|
||||
Make a descriptive git commit:
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Implement [feature name]
|
||||
|
||||
- Added [specific changes]
|
||||
- Tested with browser automation
|
||||
- Linear issue: [issue identifier]
|
||||
"
|
||||
```
|
||||
|
||||
### STEP 11: UPDATE META ISSUE
|
||||
|
||||
Add a comment to the "[META] Project Progress Tracker" issue with session summary:
|
||||
|
||||
```markdown
|
||||
## Session Complete - [Brief description]
|
||||
|
||||
### Completed This Session
|
||||
- [Issue title]: [Brief summary of implementation]
|
||||
|
||||
### Current Progress
|
||||
- X issues Done
|
||||
- Y issues In Progress
|
||||
- Z issues remaining in Todo
|
||||
|
||||
### Verification Status
|
||||
- Ran verification tests on [feature names]
|
||||
- All previously completed features still working: [Yes/No]
|
||||
|
||||
### Notes for Next Session
|
||||
- [Any important context]
|
||||
- [Recommendations for what to work on next]
|
||||
- [Any blockers or concerns]
|
||||
```
|
||||
|
||||
### STEP 12: END SESSION CLEANLY
|
||||
|
||||
Before context fills up:
|
||||
1. Commit all working code
|
||||
2. If working on an issue you can't complete:
|
||||
- Add a comment explaining progress and what's left
|
||||
- Keep status as "In Progress" (don't revert to Todo)
|
||||
3. Update META issue with session summary
|
||||
4. Ensure no uncommitted changes
|
||||
5. Leave app in working state (no broken features)
|
||||
|
||||
---
|
||||
|
||||
## LINEAR WORKFLOW RULES
|
||||
|
||||
**Status Transitions:**
|
||||
- Todo → In Progress (when you start working)
|
||||
- In Progress → Done (when verified complete)
|
||||
- Done → In Progress (only if regression found)
|
||||
|
||||
**Comments Are Your Memory:**
|
||||
- Every implementation gets a detailed comment
|
||||
- Session handoffs happen via META issue comments
|
||||
- Comments are permanent - future agents will read them
|
||||
|
||||
**NEVER:**
|
||||
- Delete or archive issues
|
||||
- Modify issue descriptions or test steps
|
||||
- Work on issues already "In Progress" by someone else
|
||||
- Mark "Done" without verification
|
||||
- Leave issues "In Progress" when switching to another issue
|
||||
|
||||
---
|
||||
|
||||
## TESTING REQUIREMENTS
|
||||
|
||||
**ALL testing must use browser automation tools.**
|
||||
|
||||
Available Puppeteer tools:
|
||||
- `mcp__puppeteer__puppeteer_navigate` - Go to URL
|
||||
- `mcp__puppeteer__puppeteer_screenshot` - Capture screenshot
|
||||
- `mcp__puppeteer__puppeteer_click` - Click elements
|
||||
- `mcp__puppeteer__puppeteer_fill` - Fill form inputs
|
||||
- `mcp__puppeteer__puppeteer_select` - Select dropdown options
|
||||
- `mcp__puppeteer__puppeteer_hover` - Hover over elements
|
||||
|
||||
Test like a human user with mouse and keyboard. Don't take shortcuts.
|
||||
|
||||
---
|
||||
|
||||
## SESSION PACING
|
||||
|
||||
**How many issues should you complete per session?**
|
||||
|
||||
This depends on the project phase:
|
||||
|
||||
**Early phase (< 20% Done):** You may complete multiple issues per session when:
|
||||
- Setting up infrastructure/scaffolding that unlocks many issues at once
|
||||
- Fixing build issues that were blocking progress
|
||||
- Auditing existing code and marking already-implemented features as Done
|
||||
|
||||
**Mid/Late phase (> 20% Done):** Slow down to **1-2 issues per session**:
|
||||
- Each feature now requires focused implementation and testing
|
||||
- Quality matters more than quantity
|
||||
- Clean handoffs are critical
|
||||
|
||||
**After completing an issue, ask yourself:**
|
||||
1. Is the app in a stable, working state right now?
|
||||
2. Have I been working for a while? (You can't measure this precisely, but use judgment)
|
||||
3. Would this be a good stopping point for handoff?
|
||||
|
||||
If yes to all three → proceed to Step 11 (session summary) and end cleanly.
|
||||
If no → you may continue to the next issue, but **commit first** and stay aware.
|
||||
|
||||
**Golden rule:** It's always better to end a session cleanly with good handoff notes
|
||||
than to start another issue and risk running out of context mid-implementation.
|
||||
|
||||
---
|
||||
|
||||
## IMPORTANT REMINDERS
|
||||
|
||||
**Your Goal:** Production-quality application with all Linear issues Done
|
||||
|
||||
**This Session's Goal:** Make meaningful progress with clean handoff
|
||||
|
||||
**Priority:** Fix regressions before implementing new features
|
||||
|
||||
**Quality Bar:**
|
||||
- Zero console errors
|
||||
- Polished UI matching the design in app_spec.txt
|
||||
- All features work end-to-end through the UI
|
||||
- Fast, responsive, professional
|
||||
|
||||
**Context is finite.** You cannot monitor your context usage, so err on the side
|
||||
of ending sessions early with good handoff notes. The next agent will continue.
|
||||
|
||||
---
|
||||
|
||||
Begin by running Step 1 (Get Your Bearings).
|
||||
187
prompts/initializer_bis_prompt.md
Normal file
187
prompts/initializer_bis_prompt.md
Normal file
@@ -0,0 +1,187 @@
|
||||
## YOUR ROLE - INITIALIZER BIS AGENT (Adding New Specifications)
|
||||
|
||||
You are an EXTENSION agent in a long-running autonomous development process.
|
||||
Your job is to ADD NEW SPECIFICATIONS to an EXISTING project that has already been initialized.
|
||||
|
||||
**IMPORTANT:** This project already exists and has been initialized. You are NOT creating a new project.
|
||||
You are ADDING new features based on a new specification file.
|
||||
|
||||
You have access to Linear for project management via MCP tools. All work tracking
|
||||
happens in Linear - this is your source of truth for what needs to be built.
|
||||
|
||||
### FIRST: Understand the Existing Project
|
||||
|
||||
Start by reading the existing project state:
|
||||
|
||||
1. **Read `.linear_project.json`:**
|
||||
```bash
|
||||
cat .linear_project.json
|
||||
```
|
||||
This file contains:
|
||||
- `project_id`: The Linear project ID (you'll use this for new issues)
|
||||
- `team_id`: The team ID (you'll use this for new issues)
|
||||
- `meta_issue_id`: The META issue ID (you'll add a comment here)
|
||||
- `total_issues`: Current total number of issues
|
||||
|
||||
2. **Read the original `app_spec.txt`** (if it exists) to understand what was already built:
|
||||
```bash
|
||||
cat app_spec.txt
|
||||
```
|
||||
|
||||
3. **Check existing Linear issues** to understand what's already been done:
|
||||
Use `mcp__linear__list_issues` with the project ID from `.linear_project.json`
|
||||
to see existing issues and their statuses.
|
||||
|
||||
### SECOND: Read the New Specification File
|
||||
|
||||
Read the NEW specification file that was provided. This file contains the ADDITIONAL
|
||||
features to be added to the existing project. The filename will be something like
|
||||
`app_spec_new1.txt` or similar.
|
||||
|
||||
```bash
|
||||
# List files to find the new spec file
|
||||
ls -la *.txt
|
||||
|
||||
# Read the new specification file
|
||||
cat app_spec_new*.txt
|
||||
# (or whatever the filename is)
|
||||
```
|
||||
|
||||
Read it carefully to understand what NEW features need to be added.
|
||||
|
||||
### CRITICAL TASK: Create NEW Linear Issues
|
||||
|
||||
Based on the NEW specification file, create NEW Linear issues for each NEW feature
|
||||
using the `mcp__linear__create_issue` tool.
|
||||
|
||||
**IMPORTANT:**
|
||||
- Use the EXISTING `project_id` and `team_id` from `.linear_project.json`
|
||||
- Do NOT create a new Linear project
|
||||
- Do NOT modify existing issues
|
||||
- Only create NEW issues for the NEW features
|
||||
|
||||
**For each NEW feature, create an issue with:**
|
||||
|
||||
```
|
||||
title: Brief feature name (e.g., "New Feature - Advanced search")
|
||||
teamId: [Use the team ID from .linear_project.json]
|
||||
projectId: [Use the project ID from .linear_project.json]
|
||||
description: Markdown with feature details and test steps (see template below)
|
||||
priority: 1-4 based on importance (1=urgent/foundational, 4=low/polish)
|
||||
```
|
||||
|
||||
**Issue Description Template:**
|
||||
```markdown
|
||||
## Feature Description
|
||||
[Brief description of what this NEW feature does and why it matters]
|
||||
|
||||
## Category
|
||||
[functional OR style]
|
||||
|
||||
## Test Steps
|
||||
1. Navigate to [page/location]
|
||||
2. [Specific action to perform]
|
||||
3. [Another action]
|
||||
4. Verify [expected result]
|
||||
5. [Additional verification steps as needed]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Specific criterion 1]
|
||||
- [ ] [Specific criterion 2]
|
||||
- [ ] [Specific criterion 3]
|
||||
|
||||
## Note
|
||||
This is a NEW feature added via initializer bis. It extends the existing application.
|
||||
```
|
||||
|
||||
**Requirements for NEW Linear Issues:**
|
||||
- Create issues ONLY for NEW features from the new spec file
|
||||
- Do NOT duplicate features that already exist
|
||||
- Mix of functional and style features (note category in description)
|
||||
- Order by priority: foundational features get priority 1-2, polish features get 3-4
|
||||
- Include detailed test steps in each issue description
|
||||
- All issues start in "Todo" status (default)
|
||||
- Prefix issue titles with something like "[NEW]" if helpful to distinguish from existing issues
|
||||
|
||||
**Priority Guidelines:**
|
||||
- Priority 1 (Urgent): Core infrastructure additions, critical new features
|
||||
- Priority 2 (High): Important user-facing new features
|
||||
- Priority 3 (Medium): Secondary new features, enhancements
|
||||
- Priority 4 (Low): Polish, nice-to-haves, edge cases
|
||||
|
||||
**CRITICAL INSTRUCTION:**
|
||||
Once created, issues can ONLY have their status changed (Todo → In Progress → Done).
|
||||
Never delete issues, never modify descriptions after creation.
|
||||
This ensures no functionality is missed across sessions.
|
||||
|
||||
### NEXT TASK: Update Linear Project State
|
||||
|
||||
Update the `.linear_project.json` file to reflect the new total number of issues:
|
||||
|
||||
1. Read the current `.linear_project.json`
|
||||
2. Count how many NEW issues you created
|
||||
3. Add that number to the existing `total_issues` count
|
||||
4. Update the file with the new total
|
||||
|
||||
Example update:
|
||||
```json
|
||||
{
|
||||
"initialized": true,
|
||||
"created_at": "[original timestamp]",
|
||||
"team_id": "[existing team ID]",
|
||||
"project_id": "[existing project ID]",
|
||||
"project_name": "[existing project name]",
|
||||
"meta_issue_id": "[existing meta issue ID]",
|
||||
"total_issues": [original_count + new_issues_count],
|
||||
"notes": "Project initialized by initializer agent. Extended by initializer bis with [X] new issues."
|
||||
}
|
||||
```
|
||||
|
||||
### NEXT TASK: Update META Issue
|
||||
|
||||
Add a comment to the existing "[META] Project Progress Tracker" issue (use the `meta_issue_id`
|
||||
from `.linear_project.json`) summarizing what you accomplished:
|
||||
|
||||
```markdown
|
||||
## Initializer Bis Session Complete - New Specifications Added
|
||||
|
||||
### Accomplished
|
||||
- Read new specification file: [filename]
|
||||
- Created [X] NEW Linear issues for additional features
|
||||
- Updated .linear_project.json with new total issue count
|
||||
- [Any other relevant information]
|
||||
|
||||
### New Issues Created
|
||||
- Total new issues: [X]
|
||||
- Priority 1: [X]
|
||||
- Priority 2: [X]
|
||||
- Priority 3: [X]
|
||||
- Priority 4: [X]
|
||||
|
||||
### Updated Linear Status
|
||||
- Previous total issues: [Y]
|
||||
- New total issues: [Y + X]
|
||||
- All new issues start in "Todo" status
|
||||
|
||||
### Notes for Next Session
|
||||
- [Any important context about the new features]
|
||||
- [Recommendations for what to work on next]
|
||||
- [Any dependencies or integration points with existing features]
|
||||
```
|
||||
|
||||
### ENDING THIS SESSION
|
||||
|
||||
Before your context fills up:
|
||||
1. Commit all work with descriptive messages
|
||||
2. Add a comment to the META issue (as described above)
|
||||
3. Ensure `.linear_project.json` is updated with the new total
|
||||
4. Leave the environment in a clean, working state
|
||||
|
||||
The next agent (coding agent) will continue from here with a fresh context window and will
|
||||
see both the original issues and the new issues you created.
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You are EXTENDING an existing project, not creating a new one.
|
||||
Focus on adding the new features cleanly without breaking existing functionality.
|
||||
Production-ready integration is the goal.
|
||||
202
prompts/initializer_prompt.md
Normal file
202
prompts/initializer_prompt.md
Normal file
@@ -0,0 +1,202 @@
|
||||
## YOUR ROLE - INITIALIZER AGENT (Session 1 of Many)
|
||||
|
||||
You are the FIRST agent in a long-running autonomous development process.
|
||||
Your job is to set up the foundation for all future coding agents.
|
||||
|
||||
You have access to Linear for project management via MCP tools. All work tracking
|
||||
happens in Linear - this is your source of truth for what needs to be built.
|
||||
|
||||
### FIRST: Read the Project Specification
|
||||
|
||||
Start by reading `app_spec.txt` in your working directory. This file contains
|
||||
the complete specification for what you need to build. Read it carefully
|
||||
before proceeding.
|
||||
|
||||
### SECOND: Set Up Linear Project
|
||||
|
||||
Before creating issues, you need to set up Linear:
|
||||
|
||||
1. **Get the team ID:**
|
||||
Use `mcp__linear__list_teams` to see available teams.
|
||||
Note the team ID (e.g., "TEAM-123") for the team where you'll create issues.
|
||||
|
||||
2. **Create a Linear project:**
|
||||
Use `mcp__linear__create_project` to create a new project:
|
||||
- `name`: Use the project name from app_spec.txt (e.g., "Claude.ai Clone")
|
||||
- `teamIds`: Array with your team ID
|
||||
- `description`: Brief project overview from app_spec.txt
|
||||
|
||||
Save the returned project ID - you'll use it when creating issues.
|
||||
|
||||
### CRITICAL TASK: Create Linear Issues
|
||||
|
||||
Based on `app_spec.txt`, create Linear issues for each feature using the
|
||||
`mcp__linear__create_issue` tool. Create 50 detailed issues that
|
||||
comprehensively cover all features in the spec.
|
||||
|
||||
**For each feature, create an issue with:**
|
||||
|
||||
```
|
||||
title: Brief feature name (e.g., "Auth - User login flow")
|
||||
teamId: [Use the team ID you found earlier]
|
||||
projectId: [Use the project ID from the project you created]
|
||||
description: Markdown with feature details and test steps (see template below)
|
||||
priority: 1-4 based on importance (1=urgent/foundational, 4=low/polish)
|
||||
```
|
||||
|
||||
**Issue Description Template:**
|
||||
```markdown
|
||||
## Feature Description
|
||||
[Brief description of what this feature does and why it matters]
|
||||
|
||||
## Category
|
||||
[functional OR style]
|
||||
|
||||
## Test Steps
|
||||
1. Navigate to [page/location]
|
||||
2. [Specific action to perform]
|
||||
3. [Another action]
|
||||
4. Verify [expected result]
|
||||
5. [Additional verification steps as needed]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Specific criterion 1]
|
||||
- [ ] [Specific criterion 2]
|
||||
- [ ] [Specific criterion 3]
|
||||
```
|
||||
|
||||
**Requirements for Linear Issues:**
|
||||
- Create 50 issues total covering all features in the spec
|
||||
- Mix of functional and style features (note category in description)
|
||||
- Order by priority: foundational features get priority 1-2, polish features get 3-4
|
||||
- Include detailed test steps in each issue description
|
||||
- All issues start in "Todo" status (default)
|
||||
|
||||
**Priority Guidelines:**
|
||||
- Priority 1 (Urgent): Core infrastructure, database, basic UI layout
|
||||
- Priority 2 (High): Primary user-facing features, authentication
|
||||
- Priority 3 (Medium): Secondary features, enhancements
|
||||
- Priority 4 (Low): Polish, nice-to-haves, edge cases
|
||||
|
||||
**CRITICAL INSTRUCTION:**
|
||||
Once created, issues can ONLY have their status changed (Todo → In Progress → Done).
|
||||
Never delete issues, never modify descriptions after creation.
|
||||
This ensures no functionality is missed across sessions.
|
||||
|
||||
### NEXT TASK: Create Meta Issue for Session Tracking
|
||||
|
||||
Create a special issue titled "[META] Project Progress Tracker" with:
|
||||
|
||||
```markdown
|
||||
## Project Overview
|
||||
[Copy the project name and brief overview from app_spec.txt]
|
||||
|
||||
## Session Tracking
|
||||
This issue is used for session handoff between coding agents.
|
||||
Each agent should add a comment summarizing their session.
|
||||
|
||||
## Key Milestones
|
||||
- [ ] Project setup complete
|
||||
- [ ] Core infrastructure working
|
||||
- [ ] Primary features implemented
|
||||
- [ ] All features complete
|
||||
- [ ] Polish and refinement done
|
||||
|
||||
## Notes
|
||||
[Any important context about the project]
|
||||
```
|
||||
|
||||
This META issue will be used by all future agents to:
|
||||
- Read context from previous sessions (via comments)
|
||||
- Write session summaries before ending
|
||||
- Track overall project milestones
|
||||
|
||||
### NEXT TASK: Create init.sh
|
||||
|
||||
Create a script called `init.sh` that future agents can use to quickly
|
||||
set up and run the development environment. The script should:
|
||||
|
||||
1. Install any required dependencies
|
||||
2. Start any necessary servers or services
|
||||
3. Print helpful information about how to access the running application
|
||||
|
||||
Base the script on the technology stack specified in `app_spec.txt`.
|
||||
|
||||
### NEXT TASK: Initialize Git
|
||||
|
||||
Create a git repository and make your first commit with:
|
||||
- init.sh (environment setup script)
|
||||
- README.md (project overview and setup instructions)
|
||||
- Any initial project structure files
|
||||
|
||||
Commit message: "Initial setup: project structure and init script"
|
||||
|
||||
### NEXT TASK: Create Project Structure
|
||||
|
||||
Set up the basic project structure based on what's specified in `app_spec.txt`.
|
||||
This typically includes directories for frontend, backend, and any other
|
||||
components mentioned in the spec.
|
||||
|
||||
### NEXT TASK: Save Linear Project State
|
||||
|
||||
Create a file called `.linear_project.json` with the following information:
|
||||
```json
|
||||
{
|
||||
"initialized": true,
|
||||
"created_at": "[current timestamp]",
|
||||
"team_id": "[ID of the team you used]",
|
||||
"project_id": "[ID of the Linear project you created]",
|
||||
"project_name": "[Name of the project from app_spec.txt]",
|
||||
"meta_issue_id": "[ID of the META issue you created]",
|
||||
"total_issues": 50,
|
||||
"notes": "Project initialized by initializer agent"
|
||||
}
|
||||
```
|
||||
|
||||
This file tells future sessions that Linear has been set up.
|
||||
|
||||
### OPTIONAL: Start Implementation
|
||||
|
||||
If you have time remaining in this session, you may begin implementing
|
||||
the highest-priority features. Remember:
|
||||
- Use `mcp__linear__linear_search_issues` to find Todo issues with priority 1
|
||||
- Use `mcp__linear__linear_update_issue` to set status to "In Progress"
|
||||
- Work on ONE feature at a time
|
||||
- Test thoroughly before marking status as "Done"
|
||||
- Add a comment to the issue with implementation notes
|
||||
- Commit your progress before session ends
|
||||
|
||||
### ENDING THIS SESSION
|
||||
|
||||
Before your context fills up:
|
||||
1. Commit all work with descriptive messages
|
||||
2. Add a comment to the META issue summarizing what you accomplished:
|
||||
```markdown
|
||||
## Session 1 Complete - Initialization
|
||||
|
||||
### Accomplished
|
||||
- Created 50 Linear issues from app_spec.txt
|
||||
- Set up project structure
|
||||
- Created init.sh
|
||||
- Initialized git repository
|
||||
- [Any features started/completed]
|
||||
|
||||
### Linear Status
|
||||
- Total issues: 50
|
||||
- Done: X
|
||||
- In Progress: Y
|
||||
- Todo: Z
|
||||
|
||||
### Notes for Next Session
|
||||
- [Any important context]
|
||||
- [Recommendations for what to work on next]
|
||||
```
|
||||
3. Ensure `.linear_project.json` exists
|
||||
4. Leave the environment in a clean, working state
|
||||
|
||||
The next agent will continue from here with a fresh context window.
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You have unlimited time across many sessions. Focus on
|
||||
quality over speed. Production-ready is the goal.
|
||||
Reference in New Issue
Block a user