├── .claude ├── commands │ ├── research │ │ ├── STUDY-microservices-architecture.md │ │ ├── research-with-auto-mcp.md │ │ ├── STUDY-current-repo.md │ │ ├── STUDY-comfyui-custom-nodes-ecosystem.md │ │ └── STUDY-node-editor-performance-optimizations.md │ ├── minor-precautions │ │ └── careful-of-refactor-between-msgs.md │ ├── testing │ │ └── comprehensive-test-review.md │ ├── github │ │ ├── GH-daily-report.md │ │ ├── GH-summarize-my-recent-prs.md │ │ ├── GH-create-github-issue.md │ │ ├── GH-rebase-onto.md │ │ └── SOLVEBUG-solve-issue-tdd.md │ ├── development │ │ ├── create-feature-task.md │ │ └── use-command-template.md │ ├── validation │ │ ├── scan-configuration.md │ │ ├── scan-accessibility.md │ │ ├── scan-performance.md │ │ ├── scan-circular-dependencies.md │ │ ├── scan-test-coverage.md │ │ ├── scan-api-contracts.md │ │ ├── scan-dead-code.md │ │ ├── scan-bundle-size.md │ │ ├── validate-basic-security.md │ │ ├── scan-error-handling.md │ │ ├── scan-memory-leaks.md │ │ ├── validate-code-quality.md │ │ ├── scan-type-safety.md │ │ ├── scan-index.md │ │ ├── validate-dependencies.md │ │ └── frontend │ │ │ ├── scan-vue-patterns.md │ │ │ └── scan-performance-reactivity.md │ ├── system │ │ ├── memory-health-check.md │ │ └── semantic-memory-search.md │ ├── blog │ │ ├── add-idea.md │ │ └── list-ideas.md │ ├── summarize-book.md │ └── agents │ │ ├── AGENT-playbook-to-automated-agent-workflow.md │ │ └── AGENT-summarize-and-log-current-session.md ├── knowledge │ ├── custom-node-descrips │ │ ├── nodes_data.db │ │ └── CLAUDE.md │ ├── comfyui-execution │ │ ├── README.md │ │ ├── validation-flow.md │ │ └── VALIDATE_INPUTS.md │ ├── bounty-management │ │ ├── README.md │ │ └── issue-complexity-assessment.md │ ├── comfyui-troubleshooting │ │ ├── README.md │ │ └── gpu-compatibility-issues.md │ ├── node-editor-performance-optimizations │ │ ├── research-summary.md │ │ ├── d3-in-node-editors.md │ │ ├── CLAUDE.md │ │ └── flow-libraries-comparison.md │ ├── vue-based-node-system │ │ ├── implementation │ │ │ ├── VIEWPORT_CULLING_IMPLEMENTATION.md │ │ │ └── PHASE_1_COMPLETE.md │ │ ├── CRITICAL_VIEWPORT_CULLING_TRANSFORM.md │ │ ├── custom-hybrid-implementation-patterns.md │ │ └── UPDATES_LOG.md │ ├── comfyui-v3 │ │ └── README.md │ ├── comfyui-frontend │ │ ├── file-path-annotations.md │ │ ├── primevue-integration-patterns.md │ │ └── vue-composable-patterns.md │ ├── claude-code-best-practices │ │ ├── 00-overview.md │ │ ├── README.md │ │ ├── 01-claude-code-fundamentals.md │ │ ├── 10-resources.md │ │ ├── 06-evaluation-frameworks.md │ │ └── 09-pattern-consistency.md │ ├── comfy-claude-prompt-library │ │ └── README.md │ ├── dev-blog-best-practices │ │ └── 00-overview.md │ ├── graphics-rendering-fundamentals │ │ └── README.md │ └── kubernetes │ │ ├── README.md │ │ └── 00-fundamentals │ │ └── 00-what-is-kubernetes.md ├── settings.json ├── templates │ ├── test-checklist.md │ ├── code-review-checklist.md │ ├── command-template.md │ └── feature-task-template.md └── config │ └── command-patterns.yml ├── project-summaries-for-agents ├── ComfyUI-React-Extension-Template │ └── repository-summary.md ├── filepath-mapping.json.template ├── filepath-mapping.json └── vue-flow │ └── github-issue-ideas │ ├── transform-zoom-pixel-stretch-issue.md │ ├── viewport-culling-optimization-discussion.md │ ├── handle-connection-precision-enhancement.md │ ├── transform-performance-monitoring.md │ └── README.md ├── .gitignore ├── LICENSE ├── CONTRIBUTING.md └── .github └── workflows ├── validate-commands.yml └── check-readme-documentation.yml /.claude/commands/research/STUDY-microservices-architecture.md: -------------------------------------------------------------------------------- 1 | For reference, read the guide on microservices architecture here: https://microservices.io/index.html -------------------------------------------------------------------------------- /.claude/knowledge/custom-node-descrips/nodes_data.db: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Comfy-Org/comfy-claude-prompt-library/HEAD/.claude/knowledge/custom-node-descrips/nodes_data.db -------------------------------------------------------------------------------- /.claude/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "permissions": { 3 | "allow": [ 4 | "WebFetch(domain:docs.anthropic.com)", 5 | "Bash(gh issue list:*)" 6 | ], 7 | "deny": [] 8 | } 9 | } 10 | -------------------------------------------------------------------------------- /project-summaries-for-agents/ComfyUI-React-Extension-Template/repository-summary.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Comfy-Org/comfy-claude-prompt-library/HEAD/project-summaries-for-agents/ComfyUI-React-Extension-Template/repository-summary.md -------------------------------------------------------------------------------- /project-summaries-for-agents/filepath-mapping.json.template: -------------------------------------------------------------------------------- 1 | { 2 | "/path/to/your/project1": "project1-folder-name", 3 | "/path/to/your/project2": "project2-folder-name", 4 | "/path/to/ComfyUI": "ComfyUI", 5 | "/path/to/ComfyUI_frontend": "ComfyUI_frontend" 6 | } -------------------------------------------------------------------------------- /.claude/commands/minor-precautions/careful-of-refactor-between-msgs.md: -------------------------------------------------------------------------------- 1 | Yes, what you said is good and we can proceed, but i also just did some unrelated refactoring in your current project, so try to re-orient yourself to the changes quickly, looking out for any changed filenames or moved chunks of text. Once you're re-oriented, go ahead and proceed with what you just proposed. 2 | -------------------------------------------------------------------------------- /.claude/templates/test-checklist.md: -------------------------------------------------------------------------------- 1 | # Standard Test Checklist 2 | 3 | - [ ] Unit tests pass 4 | - [ ] Integration tests pass (if applicable) 5 | - [ ] No console errors 6 | - [ ] Code coverage maintained or improved 7 | - [ ] Edge cases covered 8 | - [ ] Error states handled 9 | - [ ] Performance benchmarks acceptable 10 | - [ ] Accessibility tests pass (if UI component) 11 | - [ ] Cross-browser compatibility verified (if web) 12 | - [ ] Documentation updated -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Cache files 2 | .users_cache.json 3 | *.cache 4 | 5 | # Temporary files 6 | *.tmp 7 | *.bak 8 | *~ 9 | 10 | # OS files 11 | .DS_Store 12 | Thumbs.db 13 | 14 | # Editor files 15 | .vscode/ 16 | .idea/ 17 | *.swp 18 | *.swo 19 | 20 | # Logs 21 | *.log 22 | 23 | # User-specific configuration 24 | project-summaries-for-agents/filepath-mapping.json 25 | 26 | # Environment-specific content that should never be tracked 27 | .claude/archive/ 28 | .claude/*.cache.json 29 | .claude/.channels_cache.json -------------------------------------------------------------------------------- /.claude/commands/testing/comprehensive-test-review.md: -------------------------------------------------------------------------------- 1 | # Comprehensive Test Review 2 | 3 | I need to review and ensure comprehensive testing for: $ARGUMENTS 4 | 5 | ## Test Review Process 6 | 7 | I'll perform a thorough test review following our standard checklist: 8 | 9 | @include templates/test-checklist.md 10 | 11 | ## Additional Considerations 12 | 13 | Beyond the standard checklist, I'll also examine: 14 | - Test isolation and independence 15 | - Mock usage appropriateness 16 | - Test execution time 17 | - Flaky test patterns 18 | - Test naming clarity 19 | 20 | Let me analyze the testing situation... -------------------------------------------------------------------------------- /.claude/templates/code-review-checklist.md: -------------------------------------------------------------------------------- 1 | # Code Review Checklist 2 | 3 | ## Code Quality 4 | - [ ] Functions < 50 lines 5 | - [ ] Cyclomatic complexity < 10 6 | - [ ] No obvious code smells 7 | - [ ] DRY principles followed 8 | - [ ] Clear variable/function names 9 | 10 | ## Security 11 | - [ ] No hardcoded secrets 12 | - [ ] Input validation present 13 | - [ ] SQL injection prevention 14 | - [ ] XSS prevention (if applicable) 15 | 16 | ## Testing 17 | - [ ] Tests included for new functionality 18 | - [ ] Tests updated for modified code 19 | - [ ] Edge cases covered 20 | 21 | ## Documentation 22 | - [ ] Code comments where necessary 23 | - [ ] API documentation updated 24 | - [ ] README updated if needed -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-execution/README.md: -------------------------------------------------------------------------------- 1 | # ComfyUI Execution System 2 | 3 | This folder contains knowledge about ComfyUI's execution and validation systems. 4 | 5 | ## Files 6 | 7 | - **validation-flow.md**: Sequential validation order and timing dependencies 8 | - **VALIDATE_INPUTS.md**: Custom validation implementation patterns and examples 9 | 10 | ## Key Concepts 11 | 12 | - **Validation Timing**: Static validation must pass before custom validation runs 13 | - **Input Types**: String types vs list types have different validation paths 14 | - **Custom Validation**: VALIDATE_INPUTS provides runtime validation with full context 15 | - **Execution Order**: Understanding the pipeline prevents debugging confusion 16 | 17 | ## Related Knowledge 18 | 19 | - See `comfyui-terminology/` for basic ComfyUI concepts 20 | - See `custom-node-descrips/` for node development patterns -------------------------------------------------------------------------------- /.claude/knowledge/bounty-management/README.md: -------------------------------------------------------------------------------- 1 | # Bounty Management Knowledge Base 2 | 3 | This folder contains knowledge and patterns learned from managing the ComfyUI bounty program, which serves dual purposes: 4 | 1. **Bounty Program**: External contributors, payment on merge 5 | 2. **New Hire Onboarding**: First tasks for new team members 6 | 7 | ## Contents 8 | 9 | - `issue-complexity-assessment.md` - Hard-learned lessons about realistic complexity evaluation 10 | - `dual-purpose-issue-scanning.md` - Patterns for identifying bounty vs new hire candidates 11 | - `scanning-efficiency-patterns.md` - Memory systems and tracking to avoid re-work 12 | 13 | ## Key Principles 14 | 15 | - **New hires get bugs** (more lenient complexity, better learning) 16 | - **Bounties get simple features** (isolated, well-defined tasks) 17 | - **Reality check complexity** (initial assessments often too optimistic) 18 | - **Check assignment status** (read comments before recommending) -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-troubleshooting/README.md: -------------------------------------------------------------------------------- 1 | # ComfyUI Troubleshooting Knowledge Base 2 | 3 | This folder contains documented solutions for common ComfyUI issues, hardware compatibility problems, and workarounds discovered through debugging sessions. 4 | 5 | ## Contents 6 | 7 | - `gpu-compatibility-issues.md` - GPU-specific problems and solutions 8 | - More sections to be added as issues are documented 9 | 10 | ## Purpose 11 | 12 | This knowledge base serves to: 13 | 1. Document hard-learned lessons from troubleshooting ComfyUI 14 | 2. Provide quick reference for known issues and their solutions 15 | 3. Track hardware/software compatibility problems 16 | 4. Share community-discovered workarounds 17 | 18 | ## Contributing 19 | 20 | When adding new troubleshooting knowledge: 21 | - Include specific error messages for searchability 22 | - Document the environment (versions, hardware) 23 | - Provide working solutions with exact commands 24 | - Note any performance implications 25 | - Include references to GitHub issues/discussions -------------------------------------------------------------------------------- /.claude/knowledge/custom-node-descrips/CLAUDE.md: -------------------------------------------------------------------------------- 1 | # ComfyUI Custom Nodes Dataset 2 | 3 | ## Purpose 4 | 5 | This folder contains a comprehensive dataset of all ComfyUI custom nodes available in the official registry, collected from the ComfyUI API. The data is sorted by popularity (download count) to help identify the most useful and widely-adopted community extensions. 6 | 7 | ## What This Data Represents 8 | 9 | - **Source**: ComfyUI Registry API (https://api.comfy.org/nodes) 10 | - **Collection Date**: June 17, 2025 11 | - **Total Nodes**: 2,654 custom node packages 12 | - **Data Completeness**: 97.6% complete records 13 | - **Sort Order**: By download count (highest to lowest) 14 | 15 | Each node record contains: 16 | - **Name**: Package identifier 17 | - **Description**: Functionality overview 18 | - **Repository URL**: GitHub source code location 19 | - **Download Count**: Total installations across all versions 20 | 21 | ## Files in This Folder 22 | 23 | ### Data Files 24 | - **`nodes_data.json`** (787 KB) - Complete dataset in JSON format 25 | - **`nodes_data.db`** (922 KB) - SQLite database with indexes for fast queries 26 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 Comfy-Org 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /.claude/templates/command-template.md: -------------------------------------------------------------------------------- 1 | # Command Template 2 | 3 | ## Purpose 4 | [Single sentence describing what the command does] 5 | 6 | ## Your Task 7 | 8 | [Clear description of what needs to be accomplished with: $ARGUMENTS] 9 | 10 | ## Execution Steps 11 | 12 | 1. **Phase 1 - Analysis** 13 | - [Step 1] 14 | - [Step 2] 15 | - [Step 3] 16 | 17 | 2. **Phase 2 - Implementation** 18 | - [Step 1] 19 | - [Step 2] 20 | - [Step 3] 21 | 22 | 3. **Phase 3 - Validation** 23 | - [Step 1] 24 | - [Step 2] 25 | - [Step 3] 26 | 27 | ## Context Preservation 28 | 29 | Cache the following for future commands: 30 | - Key findings 31 | - Decisions made 32 | - Files modified 33 | - Patterns identified 34 | 35 | ## Expected Output 36 | 37 | ``` 38 | ## [Command] Results 39 | 40 | ### Summary 41 | - [Key outcome 1] 42 | - [Key outcome 2] 43 | 44 | ### Details 45 | [Structured output based on command type] 46 | 47 | ### Next Steps 48 | - [Recommended follow-up action 1] 49 | - [Recommended follow-up action 2] 50 | ``` 51 | 52 | ## Integration 53 | 54 | **Prerequisites**: [What should be done before this command] 55 | **Follow-up**: [What commands naturally follow this one] 56 | **Related**: [Other commands that work well with this] -------------------------------------------------------------------------------- /.claude/knowledge/node-editor-performance-optimizations/research-summary.md: -------------------------------------------------------------------------------- 1 | # Node Editor Performance Research Summary 2 | 3 | ## Executive Summary 4 | 5 | Analyzed how modern DAG flow libraries use transforms, SVG, culling, GPU accel, RAF batching, event delegation, LOD, transform containers, etc. to optimize rendering performance. Tldraw seems far better than others, but using with PrimeVue components and Vue 3.5 might be **impossible** because it requires rebuilding everything in their shape system. Vue-flow would be easier but its performance would not be as good (performance is nearly identical to React Flow - both lack many things like culling, LOD, and RAF batching). Implementing this ourselves with canvas for bg and edges and labels and Vue for nodes would be **complex but optimal** - allowing tldraw-level performance optimizations while keeping Vue component compatibility. 6 | 7 | ## Key Verifications from the Analysis 8 | 9 | - Vue Flow and React Flow have nearly identical performance - both use d3-zoom, single viewport transforms, and lack advanced optimizations 10 | - **Tldraw integration would be impossible with existing Vue components** - not just hard 11 | - **A custom hybrid approach (canvas + Vue) would be the only way to get both performance AND component reuse** -------------------------------------------------------------------------------- /.claude/commands/github/GH-daily-report.md: -------------------------------------------------------------------------------- 1 | Analyze the top issues and PRs from these ComfyUI ecosystem repositories and create a morning briefing: 2 | 3 | - comfyanonymous/ComfyUI 4 | - Comfy-Org/ComfyUI_frontend 5 | - Comfy-Org/desktop 6 | - Comfy-Org/rfcs 7 | - Comfy-Org/comfy-cli 8 | 9 | For each repository: 10 | 1. Use gh to fetch recent open issues: gh issue list --repo --limit 20 --state open 11 | 2. Identify the top 5-7 most important issues based on: 12 | - Labels (bug, enhancement, priority, breaking) 13 | - Number of comments/reactions 14 | - Recent activity (updated within last week) 15 | - Milestone/project assignment 16 | 17 | Create a concise morning briefing with: 18 | 19 | ## ComfyUI Ecosystem Daily Digest 20 | 21 | ### Critical Issues 22 | - Any bugs blocking core functionality 23 | - Security vulnerabilities 24 | - Breaking changes needing attention 25 | 26 | ### Repository Summaries 27 | For each repo: 28 | - **[Repo Name]** - Brief one-line description 29 | - Top issues with: #number, title, impact summary, assignee 30 | - Key PRs in review 31 | - Community requests trending 32 | 33 | ### Cross-Repository Themes 34 | - Common issues affecting multiple repos 35 | - Ecosystem-wide initiatives 36 | - Community sentiment/feedback patterns 37 | 38 | Format for quick scanning during morning coffee. 39 | -------------------------------------------------------------------------------- /.claude/commands/github/GH-summarize-my-recent-prs.md: -------------------------------------------------------------------------------- 1 | Get all pull requests created by the current user in the past $ARGUMENTS hours (whether opened or closed) and provide a nicely formatted list with links and summaries. 2 | 3 | Follow these steps: 4 | 5 | 1. Use `gh pr list` with appropriate filters to get both open and closed PRs from all repositories you have access to 6 | 2. Filter the results to show only PRs created by the current user in the past $ARGUMENTS hours (if not specified, use 26 hours) 7 | 3. For each PR, gather: 8 | - PR title and number 9 | - Repository name 10 | - Status (open/closed/merged) 11 | - Creation date/time 12 | - Direct link to the PR 13 | - Brief summary of what the PR does (from the description or title) 14 | 15 | 4. Format the output as: 16 | - A clear header with the time range 17 | - Each PR as a bullet point with all the gathered information 18 | - Use markdown formatting for better readability 19 | - Include clickable links 20 | 21 | 5. If no PRs are found in the time range, clearly state that 22 | 23 | Commands to use: 24 | - `gh pr list --author=@me --state=all --limit=50` (to get both open and closed) 25 | - `gh pr view --repo ` to get additional details if needed 26 | - Use date filtering to ensure only PRs from the past $ARGUMENTS hours are included 27 | 28 | Remember to handle cases where: 29 | - No PRs exist in the timeframe 30 | - PRs might be from different repositories 31 | - Some PRs might have minimal descriptions -------------------------------------------------------------------------------- /.claude/knowledge/vue-based-node-system/implementation/VIEWPORT_CULLING_IMPLEMENTATION.md: -------------------------------------------------------------------------------- 1 | # Viewport Culling Implementation 2 | 3 | ## ⚠️ CRITICAL: Coordinate Transformation 4 | 5 | **THE MOST IMPORTANT THING TO KNOW:** 6 | ```typescript 7 | // CORRECT: Add offset BEFORE scaling 8 | screen_pos = (canvas_pos + offset) * scale ✅ 9 | 10 | // WRONG: This will break everything 11 | screen_pos = canvas_pos * scale + offset ❌ 12 | ``` 13 | 14 | ## Implementation Details 15 | 16 | ### 1. Transform Calculation 17 | Always use this exact formula for canvas to screen transformation: 18 | ```typescript 19 | const screen_x = (node.pos[0] + ds.offset[0]) * ds.scale 20 | const screen_y = (node.pos[1] + ds.offset[1]) * ds.scale 21 | const screen_width = node.size[0] * ds.scale 22 | const screen_height = node.size[1] * ds.scale 23 | ``` 24 | 25 | ### 2. Visibility Check 26 | ```typescript 27 | const isVisible = !( 28 | screen_x + screen_width < -margin_x || 29 | screen_x > viewport_width + margin_x || 30 | screen_y + screen_height < -margin_y || 31 | screen_y > viewport_height + margin_y 32 | ) 33 | ``` 34 | 35 | ### 3. Integration Points 36 | - GraphCanvas.vue: nodesToRender computed property 37 | - Use canvasStore.canvas for accessing LiteGraph canvas 38 | - Sync transform state when needed 39 | 40 | ### 4. Common Pitfalls 41 | - Wrong coordinate transformation order (see above) 42 | - Not syncing transform state before visibility checks 43 | - Using window dimensions instead of canvas element dimensions 44 | - Forgetting to account for margin in canvas space vs screen space -------------------------------------------------------------------------------- /.claude/commands/development/create-feature-task.md: -------------------------------------------------------------------------------- 1 | # Create Feature Development Task 2 | 3 | I need to create a structured development task for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Set up a comprehensive feature development task with proper tracking, phases, and documentation. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Parse Feature Requirements** 12 | - Extract feature name and description from $ARGUMENTS 13 | - Identify key requirements and constraints 14 | - Determine complexity and scope 15 | 16 | 2. **Generate Task Structure** 17 | - Use the feature task template as base 18 | - Customize phases based on feature type 19 | - Add specific acceptance criteria 20 | - Include relevant technical considerations 21 | 22 | 3. **Create Task Documentation** 23 | - Copy template from ~/.claude/templates/feature-task-template.md 24 | - Fill in all sections with feature-specific details 25 | - Save to appropriate location (suggest: .claude/tasks/[feature-name].md) 26 | - Create initial git branch if requested 27 | 28 | 4. **Set Up Tracking** 29 | - Add task to TODO list if applicable 30 | - Create initial checkpoints 31 | - Set up progress markers 32 | - Configure any automation needed 33 | 34 | ## Template Usage 35 | 36 | @include templates/feature-task-template.md 37 | 38 | ## Context Preservation 39 | 40 | When creating the task, preserve: 41 | - Initial requirements 42 | - Key technical decisions 43 | - File locations 44 | - Dependencies identified 45 | - Risk factors 46 | 47 | ## Integration 48 | 49 | **Prerequisites**: Clear feature requirements 50 | **Follow-up**: `/development:implement-feature [task-file]` 51 | **Related**: `create-test-plan`, `estimate-context-window` -------------------------------------------------------------------------------- /.claude/knowledge/vue-based-node-system/CRITICAL_VIEWPORT_CULLING_TRANSFORM.md: -------------------------------------------------------------------------------- 1 | # CRITICAL: Canvas to Screen Coordinate Transformation 2 | 3 | ## THE CORRECT FORMULA (ALWAYS USE THIS) 4 | 5 | ```typescript 6 | // Transform canvas position to screen position 7 | const screen_x = (node.pos[0] + ds.offset[0]) * ds.scale 8 | const screen_y = (node.pos[1] + ds.offset[1]) * ds.scale 9 | ``` 10 | 11 | ## WRONG FORMULA (NEVER USE THIS) 12 | 13 | ```typescript 14 | // WRONG! This caused hours of debugging 15 | const screen_x = node.pos[0] * ds.scale + ds.offset[0] // ❌ WRONG ORDER 16 | const screen_y = node.pos[1] * ds.scale + ds.offset[1] // ❌ WRONG ORDER 17 | ``` 18 | 19 | ## Key Learning 20 | 21 | The offset MUST be added to the position BEFORE scaling. This is how LiteGraph's coordinate system works: 22 | 23 | 1. Add offset to canvas position (translation) 24 | 2. Then multiply by scale (zoom) 25 | 3. Optionally add canvas element position for client coordinates 26 | 27 | ## Reference Implementation 28 | 29 | The correct implementation can always be found in: 30 | - `/src/composables/element/useCanvasPositionConversion.ts` 31 | - DOM widgets use this correctly via `canvasPosToClientPos` 32 | 33 | ## Why This Matters 34 | 35 | Getting this wrong causes: 36 | - Nodes appear visible when they're actually off-screen 37 | - Viewport culling completely breaks 38 | - Spatial indexing returns wrong results 39 | - Hours of painful debugging 40 | 41 | ## Always Remember 42 | 43 | When implementing viewport culling or any screen-space calculations: 44 | 1. Use the existing `useCanvasPositionConversion` composable if possible 45 | 2. If you must calculate manually, use: `(pos + offset) * scale` 46 | 3. Test with different zoom levels (especially zoom < 1.0) -------------------------------------------------------------------------------- /.claude/knowledge/node-editor-performance-optimizations/d3-in-node-editors.md: -------------------------------------------------------------------------------- 1 | # D3.js in Node Editor Libraries 2 | 3 | ## What is D3.js? 4 | 5 | D3 (Data-Driven Documents) is a JavaScript library for manipulating documents based on data. It's particularly powerful for creating dynamic, interactive data visualizations. 6 | 7 | ## Why D3 is Used in Node Editors 8 | 9 | ### 1. SVG Manipulation 10 | D3 excels at creating and manipulating SVG elements, which are perfect for drawing nodes, edges, and complex shapes in node editors. 11 | 12 | ### 2. Data Binding 13 | D3's core strength is binding data to DOM elements, making it easy to update visual representations when underlying node graph data changes. 14 | 15 | ### 3. Transitions & Animations 16 | Built-in support for smooth animations for node movements, edge updates, and state changes. 17 | 18 | ### 4. Force Simulation 19 | Includes a physics engine for auto-layout algorithms (force-directed graphs), useful for automatically arranging nodes. 20 | 21 | ### 5. Drag Behaviors 22 | Sophisticated drag-and-drop handling out of the box for interactive node manipulation. 23 | 24 | ### 6. Zoom & Pan 25 | Built-in behaviors for canvas navigation, essential for large node graphs. 26 | 27 | ### 7. Scales & Coordinates 28 | Powerful coordinate system transformations for mapping between data space and screen space. 29 | 30 | ## Modern Alternatives 31 | 32 | Many modern libraries (like React Flow, Vue Flow) have moved away from D3 because: 33 | 34 | - They use their own rendering engines optimized for their specific use cases 35 | - Canvas or WebGL rendering for better performance with many nodes 36 | - Framework-specific state management instead of D3's data binding 37 | - Simpler APIs tailored to node editing rather than general visualization -------------------------------------------------------------------------------- /.claude/commands/validation/scan-configuration.md: -------------------------------------------------------------------------------- 1 | # Scan Configuration Files 2 | 3 | I need to validate configuration files for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze configuration files for security issues, inconsistencies, and best practices violations. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Identify Configuration Files** 12 | - .env, .env.*, config.json, config.yml 13 | - docker-compose.yml, Dockerfile 14 | - nginx.conf, apache.conf 15 | - CI/CD configs (.github/workflows, .gitlab-ci.yml) 16 | - Build configs (webpack, vite, rollup) 17 | 18 | 2. **Security Checks** 19 | - Hardcoded credentials or secrets 20 | - Insecure default settings 21 | - Exposed debug flags in production 22 | - Permissive CORS or security headers 23 | - Open ports or services 24 | 25 | 3. **Consistency Validation** 26 | - Environment variable mismatches 27 | - Conflicting settings across files 28 | - Missing required configurations 29 | - Duplicate or redundant settings 30 | 31 | 4. **Best Practices** 32 | - Using environment-specific configs 33 | - Proper secret management 34 | - Resource limits defined 35 | - Logging levels appropriate 36 | - Backup and recovery settings 37 | 38 | 5. **Infrastructure Validation** 39 | - Container security settings 40 | - Network isolation 41 | - Volume mount permissions 42 | - Resource constraints 43 | - Health check configurations 44 | 45 | ## Report Format 46 | 47 | ``` 48 | ## Configuration Scan Results 49 | 50 | ### Security Issues 51 | - [Config File]: [Issue] - [Risk Level] 52 | Fix: [Specific remediation] 53 | 54 | ### Inconsistencies 55 | - [Setting]: Defined differently in [File1] vs [File2] 56 | 57 | ### Missing Configurations 58 | - [Required Setting]: Not found in [Environment] 59 | 60 | ### Best Practice Violations 61 | - [Issue]: [File] - [Recommendation] 62 | ``` -------------------------------------------------------------------------------- /.claude/templates/feature-task-template.md: -------------------------------------------------------------------------------- 1 | # Feature Development Task Template 2 | 3 | ## Task: [FEATURE_NAME] 4 | 5 | ### Requirements 6 | - **User Story**: As a [user], I want [feature] so that [benefit] 7 | - **Acceptance Criteria**: 8 | - [ ] Criterion 1 9 | - [ ] Criterion 2 10 | - [ ] Criterion 3 11 | 12 | ### Technical Breakdown 13 | 14 | #### Phase 1: Analysis & Design 15 | - [ ] Understand existing architecture 16 | - [ ] Identify affected components 17 | - [ ] Design integration approach 18 | - [ ] Create/update technical spec 19 | 20 | #### Phase 2: Implementation 21 | - [ ] Set up feature branch 22 | - [ ] Implement core functionality 23 | - [ ] Add error handling 24 | - [ ] Integrate with existing systems 25 | 26 | #### Phase 3: Testing 27 | - [ ] Write unit tests 28 | - [ ] Add integration tests 29 | - [ ] Perform manual testing 30 | - [ ] Fix any issues found 31 | 32 | #### Phase 4: Documentation & Review 33 | - [ ] Update API documentation 34 | - [ ] Add inline code comments 35 | - [ ] Update README if needed 36 | - [ ] Create PR with clear description 37 | 38 | ### Files Affected 39 | - **New Files**: 40 | - `path/to/new/file.ts` 41 | - **Modified Files**: 42 | - `path/to/existing/file.ts` 43 | - **Tests**: 44 | - `path/to/test/file.test.ts` 45 | 46 | ### Dependencies 47 | - External libraries needed: [list] 48 | - Internal dependencies: [list] 49 | 50 | ### Risk Assessment 51 | - **Complexity**: Low/Medium/High 52 | - **Breaking Changes**: Yes/No 53 | - **Performance Impact**: [description] 54 | - **Security Considerations**: [list] 55 | 56 | ### Progress Tracking 57 | - [ ] Branch created 58 | - [ ] Core implementation complete 59 | - [ ] Tests passing 60 | - [ ] Code review approved 61 | - [ ] Merged to main 62 | 63 | ### Notes & Decisions 64 | - [Document key decisions made during implementation] 65 | - [Note any blockers or issues encountered] 66 | - [Record alternative approaches considered] -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-v3/README.md: -------------------------------------------------------------------------------- 1 | # ComfyUI v3 Initiative 2 | 3 | This knowledge base documents the ComfyUI v3 initiative, a major architectural overhaul aimed at improving the custom node experience through better dependency management, modern APIs, and scalable execution. 4 | 5 | ## Overview 6 | 7 | The v3 initiative consists of three interconnected components: 8 | 9 | 1. **[v3 Node Schema](./v3-schema.md)** - New object-oriented node definition system 10 | 2. **[Async Nodes](./async-nodes.md)** - Native async/await support for non-blocking execution 11 | 3. **[Process Isolation](./process-isolation.md)** - Multi-process node execution via pyisolate 12 | 13 | ## Key Goals 14 | 15 | - **Improve Stability** - Separate internal functions from public APIs 16 | - **Solve Dependency Conflicts** - Run nodes with conflicting dependencies 17 | - **Enable Dynamic I/O** - First-class support for dynamic inputs/outputs 18 | - **Streamline Development** - Better IDE support, type hints, documentation 19 | - **Future-Proof Architecture** - Support for distributed/parallel execution 20 | 21 | ## Quick Links 22 | 23 | - [Migration Guide](./migration-guide.md) - Converting v1 nodes to v3 24 | - [API Reference](./api-reference.md) - Complete v3 API documentation 25 | - [Examples](./examples.md) - Sample v3 node implementations 26 | - [Technical Deep Dive](./technical-details.md) - Architecture and implementation details 27 | 28 | ## Timeline 29 | 30 | - **Current Status**: In development, seeking feedback 31 | - **v3 Schema**: Active development on `v3-definition` branch 32 | - **Async Nodes**: Working implementation on `js/drafts/async_nodes_v2` branch 33 | - **Process Isolation**: pyisolate package available, integration pending 34 | 35 | ## Resources 36 | 37 | - Blog Post: [Dependency Resolution and Custom Node Standards](https://blog.comfy.org/dependency-resolution-and-custom-node-standards) 38 | - Discord: #exclusive-custom-node-devs channel 39 | - GitHub: [ComfyUI Repository](https://github.com/comfyanonymous/ComfyUI) -------------------------------------------------------------------------------- /.claude/commands/validation/scan-accessibility.md: -------------------------------------------------------------------------------- 1 | # Scan Accessibility Issues 2 | 3 | I need to check accessibility compliance for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze UI components and pages for WCAG compliance and accessibility best practices. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Semantic HTML Validation** 12 | - Missing or incorrect heading hierarchy 13 | - Non-semantic elements for interactive content 14 | - Missing landmark regions 15 | - Improper list structures 16 | - Form elements without labels 17 | 18 | 2. **ARIA Implementation** 19 | - Missing ARIA labels on interactive elements 20 | - Incorrect ARIA roles 21 | - Invalid ARIA attribute combinations 22 | - Redundant or conflicting ARIA 23 | 24 | 3. **Keyboard Navigation** 25 | - Elements not reachable by keyboard 26 | - Missing focus indicators 27 | - Incorrect tab order 28 | - Keyboard traps 29 | - Missing skip links 30 | 31 | 4. **Screen Reader Support** 32 | - Images without alt text 33 | - Decorative images not hidden 34 | - Dynamic content without announcements 35 | - Missing form error associations 36 | - Unclear button/link text 37 | 38 | 5. **Visual Accessibility** 39 | - Insufficient color contrast ratios 40 | - Color as sole information indicator 41 | - Missing focus indicators 42 | - Small touch targets (<44x44px) 43 | - No visible labels 44 | 45 | ## Report Format 46 | 47 | ``` 48 | ## Accessibility Scan Results 49 | 50 | ### WCAG Violations 51 | - Level A (Must Fix): 52 | - [Issue]: [File:Line] - [Impact on users] 53 | 54 | - Level AA (Should Fix): 55 | - [Issue]: [File:Line] - [Impact on users] 56 | 57 | ### Keyboard Navigation Issues 58 | - [Component]: Not keyboard accessible 59 | Fix: Add tabIndex and key handlers 60 | 61 | ### Screen Reader Issues 62 | - [Element]: Missing accessible name 63 | Fix: Add aria-label or aria-labelledby 64 | 65 | ### Quick Fixes 66 | - Add alt="" to decorative images 67 | - Increase contrast ratio to 4.5:1 68 | - Add focus-visible styles 69 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/scan-performance.md: -------------------------------------------------------------------------------- 1 | # Scan Performance Issues 2 | 3 | I need to analyze performance characteristics of: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Profile code for performance bottlenecks, inefficient algorithms, and resource usage issues. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Algorithm Complexity Analysis** 12 | - Identify O(n²) or worse algorithms 13 | - Nested loops with large datasets 14 | - Recursive functions without memoization 15 | - Inefficient sorting/searching 16 | 17 | 2. **Database Performance** 18 | - N+1 query patterns 19 | - Missing database indexes 20 | - Unnecessary data fetching 21 | - Inefficient joins or subqueries 22 | - No query result caching 23 | 24 | 3. **Memory Usage Patterns** 25 | - Memory leaks (event listeners, closures) 26 | - Large object allocations 27 | - Unnecessary data copying 28 | - Missing cleanup in useEffect/componentWillUnmount 29 | 30 | 4. **Rendering Performance (Frontend)** 31 | - Unnecessary re-renders 32 | - Missing React.memo/useMemo/useCallback 33 | - Large component trees 34 | - Expensive computations in render 35 | - Missing virtualization for long lists 36 | 37 | 5. **Network Performance** 38 | - Waterfall loading instead of parallel 39 | - Missing compression 40 | - No caching headers 41 | - Large payload sizes 42 | - Chatty APIs (too many requests) 43 | 44 | ## Report Format 45 | 46 | ``` 47 | ## Performance Analysis 48 | 49 | ### Critical Performance Issues 50 | - [Issue]: [File:Line] - Impact: [Time/Memory] 51 | Fix: [Optimization approach] 52 | 53 | ### Algorithm Complexity 54 | - [Function]: O(n²) complexity detected 55 | Suggestion: [Better algorithm] 56 | 57 | ### Database Optimization 58 | - [Query Location]: N+1 pattern found 59 | Fix: Use eager loading/joins 60 | 61 | ### Memory Concerns 62 | - [Component/Function]: Potential memory leak 63 | Fix: [Cleanup approach] 64 | 65 | ### Quick Wins 66 | - Enable compression: ~70% reduction 67 | - Add caching: ~50ms saved per request 68 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/scan-circular-dependencies.md: -------------------------------------------------------------------------------- 1 | # Scan Circular Dependencies 2 | 3 | I need to detect circular dependencies in: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Identify circular dependency chains that could cause runtime errors or build issues. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Import Cycle Detection** 12 | - Direct circular imports (A→B→A) 13 | - Indirect cycles (A→B→C→A) 14 | - Barrel export cycles 15 | - Dynamic import cycles 16 | - Type-only import cycles 17 | 18 | 2. **Module Boundary Analysis** 19 | - Cross-feature dependencies 20 | - Layer violations (UI→Data→UI) 21 | - Service interdependencies 22 | - Store/state circular refs 23 | - Component circular deps 24 | 25 | 3. **Impact Assessment** 26 | - Runtime initialization errors 27 | - Undefined exports at runtime 28 | - Build tool warnings 29 | - Hot reload broken 30 | - Test isolation issues 31 | 32 | 4. **Architectural Violations** 33 | - Domain boundaries crossed 34 | - Abstraction inversions 35 | - Framework fighting patterns 36 | - Coupling metrics exceeded 37 | - Cohesion problems 38 | 39 | 5. **Resolution Strategies** 40 | - Identify cycle breaking points 41 | - Suggest refactoring approach 42 | - Interface extraction needs 43 | - Dependency injection points 44 | - Module reorganization 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Circular Dependency Analysis 50 | 51 | ### Critical Cycles Found 52 | - Cycle: A → B → C → A 53 | Files: [List of files in cycle] 54 | Break point: Extract interface at B 55 | 56 | ### Module Violations 57 | - [Feature X] ← → [Feature Y] 58 | Suggestion: Extract shared types 59 | 60 | ### Architecture Issues 61 | - UI layer importing from Data layer 62 | Fix: Use dependency injection 63 | 64 | ### Impact Summary 65 | - X cycles affecting Y files 66 | - Z% of modules involved 67 | - Build time impact: +N seconds 68 | 69 | ### Resolution Priority 70 | 1. Break cycle in [critical path] 71 | 2. Extract [shared interface] 72 | 3. Reorganize [module structure] 73 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/scan-test-coverage.md: -------------------------------------------------------------------------------- 1 | # Scan Test Coverage 2 | 3 | I need to analyze test coverage and quality for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Evaluate test coverage, identify untested code paths, and assess test quality. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Coverage Metrics** 12 | - Line coverage percentage 13 | - Branch coverage percentage 14 | - Function coverage percentage 15 | - Statement coverage percentage 16 | - Identify coverage config files 17 | 18 | 2. **Untested Code Detection** 19 | - Critical paths without tests 20 | - Error handling branches 21 | - Edge cases not covered 22 | - New code without tests 23 | - Complex functions with low coverage 24 | 25 | 3. **Test Quality Assessment** 26 | - Tests that only check happy path 27 | - Missing negative test cases 28 | - No edge case testing 29 | - Weak assertions (only checking defined) 30 | - Tests with no assertions 31 | 32 | 4. **Test Patterns** 33 | - Integration vs unit test balance 34 | - Test isolation issues 35 | - Excessive mocking 36 | - Flaky tests patterns 37 | - Slow test identification 38 | 39 | 5. **Critical Gap Analysis** 40 | - Authentication/authorization logic 41 | - Payment/financial calculations 42 | - Data validation functions 43 | - Security-critical code 44 | - User input handling 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Test Coverage Analysis 50 | 51 | ### Coverage Summary 52 | - Line Coverage: X% 53 | - Branch Coverage: Y% 54 | - Uncovered Files: Z 55 | 56 | ### Critical Untested Code 57 | - [Function/Component]: 0% coverage - HIGH RISK 58 | Purpose: [What this code does] 59 | 60 | ### Test Quality Issues 61 | - [Test File]: Only tests happy path 62 | - [Test File]: No error case testing 63 | - [Test File]: Weak assertions 64 | 65 | ### Missing Test Categories 66 | - Error boundary testing 67 | - Edge case validation 68 | - Performance regression tests 69 | 70 | ### Recommendations 71 | 1. Add tests for [critical function] 72 | 2. Improve branch coverage in [file] 73 | 3. Add negative test cases 74 | ``` -------------------------------------------------------------------------------- /.claude/knowledge/node-editor-performance-optimizations/CLAUDE.md: -------------------------------------------------------------------------------- 1 | # Node Editor Performance Optimizations Research 2 | 3 | ## Overview 4 | Deep analysis of CSS transform usage and rendering performance strategies across modern graph/canvas libraries. 5 | 6 | ## Files 7 | 8 | ### vue-flow-transform-analysis.md 9 | - **Library**: Vue Flow (https://github.com/bcakmakoglu/vue-flow) 10 | - **Research**: Analyzed Transform.vue, viewport handling, d3-zoom integration 11 | - **Key Finding**: Single viewport transform container pattern 12 | 13 | ### reactflow-transform-analysis.md 14 | - **Library**: React Flow (https://github.com/xyflow/xyflow) 15 | - **Research**: Examined Viewport/index.tsx, array-based transforms, portal rendering 16 | - **Key Finding**: Similar to Vue Flow but with React-specific optimizations 17 | 18 | ### tldraw-transform-analysis.md 19 | - **Library**: tldraw (https://github.com/tldraw/tldraw) 20 | - **Research**: Studied Mat.ts matrix class, individual shape transforms, LOD system 21 | - **Key Finding**: Individual shape transforms with sophisticated matrix math 22 | 23 | ### retejs-transform-analysis.md 24 | - **Library**: Rete.js (https://github.com/retejs/rete) 25 | - **Research**: Analyzed plugin architecture, area-plugin transforms, dual transform system 26 | - **Key Finding**: Framework-agnostic via plugins, dual transform pattern 27 | 28 | ### d3-in-node-editors.md 29 | - **Library**: D3.js zoom behavior analysis 30 | - **Research**: How Vue Flow and React Flow integrate d3-zoom for viewport management 31 | - **Key Finding**: Both use d3's transform interpolation and event handling 32 | 33 | ### flow-libraries-comparison.md 34 | - **Summary**: Comprehensive feature comparison matrix 35 | - **Categories**: Transform patterns, GPU hints, edge rendering, event handling, performance optimizations 36 | 37 | ## Research Method 38 | Each analysis involved: 39 | 1. Cloning the repository 40 | 2. Searching for transform/performance patterns 41 | 3. Reading core implementation files 42 | 4. Creating architecture diagrams 43 | 5. Identifying optimization opportunities 44 | 6. Second-pass analysis for missed details -------------------------------------------------------------------------------- /.claude/commands/validation/scan-api-contracts.md: -------------------------------------------------------------------------------- 1 | # Scan API Contracts 2 | 3 | I need to validate API contracts and consistency for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze API definitions, implementations, and usage for consistency and contract violations. 8 | 9 | ## Execution Steps 10 | 11 | 1. **API Definition Analysis** 12 | - Locate OpenAPI/Swagger specs 13 | - GraphQL schema definitions 14 | - TypeScript interfaces/types 15 | - API documentation 16 | - Postman collections 17 | 18 | 2. **Implementation Validation** 19 | - Response shapes match definitions 20 | - Required fields always present 21 | - Data types match specifications 22 | - Status codes used correctly 23 | - Error response consistency 24 | 25 | 3. **Client-Server Contract** 26 | - Request validation implementation 27 | - Response type safety 28 | - Missing error handling 29 | - Assumed optional fields 30 | - Version compatibility 31 | 32 | 4. **REST Best Practices** 33 | - Proper HTTP methods (GET not mutating) 34 | - RESTful resource naming 35 | - Consistent URL patterns 36 | - Proper status code usage 37 | - HATEOAS compliance (if applicable) 38 | 39 | 5. **Breaking Change Detection** 40 | - Removed endpoints 41 | - Changed field types 42 | - New required fields 43 | - Modified enums 44 | - Changed authentication 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## API Contract Analysis 50 | 51 | ### Contract Violations 52 | - [Endpoint]: Response missing required field 'X' 53 | - [Endpoint]: Returns 200 for errors (should be 4xx) 54 | 55 | ### Type Mismatches 56 | - [Field]: Defined as number, returns string 57 | - [Field]: Sometimes null, not marked optional 58 | 59 | ### Breaking Changes Detected 60 | - [Endpoint]: Field 'X' changed from string to number 61 | - [Endpoint]: New required field 'Y' added 62 | 63 | ### Best Practice Issues 64 | - GET /api/users/delete - Should use DELETE method 65 | - Inconsistent error response format 66 | 67 | ### Recommendations 68 | 1. Generate types from OpenAPI spec 69 | 2. Add runtime validation 70 | 3. Version the API properly 71 | ``` -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to Claude Code Prompt Library 2 | 3 | ## Guidelines for Adding New Commands 4 | 5 | ### Command Naming Convention 6 | - Use descriptive prefixes: `GH-`, `NOTION-`, `AGENT-`, `STUDY-`, `TEAM-` 7 | - Use kebab-case for multi-word commands 8 | - Be specific about the command's purpose 9 | 10 | ### Command Structure 11 | 1. **Title**: Clear H1 heading describing the command 12 | 2. **Context**: Brief explanation of when to use this command 13 | 3. **Instructions**: Step-by-step workflow using `` or similar tags 14 | 4. **Parameters**: Use `$ARGUMENTS` for user input 15 | 5. **Examples**: Include usage examples when helpful 16 | 17 | ### File Organization 18 | Commands should be placed in appropriate subdirectories: 19 | - `github/` - Git and GitHub-related commands 20 | - `notion/` - Notion workspace commands 21 | - `agents/` - Meta commands for creating/improving commands 22 | - `analysis/` - Repository and code analysis commands 23 | - `research/` - Study and learning commands 24 | - `team/` - Team collaboration and standup commands 25 | 26 | ### Testing New Commands 27 | Before submitting a new command: 28 | 1. Test the command in your local environment 29 | 2. Verify the `$ARGUMENTS` placeholder works correctly 30 | 3. Ensure the command follows existing patterns 31 | 4. Check that instructions are clear and actionable 32 | 33 | ### Code Review Process 34 | 1. Create a new branch for your command 35 | 2. Add the command file(s) 36 | 3. Update the README.md if adding a new category 37 | 4. Submit a pull request with a clear description 38 | 5. Wait for team review before merging 39 | 40 | ### Best Practices 41 | - Keep commands focused on a single responsibility 42 | - Use clear, actionable language 43 | - Include error handling guidance where appropriate 44 | - Reference the [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) 45 | 46 | ### Command Dependencies 47 | If your command relies on other commands or tools: 48 | - Document dependencies clearly 49 | - Test that required tools are available 50 | - Provide fallback instructions when possible -------------------------------------------------------------------------------- /.claude/commands/validation/scan-dead-code.md: -------------------------------------------------------------------------------- 1 | # Scan for Dead Code 2 | 3 | I need to identify unused code in: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Find unused functions, variables, imports, and files that can be safely removed. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Unused Imports** 12 | - Imported but never used 13 | - Entire modules imported for one function 14 | - Duplicate imports 15 | - Circular imports 16 | - Dev dependencies in production code 17 | 18 | 2. **Unused Functions/Methods** 19 | - Private methods never called 20 | - Public methods with no references 21 | - Utility functions not exported/used 22 | - Event handlers not attached 23 | - Lifecycle methods with no logic 24 | 25 | 3. **Unused Variables/Constants** 26 | - Declared but never read 27 | - Written but never read 28 | - Function parameters unused 29 | - Destructured properties unused 30 | - Global variables unreferenced 31 | 32 | 4. **Unused Components/Modules** 33 | - React components not imported 34 | - Entire files unreferenced 35 | - Styles/CSS not applied 36 | - Assets not used 37 | - Config files orphaned 38 | 39 | 5. **Feature Flag Cleanup** 40 | - Flags always true/false 41 | - Old experiment code 42 | - Commented code blocks 43 | - Debug/test code in production 44 | - Deprecated API versions 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Dead Code Analysis 50 | 51 | ### Unused Imports (Safe to Remove) 52 | - [File]: import { X } - never used 53 | - [File]: import Y - available in global 54 | 55 | ### Unused Functions 56 | - [Function]: No references found 57 | Location: [File:Line] 58 | Size: X lines 59 | 60 | ### Unused Files 61 | - [FilePath]: No imports found 62 | Size: X KB 63 | Last modified: [Date] 64 | 65 | ### Commented Code 66 | - [File:Line]: Large commented block 67 | Suggestion: Remove or document why kept 68 | 69 | ### Savings Summary 70 | - Files: X files (Y KB) 71 | - Functions: A functions (B lines) 72 | - Imports: C imports 73 | 74 | ### Recommendations 75 | 1. Run tree-shaking build 76 | 2. Remove unused files 77 | 3. Clean up old feature flags 78 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/scan-bundle-size.md: -------------------------------------------------------------------------------- 1 | # Scan Bundle Size 2 | 3 | I need to analyze bundle size and optimization opportunities for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze JavaScript/CSS bundle sizes, identify bloat, and find optimization opportunities. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Bundle Composition** 12 | - Total bundle size (raw/gzipped) 13 | - Number of chunks 14 | - Entry point sizes 15 | - Vendor vs application code ratio 16 | - CSS bundle sizes 17 | 18 | 2. **Large Dependencies** 19 | - Top 10 largest dependencies 20 | - Duplicate packages (different versions) 21 | - Development dependencies in bundle 22 | - Unused exports from packages 23 | - Alternative lighter packages 24 | 25 | 3. **Code Splitting Analysis** 26 | - Missing lazy loading opportunities 27 | - Large synchronous imports 28 | - Route-based splitting potential 29 | - Shared chunks efficiency 30 | - Dynamic import usage 31 | 32 | 4. **Asset Optimization** 33 | - Unoptimized images 34 | - Large font files 35 | - Uncompressed assets 36 | - Missing modern formats (WebP, AVIF) 37 | - Inline vs external resources 38 | 39 | 5. **Build Configuration** 40 | - Tree shaking effectiveness 41 | - Minification settings 42 | - Source map inclusion 43 | - Compression (gzip/brotli) 44 | - Modern vs legacy bundles 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Bundle Size Analysis 50 | 51 | ### Bundle Overview 52 | - Total Size: X MB (Y MB gzipped) 53 | - JS: A MB | CSS: B MB | Assets: C MB 54 | - Initial Load: D MB 55 | 56 | ### Largest Dependencies 57 | 1. [package]: X KB - Consider [alternative] 58 | 2. [package]: Y KB - Only using 10% 59 | 60 | ### Optimization Opportunities 61 | - Enable code splitting: Save ~X KB 62 | - Lazy load [component]: Save ~Y KB 63 | - Replace [package] with [lighter]: Save ~Z KB 64 | 65 | ### Quick Wins 66 | - Remove unused CSS: ~30% reduction 67 | - Optimize images: ~2MB savings 68 | - Enable compression: ~70% reduction 69 | 70 | ### Build Recommendations 71 | 1. Configure webpack SplitChunksPlugin 72 | 2. Add bundle analyzer plugin 73 | 3. Set up progressive loading 74 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/validate-basic-security.md: -------------------------------------------------------------------------------- 1 | # Basic Security Validation 2 | 3 | I need to check for basic security issues in: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Perform a lightweight security scan focusing on common, easily-fixable security issues. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Scan for Hardcoded Secrets** 12 | - API keys, tokens, passwords in code 13 | - Connection strings with credentials 14 | - Private keys or certificates 15 | - AWS/cloud credentials 16 | 17 | 2. **Check Common Vulnerabilities** 18 | - SQL injection risks (string concatenation in queries) 19 | - Command injection (exec/system calls with user input) 20 | - Path traversal vulnerabilities 21 | - Unvalidated redirects 22 | 23 | 3. **Review Authentication Patterns** 24 | - Passwords stored in plain text 25 | - Weak hashing algorithms (MD5, SHA1) 26 | - Missing authentication on sensitive endpoints 27 | - Session management issues 28 | 29 | 4. **Configuration Security** 30 | - Debug mode enabled in production configs 31 | - Exposed admin interfaces 32 | - Default credentials 33 | - Overly permissive CORS settings 34 | 35 | 5. **Quick Wins** 36 | - Files that shouldn't be committed (.env, config with secrets) 37 | - Exposed sensitive endpoints 38 | - Missing input validation 39 | - Console.log with sensitive data 40 | 41 | ## Report Format 42 | 43 | ``` 44 | ## Security Scan Results 45 | 46 | ### Critical - Fix Immediately 47 | - [Issue]: [File:Line] - [Impact] 48 | Fix: [Specific remediation] 49 | 50 | ### Important - Fix Soon 51 | - [Issue]: [File:Line] - [Impact] 52 | Fix: [Specific remediation] 53 | 54 | ### Consider Fixing 55 | - [Issue]: [File:Line] - [Impact] 56 | Fix: [Specific remediation] 57 | 58 | ### Summary 59 | - Total issues found: X 60 | - Critical issues: Y 61 | - Files scanned: Z 62 | ``` 63 | 64 | ## Important Notes 65 | 66 | - Focus on practical, fixable issues 67 | - Don't overwhelm with theoretical vulnerabilities 68 | - Provide clear, actionable fixes 69 | - Skip complex security analysis that requires specialized tools 70 | - If secrets are found, note them but don't display the actual values -------------------------------------------------------------------------------- /.claude/commands/validation/scan-error-handling.md: -------------------------------------------------------------------------------- 1 | # Scan Error Handling 2 | 3 | I need to analyze error handling patterns in: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Evaluate error handling completeness, consistency, and recovery strategies. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Missing Error Handling** 12 | - Unhandled promise rejections 13 | - Missing try-catch blocks 14 | - Uncaught async errors 15 | - Network calls without error handling 16 | - File operations without checks 17 | 18 | 2. **Poor Error Patterns** 19 | - Catching and ignoring errors 20 | - Generic catch blocks 21 | - No error logging 22 | - Missing error context 23 | - Swallowing specific errors 24 | 25 | 3. **User Experience** 26 | - Generic error messages 27 | - No fallback UI/components 28 | - Missing loading states 29 | - No retry mechanisms 30 | - Poor error boundaries (React) 31 | 32 | 4. **Error Recovery** 33 | - No graceful degradation 34 | - Missing rollback logic 35 | - No circuit breakers 36 | - Cascading failures 37 | - Resource cleanup missing 38 | 39 | 5. **Monitoring Gaps** 40 | - Errors not reported 41 | - Missing error metadata 42 | - No error categorization 43 | - Performance impact not tracked 44 | - No alerting configuration 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Error Handling Analysis 50 | 51 | ### Critical Gaps 52 | - [File:Line]: Async operation with no error handling 53 | Risk: App crash on network failure 54 | Fix: Add try-catch with user feedback 55 | 56 | ### Poor Patterns 57 | - [File:Line]: catch(e) {} - Error swallowed 58 | Fix: Log error and handle appropriately 59 | 60 | ### User Experience Issues 61 | - [Component]: No error boundary 62 | Impact: Entire app crashes on error 63 | Fix: Add ErrorBoundary component 64 | 65 | ### Missing Recovery 66 | - [Operation]: No retry logic 67 | Fix: Add exponential backoff retry 68 | 69 | ### Monitoring Gaps 70 | - X% of errors not logged 71 | - No error reporting service configured 72 | 73 | ### Recommendations 74 | 1. Implement global error handler 75 | 2. Add error boundaries to key components 76 | 3. Standardize error messages 77 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/scan-memory-leaks.md: -------------------------------------------------------------------------------- 1 | # Scan for Memory Leaks 2 | 3 | I need to identify potential memory leaks in: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Detect patterns that commonly cause memory leaks in JavaScript/TypeScript applications. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Event Listener Leaks** 12 | - addEventListener without removeEventListener 13 | - Global event handlers 14 | - Window/document listeners in components 15 | - WebSocket listeners not cleaned 16 | - Observer patterns without unsubscribe 17 | 18 | 2. **React/Vue Memory Leaks** 19 | - Missing cleanup in useEffect 20 | - Timers not cleared 21 | - Subscriptions not unsubscribed 22 | - Refs holding large objects 23 | - Closures capturing components 24 | 25 | 3. **DOM Reference Leaks** 26 | - Detached DOM nodes kept in memory 27 | - Large data in data attributes 28 | - Global references to DOM elements 29 | - jQuery handlers not removed 30 | - Cached query selectors 31 | 32 | 4. **Data Structure Leaks** 33 | - Unbounded caches/maps 34 | - Circular references 35 | - Large arrays never cleared 36 | - Global state accumulation 37 | - Console.log keeping references 38 | 39 | 5. **Async Operation Leaks** 40 | - Promises never settling 41 | - Uncancelled requests 42 | - Long polling without cleanup 43 | - Worker threads not terminated 44 | - Open connections not closed 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Memory Leak Analysis 50 | 51 | ### High Risk Patterns 52 | - [Component]: Timer not cleared in cleanup 53 | Location: [File:Line] 54 | Fix: Clear timer in cleanup function 55 | 56 | ### Event Listener Leaks 57 | - [File:Line]: Global listener never removed 58 | Fix: Store reference and remove on cleanup 59 | 60 | ### React-Specific Issues 61 | - [Component]: Missing useEffect cleanup 62 | Impact: Subscription leak on unmount 63 | Fix: Return cleanup function 64 | 65 | ### Data Structure Issues 66 | - [Cache]: Unbounded growth detected 67 | Fix: Implement LRU eviction 68 | 69 | ### Quick Fixes 70 | 1. Add cleanup to X components 71 | 2. Implement WeakMap for Y cache 72 | 3. Clear intervals in Z locations 73 | ``` -------------------------------------------------------------------------------- /.claude/commands/validation/validate-code-quality.md: -------------------------------------------------------------------------------- 1 | # Validate Code Quality 2 | 3 | I need to analyze code quality metrics for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Perform a comprehensive code quality analysis focusing on maintainability, complexity, and best practices. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Identify Target Files** 12 | - Parse $ARGUMENTS to determine which files/directories to analyze 13 | - If no specific files provided, analyze the current working directory 14 | - Focus on source code files (exclude node_modules, vendor, etc.) 15 | 16 | 2. **Analyze Code Complexity** 17 | - Check cyclomatic complexity (should be < 10 per function) 18 | - Measure nesting depth (should be < 4 levels) 19 | - Count function/method length (should be < 50 lines) 20 | - Identify long parameter lists (> 5 parameters) 21 | 22 | 3. **Check for Code Smells** 23 | - Duplicate code blocks 24 | - Dead code or unused variables 25 | - Large classes or God objects 26 | - Feature envy (methods using other class data excessively) 27 | - Long method chains 28 | 29 | 4. **Performance Patterns** 30 | - Look for O(n²) or worse algorithms 31 | - Identify N+1 query patterns 32 | - Check for inefficient loops or iterations 33 | - Memory leak potentials 34 | 35 | 5. **Generate Report** 36 | - Summarize findings by severity 37 | - Provide specific line numbers and examples 38 | - Suggest refactoring approaches 39 | - Prioritize issues by impact 40 | 41 | ## Report Format 42 | 43 | ``` 44 | ## Code Quality Analysis 45 | 46 | ### Critical Issues 47 | - [Issue]: [File:Line] - [Description] 48 | 49 | ### High Priority 50 | - [Issue]: [File:Line] - [Description] 51 | 52 | ### Medium Priority 53 | - [Issue]: [File:Line] - [Description] 54 | 55 | ### Metrics Summary 56 | - Total Complexity Score: X 57 | - Average Function Length: Y lines 58 | - Duplication Percentage: Z% 59 | ``` 60 | 61 | ## Important Notes 62 | 63 | - Focus on actionable issues, not style preferences 64 | - Consider the project's existing patterns before suggesting changes 65 | - Provide concrete examples of how to fix issues 66 | - If analyzing a large codebase, sample representative files -------------------------------------------------------------------------------- /.claude/commands/validation/scan-type-safety.md: -------------------------------------------------------------------------------- 1 | # Scan Type Safety Issues 2 | 3 | I need to check type safety for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze TypeScript/type annotations for type safety issues, any types, and weak typing. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Type Coverage Analysis** 12 | - Percentage of typed vs untyped code 13 | - Files missing type definitions 14 | - Functions without return types 15 | - Untyped function parameters 16 | - Missing interface definitions 17 | 18 | 2. **Dangerous Type Patterns** 19 | - Usage of 'any' type 20 | - Type assertions (as) without validation 21 | - @ts-ignore or @ts-nocheck comments 22 | - Implicit any from missing types 23 | - Unsafe type narrowing 24 | 25 | 3. **Type Inconsistencies** 26 | - Mismatched types across files 27 | - Inconsistent interface definitions 28 | - Optional vs required confusion 29 | - Union type misuse 30 | - Generic type issues 31 | 32 | 4. **Runtime Type Safety** 33 | - Missing runtime validation 34 | - Type guards not used 35 | - External data not validated 36 | - JSON parsing without validation 37 | - API responses not typed 38 | 39 | 5. **Common Type Bugs** 40 | - Null/undefined not handled 41 | - Array access without bounds check 42 | - Object property access on possibly null 43 | - Incorrect type in catch blocks 44 | - Event handler type mismatches 45 | 46 | ## Report Format 47 | 48 | ``` 49 | ## Type Safety Analysis 50 | 51 | ### Type Coverage 52 | - Overall: X% typed 53 | - Files with no types: Y 54 | - Functions missing types: Z 55 | 56 | ### Critical Type Issues 57 | - [File:Line]: Using 'any' type 58 | Context: [Why this is risky] 59 | Fix: Use specific type or unknown 60 | 61 | ### Type Safety Violations 62 | - [File:Line]: Unsafe type assertion 63 | Risk: Runtime error if wrong type 64 | Fix: Add type guard 65 | 66 | ### Missing Validations 67 | - [API Call]: No runtime validation 68 | Risk: Crash on unexpected data 69 | Fix: Add zod/joi validation 70 | 71 | ### Recommendations 72 | 1. Enable strict mode in tsconfig 73 | 2. Replace 'any' with specific types 74 | 3. Add runtime validation for external data 75 | ``` -------------------------------------------------------------------------------- /.claude/commands/development/use-command-template.md: -------------------------------------------------------------------------------- 1 | # Use Command Template 2 | 3 | I need to create a new command using the standard template for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Create a new Claude Code command following our established patterns and templates. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Determine Command Type** 12 | - Parse command purpose from $ARGUMENTS 13 | - Identify appropriate category (analysis/development/quality/etc) 14 | - Choose suitable command name (verb-noun format) 15 | 16 | 2. **Apply Template** 17 | - Start with base template from ~/.claude/templates/command-template.md 18 | - Customize sections for specific command purpose 19 | - Ensure all required sections are included 20 | - Add command-specific flags if needed 21 | 22 | 3. **Configure Integration** 23 | - Check ~/.claude/config/command-patterns.yml for workflow placement 24 | - Identify prerequisite commands 25 | - Define what context this command produces 26 | - Add to appropriate workflow chains 27 | 28 | 4. **Create Command File** 29 | - Determine correct folder based on category 30 | - Create .md file with command content 31 | - Verify @include references work correctly 32 | - Test with example usage 33 | 34 | ## Template Structure 35 | 36 | The standard template includes: 37 | - Purpose (single sentence) 38 | - Task description with $ARGUMENTS 39 | - Phased execution steps 40 | - Context preservation rules 41 | - Expected output format 42 | - Integration guidance 43 | 44 | ## Best Practices 45 | 46 | - Keep commands focused on a single responsibility 47 | - Use clear verb-noun naming (analyze-dependencies, create-component) 48 | - Include at least 3 example usages 49 | - Define what gets cached for reuse 50 | - Specify prerequisite and follow-up commands 51 | 52 | ## Example Usage 53 | 54 | ```bash 55 | # Create a new analysis command 56 | /development:use-command-template analyze API endpoints for rate limiting needs 57 | 58 | # Create a new validation command 59 | /development:use-command-template validate database migrations for safety 60 | 61 | # Create a new generation command 62 | /development:use-command-template generate TypeScript types from API schema 63 | ``` -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-frontend/file-path-annotations.md: -------------------------------------------------------------------------------- 1 | # ComfyUI File Path Annotations 2 | 3 | ## Temporary File Annotation Pattern 4 | 5 | ComfyUI uses a special annotation pattern in file paths to indicate temporary files that are part of the workflow execution: 6 | 7 | ### Format 8 | ``` 9 | {subfolder}/{filename} [temp] 10 | ``` 11 | 12 | ### Examples 13 | - `audio/recording-123.wav [temp]` 14 | - `webcam/capture-456.png [temp]` 15 | - `threed/render-789.png [temp]` 16 | 17 | ### Key Points 18 | 19 | 1. **Dual-Purpose System**: The `[temp]` annotation works alongside the upload API's `type` parameter: 20 | ```typescript 21 | // Upload API parameter 22 | body.append('type', 'temp') 23 | 24 | // File path annotation 25 | return `audio/${tempAudio.name} [temp]` 26 | ``` 27 | 28 | 2. **UI Indication**: The `[temp]` annotation tells the frontend this is a temporary file that should be handled differently from regular input files during workflow serialization and execution. 29 | 30 | 3. **Consistent Pattern**: Used across different node types: 31 | - Audio recording nodes: `audio/${name} [temp]` 32 | - Webcam capture nodes: `webcam/${name} [temp]` 33 | - 3D rendering nodes: `threed/${name} [temp]` 34 | 35 | 4. **Workflow Serialization**: These annotated paths are included when workflows are saved/loaded, allowing the system to distinguish between permanent assets and temporary captures. 36 | 37 | ### Implementation Example 38 | 39 | From the audio recording implementation: 40 | ```typescript 41 | const convertBlobToFileAndSubmit = async (blob: Blob): Promise => { 42 | const name = `recording-${Date.now()}.wav` 43 | const file = new File([blob], name, { type: blob.type || 'audio/wav' }) 44 | 45 | const body = new FormData() 46 | body.append('image', file) 47 | body.append('subfolder', 'audio') 48 | body.append('type', 'temp') // Backend storage type 49 | 50 | const resp = await api.fetchApi('/upload/image', { 51 | method: 'POST', 52 | body 53 | }) 54 | 55 | const tempAudio = await resp.json() 56 | return `audio/${tempAudio.name} [temp]` // Frontend annotation 57 | } 58 | ``` 59 | 60 | This pattern ensures proper handling of temporary files throughout the ComfyUI workflow lifecycle. -------------------------------------------------------------------------------- /.claude/commands/research/research-with-auto-mcp.md: -------------------------------------------------------------------------------- 1 | # Smart Research with MCP Auto-Detection 2 | 3 | You want me to research: $ARGUMENTS 4 | 5 | ## Auto-Detection Strategy 6 | 7 | I'll analyze your request and automatically use the most relevant MCPs: 8 | 9 | **Library/Framework Research:** 10 | - **If your request contains library/framework names** → Use Context7 MCP for official docs 11 | - **If you need deep technical documentation** → Use mcp-deepwiki for comprehensive info 12 | - **If you mention books or publications** → Use open-library MCP for references 13 | 14 | **API & Integration:** 15 | - **If you mention "API" or "OpenAPI"** → Check reapi-mcp-openapi for existing specs 16 | - **If you mention "Supabase" or database** → Use Supabase MCP for project data 17 | 18 | **Design & UI:** 19 | - **If you mention "design", "UI", or "mockup"** → Use Figma MCP for design system patterns 20 | 21 | **Testing & Automation:** 22 | - **If you mention "testing", "E2E", or "automation"** → Use Playwright MCP for browser testing 23 | - **If you need browser interaction** → Use browser-tools MCP for web automation 24 | 25 | **Documentation & Knowledge:** 26 | - **If you mention "Notion" or "documentation"** → Use Notion API MCP for team knowledge 27 | - **If you mention "Slack" or "team communication"** → Use Slack MCP for team context 28 | - **If you have complex documents to parse** → Use markitdown MCP for conversion 29 | 30 | **Media & Content:** 31 | - **If you mention "YouTube" or "video transcript"** → Use youtube-transcript MCP 32 | - **If you mention "marketing" or "strategy"** → Use osp_marketing_tools MCP 33 | 34 | ## Research Process 35 | 36 | 1. **Primary Research**: Use the most relevant MCP based on auto-detection 37 | 2. **Cross-Reference**: Use additional MCPs if the topic spans multiple areas 38 | 3. **Verification**: Cross-check findings across sources 39 | 4. **Documentation**: Provide clear citations and confidence levels 40 | 41 | ## Evidence Requirements 42 | 43 | Every response will include: 44 | - **Source**: Which MCP(s) provided the information 45 | - **Confidence**: How certain I am about the recommendation (0-100%) 46 | - **Alternatives**: Other approaches I considered 47 | - **Next Steps**: Specific actions you can take 48 | 49 | Let me start by analyzing your request for relevant patterns... -------------------------------------------------------------------------------- /.claude/commands/validation/scan-index.md: -------------------------------------------------------------------------------- 1 | # Validation & Scanning Commands Index 2 | 3 | I need to help you choose the right validation scan for: $ARGUMENTS 4 | 5 | ## Available Scanning Commands 6 | 7 | ### Security & Safety 8 | - **validate-basic-security** - Quick scan for common security issues (secrets, injections, auth) 9 | - **scan-configuration** - Validate config files for security and consistency 10 | 11 | ### Code Quality 12 | - **validate-code-quality** - Analyze complexity, code smells, and maintainability 13 | - **scan-performance** - Find performance bottlenecks and inefficient patterns 14 | - **scan-type-safety** - Check TypeScript typing coverage and safety 15 | - **scan-dead-code** - Identify unused code that can be removed 16 | - **scan-error-handling** - Evaluate error handling completeness 17 | 18 | ### Dependencies & Build 19 | - **validate-dependencies** - Audit packages for vulnerabilities and updates 20 | - **scan-bundle-size** - Analyze bundle size and optimization opportunities 21 | - **scan-circular-dependencies** - Detect circular dependency chains 22 | 23 | ### Testing & Coverage 24 | - **scan-test-coverage** - Analyze test coverage and quality 25 | - **scan-api-contracts** - Validate API contracts and consistency 26 | 27 | ### Frontend Specific 28 | - **scan-accessibility** - Check WCAG compliance and a11y best practices 29 | - **scan-memory-leaks** - Detect potential memory leak patterns 30 | 31 | ## Quick Selection Guide 32 | 33 | **"I need a general health check"** 34 | → Run: validate-code-quality, validate-dependencies, scan-test-coverage 35 | 36 | **"Preparing for production"** 37 | → Run: validate-basic-security, scan-configuration, scan-bundle-size 38 | 39 | **"Performance issues"** 40 | → Run: scan-performance, scan-memory-leaks, scan-bundle-size 41 | 42 | **"Code cleanup"** 43 | → Run: scan-dead-code, scan-circular-dependencies, validate-code-quality 44 | 45 | **"Security audit"** 46 | → Run: validate-basic-security, validate-dependencies, scan-configuration 47 | 48 | ## Usage Examples 49 | 50 | ```bash 51 | # Scan entire project 52 | /validation:validate-code-quality . 53 | 54 | # Scan specific directory 55 | /validation:scan-performance src/components 56 | 57 | # Multiple scans 58 | /validation:validate-basic-security && /validation:scan-test-coverage 59 | ``` 60 | 61 | Would you like me to run a specific scan or combination of scans? -------------------------------------------------------------------------------- /.claude/knowledge/claude-code-best-practices/00-overview.md: -------------------------------------------------------------------------------- 1 | # Claude Code Command Creation Overview 2 | 3 | ## Purpose 4 | 5 | This guide helps you create effective Claude Code commands - stored prompt templates in Markdown files within the `.claude/commands` folder. Custom slash commands can include the special keyword `$ARGUMENTS` to pass parameters from command invocation. 6 | 7 | ## Basic Example 8 | 9 | **Example:** Putting content into `.claude/commands/fix-github-issue.md` makes it available as the `/project:fix-github-issue` command. You could then use `/project:fix-github-issue 1234` to have Claude fix issue #1234. 10 | 11 | ### Basic Command Structure 12 | 13 | ```md 14 | Please analyze and fix the GitHub issue: $ARGUMENTS. 15 | 16 | Follow these steps: 17 | 18 | 1. Use `gh issue view` to get the issue details 19 | 2. Understand the problem described in the issue 20 | 3. Search the codebase for relevant files 21 | 4. Implement the necessary changes to fix the issue 22 | 5. Write and run tests to verify the fix 23 | 6. Ensure code passes linting and type checking 24 | 7. Create a descriptive commit message 25 | 8. Push and create a PR 26 | 27 | Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks. 28 | ``` 29 | 30 | ## Command Locations 31 | 32 | You can add commands to: 33 | - `.claude/commands/` folder for project-specific commands 34 | - `~/.claude/commands` folder for personal commands available in all sessions 35 | 36 | ## Task Structure 37 | 38 | When given a task to create a new Claude Code command, follow this process: 39 | 40 | ```xml 41 | 42 | I want to create a new Claude Code command for the following task: $ARGUMENTS. 43 | 44 | ``` 45 | 46 | ## Key Principles 47 | 48 | 1. **Be Direct** - Think of Claude as a brilliant but very new employee who needs explicit instructions 49 | 2. **Use Examples** - Provide 3-5 diverse, relevant examples to show Claude exactly what you want 50 | 3. **Structure with XML** - Use tags like ``, ``, and `` to organize prompts 51 | 4. **Enable Thinking** - Allow Claude to work through complex problems step by step 52 | 5. **Give Claude a Role** - Use system prompts to set context and expertise level 53 | 6. **Chain for Complexity** - Break complex tasks into smaller, manageable subtasks 54 | 7. **Evaluate and Iterate** - Build test suites to measure and improve prompt performance -------------------------------------------------------------------------------- /.claude/knowledge/comfy-claude-prompt-library/README.md: -------------------------------------------------------------------------------- 1 | # Comfy Claude Prompt Library Knowledge Base 2 | 3 | This knowledge folder contains comprehensive documentation about the Claude Code command library architecture, patterns, and development guidelines. 4 | 5 | ## Knowledge Files 6 | 7 | ### Core Architecture 8 | - [`command-architecture.md`](./command-architecture.md) - Command structure, patterns, and design principles 9 | - [`meta-command-system.md`](./meta-command-system.md) - Self-improving command architecture and workflows 10 | - [`workflow-patterns.md`](./workflow-patterns.md) - Command chains, context sharing, and automation patterns 11 | 12 | ### Development Guidelines 13 | - [`development-standards.md`](./development-standards.md) - Code quality, naming conventions, and best practices 14 | - [`memory-integration.md`](./memory-integration.md) - Semantic memory system and conversation continuity 15 | - [`context-estimation.md`](./context-estimation.md) - Token management and Gemini CLI integration 16 | 17 | ### Command Categories 18 | - [`command-categories.md`](./command-categories.md) - Complete catalog of available command types and their purposes 19 | - [`validation-framework.md`](./validation-framework.md) - Quality assurance and security scanning tools 20 | - [`github-automation.md`](./github-automation.md) - Git workflows, PR management, and issue handling 21 | 22 | ### Integration Patterns 23 | - [`external-tools.md`](./external-tools.md) - GitHub CLI, Gemini CLI, and dependency management 24 | - [`ci-cd-patterns.md`](./ci-cd-patterns.md) - Automated validation and documentation checks 25 | - [`repository-analysis.md`](./repository-analysis.md) - Automated documentation generation system 26 | 27 | ## Usage 28 | 29 | These knowledge files are designed to be consumed by: 30 | 31 | 1. **Claude Code agents** for understanding repository patterns 32 | 2. **Command development** for maintaining consistency 33 | 3. **New contributors** for onboarding and context 34 | 4. **Meta-commands** for self-improvement and validation 35 | 36 | ## Quick Reference 37 | 38 | - **Command Template**: See `command-architecture.md` for standard structure 39 | - **Naming Conventions**: Check `development-standards.md` for prefixes and formats 40 | - **Workflow Automation**: Reference `workflow-patterns.md` for chaining commands 41 | - **Quality Standards**: Use `validation-framework.md` for scanning and checks -------------------------------------------------------------------------------- /.claude/commands/validation/validate-dependencies.md: -------------------------------------------------------------------------------- 1 | # Validate Dependencies 2 | 3 | I need to audit dependencies for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze project dependencies for vulnerabilities, outdated packages, and licensing issues. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Locate Package Files** 12 | - Check for package.json (Node.js) 13 | - Check for requirements.txt, Pipfile, pyproject.toml (Python) 14 | - Check for Cargo.toml (Rust) 15 | - Check for go.mod (Go) 16 | - Check for composer.json (PHP) 17 | 18 | 2. **Analyze Direct Dependencies** 19 | - List all direct dependencies with current versions 20 | - Check against latest stable versions 21 | - Identify deprecated packages 22 | - Note packages that haven't been updated in >2 years 23 | 24 | 3. **Security Vulnerability Check** 25 | - Check for known CVEs in dependencies 26 | - Identify packages with security advisories 27 | - Look for packages using outdated crypto or auth methods 28 | - Check npm audit, pip-audit, or equivalent 29 | 30 | 4. **License Compliance** 31 | - Identify all dependency licenses 32 | - Flag GPL/AGPL in commercial projects 33 | - Check for license compatibility issues 34 | - Identify packages with no clear license 35 | 36 | 5. **Dependency Health Analysis** 37 | - Check download stats/popularity 38 | - Review maintenance status 39 | - Analyze transitive dependency depth 40 | - Identify single points of failure 41 | 42 | ## Report Format 43 | 44 | ``` 45 | ## Dependency Audit Report 46 | 47 | ### Security Vulnerabilities 48 | - [Package@Version]: [CVE-ID] - [Description] 49 | Fix: Update to version X.Y.Z 50 | 51 | ### Outdated Packages 52 | - [Package]: Current: X.Y.Z → Latest: A.B.C 53 | Breaking changes: [Yes/No] 54 | 55 | ### License Issues 56 | - [Package]: [License Type] - [Potential Issue] 57 | 58 | ### Maintenance Concerns 59 | - [Package]: Last updated [Date] - [Concern] 60 | 61 | ### Recommendations 62 | 1. Immediate updates needed for security 63 | 2. Consider replacing unmaintained packages 64 | 3. Review license compliance 65 | ``` 66 | 67 | ## Important Notes 68 | 69 | - Prioritize security vulnerabilities as Critical 70 | - Consider the stability of the project before suggesting major updates 71 | - Check if updates have breaking changes 72 | - For monorepos, analyze each package separately 73 | - Include both production and development dependencies in the analysis -------------------------------------------------------------------------------- /.claude/commands/github/GH-create-github-issue.md: -------------------------------------------------------------------------------- 1 | # Create GitHub Issue with Research 2 | 3 | For this task: $ARGUMENTS 4 | 5 | ## Research Phase 6 | 7 | 1. **Read Issue Templates** 8 | - Check if repo exists locally first, otherwise fetch it 9 | - Read templates in .github/ISSUE_TEMPLATE/ or .github/ folder 10 | - Note required fields, formatting guidelines, and labels 11 | 12 | 2. **Read Core Documentation:** 13 | - https://deepwiki.com/comfyanonymous/ComfyUI (core ComfyUI) 14 | - https://deepwiki.com/Comfy-Org/ComfyUI_frontend (frontend architecture) 15 | - https://deepwiki.com/Comfy-Org/ComfyUI-Manager (custom node manager) 16 | - https://deepwiki.com/Comfy-Org/litegraph.js (graph canvas system) 17 | - ~/projects/comfy-testing-environment/ 18 | - ~/projects/comfyui-frontend-testing/ 19 | - ~/projects/comfyui-frontend-testing/docs/ 20 | 21 | 3. **Read Repository Documentation** 22 | - Look for deepwikis, CONTRIBUTING.md, or other relevant docs 23 | - Understand the project's issue reporting standards 24 | 25 | 4. **Analyze Existing Issues** 26 | - Use `gh issue list` and `gh api` to query similar issues 27 | - Study formatting, etiquette, and common patterns 28 | - Check for duplicates or related discussions 29 | 30 | 5. **Review Commit History** 31 | - Search commits related to the feature/bug area 32 | - Understand recent changes that might be relevant 33 | 34 | ## Visual Documentation (if needed) 35 | 36 | If screenshots would help illustrate the issue: 37 | - Tell me to start ComfyUI in a separate process 38 | - Once I confirm it's running, navigate to localhost:8188 39 | - Take relevant screenshots of the issue/feature request 40 | 41 | For design specifications or visual details: 42 | - Visit Figma: https://www.figma.com/files/team/1359619007376639842/recents-and-sharing?fuid=1462318000816924530 43 | - Capture any relevant design elements 44 | 45 | ## Create the Issue 46 | 47 | Using all gathered information: 48 | 1. Draft issue following the template and standards discovered 49 | 2. Include relevant context, screenshots, and references 50 | 3. Apply appropriate labels and metadata 51 | 4. Use `gh issue create` to submit 52 | 53 | Remember to: 54 | - Be concise but thorough 55 | - Follow the project's contribution guidelines 56 | - Reference related issues/PRs where applicable 57 | - Use clear, descriptive title 58 | - Include reproduction steps for bugs 59 | - Specify expected vs actual behavior -------------------------------------------------------------------------------- /.claude/commands/github/GH-rebase-onto.md: -------------------------------------------------------------------------------- 1 | Rebase the current branch onto the target branch: $ARGUMENTS 2 | 3 | 4 | 1. First, check the current git status and branch to understand the starting state 5 | 2. Fetch the latest changes to ensure we have up-to-date refs 6 | 3. Attempt to rebase the current branch onto $ARGUMENTS 7 | 4. If the rebase completes successfully, report the result 8 | 5. If there are merge conflicts: 9 | - Stop the rebase process immediately (don't abort the rebase, just pause what you're doing) 10 | - List all conflicted files clearly 11 | - Provide specific instructions for manual resolution 12 | - Wait for user confirmation before proceeding 13 | 1. After user confirms conflicts are resolved, continue the rebase 14 | 2. Report the final status 15 | 16 | 17 | 18 | **Step 1: Check current state** 19 | - Run `git status` to see current branch and any uncommitted changes 20 | - Run `git branch` to confirm which branch we're on 21 | 22 | **Step 2: Fetch latest changes** 23 | - Run `git fetch --all` to ensure we have the latest refs 24 | 25 | **Step 3: Attempt rebase** 26 | - Run `git rebase $ARGUMENTS` 27 | - Monitor the output carefully for conflict indicators 28 | 29 | **Step 4: Handle conflicts** 30 | If conflicts occur: 31 | - Run `git status` to see which files have conflicts 32 | - List each conflicted file with a clear explanation 33 | - Tell the user: "I've stopped the rebase due to conflicts. Please resolve them manually using your preferred editor/tool, then tell me when you're ready to continue." 34 | - Do NOT attempt to resolve conflicts automatically 35 | - Wait for explicit user confirmation to proceed 36 | 37 | **Step 5: Continue after manual resolution** 38 | When user says they're done: 39 | - Run `git add .` to stage resolved files 40 | - Run `git rebase --continue` to proceed 41 | - Handle any additional conflicts that may arise by repeating the process 42 | 43 | **Step 6: Final verification** 44 | - Run `git status` to confirm the rebase completed successfully 45 | - Report the final branch state and any relevant information 46 | 47 | 48 | 49 | - Never automatically resolve merge conflicts 50 | - Always stop and alert the user about conflicts before proceeding 51 | - Preserve user work by being conservative with git operations 52 | - If anything seems wrong, stop and ask for clarification 53 | 54 | 55 | Remember: The goal is to safely rebase onto $ARGUMENTS while giving the user full control over conflict resolution. -------------------------------------------------------------------------------- /.claude/commands/system/memory-health-check.md: -------------------------------------------------------------------------------- 1 | # Memory System Health Check 2 | 3 | You are performing a comprehensive health check on the semantic memory system. 4 | 5 | ## Tasks to Complete 6 | 7 | 1. **Check Database Status** 8 | - Verify ChromaDB is accessible at `[path-to-claude-code-vector-memory]/chroma_db/` 9 | - Count total indexed summaries 10 | - Check for any corrupted entries 11 | 12 | 2. **Analyze Summary Coverage** 13 | - List all summaries in `~/.claude/compacted-summaries/` 14 | - Identify which summaries are indexed vs not indexed 15 | - Check for summaries missing metadata 16 | 17 | 3. **Test Search Quality** 18 | - Run test searches for common terms 19 | - Verify similarity scores are reasonable (0.5-1.0 range) 20 | - Check that recent summaries rank higher 21 | 22 | 4. **Metadata Quality Report** 23 | - Count summaries with/without: 24 | - Titles 25 | - Semantic descriptions 26 | - Date information 27 | - Technology tags 28 | - Identify summaries that need metadata improvement 29 | 30 | 5. **Performance Metrics** 31 | - Measure average search time 32 | - Check database size 33 | - Verify embedding model is loaded correctly 34 | 35 | 6. **Recommendations** 36 | - Suggest which summaries should be re-indexed 37 | - Identify missing metadata that should be added 38 | - Recommend search terms that might not work well 39 | 40 | ## Output Format 41 | 42 | Present findings in a structured report: 43 | 44 | ```markdown 45 | # Semantic Memory System Health Report 46 | 47 | ## Database Status 48 | - Total indexed summaries: X 49 | - Database size: X MB 50 | - Last indexed: [date] 51 | 52 | ## Coverage Analysis 53 | - Total summaries found: X 54 | - Successfully indexed: X 55 | - Missing from index: [list] 56 | 57 | ## Search Quality 58 | - Test search "vue": X results, avg similarity X% 59 | - Test search "typescript": X results, avg similarity X% 60 | - [Additional test results] 61 | 62 | ## Metadata Quality 63 | - With titles: X/X (X%) 64 | - With dates: X/X (X%) 65 | - With technologies: X/X (X%) 66 | 67 | ## Performance 68 | - Average search time: Xms 69 | - Embedding model: [status] 70 | 71 | ## Recommendations 72 | 1. [Specific actionable items] 73 | 2. [Re-index these files: ...] 74 | 3. [Add metadata to: ...] 75 | ``` 76 | 77 | Use the Python scripts at `[path-to-claude-code-vector-memory]/scripts/` to gather this information or run `[path-to-claude-code-vector-memory]/scripts/health_check.py` directly. 78 | Note: claude-code-vector-memory can be installed from https://github.com/christian-byrne/claude-code-vector-memory -------------------------------------------------------------------------------- /.github/workflows/validate-commands.yml: -------------------------------------------------------------------------------- 1 | name: Validate Commands 2 | 3 | on: 4 | push: 5 | paths: 6 | - '.claude/commands/**/*.md' 7 | pull_request: 8 | paths: 9 | - '.claude/commands/**/*.md' 10 | workflow_dispatch: 11 | 12 | jobs: 13 | validate: 14 | runs-on: ubuntu-latest 15 | 16 | steps: 17 | - name: Checkout repository 18 | uses: actions/checkout@v4 19 | 20 | - name: Validate command files 21 | run: | 22 | echo "🔍 Validating Claude Code commands..." 23 | 24 | COMMANDS_DIR=".claude/commands" 25 | ERRORS=0 26 | 27 | # Check if commands directory exists 28 | if [ ! -d "$COMMANDS_DIR" ]; then 29 | echo "❌ Commands directory not found: $COMMANDS_DIR" 30 | exit 1 31 | fi 32 | 33 | # Find all .md files in commands directory 34 | while IFS= read -r file; do 35 | echo "📄 Checking: $file" 36 | 37 | # Check if file is empty 38 | if [ ! -s "$file" ]; then 39 | echo " ❌ File is empty" 40 | ((ERRORS++)) 41 | continue 42 | fi 43 | 44 | # Check for proper markdown structure 45 | if ! head -1 "$file" | grep -q "^# "; then 46 | echo " ⚠️ Missing H1 title" 47 | fi 48 | 49 | # Check for $ARGUMENTS usage (if present, should be properly formatted) 50 | if grep -q '\$ARGUMENTS' "$file"; then 51 | echo " ✅ Uses \$ARGUMENTS parameter" 52 | fi 53 | 54 | # Check for basic markdown syntax issues (excluding shebangs) 55 | if grep -q '^#[^# !]' "$file"; then 56 | echo " ⚠️ Potential heading formatting issue (missing space after #)" 57 | ((ERRORS++)) 58 | fi 59 | 60 | # Check file naming convention 61 | basename_file=$(basename "$file" .md) 62 | if [[ ! "$basename_file" =~ ^[A-Z]+(-[a-z0-9-]+)*$ ]] && [[ ! "$basename_file" =~ ^[a-z]+(-[a-z0-9-]+)*$ ]]; then 63 | echo " ⚠️ Non-standard filename format: $basename_file" 64 | fi 65 | 66 | echo " ✅ Basic validation passed" 67 | done < <(find "$COMMANDS_DIR" -name "*.md" -type f) 68 | 69 | if [ $ERRORS -eq 0 ]; then 70 | echo "✅ All commands validated successfully!" 71 | exit 0 72 | else 73 | echo "❌ Found $ERRORS errors" 74 | exit 1 75 | fi -------------------------------------------------------------------------------- /.claude/knowledge/vue-based-node-system/custom-hybrid-implementation-patterns.md: -------------------------------------------------------------------------------- 1 | # Custom Hybrid Implementation Patterns 2 | 3 | ## Overview 4 | 5 | - Single Transform Container Pattern 6 | - One div with `transform: translate(x,y) scale(zoom)` 7 | - Transform-origin: 0 0 8 | - Vue nodes as children inherit this transform 9 | - RAF Batching 10 | - Batch all position updates in a single RAF 11 | - Sync canvas and DOM updates in the same frame 12 | - Viewport/Distance Culling & LOD 13 | - Only render nodes in view 14 | - Use LOD/culling for nodes that are far away 15 | - Event Delegation 16 | - Single listener on container 17 | - Use pointer events 18 | - `touch-action: none` on the container 19 | - `contain: layout style paint` on nodes 20 | 21 | ## The Optimal Hybrid Structure 22 | 23 | ``` 24 | Container (pointer-events: auto) 25 | ├── Canvas (pointer-events: none) 26 | │ └── Renders edges, background, grid 27 | └── Transform Pane (transform: translate/scale, transform-origin: 0 0, event delegation, touch-action: none) 28 | └── Vue Nodes (position: absolute, RAF batching, viewport culling, LOD) 29 | ``` 30 | 31 | ## Key Insight 32 | 33 | **Don't try to manually sync positions - use the same transform container pattern!** 34 | 35 | The canvas and DOM nodes would share the same parent transform, keeping them automatically in sync. This is much simpler than calculating separate positions for each system. 36 | 37 | ## Implementation Example 38 | 39 | ```javascript 40 | // Structure 41 |
42 | 43 |
50 | 59 |
60 |
61 | ``` 62 | 63 | ## Performance Optimizations to Include 64 | 65 | 1. **Lazy Event Listeners** - Only attach move/up on pointerdown 66 | 2. **Viewport Culling** - Only render nodes in view 67 | 3. **Node Pooling** - Reuse Vue component instances 68 | 4. **Debounced Updates** - For non-critical position changes 69 | 5. **CSS Containment** - Use `contain: layout style paint` on nodes 70 | 71 | ## What This Solves 72 | 73 | - Canvas and DOM automatically stay in sync via shared transform 74 | - Single source of truth for pan/zoom state 75 | - Leverages browser's optimized transform handling 76 | - Avoids complex coordinate conversion math 77 | - Same patterns proven in production libraries 78 | -------------------------------------------------------------------------------- /.claude/config/command-patterns.yml: -------------------------------------------------------------------------------- 1 | # Command Configuration Patterns 2 | # Defines reusable patterns for Claude Code commands 3 | 4 | Command_Categories: 5 | Analysis: 6 | - analyze-repo-for-claude 7 | - estimate-context-window 8 | - study-* 9 | - validate-* 10 | - scan-* 11 | 12 | Development: 13 | - create-feature-task 14 | - implement-feature 15 | - create-test-plan 16 | - fix-bug 17 | 18 | Quality: 19 | - comprehensive-test-review 20 | - validate-code-quality 21 | - scan-performance 22 | - scan-test-coverage 23 | 24 | Documentation: 25 | - generate-primevue-reference 26 | - document-api 27 | - create-readme 28 | 29 | Operations: 30 | - git-* 31 | - gh-* 32 | - deploy 33 | - migrate 34 | 35 | Workflow_Chains: 36 | Feature_Development: 37 | steps: 38 | - create-feature-task 39 | - study-current-repo 40 | - implement-feature 41 | - create-test-plan 42 | - comprehensive-test-review 43 | - gh-create-pr 44 | 45 | Bug_Fix: 46 | steps: 47 | - gh-issue-enhance 48 | - analyze-issue 49 | - fix-bug 50 | - test-fix 51 | - gh-pr-submit 52 | 53 | Code_Review: 54 | steps: 55 | - scan-code-quality 56 | - scan-performance 57 | - scan-test-coverage 58 | - generate-review-report 59 | 60 | Context_Sharing: 61 | # Define what context flows between commands 62 | analyze_to_implement: 63 | from: analyze-* 64 | to: implement-*, fix-* 65 | shares: [findings, patterns, architecture] 66 | 67 | scan_to_fix: 68 | from: scan-*, validate-* 69 | to: fix-*, improve-* 70 | shares: [issues, priorities, locations] 71 | 72 | test_to_deploy: 73 | from: test-*, scan-test-coverage 74 | to: deploy, gh-pr-* 75 | shares: [results, coverage, confidence] 76 | 77 | Cache_Patterns: 78 | # How long to cache results from different command types 79 | Analysis_Commands: 80 | ttl: 3600 # 1 hour 81 | invalidate_on: [file_changes, branch_switch] 82 | 83 | Scan_Commands: 84 | ttl: 1800 # 30 minutes 85 | invalidate_on: [file_changes] 86 | 87 | Build_Commands: 88 | ttl: 300 # 5 minutes 89 | invalidate_on: [any_change] 90 | 91 | Risk_Assessment: 92 | High_Risk_Commands: 93 | - deploy 94 | - migrate 95 | - cleanup-* 96 | - delete-* 97 | triggers: [confirmation, backup, dry_run] 98 | 99 | Medium_Risk_Commands: 100 | - refactor-* 101 | - update-dependencies 102 | - merge-* 103 | triggers: [plan_first, test_after] 104 | 105 | Low_Risk_Commands: 106 | - analyze-* 107 | - scan-* 108 | - study-* 109 | triggers: [] -------------------------------------------------------------------------------- /.claude/commands/research/STUDY-current-repo.md: -------------------------------------------------------------------------------- 1 | # ABSORB File Command 2 | 3 | Your task is to read and deeply absorb the repository analysis guide for the current working directory. This information will be used consistently throughout our upcoming tasks, so thorough understanding is critical. 4 | 5 | ## Repository Analysis Integration 6 | 7 | This command integrates with the ANALYZE-repo-for-claude storage system: 8 | 9 | 1. **Check for existing analysis**: Look for the repository analysis in `~/project-summaries-for-agents/` 10 | - Read `filepath-mapping.json` to find the summary folder for the current working directory 11 | - If no mapping exists, inform the user they need to run the ANALYZE-repo-for-claude command first 12 | 13 | 2. **Load repository guide**: Once the analysis folder is identified, read the comprehensive repository guide 14 | 15 | ## Instructions 16 | 17 | 1. **Locate repository analysis**: 18 | - Check if the current working directory has an existing analysis 19 | - Use the filepath mapping system to find the correct summary folder 20 | - If not found, stop and inform the user to run ANALYZE-repo-for-claude first 21 | 22 | 2. **Read the repository guide thoroughly**: Access the analysis file and understand: 23 | - The repository's purpose and context 24 | - Technology stack and architecture patterns 25 | - Development workflow and critical guidelines 26 | - Directory structure and key files 27 | - Common development tasks and procedures 28 | 29 | 3. **Absorb the information**: Process and internalize the content so you can: 30 | - Reference specific development patterns when needed 31 | - Apply the repository's conventions to related tasks 32 | - Make connections between different project components 33 | - Maintain consistency with the established architectural patterns 34 | - Follow the documented development guidelines 35 | 36 | 4. **Confirm understanding**: Provide a brief summary showing you've absorbed the key repository information, but keep it concise - the goal is absorption, not extensive explanation. 37 | 38 | ## Expected Behavior 39 | 40 | - Verify repository analysis exists before proceeding 41 | - Read the comprehensive repository guide completely and carefully 42 | - Think deeply about the architectural patterns and development conventions 43 | - Store the information for consistent use in subsequent tasks 44 | - Acknowledge completion with a focused summary of key development guidelines 45 | 46 | ## Error Handling 47 | 48 | If no repository analysis is found: 49 | - Inform the user that no analysis exists for the current repository 50 | - Suggest running the ANALYZE-repo-for-claude command first 51 | - Do not proceed with file absorption until the analysis is available 52 | 53 | This command is designed for building comprehensive repository context that will inform all future development work in the session. -------------------------------------------------------------------------------- /.claude/commands/research/STUDY-comfyui-custom-nodes-ecosystem.md: -------------------------------------------------------------------------------- 1 | # Study ComfyUI Custom Nodes Ecosystem 2 | 3 | Your task is to absorb knowledge of the ComfyUI custom nodes ecosystem by examining the descriptions in the ~/.claude/knowledge/custom-node-descrips folder. This research will help understand the landscape of extensions, plugins, and mods in the ComfyUI ecosystem. 4 | 5 | ## Analysis Scope 6 | 7 | Read through approximately 100 custom node descriptions from the folder to develop a deep understanding of: 8 | 9 | ### 1. Functional Patterns 10 | - Common categories of functionality (image processing, model management, UI enhancements, workflow automation, etc.) 11 | - Recurring problems that multiple nodes attempt to solve 12 | - Integration patterns with external services, APIs, or tools 13 | - Workflow enhancement strategies 14 | 15 | ### 2. Technical Architecture 16 | - Technologies and frameworks commonly used 17 | - Programming languages and libraries 18 | - Integration methods with ComfyUI core 19 | - Common design patterns and architectural approaches 20 | 21 | ### 3. Ecosystem Needs Analysis 22 | - Pain points that nodes consistently address 23 | - Gaps in functionality that multiple nodes try to fill 24 | - User experience improvements being implemented 25 | - Performance optimizations and efficiency enhancements 26 | 27 | ### 4. Innovation Trends 28 | - Emerging capabilities and new approaches 29 | - AI/ML model integrations 30 | - Novel UI/UX paradigms 31 | - Automation and workflow optimization techniques 32 | 33 | ## Methodology 34 | 35 | 1. **Systematic Reading**: Go through the node descriptions methodically, taking note of patterns 36 | 2. **Categorization**: Group nodes by their primary function and secondary features 37 | 3. **Pattern Recognition**: Identify common themes, repeated solutions, and shared challenges 38 | 4. **Technology Stack Analysis**: Note the tools, libraries, and frameworks mentioned 39 | 5. **Gap Analysis**: Identify what's missing or underserved in the ecosystem 40 | 41 | ## Expected Output 42 | 43 | After completing the analysis, you should have absorbed knowledge about: 44 | 45 | - The major categories of custom nodes and their distribution 46 | - Common user needs and how they're being addressed 47 | - Technical patterns and best practices in node development 48 | - Integration points and extension mechanisms 49 | - Opportunities for new nodes or improvements to existing ones 50 | 51 | ## Important Notes 52 | 53 | - This is a research and knowledge absorption task 54 | - Focus on understanding patterns and trends rather than memorizing specific nodes 55 | - No immediate action or output is required after reading 56 | - Prepare mentally to apply this knowledge to future tasks about ComfyUI custom nodes 57 | - The knowledge gained will inform decisions about node development, ecosystem improvements, or integration strategies 58 | 59 | Remember: The goal is to build a comprehensive mental model of the ComfyUI custom nodes ecosystem that can be applied to future development or analysis tasks. -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-frontend/primevue-integration-patterns.md: -------------------------------------------------------------------------------- 1 | # PrimeVue Integration Patterns in ComfyUI Frontend 2 | 3 | ## Tooltip Behavior and Z-Index Management 4 | 5 | ### Key Discovery: Body-Level Rendering 6 | PrimeVue tooltips render at `document.body` level, not within the component DOM tree. This has critical implications: 7 | 8 | 1. **Scoped CSS is ineffective** - Styles like `:deep(.p-tooltip)` within a component won't work 9 | 2. **Global styles affect all tooltips** - Changes to `.p-tooltip` impact the entire application 10 | 3. **Stacking context issues** - Tooltips need careful z-index management relative to other overlays 11 | 12 | ### The Custom Class Solution 13 | When you need targeted tooltip styling (e.g., higher z-index for specific tooltips): 14 | 15 | ```vue 16 | 17 | 18 | 19 | 20 | 21 | ``` 22 | 23 | Then target in global CSS: 24 | ```css 25 | .p-tooltip.my-custom-tooltip { 26 | z-index: 1200 !important; 27 | } 28 | ``` 29 | 30 | ### Real-World Example: Workflow Tab Tooltips 31 | Problem: Workflow tab tooltips were hidden behind the menubar (z-index: 1001) 32 | 33 | Failed approaches: 34 | 1. ❌ Global PrimeVue config: `zIndex: { tooltip: 1100 }` - doesn't work 35 | 2. ❌ Scoped component CSS: `.workflow-tabs :deep(.p-tooltip)` - tooltips render outside 36 | 3. ❌ Global tooltip rule: `.p-tooltip { z-index: 1100 }` - broke settings dialog tooltips 37 | 38 | Successful solution: 39 | ```vue 40 | 41 | 42 | ``` 43 | 44 | ```css 45 | /* style.css - targeted rule */ 46 | .p-tooltip.workflow-tab-tooltip { 47 | z-index: 1200 !important; /* Higher than menubar's 1001 */ 48 | } 49 | ``` 50 | 51 | ### Z-Index Strategy Guidelines 52 | 53 | 1. **Document your z-index layers**: 54 | - Base content: 0-10 55 | - Floating elements: 100-500 56 | - Dropdown menus: 999-1000 57 | - Modal dialogs: 1000-2000 58 | - Tooltips: 1100-1200 59 | - Critical overlays: 9999 60 | 61 | 2. **Use targeted approaches**: Prefer custom classes over global changes 62 | 3. **Test in context**: Always verify tooltips work in dialogs, with menus, etc. 63 | 4. **Consider stacking contexts**: Parent transforms/positioning can create new contexts 64 | 65 | ### Dialog and Tooltip Interactions 66 | When tooltips appear within dialogs, they need special consideration: 67 | - Dialogs create their own stacking context 68 | - Tooltips inside dialogs might need higher z-index than the dialog itself 69 | - Test tooltip behavior when dialogs are open 70 | 71 | ### Debugging Tips 72 | 1. Use browser DevTools to inspect where tooltip elements are rendered 73 | 2. Check computed z-index values and stacking contexts 74 | 3. Look for existing global CSS rules that might conflict 75 | 4. Verify parent elements don't create unexpected stacking contexts -------------------------------------------------------------------------------- /.claude/knowledge/dev-blog-best-practices/00-overview.md: -------------------------------------------------------------------------------- 1 | # Developer Blog Best Practices Overview 2 | 3 | ## Purpose 4 | 5 | This knowledge base contains research-backed best practices for writing compelling developer blog posts that engage technical audiences while providing genuine value. 6 | 7 | ## Core Philosophy 8 | 9 | Great developer blog posts serve three purposes: 10 | 1. **Educate** - Teach something valuable to fellow developers 11 | 2. **Inspire** - Show what's possible and spark new ideas 12 | 3. **Connect** - Build community and share experiences 13 | 14 | ## Key Success Factors 15 | 16 | Based on analysis of successful engineering blogs (Cloudflare, Tailscale, Netflix) and community feedback: 17 | 18 | 1. **Problem-First Approach** - Start with a real challenge that developers can relate to 19 | 2. **Technical Depth** - Provide enough detail for readers to understand and potentially implement 20 | 3. **Clear Narrative** - Tell a coherent story from problem to solution 21 | 4. **Practical Value** - Include actionable insights readers can apply 22 | 5. **Authentic Voice** - Share genuine experiences, including failures and learnings 23 | 24 | ## Content Categories 25 | 26 | ### Technical Deep Dives 27 | - Architecture decisions and trade-offs 28 | - Performance optimization journeys 29 | - Debugging war stories 30 | - Implementation walkthroughs 31 | 32 | ### Lessons Learned 33 | - Post-mortems and incident reports 34 | - Refactoring experiences 35 | - Migration case studies 36 | - Failed experiments and pivots 37 | 38 | ### Innovation Showcases 39 | - New tool/library introductions 40 | - Novel solutions to common problems 41 | - Open source contributions 42 | - Research and experimentation 43 | 44 | ### Team & Process 45 | - Engineering culture insights 46 | - Development workflow improvements 47 | - Collaboration techniques 48 | - Scaling challenges 49 | 50 | ## Anti-Patterns to Avoid 51 | 52 | 1. **Marketing Disguised as Content** - Readers quickly detect and reject promotional content 53 | 2. **Surface-Level Coverage** - Vague overviews without technical substance 54 | 3. **Disconnected Technical Details** - Code dumps without context or narrative 55 | 4. **Assumed Knowledge Gaps** - Either talking down to readers or assuming too much 56 | 5. **No Clear Takeaway** - Posts that don't answer "so what?" or "what now?" 57 | 58 | ## Quality Metrics 59 | 60 | Successful posts typically achieve: 61 | - High engagement (comments, shares, discussions) 62 | - Technical accuracy validated by peer review 63 | - Clear value proposition for target audience 64 | - Reasonable reading time (10-20 minutes) 65 | - Strong retention (readers finish the post) 66 | 67 | ## Resources in This Collection 68 | 69 | 1. **Technical Storytelling** - How to craft compelling narratives 70 | 2. **Audience Analysis** - Understanding and targeting reader segments 71 | 3. **Structure Patterns** - Proven post structures that work 72 | 4. **Code Examples** - Best practices for including code 73 | 5. **Visuals & Diagrams** - When and how to use visual aids 74 | 6. **Engagement Metrics** - Measuring and improving post performance -------------------------------------------------------------------------------- /.github/workflows/check-readme-documentation.yml: -------------------------------------------------------------------------------- 1 | name: Check README Documentation 2 | 3 | on: 4 | pull_request: 5 | paths: 6 | - '.claude/commands/**/*.md' 7 | - 'README.md' 8 | 9 | jobs: 10 | check-documentation: 11 | runs-on: ubuntu-latest 12 | 13 | steps: 14 | - name: Checkout repository 15 | uses: actions/checkout@v4 16 | with: 17 | fetch-depth: 0 18 | 19 | - name: Check for new commands without README documentation 20 | run: | 21 | echo "🔍 Checking if new commands are documented in README..." 22 | 23 | # Get the base branch (usually master/main) 24 | BASE_BRANCH="${{ github.base_ref }}" 25 | 26 | # Find new command files added in this PR 27 | NEW_COMMANDS=$(git diff --name-status origin/$BASE_BRANCH..HEAD | grep '^A' | grep '\.claude/commands/.*\.md$' | awk '{print $2}') 28 | 29 | if [ -z "$NEW_COMMANDS" ]; then 30 | echo "✅ No new command files detected in this PR" 31 | exit 0 32 | fi 33 | 34 | echo "📝 New command files detected:" 35 | echo "$NEW_COMMANDS" 36 | 37 | # Check if README.md was modified 38 | README_MODIFIED=$(git diff --name-only origin/$BASE_BRANCH..HEAD | grep '^README\.md$' || true) 39 | 40 | if [ -z "$README_MODIFIED" ]; then 41 | echo "❌ New command files were added but README.md was not updated!" 42 | echo "" 43 | echo "Please update README.md to include documentation for the new commands:" 44 | echo "$NEW_COMMANDS" 45 | echo "" 46 | echo "Add each new command as a bullet point in the appropriate section with:" 47 | echo "- A link to the command file using the format [\`/user:command-name\`](path/to/file.md)" 48 | echo "- A brief description of what the command does" 49 | echo "" 50 | echo "Example:" 51 | echo "- [\`/user:my-command\`](.claude/commands/category/my-command.md) - Brief description of the command" 52 | exit 1 53 | fi 54 | 55 | # Check if the new commands are actually referenced in the README 56 | MISSING_DOCS="" 57 | for cmd_file in $NEW_COMMANDS; do 58 | # Extract just the filename without path and extension 59 | cmd_basename=$(basename "$cmd_file" .md) 60 | 61 | # Check if this command is referenced in the README 62 | if ! grep -q "$cmd_basename" README.md; then 63 | MISSING_DOCS="$MISSING_DOCS\n- $cmd_file (command: $cmd_basename)" 64 | fi 65 | done 66 | 67 | if [ ! -z "$MISSING_DOCS" ]; then 68 | echo "❌ README.md was updated, but some new commands are not referenced:" 69 | echo -e "$MISSING_DOCS" 70 | echo "" 71 | echo "Please add bullet points for these commands in the appropriate README.md section" 72 | exit 1 73 | fi 74 | 75 | echo "✅ All new commands are properly documented in README.md" -------------------------------------------------------------------------------- /.claude/commands/system/semantic-memory-search.md: -------------------------------------------------------------------------------- 1 | # Semantic Memory Search 2 | 3 | You are accessing your shared memory with this user for the task: $ARGUMENTS 4 | 5 | ## Process 6 | 7 | 1. **Extract Key Concepts** 8 | Parse the user's request to identify: 9 | - Main objectives and actions (create, fix, implement, etc.) 10 | - Technologies and frameworks mentioned 11 | - File types or components referenced 12 | - Domain areas (UI, backend, testing, etc.) 13 | 14 | 2. **Search Semantic Memory** 15 | ```bash 16 | [path-to-claude-code-vector-memory]/search.sh "your extracted search terms" 17 | ``` 18 | 19 | 3. **Review Results** 20 | For each returned summary (typically top 3): 21 | - Read the preview carefully 22 | - Note the similarity score and relevance 23 | - Check the file path for the full summary if needed 24 | - Identify specific solutions, patterns, or decisions that apply 25 | 26 | 4. **Present Memory Recap** 27 | Show the user what relevant past work you found: 28 | 29 | ``` 30 | 📚 **Relevant Past Work Found:** 31 | 32 | **1. [Session Title] - [Date]** 33 | - Similarity: X% 34 | - Key work: [Brief description of what was done] 35 | - Relevant files: [List any key files that might help] 36 | - Useful context: [What specifically applies to current task] 37 | 38 | **2. [Session Title] - [Date]** 39 | - Similarity: X% 40 | - Key work: [Brief description] 41 | - Relevant approach: [Specific technique or pattern used] 42 | 43 | **3. [Session Title] - [Date]** 44 | - Similarity: X% 45 | - Previous solution: [What was implemented] 46 | - Could apply here for: [Specific aspect] 47 | ``` 48 | 49 | 5. **Ask for Direction** 50 | "Would you like me to build on any of these previous approaches, or should we start fresh?" 51 | 52 | ## Validation Criteria 53 | 54 | - Only present memories with >60% semantic similarity 55 | - Read enough context to verify genuine relevance 56 | - Explain WHY each memory is relevant with specific connections 57 | - If results seem tangentially related, acknowledge this: "I found some past work that might be relevant, though the connection isn't strong" 58 | 59 | ## If No Relevant Memories Found 60 | 61 | If search returns no good matches or all have low similarity: 62 | - Simply state: "I didn't find any highly relevant past work on this specific topic." 63 | - Proceed with the task without dwelling on the lack of memories 64 | 65 | ## Example Search Queries 66 | 67 | Based on user requests, here are example search terms to use: 68 | 69 | - "implement vue component" → Search: "vue component implementation widget" 70 | - "fix typescript errors" → Search: "typescript type error fix" 71 | - "add tests" → Search: "test vitest playwright testing" 72 | - "update API" → Search: "api endpoint backend" 73 | - "style with tailwind" → Search: "tailwind css styling" 74 | 75 | ## Important Notes 76 | 77 | - The semantic search understands conceptual similarity, not just keywords 78 | - Recent sessions are weighted higher in the results 79 | - Complex sessions (high file count) get a slight boost 80 | - Always verify relevance before presenting to user -------------------------------------------------------------------------------- /project-summaries-for-agents/filepath-mapping.json: -------------------------------------------------------------------------------- 1 | { 2 | "/home/c_byrne/projects/comfy-testing-environment/security-scanner": "security-scanner", 3 | "/home/c_byrne/projects/comfyui-frontend-testing/comfy-api": "comfy-api", 4 | "/home/c_byrne/projects/comfy-testing-environment/ComfyUI-Manager-clone-1": "ComfyUI-Manager", 5 | "/home/c_byrne/projects/comfyui-frontend-testing/comfy-cli": "comfy-cli", 6 | "/home/c_byrne/projects/comfy-testing-environment/ComfyUI-Copilot": "ComfyUI-Copilot", 7 | "/home/c_byrne/projects/comfyui-frontend-testing/docs": "docs", 8 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-1": "ComfyUI_frontend", 9 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-2": "ComfyUI_frontend", 10 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-3": "ComfyUI_frontend", 11 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-4": "ComfyUI_frontend", 12 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-5": "ComfyUI_frontend", 13 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-6": "ComfyUI_frontend", 14 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-7": "ComfyUI_frontend", 15 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-8": "ComfyUI_frontend", 16 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-9": "ComfyUI_frontend", 17 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-10": "ComfyUI_frontend", 18 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-11": "ComfyUI_frontend", 19 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-12": "ComfyUI_frontend", 20 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-13": "ComfyUI_frontend", 21 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-14": "ComfyUI_frontend", 22 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-15": "ComfyUI_frontend", 23 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-16": "ComfyUI_frontend", 24 | "/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_examples": "ComfyUI_examples", 25 | "/home/c_byrne/projects/comfyui-frontend-testing/desktop": "desktop", 26 | "/home/c_byrne/projects/comfyui-frontend-testing/litegraph-clone": "litegraph", 27 | "/home/c_byrne/projects/comfyui-frontend-testing/litegraph-clone-2": "litegraph", 28 | "/home/c_byrne/projects/comfyui-frontend-testing/litegraph": "litegraph", 29 | "/home/c_byrne/projects/comfyui-frontend-testing/litegraph.js": "litegraph", 30 | "/home/c_byrne/projects/comfyui-frontend-testing/rfcs": "rfcs", 31 | "/home/c_byrne/projects/comfyui-frontend-testing/website": "website", 32 | "/home/c_byrne/projects/comfyui-frontend-testing/workflow_templates": "workflow_templates", 33 | "/home/c_byrne/projects/comfyui-frontend-testing/registry-web-clone-1": "registry-web", 34 | "/home/c_byrne/projects/comfyui-frontend-testing/registry-web-clone-2": "registry-web", 35 | "/home/c_byrne/projects/comfyui-frontend-testing/registry-web": "registry-web" 36 | } -------------------------------------------------------------------------------- /.claude/knowledge/claude-code-best-practices/README.md: -------------------------------------------------------------------------------- 1 | # Claude Code Best Practices Knowledge Base 2 | 3 | This directory contains refactored and organized best practices for creating Claude Code commands and working effectively with Claude Code. 4 | 5 | ## Contents 6 | 7 | ### Foundation 8 | - **[00-overview.md](00-overview.md)** - Introduction to Claude Code commands and basic structure 9 | - **[01-claude-code-fundamentals.md](01-claude-code-fundamentals.md)** - Understanding CLAUDE.md files and environment setup 10 | 11 | ### Prompting Techniques 12 | - **[02-prompting-techniques.md](02-prompting-techniques.md)** - Core techniques: being direct, using examples, XML tags 13 | - **[03-advanced-prompting.md](03-advanced-prompting.md)** - Chain of thought, roles, prompt chaining, meta-prompting 14 | - **[04-extended-thinking.md](04-extended-thinking.md)** - Extended thinking features and optimization 15 | 16 | ### Model-Specific Guidance 17 | - **[05-claude-4-best-practices.md](05-claude-4-best-practices.md)** - Specific practices for Claude 4 models 18 | 19 | ### Development Practices 20 | - **[06-evaluation-frameworks.md](06-evaluation-frameworks.md)** - Building evaluation suites and measuring performance 21 | - **[07-workflows.md](07-workflows.md)** - Recommended workflows for different tasks 22 | - **[08-optimization-tips.md](08-optimization-tips.md)** - Tips for optimizing Claude Code usage 23 | 24 | ### Standards & Resources 25 | - **[09-pattern-consistency.md](09-pattern-consistency.md)** - Maintaining consistency across commands 26 | - **[10-resources.md](10-resources.md)** - Links to documentation and additional resources 27 | 28 | ## Quick Start 29 | 30 | 1. Start with [00-overview.md](00-overview.md) to understand the basics 31 | 2. Review [02-prompting-techniques.md](02-prompting-techniques.md) for essential techniques 32 | 3. Check [09-pattern-consistency.md](09-pattern-consistency.md) before creating new commands 33 | 4. Use [06-evaluation-frameworks.md](06-evaluation-frameworks.md) to test and improve your commands 34 | 35 | ## Key Takeaways 36 | 37 | - **Be Direct**: Treat Claude like a brilliant new employee who needs explicit instructions 38 | - **Use Examples**: 3-5 well-crafted examples dramatically improve output quality 39 | - **Structure with XML**: Use tags to organize complex prompts 40 | - **Enable Thinking**: Use trigger words ("think", "think hard", etc.) for complex tasks 41 | - **Evaluate Systematically**: Build test suites to measure and improve performance 42 | - **Maintain Consistency**: Follow established patterns in your command library 43 | 44 | ## Creating New Commands 45 | 46 | When creating a new Claude Code command: 47 | 48 | 1. Search for similar existing commands first 49 | 2. Follow naming conventions and structure patterns 50 | 3. Use the templates in [09-pattern-consistency.md](09-pattern-consistency.md) 51 | 4. Test thoroughly with diverse inputs 52 | 5. Document any new patterns you introduce 53 | 54 | ## Contributing 55 | 56 | When adding new content to this knowledge base: 57 | - Keep files focused on specific topics 58 | - Use clear, descriptive filenames 59 | - Update this README with new additions 60 | - Maintain consistent formatting across all files -------------------------------------------------------------------------------- /.claude/commands/research/STUDY-node-editor-performance-optimizations.md: -------------------------------------------------------------------------------- 1 | # Study Node Editor Performance Optimizations 2 | 3 | Your task is to absorb knowledge about node editor performance optimization strategies by examining the research in the ~/.claude/knowledge/node-editor-performance-optimizations folder. This research analyzes how modern graph/canvas libraries handle rendering performance and will inform decisions about ComfyUI node editor optimization. 4 | 5 | ## Analysis Scope 6 | 7 | Read through all the analysis files in the folder to develop a deep understanding of: 8 | 9 | ### 1. Transform Patterns 10 | - How different libraries handle viewport transforms (single container vs individual shapes) 11 | - CSS transform vs canvas transform approaches 12 | - Matrix math implementations and optimizations 13 | - GPU acceleration strategies with will-change and transform3d 14 | 15 | ### 2. Performance Optimization Techniques 16 | - Culling strategies for off-screen elements 17 | - Level of Detail (LOD) systems for zoom-based rendering 18 | - RequestAnimationFrame batching patterns 19 | - Event delegation and handling optimizations 20 | - Edge rendering performance considerations 21 | 22 | ### 3. Library-Specific Implementations 23 | - **Vue Flow**: Transform.vue, d3-zoom integration, reactive viewport 24 | - **React Flow**: Similar to Vue Flow with React-specific optimizations 25 | - **tldraw**: Advanced shape-based system with Mat.ts matrix class 26 | - **Rete.js**: Plugin architecture with framework-agnostic approach 27 | - **D3.js**: Zoom behavior and transform interpolation patterns 28 | 29 | ### 4. Architecture Trade-offs 30 | - Single viewport transform vs individual shape transforms 31 | - SVG vs Canvas vs HTML rendering 32 | - Framework integration challenges 33 | - Component reusability vs performance 34 | 35 | ## Key Files to Study 36 | 37 | 1. **research-summary.md** - Executive summary and key findings 38 | 2. **flow-libraries-comparison.md** - Comprehensive feature comparison matrix 39 | 3. **vue-flow-transform-analysis.md** - Vue Flow deep dive 40 | 4. **reactflow-transform-analysis.md** - React Flow analysis 41 | 5. **tldraw-transform-analysis.md** - tldraw's advanced approach 42 | 6. **retejs-transform-analysis.md** - Rete.js plugin system 43 | 7. **d3-in-node-editors.md** - D3 zoom behavior analysis 44 | 45 | ## Expected Insights 46 | 47 | After completing this analysis, you should understand: 48 | 49 | - Why Vue Flow and React Flow have similar performance limitations 50 | - Why tldraw's approach is incompatible with existing Vue/PrimeVue components 51 | - The trade-offs between different rendering strategies 52 | - Opportunities for a hybrid canvas/Vue approach 53 | - Specific optimizations that could benefit ComfyUI 54 | 55 | ## Important Context 56 | 57 | This research was conducted to inform decisions about optimizing the ComfyUI node editor. The key finding is that achieving both high performance AND Vue component compatibility would require a custom hybrid approach using canvas for backgrounds/edges and Vue for nodes. 58 | 59 | Remember: The goal is to build a comprehensive understanding of node editor performance patterns that can be applied to future ComfyUI optimization tasks. -------------------------------------------------------------------------------- /.claude/knowledge/graphics-rendering-fundamentals/README.md: -------------------------------------------------------------------------------- 1 | # Graphics Rendering Fundamentals 2 | 3 | This knowledge base focuses on graphics rendering concepts specifically relevant to browser-based development, with emphasis on performance optimization and practical implementation techniques. 4 | 5 | ## Contents 6 | 7 | ### 📋 Overview 8 | - **[00-overview.md](00-overview.md)** - High-level concepts and how they connect 9 | - **[01-browser-rendering-basics.md](01-browser-rendering-basics.md)** - Foundation concepts for web developers 10 | 11 | ### 🔄 Browser Rendering Pipeline 12 | - **[00-pipeline-overview.md](browser-rendering-pipeline/00-pipeline-overview.md)** - Complete rendering pipeline 13 | - **[01-parsing-dom-cssom.md](browser-rendering-pipeline/01-parsing-dom-cssom.md)** - HTML/CSS parsing phase 14 | - **[02-render-tree.md](browser-rendering-pipeline/02-render-tree.md)** - Render tree construction 15 | - **[03-layout-reflow.md](browser-rendering-pipeline/03-layout-reflow.md)** - Layout calculations and reflow 16 | - **[04-paint-composite.md](browser-rendering-pipeline/04-paint-composite.md)** - Paint and composite layers 17 | - **[05-optimization-techniques.md](browser-rendering-pipeline/05-optimization-techniques.md)** - Performance optimization strategies 18 | 19 | ### 🗂️ Spatial Data Structures 20 | - **[00-quadtree-fundamentals.md](spatial-data-structures/00-quadtree-fundamentals.md)** - Core quadtree concepts 21 | - **[01-quadtree-implementation.md](spatial-data-structures/01-quadtree-implementation.md)** - JavaScript/browser implementation 22 | - **[02-quadtree-use-cases.md](spatial-data-structures/02-quadtree-use-cases.md)** - When and why to use quadtrees 23 | 24 | ### 🚀 Practical Optimizations 25 | - **[00-performance-patterns.md](practical-optimizations/00-performance-patterns.md)** - Common optimization patterns 26 | - **[01-debugging-tools.md](practical-optimizations/01-debugging-tools.md)** - DevTools and debugging techniques 27 | - **[02-real-world-examples.md](practical-optimizations/02-real-world-examples.md)** - Case studies and examples 28 | 29 | ## Quick Navigation 30 | 31 | **For Performance Optimization**: Start with pipeline overview → optimization techniques → performance patterns 32 | **For Spatial Algorithms**: Begin with quadtree fundamentals → implementation → use cases 33 | **For Debugging**: Jump to debugging tools → real-world examples 34 | 35 | ## Key Principles 36 | 37 | 1. **Browser-First Approach**: All concepts are presented within the context of web browsers and JavaScript 38 | 2. **Performance Focused**: Emphasis on practical optimization techniques over theoretical graphics programming 39 | 3. **Developer Tools**: Heavy focus on debugging and measurement tools available to web developers 40 | 4. **Real-World Application**: Examples and patterns drawn from actual web development scenarios 41 | 42 | ## Prerequisites 43 | 44 | - Basic JavaScript knowledge 45 | - Understanding of HTML/CSS 46 | - Familiarity with browser DevTools 47 | - Basic understanding of DOM manipulation 48 | 49 | ## Related Topics 50 | 51 | - Canvas API optimization 52 | - WebGL performance patterns 53 | - CSS animations and transforms 54 | - Intersection Observer API 55 | - Viewport culling techniques -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-troubleshooting/gpu-compatibility-issues.md: -------------------------------------------------------------------------------- 1 | # GPU Compatibility Issues and Solutions 2 | 3 | ## RTX 50 Series (Blackwell) xformers Incompatibility 4 | 5 | ### Issue Description 6 | Users with NVIDIA RTX 50 series GPUs (5070, 5070 Ti, 5080, 5090) encounter CUDA errors when xformers is enabled in ComfyUI. 7 | 8 | **Error Message:** 9 | ``` 10 | CUDA error (C:/a/xformers/xformers/third_party/flash-attention/hopper\flash_fwd_launch_template.h:188): invalid argument 11 | ``` 12 | 13 | ### Affected Hardware 14 | - NVIDIA RTX 5070 15 | - NVIDIA RTX 5070 Ti 16 | - NVIDIA RTX 5080 17 | - NVIDIA RTX 5090 18 | - All Blackwell architecture GPUs (compute capability sm_120) 19 | 20 | ### Root Cause 21 | The xformers library's flash attention implementation is not compatible with the new Blackwell architecture (sm_120). The current xformers versions (including 0.0.31.post1) were built before these GPUs existed and don't include support for the new compute capability. 22 | 23 | ### Solution 24 | 25 | **Primary Solution: Disable xformers** 26 | ```bash 27 | # Windows 28 | .\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --disable-xformers 29 | 30 | # Linux/Mac 31 | python main.py --disable-xformers 32 | ``` 33 | 34 | **Alternative Solutions:** 35 | 36 | 1. **Use PyTorch's native attention (automatically enabled when xformers is disabled)** 37 | ```bash 38 | python main.py --use-pytorch-cross-attention 39 | ``` 40 | 41 | 2. **Force split attention mode** 42 | ```bash 43 | python main.py --disable-xformers --use-split-cross-attention 44 | ``` 45 | 46 | ### Performance Impact 47 | Minimal performance difference has been reported by users: 48 | - With xformers: ~1min 57.7sec (benchmark) 49 | - Without xformers: ~1min 54.7sec (benchmark) 50 | - Some users report slightly better performance without xformers on RTX 50 series 51 | 52 | ### Current Status (July 2025) 53 | - xformers still does not officially support RTX 50 series GPUs 54 | - Community builds exist but have mixed results: 55 | - `xformers-0.0.30+9a2cd3ef.d20250321` (for Python 3.12.8) 56 | - PyTorch 2.7+ with CUDA 12.8 fully supports these GPUs 57 | - Native PyTorch attention provides comparable performance 58 | 59 | ### Required Software Versions 60 | For RTX 50 series support, ensure you have: 61 | - PyTorch 2.7.0+ with CUDA 12.8 62 | - NVIDIA Driver 572.70 or newer 63 | - CUDA 12.8+ 64 | 65 | **Install command for proper PyTorch:** 66 | ```bash 67 | pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu128 68 | ``` 69 | 70 | ### References 71 | - [GitHub Issue #8861](https://github.com/comfyanonymous/ComfyUI/issues/8861) 72 | - [GitHub Discussion #6643 - Nvidia 50 Series support thread](https://github.com/comfyanonymous/ComfyUI/discussions/6643) 73 | 74 | ### Notes for Developers 75 | The issue stems from: 76 | 1. xformers' flash attention kernel not recognizing sm_120 architecture 77 | 2. The flash_fwd_launch_template.h file containing hardcoded architecture checks 78 | 3. PyTorch's native attention has caught up in performance, making xformers less critical 79 | 80 | Until xformers officially adds Blackwell support, the `--disable-xformers` flag is the recommended approach. -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-execution/validation-flow.md: -------------------------------------------------------------------------------- 1 | # ComfyUI Validation Flow 2 | 3 | ## Execution Order 4 | 5 | ComfyUI's input validation follows a strict sequential order in `execution.py`: 6 | 7 | 1. **Static Combo Validation** (lines 737-762) 8 | - Checks if input values exist in predefined combo lists 9 | - Applies to inputs defined as `(list, {...})` format 10 | - **Critical**: If this fails, execution stops and returns errors 11 | 12 | 2. **VALIDATE_INPUTS Custom Validation** (lines 764-791) 13 | - Only runs if static validation passes 14 | - Allows nodes to implement custom validation logic 15 | - Has access to full execution context and input data 16 | 17 | ## The Timing Dependency Problem 18 | 19 | ```python 20 | # In execution.py validate_inputs() 21 | if isinstance(input_type, list): 22 | combo_options = input_type 23 | if val not in combo_options: 24 | # FAIL HERE - execution stops 25 | errors.append(error) 26 | continue 27 | 28 | # This section only reached if above passes 29 | if len(validate_function_inputs) > 0 or validate_has_kwargs: 30 | ret = _map_node_over_list(obj_class, input_filtered, "VALIDATE_INPUTS") 31 | ``` 32 | 33 | **Key Insight**: `VALIDATE_INPUTS` never gets called if static combo validation fails first. This creates issues for nodes that want to: 34 | - Validate dynamic combo options at runtime 35 | - Use custom logic to determine valid values 36 | - Handle combos populated by frontend after `INPUT_TYPES()` definition 37 | 38 | ## Validation Types 39 | 40 | ### Static Combo Validation 41 | - Triggers on: `isinstance(input_type, list)` where `input_type` is first element of tuple 42 | - Examples: 43 | ```python 44 | "model": (["sd15", "sdxl", "flux"], {}) # List triggers validation 45 | "sampler": (comfy.samplers.KSampler.SAMPLERS, {}) # List triggers validation 46 | ``` 47 | 48 | ### String Type Inputs 49 | - No automatic validation for: `"COMBO"`, `"STRING"`, `"INT"`, etc. 50 | - Examples: 51 | ```python 52 | "option": ("COMBO", {"remote": {"route": "/api/options"}}) # No static validation 53 | "text": ("STRING", {}) # No static validation 54 | ``` 55 | 56 | ## Working Examples 57 | 58 | ### LoadImageOutput (Works Fine) 59 | ```python 60 | "image": ("COMBO", { 61 | "remote": { 62 | "route": "/internal/files/output", 63 | "refresh_button": True, 64 | "control_after_refresh": "first", 65 | }, 66 | }) 67 | ``` 68 | - Uses `"COMBO"` string type → skips static validation 69 | - Frontend populates via remote route 70 | - Relies on `VALIDATE_INPUTS` for file existence check 71 | 72 | ### LoadImage (Static Validation) 73 | ```python 74 | "image": (sorted(files), {"image_upload": True}) 75 | ``` 76 | - Uses actual list → triggers static validation 77 | - Files must exist in list at validation time 78 | - Both static validation AND `VALIDATE_INPUTS` run 79 | 80 | ## Best Practices 81 | 82 | 1. **Use string types** (`"COMBO"`, etc.) for dynamic options that can't be known at `INPUT_TYPES()` time 83 | 2. **Implement `VALIDATE_INPUTS`** for custom validation logic with runtime context 84 | 3. **Use list types** only for truly static, predetermined options 85 | 4. **Remember validation order** when debugging - static validation can block custom validation -------------------------------------------------------------------------------- /.claude/knowledge/claude-code-best-practices/01-claude-code-fundamentals.md: -------------------------------------------------------------------------------- 1 | # Claude Code Fundamentals 2 | 3 | ## Overview 4 | 5 | Claude Code is an agentic coding assistant that automatically pulls context into prompts. This context gathering consumes time and tokens, but you can optimize it through environment tuning. 6 | 7 | ## CLAUDE.md Files 8 | 9 | CLAUDE.md is a special file that Claude automatically pulls into context when starting a conversation. This makes it an ideal place for documenting: 10 | 11 | - Common bash commands 12 | - Core files and utility functions 13 | - Code style guidelines 14 | - Testing instructions 15 | - Repository etiquette (e.g., branch naming, merge vs. rebase, etc.) 16 | - Developer environment setup (e.g., pyenv use, which compilers work) 17 | - Any unexpected behaviors or warnings particular to the project 18 | - Other information you want Claude to remember 19 | 20 | ### File Format 21 | 22 | There's no required format for CLAUDE.md files. We recommend keeping them concise and human-readable. For example: 23 | 24 | ``` 25 | # Bash commands 26 | - npm run build: Build the project 27 | - npm run typecheck: Run the typechecker 28 | 29 | # Code style 30 | - Use ES modules (import/export) syntax, not CommonJS (require) 31 | - Destructure imports when possible (eg. import { foo } from 'bar') 32 | 33 | # Workflow 34 | - Be sure to typecheck when you're done making a series of code changes 35 | - Prefer running single tests, and not the whole test suite, for performance 36 | ``` 37 | 38 | ### File Locations 39 | 40 | You can place CLAUDE.md files in several locations: 41 | 42 | - The root of your repo, or wherever you run claude from (the most common usage). Name it CLAUDE.md and check it into git so that you can share it across sessions and with your team (recommended), or name it CLAUDE.local.md and .gitignore it 43 | - Any parent of the directory where you run claude. This is most useful for monorepos, where you might run claude from root/foo, and have CLAUDE.md files in both root/CLAUDE.md and root/foo/CLAUDE.md. Both of these will be pulled into context automatically 44 | - Any child of the directory where you run claude. This is the inverse of the above, and in this case, Claude will pull in CLAUDE.md files on demand when you work with files in child directories 45 | - Your home folder (~/.claude/CLAUDE.md), which applies it to all your claude sessions 46 | 47 | When you run the /init command, Claude will automatically generate a CLAUDE.md for you. 48 | 49 | ## Tuning Your CLAUDE.md Files 50 | 51 | Your CLAUDE.md files become part of Claude's prompts, so they should be refined like any frequently used prompt. A common mistake is adding extensive content without iterating on its effectiveness. Take time to experiment and determine what produces the best instruction following from the model. 52 | 53 | You can add content to your CLAUDE.md manually or press the # key to give Claude an instruction that it will automatically incorporate into the relevant CLAUDE.md. Many engineers use # frequently to document commands, files, and style guidelines while coding, then include CLAUDE.md changes in commits so team members benefit as well. 54 | 55 | At Anthropic, we occasionally run CLAUDE.md files through the prompt improver and often tune instructions (e.g. adding emphasis with "IMPORTANT" or "YOU MUST") to improve adherence. -------------------------------------------------------------------------------- /project-summaries-for-agents/vue-flow/github-issue-ideas/transform-zoom-pixel-stretch-issue.md: -------------------------------------------------------------------------------- 1 | # Transform-based Zoom Pixel Stretching Discussion 2 | 3 | ## Post Location 4 | **GitHub Discussions** > **Q&A Category** 5 | URL: https://github.com/bcakmakoglu/vue-flow/discussions/new?category=q-a 6 | 7 | ## Discussion Title 8 | Forcing re-rasterization at zoom thresholds to prevent pixel stretching? 9 | 10 | ## Labels to Add (if available) 11 | - `question` 12 | - `performance` 13 | - `architecture` 14 | 15 | ## Full Discussion Body 16 | 17 | I noticed that at extreme zoom levels (>5x or <0.2x), CSS transforms can show pixelation/stretching artifacts since browsers rasterize elements once and then scale that rasterized layer. 18 | 19 | Looking at [`Transform.vue`](https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/container/Viewport/Transform.vue#L15): 20 | 21 | ```typescript 22 | transform: `translate(${viewport.value.x}px,${viewport.value.y}px) scale(${viewport.value.zoom})` 23 | ``` 24 | 25 | Has the team considered forcing a reflow/re-rasterization at certain zoom thresholds? For example, triggering a brief style change that forces the browser to re-rasterize the transform layer: 26 | 27 | ```typescript 28 | // At zoom threshold crossings (e.g., 2x, 4x, 8x) 29 | if (crossedThreshold) { 30 | // Force re-rasterization 31 | element.style.willChange = 'auto' 32 | element.offsetHeight // Force reflow 33 | element.style.willChange = 'transform' 34 | } 35 | ``` 36 | 37 | The idea being to get fresh rasterization at the new scale rather than stretching the original. Has this come up before, or do Vue Flow's typical use cases not hit the zoom levels where this becomes noticeable? 38 | 39 | ## Code References with GitHub Line URLs 40 | 41 | 1. **Main transform application**: 42 | https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/container/Viewport/Transform.vue#L15 43 | 44 | 2. **Transform container CSS**: 45 | https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/style.css#L34-L38 46 | 47 | 3. **Node positioning via transform**: 48 | https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/components/Nodes/NodeWrapper.ts#L281 49 | 50 | 4. **D3 zoom configuration**: 51 | https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/container/Viewport/Viewport.vue#L89-L92 52 | 53 | 5. **Transform calculation utilities**: 54 | https://github.com/bcakmakoglu/vue-flow/blob/main/packages/core/src/utils/graph.ts#L298-L310 55 | 56 | ## Additional Notes for Posting 57 | 58 | 1. **Check line numbers** - These URLs are current as of the latest commit, but double-check before posting 59 | 2. **Category** - Post in Q&A category as directed by their issue template config 60 | 3. **Follow-up** - Be prepared to share benchmarks or visual examples if asked 61 | 4. **Tone** - Keep it conversational and collaborative 62 | 63 | ## Quick Copy Section 64 | 65 | **Title:** 66 | ``` 67 | Forcing re-rasterization at zoom thresholds to prevent pixel stretching? 68 | ``` 69 | 70 | **First paragraph (hook):** 71 | ``` 72 | I noticed that at extreme zoom levels (>5x or <0.2x), CSS transforms can show pixelation/stretching artifacts since browsers rasterize elements once and then scale that rasterized layer. 73 | ``` 74 | 75 | ## File Path 76 | `~/project-summaries-for-agents/vue-flow/github-issue-ideas/transform-zoom-pixel-stretch-issue.md` -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-frontend/vue-composable-patterns.md: -------------------------------------------------------------------------------- 1 | # Vue Composable Patterns in ComfyUI Frontend 2 | 3 | ## VueUse Integration for Common UI Patterns 4 | 5 | ### Click Outside Detection with onClickOutside 6 | 7 | The `onClickOutside` composable from VueUse provides a cleaner implementation than manual event listeners for detecting clicks outside an element. 8 | 9 | #### Benefits Over Manual Implementation 10 | - **Automatic cleanup**: No need to manually remove event listeners in `onUnmounted` 11 | - **Built-in ignore option**: Easily exclude elements from triggering the outside click 12 | - **Lightweight**: Only 1.03KB added to bundle 13 | - **Better lifecycle handling**: Automatically handles component unmount 14 | 15 | #### Example: Replacing Manual Event Listeners 16 | 17 | **Before (Manual Implementation):** 18 | ```typescript 19 | // Complex manual implementation 20 | const helpCenterRef = ref(null) 21 | 22 | const handleClickOutside = (event: MouseEvent): void => { 23 | const target = event.target as Element 24 | 25 | if (helpCenterRef.value && !helpCenterRef.value.contains(target)) { 26 | if ( 27 | isSubmenuVisible.value && 28 | submenuRef.value && 29 | submenuRef.value.contains(target) 30 | ) { 31 | return 32 | } 33 | emit('close') 34 | } 35 | } 36 | 37 | onMounted(() => { 38 | document.addEventListener('mousedown', handleClickOutside) 39 | }) 40 | 41 | onUnmounted(() => { 42 | document.removeEventListener('mousedown', handleClickOutside) 43 | }) 44 | ``` 45 | 46 | **After (VueUse onClickOutside):** 47 | ```typescript 48 | import { onClickOutside } from '@vueuse/core' 49 | 50 | const helpCenterRef = ref(null) 51 | const submenuRef = ref(null) 52 | 53 | // Clean, declarative implementation 54 | onClickOutside( 55 | helpCenterRef, 56 | () => emit('close'), 57 | { ignore: [submenuRef] } 58 | ) 59 | ``` 60 | 61 | #### Installation and Setup 62 | VueUse is already included in ComfyUI Frontend dependencies (`@vueuse/core v11.0.0`). 63 | 64 | #### Common Use Cases 65 | 1. **Dropdown menus**: Close when clicking outside 66 | 2. **Modal dialogs**: Dismiss on backdrop click 67 | 3. **Popovers**: Hide when user clicks elsewhere 68 | 4. **Context menus**: Dismiss on outside interaction 69 | 70 | #### Advanced Options 71 | ```typescript 72 | // With more control 73 | const { stop } = onClickOutside( 74 | target, 75 | (event) => { 76 | console.log('Clicked outside:', event) 77 | closeMenu() 78 | }, 79 | { 80 | ignore: [ignoreElRef, '.ignore-class'], 81 | capture: true, 82 | detectIframe: true 83 | } 84 | ) 85 | 86 | // Stop listening when needed 87 | stop() 88 | ``` 89 | 90 | ### Other Useful VueUse Composables 91 | 92 | While we haven't explored all of these in depth, VueUse offers many composables that could simplify ComfyUI Frontend code: 93 | 94 | - `useEventListener`: Better event handling with auto-cleanup 95 | - `useFocusTrap`: Trap focus within modals/dialogs 96 | - `useKeyModifier`: Track modifier key states 97 | - `useElementVisibility`: Track element visibility 98 | - `useDraggable`: Implement drag functionality 99 | - `useResizeObserver`: Monitor element size changes 100 | 101 | Consider exploring VueUse documentation for more patterns that could replace manual implementations. -------------------------------------------------------------------------------- /.claude/commands/blog/add-idea.md: -------------------------------------------------------------------------------- 1 | # Add Blog Idea 2 | 3 | 4 | You are a content strategist who helps capture and organize blog post ideas as they emerge, ensuring no valuable topic is forgotten. 5 | 6 | 7 | 8 | Add a new blog idea to the backlog: $ARGUMENTS 9 | 10 | 11 | 12 | 1. **Parse the idea** 13 | Extract from the input: 14 | - Topic/title 15 | - Brief description (if provided) 16 | - Priority indicators (urgent, high, medium, low) 17 | - Related projects (if mentioned) 18 | - Potential angle or hook 19 | 20 | 2. **Check for existing ideas** 21 | - Read `./posts/ideas-backlog.md` if it exists 22 | - Check if similar idea already exists 23 | - If similar exists, ask if this is a variant or update 24 | 25 | 3. **Generate idea entry** 26 | Format the idea as: 27 | ```markdown 28 | ## [Generated Title] 29 | - **Priority**: [high/medium/low] 30 | - **Added**: [Current date] 31 | - **Projects**: [Related projects or "General"] 32 | - **Description**: [Brief description of the idea] 33 | - **Potential Angle**: [What would make this interesting] 34 | - **Estimated Effort**: [Quick/Medium/Deep-dive] 35 | - **Notes**: [Any additional context] 36 | ``` 37 | 38 | 4. **Add to backlog** 39 | - If backlog doesn't exist, create `./posts/ideas-backlog.md` with header 40 | - Insert new idea at appropriate priority level 41 | - Higher priority ideas go near the top 42 | - Keep ideas organized by priority sections 43 | 44 | 5. **Suggest related ideas** 45 | Based on the new idea, suggest 1-2 related topics: 46 | - "This could pair well with a post about..." 47 | - "A natural follow-up might be..." 48 | 49 | 6. **Confirm addition** 50 | Report back: 51 | - Idea added to backlog 52 | - Current total number of ideas 53 | - Suggest using `/blog:list-ideas` to review all 54 | 55 | 56 | 57 | 58 | Input: "How we reduced node editor render time by 80%" 59 | Output: 60 | ```markdown 61 | ## How We Reduced Node Editor Render Time by 80% 62 | - **Priority**: high 63 | - **Added**: 2024-01-15 64 | - **Projects**: comfyui-frontend, node-editor-performance 65 | - **Description**: Deep dive into performance optimizations for node editor rendering 66 | - **Potential Angle**: Step-by-step optimization journey with benchmarks 67 | - **Estimated Effort**: Deep-dive 68 | - **Notes**: Has great before/after metrics, visual performance comparisons 69 | ``` 70 | 71 | 72 | 73 | Input: "Quick post about our new vim mode keybindings" 74 | Output: 75 | ```markdown 76 | ## Implementing Vim Mode: A Technical Journey 77 | - **Priority**: medium 78 | - **Added**: 2024-01-15 79 | - **Projects**: comfyui-frontend 80 | - **Description**: How we added full vim keybinding support to our visual editor 81 | - **Potential Angle**: State machine design and handling complex key combinations 82 | - **Estimated Effort**: Medium 83 | - **Notes**: Good example of community-driven feature development 84 | ``` 85 | 86 | 87 | 88 | 89 | # Blog Ideas Backlog 90 | 91 | ## High Priority 92 | [Ideas that are timely or have high impact] 93 | 94 | ## Medium Priority 95 | [Solid ideas that can be written anytime] 96 | 97 | ## Low Priority 98 | [Interesting but not urgent ideas] 99 | 100 | ## Future/Maybe 101 | [Ideas that need more research or aren't fully formed] 102 | -------------------------------------------------------------------------------- /.claude/commands/validation/frontend/scan-vue-patterns.md: -------------------------------------------------------------------------------- 1 | # Scan Vue 3.5 & Component Patterns 2 | 3 | I need to check Vue 3.5 composition patterns and component communication for: $ARGUMENTS 4 | 5 | ## Your Task 6 | 7 | Analyze Vue components for Vue 3.5 best practices, composition API usage, and proper component communication patterns. 8 | 9 | ## Execution Steps 10 | 11 | 1. **Vue 3.5 Composition API Compliance** 12 | - Props destructuring usage (Vue 3.5 style without `props` variable) 13 | - Options API vs Composition API detection 14 | - Proper `ref`, `reactive`, `computed`, `watch`, `watchEffect` usage 15 | - Missing setup function or ` 67 | ``` 68 | 69 | But built-in support would be cleaner and could access internal timings. 70 | 71 | ### Questions 72 | 73 | 1. **Is performance monitoring something you've considered?** I saw the excellent TypeScript types for viewport transforms but no performance APIs. 74 | 75 | 2. **Would this fit Vue Flow's philosophy?** I know you value a clean API surface. 76 | 77 | 3. **Alternative approaches?** Perhaps a plugin system where performance monitoring could be one example? 78 | 79 | ### Why Built-in Makes Sense 80 | 81 | - Vue Flow already has the perfect observation points in the transform system 82 | - Could leverage Vue's built-in scheduler APIs 83 | - Minimal overhead when disabled 84 | - Would help users optimize their node/edge implementations 85 | 86 | ### I'd Be Happy To 87 | 88 | - Create a proof-of-concept implementation 89 | - Research performance API best practices from other libraries 90 | - Document performance optimization patterns I've discovered 91 | 92 | Thanks for considering this! Even if it's not a fit for core, I'd love to hear your thoughts on performance monitoring in node-based UIs. 93 | 94 | P.S. The recent shallowRef optimizations were great - noticed the improvement in our large graphs! 95 | 96 | ## Why This Issue Works 97 | 98 | 1. **Adds Value**: Performance monitoring is universally useful 99 | 2. **Shows Expertise**: Demonstrates understanding of performance concerns 100 | 3. **Concrete Proposal**: Not just "make it faster" but specific implementation ideas 101 | 4. **Flexible Approach**: Open to alternatives like plugin system 102 | 5. **Offers to Help**: Shows commitment to contributing 103 | 6. **Acknowledges Recent Work**: Shows you're paying attention to their optimization efforts -------------------------------------------------------------------------------- /.claude/knowledge/vue-based-node-system/implementation/PHASE_1_COMPLETE.md: -------------------------------------------------------------------------------- 1 | # Phase 1: Transform Foundation - COMPLETE ✅ 2 | 3 | ## Overview 4 | 5 | Phase 1 established the core transform synchronization system that enables Vue components to render in perfect alignment with the LiteGraph canvas. 6 | 7 | ## Completed Features 8 | 9 | ### 1. TransformPane Component 10 | Created the foundation component that synchronizes canvas transforms to DOM: 11 | 12 | ```vue 13 | 17 | 18 | 19 | ``` 20 | 21 | **Key Implementation:** 22 | - Single CSS transform container 23 | - RAF-based transform updates 24 | - Viewport prop for culling preparation 25 | - Event emission for lifecycle hooks 26 | 27 | ### 2. Transform State Management 28 | Implemented `useTransformState` composable: 29 | - Reactive transform values (scale, offset) 30 | - Computed transform strings 31 | - Canvas event listeners 32 | - Coordinate conversion utilities 33 | 34 | ### 3. Basic Node Rendering 35 | Initial Vue node component structure: 36 | - `LGraphNode.vue` - Main container 37 | - `NodeHeader.vue` - Title and controls 38 | - `NodeSlots.vue` - Input/output connections 39 | - Position synchronization via CSS transforms 40 | 41 | ### 4. Feature Flag System 42 | Integrated with existing settings: 43 | ```typescript 44 | const isVueNodesEnabled = computed(() => 45 | settingStore.get('Comfy.VueNodes.Enabled') ?? true 46 | ) 47 | ``` 48 | 49 | ### 5. Debug Tools 50 | Comprehensive debug panel with: 51 | - Transform metrics (scale, offset) 52 | - Node count tracking 53 | - FPS monitoring 54 | - Feature flag overrides 55 | 56 | ## Technical Decisions 57 | 58 | ### CSS Transform Strategy 59 | Chose single container transform over individual node transforms: 60 | - **Performance**: O(1) vs O(n) DOM updates 61 | - **Simplicity**: Nodes use absolute positioning 62 | - **Quality**: Uniform scaling, no rounding errors 63 | 64 | ### Event-Driven Architecture 65 | Canvas events drive transform updates: 66 | - No polling or continuous sync 67 | - Updates only when canvas changes 68 | - Clean separation of concerns 69 | 70 | ### Non-Reactive Canvas References 71 | Store canvas/graph without Vue reactivity: 72 | ```typescript 73 | const canvasRef = shallowRef(null) 74 | ``` 75 | 76 | ## Challenges Solved 77 | 78 | ### 1. Coordinate System Alignment 79 | - Canvas uses its own transform matrix 80 | - Solution: Mirror exact transform values to CSS 81 | - Result: Pixel-perfect alignment 82 | 83 | ### 2. Performance During Pan/Zoom 84 | - Initial approach caused janky updates 85 | - Solution: RAF batching + CSS containment 86 | - Result: Smooth 60 FPS 87 | 88 | ### 3. Debug Panel Interference 89 | - Debug panel caused layout shifts 90 | - Solution: Fixed positioning outside transform 91 | - Result: Stable metrics display 92 | 93 | ## Code Locations 94 | 95 | - `/src/components/graph/TransformPane.vue` - Core container 96 | - `/src/composables/graph/useTransformState.ts` - Transform state 97 | - `/src/components/graph/GraphCanvas.vue` - Integration point 98 | - `/src/components/graph/vueNodes/LGraphNode.vue` - Node component 99 | 100 | ## Metrics 101 | 102 | - ✅ Transform sync working at 60 FPS 103 | - ✅ No memory leaks detected 104 | - ✅ Feature flag enables/disables cleanly 105 | - ✅ Debug tools provide real-time insights 106 | 107 | ## Lessons Learned 108 | 109 | 1. **CSS transforms are incredibly efficient** when used correctly 110 | 2. **Single container pattern** eliminates complexity 111 | 3. **RAF batching** is essential for smooth updates 112 | 4. **Debug tools** should be built from day one 113 | 114 | ## Foundation for Next Phases 115 | 116 | Phase 1 provides: 117 | - ✅ Reliable transform synchronization 118 | - ✅ Performance monitoring infrastructure 119 | - ✅ Clean component architecture 120 | - ✅ Feature flag system for safe iteration 121 | 122 | This foundation enables Phase 2 (lifecycle management) and beyond. -------------------------------------------------------------------------------- /.claude/knowledge/node-editor-performance-optimizations/flow-libraries-comparison.md: -------------------------------------------------------------------------------- 1 | # Flow Libraries Comprehensive Comparison 2 | 3 | ## Transform & Rendering Comparison Matrix 4 | 5 | | Feature | Rete.js | Vue Flow | React Flow | tldraw | 6 | |---------|---------|----------|------------|---------| 7 | | Transform Pattern | Dual (viewport + nodes) | Single viewport | Single viewport | Individual shapes | 8 | | Transform Container | `.holder` with scale + translate | `.vue-flow__transformationpane` | `.react-flow__viewport` | Per-shape transforms | 9 | | Node Positioning | Individual transforms | Individual transforms | Individual transforms | Matrix-based transforms | 10 | | Transform Origin | `0 0` | `0 0` | `0 0` | Varies by shape | 11 | | GPU Acceleration Hints | ❌ | ❌ | ❌ | ❌ | 12 | | will-change Usage | ❌ | ❌ | ❌ | ❌ | 13 | | translate3d/translateZ | ❌ | ❌ | ❌ | ❌ | 14 | | CSS Containment | ❌ | ❌ | ❌ | ✅ | 15 | | Viewport Culling | ❌ | ❌ | ❌ | ✅ | 16 | | Transform Caching | ❌ | ❌ | ❌ | ✅ (Mat class) | 17 | | RAF Batching | ❌ | ❌ | ❌ | ✅ | 18 | | Edge Technology | Framework-dependent | SVG `` | SVG `` | SVG `` | 19 | | Edge Container | Absolute positioned div | SVG element | SVG element | SVG per shape | 20 | | Edge Transforms | ❌ | ❌ | ❌ | ✅ (shape transforms) | 21 | | Path Calculation | Plugin handles | Built-in bezier | Built-in bezier | Per-shape custom | 22 | | Edge Animation Support | Plugin-dependent | CSS animations | CSS animations | Built-in tweening | 23 | | Label Technology | Plugin-dependent | HTML in foreignObject | React Portal | SVG text | 24 | | Label Positioning | Plugin-dependent | Path midpoint | Separate DOM layer | Shape-relative | 25 | | Label Transforms | Plugin-dependent | Inherits viewport | Independent | Matrix transforms | 26 | | Zoom Library | Custom | d3-zoom | d3-zoom | Custom | 27 | | Gesture Recognition | Basic | d3-based | d3-based | Advanced | 28 | | Event System | Plugin pipes | Vue events + d3 | React + d3 | Custom observer | 29 | | Lazy Listeners | ✅ | ❌ | ❌ | ✅ | 30 | | Event Batching | ❌ | Vue reactivity | React batching | ✅ | 31 | | Plugin System | ✅ Core feature | ❌ | ❌ | ❌ | 32 | | Framework Agnostic | ✅ | ❌ | ❌ | ✅ | 33 | | Extension System | ✅ Rich | ✅ Composables | ✅ Hooks | ✅ Tools | 34 | | Coordinate Space | Dual (viewport + node) | Single transformed | Single transformed | Shape-local | 35 | | Matrix Support | ❌ | ❌ | ❌ | ✅ Full 2D affine | 36 | | Animation System | Plugin-dependent | CSS/Vue transitions | CSS/React | Built-in tweening | 37 | | Spring Physics | ❌ | ❌ | ❌ | ✅ | 38 | | Easing Functions | Plugin-dependent | CSS/JS | CSS/JS | ✅ Custom | 39 | | Level of Detail (LOD) | ❌ | ❌ | ❌ | ✅ | 40 | | Text Shadow LOD | ❌ | ❌ | ❌ | ✅ | 41 | | Shape Simplification | ❌ | ❌ | ❌ | ✅ | 42 | | Render Skipping | ❌ | ❌ | ❌ | ✅ | 43 | | DOM Hierarchy | Minimal | Deep | Deep | Optimized | 44 | | z-index Management | DOM order | z-index | z-index | Layer system | 45 | | Foreign Objects | Plugin-dependent | ✅ | ❌ | ❌ | 46 | | Portal Usage | Plugin-dependent | ❌ | ✅ | ❌ | 47 | 48 | ## Legend 49 | 50 | - ✅ Full support / Feature present 51 | - ❌ Not supported / Feature absent 52 | - N/A Not applicable 53 | - Plugin-dependent: Varies based on which rendering plugin is used 54 | 55 | ## Key Takeaways 56 | 57 | 1. **Transform Strategies Vary Significantly** 58 | - Vue Flow & React Flow: Single viewport transform (simplest) 59 | - Rete.js: Dual transform system (most flexible) 60 | - tldraw: Individual shape transforms with matrices (most sophisticated) 61 | 62 | 2. **Performance Optimizations Are Lacking Across the Board** 63 | - None use GPU acceleration hints (will-change, translate3d) 64 | - Only tldraw implements viewport culling and LOD 65 | - Only tldraw uses requestAnimationFrame batching 66 | 67 | 3. **Edge Rendering Approaches** 68 | - Rete.js: Delegates to framework plugins 69 | - Vue Flow & React Flow: Native SVG paths 70 | - tldraw: Part of unified shape system 71 | 72 | 4. **Architecture Philosophy** 73 | - Rete.js: Maximum flexibility through plugins 74 | - Vue Flow & React Flow: Framework-specific optimization 75 | - tldraw: Performance-first with custom everything -------------------------------------------------------------------------------- /.claude/knowledge/comfyui-execution/VALIDATE_INPUTS.md: -------------------------------------------------------------------------------- 1 | # VALIDATE_INPUTS in ComfyUI 2 | 3 | ## Overview 4 | 5 | `VALIDATE_INPUTS` is a class method nodes can implement to provide custom input validation beyond the built-in type checking. 6 | 7 | ## Execution Context 8 | 9 | **Critical Timing**: `VALIDATE_INPUTS` only executes AFTER static validation passes. If static combo validation fails (lines 737-762), `VALIDATE_INPUTS` never runs. 10 | 11 | Location in `execution.py`: Lines 764-791 12 | 13 | ## Implementation Pattern 14 | 15 | ```python 16 | class MyNode: 17 | @classmethod 18 | def INPUT_TYPES(s): 19 | return { 20 | "required": { 21 | "file_path": ("STRING", {}), 22 | "mode": (["read", "write"], {}), 23 | } 24 | } 25 | 26 | @classmethod 27 | def VALIDATE_INPUTS(s, file_path, mode): 28 | # Custom validation with full context 29 | if mode == "write" and not os.access(file_path, os.W_OK): 30 | return f"No write permission for {file_path}" 31 | 32 | if mode == "read" and not os.path.exists(file_path): 33 | return f"File not found: {file_path}" 34 | 35 | return True # Validation passed 36 | ``` 37 | 38 | ## Method Signature 39 | 40 | ```python 41 | @classmethod 42 | def VALIDATE_INPUTS(cls, **kwargs): 43 | # kwargs contains all inputs by name 44 | # Return True for success 45 | # Return string for error message 46 | # Can also return ExecutionBlocker for advanced control 47 | ``` 48 | 49 | ## Input Access 50 | 51 | The method receives filtered inputs based on its signature: 52 | 53 | ```python 54 | # In execution.py 55 | argspec = inspect.getfullargspec(obj_class.VALIDATE_INPUTS) 56 | validate_function_inputs = argspec.args # ['cls', 'input1', 'input2'] 57 | validate_has_kwargs = argspec.varkw is not None # **kwargs present? 58 | 59 | # Only inputs matching signature are passed 60 | for x in input_data_all: 61 | if x in validate_function_inputs or validate_has_kwargs: 62 | input_filtered[x] = input_data_all[x] 63 | ``` 64 | 65 | ## Special Parameters 66 | 67 | - `input_types`: Include this parameter to receive type information 68 | ```python 69 | def VALIDATE_INPUTS(s, file_path, input_types): 70 | # input_types contains the received type info 71 | ``` 72 | 73 | ## Real Examples from Codebase 74 | 75 | ### File Validation 76 | ```python 77 | # From LoadImage 78 | @classmethod 79 | def VALIDATE_INPUTS(s, image): 80 | if not folder_paths.exists_annotated_filepath(image): 81 | return "Invalid image file: {}".format(image) 82 | return True 83 | ``` 84 | 85 | ### Latent File Validation 86 | ```python 87 | # From LoadLatent 88 | @classmethod 89 | def VALIDATE_INPUTS(s, latent): 90 | if not folder_paths.exists_annotated_filepath(latent): 91 | return "Invalid latent file: {}".format(latent) 92 | return True 93 | ``` 94 | 95 | ## Return Values 96 | 97 | - `True`: Validation successful 98 | - `False`: Generic validation failure 99 | - `str`: Specific error message (preferred) 100 | - `ExecutionBlocker`: Advanced control over execution flow 101 | 102 | ## Error Handling 103 | 104 | Failed validation produces: 105 | ```python 106 | error = { 107 | "type": "custom_validation_failed", 108 | "message": "Custom validation failed for node", 109 | "details": f"{input_name} - {error_message}", 110 | "extra_info": {"input_name": input_name} 111 | } 112 | ``` 113 | 114 | ## Use Cases 115 | 116 | 1. **File existence/permission checks** 117 | 2. **Cross-input validation** (e.g., width/height ratios) 118 | 3. **External resource validation** (API keys, URLs) 119 | 4. **Dynamic value validation** when static combo validation isn't suitable 120 | 5. **Complex business logic** that requires multiple inputs 121 | 122 | ## Limitations 123 | 124 | - **Never runs if static validation fails first** 125 | - Only receives inputs that match method signature 126 | - Cannot modify inputs, only validate them 127 | - Runs during prompt validation, not during actual execution -------------------------------------------------------------------------------- /.claude/commands/agents/AGENT-playbook-to-automated-agent-workflow.md: -------------------------------------------------------------------------------- 1 | # Convert Manual Playbook to Automated Agent Workflow 2 | 3 | You are a workflow automation specialist who transforms human-oriented documentation into precise, actionable instructions for AI agents. Your expertise is in creating deterministic, repeatable processes that work reliably in automated environments. 4 | 5 | ## Task 6 | 7 | Transform the following manual playbook into agent-executable instructions (leave the original file and create a copy of the transformed file in nearby directory called something similar to "agent-workflows" -- create it if it doesn't exist): 8 | 9 | 10 | $ARGUMENTS 11 | 12 | 13 | ## Instructions 14 | 15 | Follow these steps to create automated agent instructions: 16 | 17 | ### 1. Analysis Phase 18 | - Identify all vague references (e.g., "use a database", "check logs") 19 | - Note any time-based conditions that need automation logic 20 | - Find assumptions about human judgment or context 21 | - List any undefined file paths, tools, or systems 22 | 23 | ### 2. Specification Phase 24 | For each vague element, provide: 25 | - **Exact file paths** (e.g., `/data/reports/hashtag_analysis.json`) 26 | - **Specific tool commands** (e.g., `grep "ERROR" /var/log/app.log`) 27 | - **Conditional logic** for file existence and timing checks 28 | - **Explicit decision criteria** replacing human judgment 29 | 30 | ### 3. State-Aware Design 31 | Assume the agent may run this workflow multiple times. For each instruction: 32 | - Handle cases where files may or may not exist 33 | - Include timestamp/date checking logic where relevant 34 | - Provide clear success/failure criteria 35 | - Specify what to do if prerequisites are missing 36 | 37 | ### 4. Output Format 38 | Structure your response as: 39 | 40 | 41 | **Objective:** [Clear statement of what this workflow accomplishes] 42 | 43 | **Prerequisites:** 44 | - [List any required files, tools, or system states] 45 | 46 | **Instructions:** 47 | 1. [Step-by-step instructions with specific commands/file paths] 48 | 2. [Include conditional logic: "If X exists, then Y, otherwise Z"] 49 | 3. [Time-based checks: "If last run was more than N days ago..."] 50 | 51 | **Verification:** 52 | - [How to confirm the workflow completed successfully] 53 | - [What outputs/files should exist after completion] 54 | 55 | **Error Handling:** 56 | - [What to do if key files are missing] 57 | - [How to handle common failure scenarios] 58 | 59 | 60 | ## Examples 61 | 62 | 63 | **Before (Manual):** "Weekly hashtag reporting: review social media performance" 64 | 65 | **After (Automated):** 66 | ``` 67 | 1. Check file `/reports/hashtag_analysis.json` for last run date 68 | 2. If no file exists OR last run was >7 days ago: 69 | a. Execute: `python scripts/social_analytics.py --export /reports/hashtag_analysis.json` 70 | b. Generate summary: `python scripts/summarize_hashtags.py /reports/hashtag_analysis.json > /reports/weekly_hashtag_summary.md` 71 | 3. If file exists and last run was <7 days ago: skip processing 72 | ``` 73 | 74 | 75 | 76 | **Before (Manual):** "Use database or logs to check system health" 77 | 78 | **After (Automated):** 79 | ``` 80 | 1. Check system database: `mysql -e "SELECT COUNT(*) FROM active_connections" monitoring_db` 81 | 2. If database unavailable, fallback to log analysis: `tail -100 /var/log/system.log | grep -c "ERROR"` 82 | 3. If error count >10: create alert file `/alerts/system_health_warning.txt` with timestamp 83 | ``` 84 | 85 | 86 | ## Quality Criteria 87 | 88 | Your automated workflow must be: 89 | - **Deterministic:** Same inputs always produce same outputs 90 | - **Self-contained:** No undefined file paths or tools 91 | - **Resilient:** Handles missing files and edge cases gracefully 92 | - **Verifiable:** Clear success/failure indicators 93 | 94 | If any part of the manual playbook cannot be automated without additional context, explicitly state: "REQUIRES CLARIFICATION:" followed by specific questions about the unclear elements. 95 | 96 | Never make assumptions about file locations, tool availability, or system configuration that aren't specified in the original playbook. 97 | -------------------------------------------------------------------------------- /.claude/knowledge/claude-code-best-practices/09-pattern-consistency.md: -------------------------------------------------------------------------------- 1 | # Pattern Consistency Enforcement 2 | 3 | Before creating any new command, ensure it maintains consistency with existing patterns: 4 | 5 | ## 1. Search for Similar Commands First 6 | - Look for existing commands that solve similar problems 7 | - Check both project-specific and global command directories 8 | - Analyze their structure, naming conventions, and approach 9 | 10 | ## 2. Match Existing Patterns 11 | - Follow the same formatting style as other commands 12 | - Use consistent variable naming (e.g., always use `$ARGUMENTS` for parameters) 13 | - Maintain similar section headers and organization 14 | 15 | ## 3. Align with Project Conventions 16 | - Check for any README files in the commands directories 17 | - Look for established patterns in command naming (kebab-case, prefixes, etc.) 18 | - Ensure your command fits logically within the existing command hierarchy 19 | 20 | ## 4. Reuse Common Components 21 | - If other commands use specific tools or workflows, adopt the same approach 22 | - Don't reinvent patterns that already exist in the command library 23 | - Reference and build upon existing command structures when appropriate 24 | 25 | ## Command Naming Conventions 26 | 27 | Follow these patterns for consistency: 28 | 29 | ### Project Commands 30 | - Use descriptive kebab-case names: `fix-github-issue`, `run-test-suite` 31 | - Group related commands with prefixes: `db-migrate`, `db-backup`, `db-restore` 32 | - Keep names concise but clear about the command's purpose 33 | 34 | ### Global Commands 35 | - Prefix with domain if applicable: `aws-deploy`, `docker-build` 36 | - Use verbs that clearly indicate action: `generate-`, `analyze-`, `create-` 37 | - Avoid overly generic names that could conflict 38 | 39 | ## Structure Patterns 40 | 41 | ### Standard Command Template 42 | ```md 43 | # [Command Title] 44 | 45 | [Brief description of what the command does] 46 | 47 | 48 | [Task description with $ARGUMENTS placeholder] 49 | 50 | 51 | ## Steps 52 | 53 | 1. [First step] 54 | 2. [Second step] 55 | 3. [Continue numbered steps...] 56 | 57 | ## Important Notes 58 | 59 | - [Any warnings or important considerations] 60 | - [Dependencies or prerequisites] 61 | 62 | ## Expected Output 63 | 64 | [Description of what the command will produce] 65 | ``` 66 | 67 | ### Complex Command Template 68 | ```md 69 | # [Command Title] 70 | 71 | 72 | You are [specific role/expertise]. 73 | 74 | 75 | 76 | [Any necessary background or context] 77 | 78 | 79 | 80 | [Detailed task description with $ARGUMENTS] 81 | 82 | 83 | 84 | 1. [Detailed step] 85 | 2. [Another step] 86 | - [Sub-step if needed] 87 | - [Another sub-step] 88 | 89 | 90 | 91 | - [Limitation or requirement] 92 | - [Another constraint] 93 | 94 | 95 | 96 | 97 | Input: [Example input] 98 | Output: [Expected output] 99 | 100 | 101 | 102 | 103 | [Specific formatting requirements] 104 | 105 | ``` 106 | 107 | ## Integration Patterns 108 | 109 | ### Tool Usage 110 | - If commands in the directory use `gh` for GitHub operations, your command should too 111 | - Match the error handling approaches used in similar commands 112 | - Follow established patterns for file operations, API calls, etc. 113 | 114 | ### Documentation References 115 | - Link to the same documentation sources used by related commands 116 | - Maintain consistent citation and reference styles 117 | - Use the same format for external links and resources 118 | 119 | ## Quality Checklist 120 | 121 | Before finalizing a new command: 122 | 123 | - [ ] Checked for similar existing commands 124 | - [ ] Followed naming conventions from the command directory 125 | - [ ] Used consistent structure and formatting 126 | - [ ] Adopted established tool usage patterns 127 | - [ ] Aligned with project-specific conventions in CLAUDE.md 128 | - [ ] Tested the command with various inputs 129 | - [ ] Documented any new patterns introduced 130 | - [ ] Ensured backward compatibility with related commands -------------------------------------------------------------------------------- /.claude/commands/agents/AGENT-summarize-and-log-current-session.md: -------------------------------------------------------------------------------- 1 | Your task is to create an ultra-compact summary of our entire conversation with structured metadata AND intelligently update knowledge folders when warranted. Follow these requirements exactly: 2 | 3 | ## Summary Requirements 4 | 5 | 1. **Metadata Header (YAML Frontmatter)**: 6 | ```yaml 7 | --- 8 | title: "Brief descriptive title (5-10 words)" 9 | tags: [keyword1, keyword2, keyword3, ...] # 5-10 most relevant keywords 10 | project: "project-name" # Extract from file paths if possible 11 | complexity: low|medium|high # Based on scope and technical depth 12 | outcome: success|partial|blocked # Task completion status 13 | duration: "Xh Ym" # Estimate based on conversation length 14 | technologies: [tech1, tech2, ...] # Languages, frameworks, tools used 15 | key_files: 16 | - /path/to/important/file1 17 | - /path/to/important/file2 18 | decisions: 19 | - "Key technical decision made" 20 | - "Important approach chosen" 21 | --- 22 | ``` 23 | 24 | 2. **Maximum Information Density**: Every sentence must convey multiple ideas. Eliminate all filler words, redundant phrases, and unnecessary transitions. Think of this as creating a reference card, not prose. 25 | 26 | 3. **Include All Critical Elements**: 27 | - Core topics/problems discussed 28 | - Exact absolute file paths mentioned or worked with 29 | - URLs/links referenced 30 | - Key decisions made 31 | - Solutions implemented 32 | - Commands executed 33 | - Errors encountered and resolutions 34 | 35 | 4. **Structure**: 36 | - Start with a one-line executive summary immediately after metadata 37 | - Group related items under ultra-brief headers 38 | - Use bullet points with extreme brevity 39 | - Include timestamp markers for chronological context if relevant 40 | 41 | 5. **File Handling**: 42 | - Save to: `~/.claude/compacted-summaries/` 43 | - Filename format: `summary-YYYY-MM-DD-HHMMSS-semantic-description.md` 44 | - Use current timestamp for YYYY-MM-DD-HHMMSS 45 | - Add a kebab-case semantic description of the main topics (3-7 words) 46 | - Example: `summary-2025-06-29-181658-comfyui-vue-widget-interfaces.md` 47 | - CRITICAL: First check if a file with the same name exists 48 | - If it exists, append `-v2`, `-v3`, etc. until you find an available filename 49 | - This is essential as multiple people may be writing to this folder simultaneously 50 | 51 | ## Knowledge Update Requirements 52 | 53 | After creating the summary, evaluate if this conversation warrants updates to knowledge folders: 54 | 55 | 1. **Criteria for Knowledge Updates**: 56 | - New technical patterns or solutions discovered 57 | - Reusable code architectures or implementations 58 | - Important system behaviors or quirks documented 59 | - Best practices or anti-patterns identified 60 | - Complex problem-solving approaches that could help future tasks 61 | 62 | 2. **Knowledge Organization**: 63 | - Check existing knowledge folders in `~/.claude/knowledge/` 64 | - Create new topic folders if needed (kebab-case naming) 65 | - Update or create markdown files with clear, reusable documentation 66 | - Focus on generalizable patterns, not project-specific details 67 | 68 | 3. **Knowledge File Format**: 69 | ```markdown 70 | # [Clear Topic Title] 71 | 72 | ## Context 73 | Brief explanation of when/why this applies 74 | 75 | ## Solution/Pattern 76 | The actual reusable content 77 | 78 | ## Examples 79 | Concrete examples if helpful 80 | 81 | ## Related 82 | Links to other relevant knowledge files 83 | ``` 84 | 85 | ## Examples of Extreme Brevity 86 | 87 | **Good**: "Implemented Vue3 widget system: created BaseWidget.vue, integrated PrimeVue DataTable, fixed TypeScript prop validation errors, 47 files modified" 88 | 89 | **Bad**: "We worked on implementing a widget system using Vue 3. Created a base widget component and integrated it with PrimeVue's DataTable component. Also fixed some TypeScript errors related to prop validation. Modified many files in the process." 90 | 91 | ## Execution 92 | 93 | This should be run as an Agent when requested to summarize a conversation. Include both the summary creation AND knowledge updates if warranted. -------------------------------------------------------------------------------- /.claude/commands/github/SOLVEBUG-solve-issue-tdd.md: -------------------------------------------------------------------------------- 1 | # Solve GitHub Issue with Test-Driven Development 2 | 3 | Your task is to fetch and solve the GitHub issue: **$ARGUMENTS** using test-driven development (TDD). 4 | 5 | ## Context 6 | 7 | Test-driven development becomes extremely powerful with agentic coding. You will perform best when you have a clear target to iterate against—in this case, test cases that define expected behavior. This workflow ensures robust, well-tested solutions. 8 | 9 | ## Instructions 10 | 11 | Follow these steps in sequence. **Do not skip steps or work ahead.** 12 | 13 | ### Step 1: Issue Analysis 14 | 15 | 1. Use `gh issue view $ARGUMENTS` to fetch the complete issue details 16 | 2. Understand the problem, requirements, and expected behavior described 17 | 3. Identify the scope of changes needed 18 | 4. Search the codebase for relevant files and existing patterns 19 | 5. **Do not write any code yet** - this is analysis only 20 | 21 | 22 | ### Step 2: Test Design (TDD Phase 1) 23 | 24 | 1. Based on the issue requirements, write comprehensive tests that define the expected behavior 25 | 2. Focus on **expected input/output pairs** from the issue description 26 | 3. **Be explicit about doing test-driven development** - avoid creating mock implementations for functionality that doesn't exist yet 27 | 4. Write tests that will **fail initially** since the functionality isn't implemented 28 | 5. Include edge cases and error conditions mentioned in the issue 29 | 6. **Do not write any implementation code** - only tests 30 | 31 | 32 | ### Step 3: Test Verification 33 | 34 | 1. Run the tests you just created 35 | 2. **Confirm they fail** as expected (this proves the functionality doesn't exist yet) 36 | 3. Verify the test failures are for the right reasons (missing functionality, not syntax errors) 37 | 4. If tests pass unexpectedly, the functionality may already exist - investigate further 38 | 39 | 40 | ### Step 4: Commit Tests 41 | 42 | 1. Review the tests to ensure they properly capture the issue requirements 43 | 2. When satisfied with test coverage and quality, commit the tests with a descriptive message 44 | 3. Use format: `[test] Add tests for issue #X - [brief description]` 45 | 46 | 47 | ### Step 5: Implementation (TDD Phase 2) 48 | 49 | 1. Now write code that makes the tests pass 50 | 2. **Do not modify the tests** - they define the contract 51 | 3. Implement the minimum functionality needed to pass each test 52 | 4. Run tests frequently and iterate on the implementation 53 | 5. **Keep going until all tests pass** - this may take multiple iterations 54 | 6. Focus on making tests pass first, optimize later if needed 55 | 56 | 57 | ### Step 6: Verification & Validation 58 | 59 | 1. Ensure all tests pass consistently 60 | 2. Run any existing test suites to verify no regressions 61 | 3. **Use independent verification**: Create a subagent to review the implementation and ensure it's not overfitting to the tests 62 | 4. Check that the solution actually addresses the original issue requirements 63 | 5. Test edge cases manually if needed 64 | 65 | 66 | ### Step 7: Final Commit & Cleanup 67 | 68 | 1. When satisfied with the implementation, commit the code changes 69 | 2. Use format: `[feat] Implement solution for issue #X - [brief description]` 70 | 3. Ensure the solution is complete and ready for review 71 | 4. Run any required linting or formatting tools 72 | 73 | 74 | ## Important Notes 75 | 76 | - **Do not jump ahead** - follow the TDD workflow strictly 77 | - **Tests define the contract** - don't modify them during implementation 78 | - **Iterate until success** - expect multiple rounds of code → test → adjust 79 | - **Use subagents for verification** to catch overfitting or missed requirements 80 | - **Focus on the issue requirements** - don't add unnecessary features 81 | 82 | ## Success Criteria 83 | 84 | ✅ Issue requirements fully understood 85 | ✅ Comprehensive tests written and initially failing 86 | ✅ Tests committed before implementation 87 | ✅ Implementation makes all tests pass 88 | ✅ No regressions in existing functionality 89 | ✅ Independent verification confirms solution quality 90 | ✅ Final implementation committed 91 | 92 | Begin with Step 1 and work through each phase methodically. -------------------------------------------------------------------------------- /project-summaries-for-agents/vue-flow/github-issue-ideas/README.md: -------------------------------------------------------------------------------- 1 | # Vue Flow GitHub Issue Ideas 2 | 3 | This directory contains well-researched GitHub issue ideas designed to build relationships with the Vue Flow development team while showcasing technical expertise. 4 | 5 | ## Issue Strategy 6 | 7 | Each issue is crafted to: 8 | - **Show Deep Technical Understanding** - References actual Vue Flow code and architecture 9 | - **Provide Value** - Offers insights, benchmarks, or solutions 10 | - **Build Relationships** - Uses collaborative language and acknowledges good work 11 | - **Open Discussions** - Asks for input rather than demanding features 12 | - **Offer Contributions** - Shows willingness to help implement solutions 13 | 14 | ## Issue Categories 15 | 16 | ### 🔍 Performance & Optimization 17 | 1. **[Transform Zoom Pixel Stretching](./transform-zoom-pixel-stretch-issue.md)** 18 | - Advanced zoom optimization strategies 19 | - Hybrid DOM/CSS transform approach 20 | - Visual quality at extreme zoom levels 21 | 22 | 2. **[Viewport Culling Optimization](./viewport-culling-optimization-discussion.md)** 23 | - Large graph performance (1000+ nodes) 24 | - Virtual scrolling and spatial indexing 25 | - CSS containment strategies 26 | 27 | 3. **[Edge Path Optimization](./edge-path-optimization-discussion.md)** 28 | - Dense graph edge rendering 29 | - Path calculation memoization 30 | - Batch updates and LOD systems 31 | 32 | 4. **[Transform Performance Monitoring](./transform-performance-monitoring.md)** 33 | - Built-in performance metrics 34 | - Frame timing and reflow detection 35 | - Development and production insights 36 | 37 | ### 🎯 Precision & Quality 38 | 5. **[Handle Connection Precision](./handle-connection-precision-enhancement.md)** 39 | - Sub-pixel precision for handles 40 | - Browser consistency improvements 41 | - Specialized use case optimizations 42 | 43 | ## How to Use These Issues 44 | 45 | ### Before Posting 46 | 1. **Study the latest Vue Flow releases** - Ensure the issue is still relevant 47 | 2. **Check existing issues** - Make sure you're not duplicating discussions 48 | 3. **Personalize the content** - Add your specific use case details 49 | 4. **Update code references** - Verify line numbers and file paths are current 50 | 51 | ### Posting Strategy 52 | - **Space them out** - Don't post all at once 53 | - **Start with the most valuable** - Lead with your strongest technical insight 54 | - **Engage authentically** - Respond thoughtfully to any replies 55 | - **Follow through** - If you offer to contribute, be ready to do so 56 | 57 | ### Customization Tips 58 | - Replace generic use cases with your specific project details 59 | - Add your own benchmarking data if available 60 | - Reference your company's technical challenges 61 | - Include links to relevant research or related work 62 | 63 | ## Technical Credibility Factors 64 | 65 | Each issue demonstrates: 66 | - **Code Analysis** - References actual Vue Flow implementation details 67 | - **Architecture Understanding** - Shows grasp of design decisions 68 | - **Performance Awareness** - Includes timing, benchmarks, and trade-offs 69 | - **Browser Expertise** - Discusses cross-browser considerations 70 | - **Scaling Experience** - Addresses real-world performance at scale 71 | 72 | ## Expected Outcomes 73 | 74 | Well-crafted issues typically result in: 75 | - **Technical discussions** with maintainers 76 | - **Architecture insights** from the core team 77 | - **Feature consideration** for future releases 78 | - **Contribution opportunities** if solutions are needed 79 | - **Professional relationships** with other experts in the field 80 | 81 | ## Notes on Tone 82 | 83 | The issues use: 84 | - **Collaborative language** ("I'd love to discuss" vs "You should implement") 85 | - **Acknowledgment of good work** - Genuine appreciation for Vue Flow's quality 86 | - **Humble expertise** - Shows knowledge without being arrogant 87 | - **Open-ended questions** - Invites discussion rather than demanding answers 88 | 89 | ## Success Metrics 90 | 91 | Good issues will: 92 | - Generate thoughtful responses from maintainers 93 | - Lead to technical discussions about implementation 94 | - Potentially influence future Vue Flow features 95 | - Establish you as a knowledgeable community member 96 | - Open doors for collaboration opportunities 97 | 98 | Remember: The goal is building relationships and contributing to the community, not just getting features added. --------------------------------------------------------------------------------