{"owner":"alpinejs","repo":"alpine","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# Alpine.js Development Guidelines\n\n## Pull Request Evaluation Criteria\n\nWhen evaluating pull requests for Alpine.js, assess the following:\n\n### 1. Tests\n- Are tests provided for the change?\n- Do existing tests still pass?\n- For configuration changes (package.json, build scripts), tests may not be required\n\n### 2. Code Style\n- Does the code match Alpine's existing patterns?\n- Check indentation, naming conventions, and structure\n- For package.json changes, ensure consistency with other packages in the monorepo\n\n### 3. Code Quality\n- Is the code clean and maintainable?\n- Is the change focused and minimal?\n- Are there any unnecessary changes or complexity?\n- Does this PR contain changes that should apply elsewhere?\n\n### 4. Simplicity\n- Is this a simple, focused change?\n- Does it follow Alpine's philosophy of simplicity?\n- Could it be implemented more simply?\n- Are the proposed additions intuitive for users? or do they require extra knowledge that they have to dig for.\n\n### 5. Precedent\n- Does this PR (both public facing additions and internal implementation) follow established precedents in the project\n- Does it use terms that are unfamiliar to the project as of yet?\n\n### 6. Description Quality\n- Is there a clear explanation of what/why/how?\n- Are breaking changes documented?\n- Is backward compatibility addressed?\n\n### 7. Community Engagement\n- Are there comments, reviews, or discussions?\n- Has it been approved by maintainers?\n- Are there any conflicting opinions or unresolved concerns?\n\n### Mergeability Rating\nBased on the above, rate as:\n- **HIGH**: Ready to merge (all criteria met, approved)\n- **MEDIUM**: Needs attention (technically sound but missing reviews/tests)\n- **LOW**: Requires work (has issues or conflicts to resolve)\n\n## Project Structure\n\nAlpine.js is a monorepo with packages in `/packages/`:\n- Each package has its own package.json\n- Build outputs go to `dist/` with `.cjs.js`, `.esm.js`, and `.min.js` versions\n- Browser tests use Cypress, unit tests use Vitest\n- CI runs on GitHub Actions\n\n## Common Commands\n\n```bash\n# Build\nnpm run build                # Build all packages\n\n# Browser tests (Cypress)\nnpm test                     # Run all tests\nnpx cypress run --spec ./tests/cypress/integration/[filename].spec.js  # Run single spec\n\n# Unit tests (Vitest)\nnpx vitest run tests/vitest/[filename].spec.js  # Run single spec\n\n# Review PRs\ngh pr list                   # List open PRs\ngh pr view [number]          # View PR details\ngh pr diff [number]          # View code changes\ngh pr checks [number]        # Check CI status\n```\n\n## Manual Testing\n\n1. Edit `./index.html` at project root\n2. Open in browser at `http://alpine.test/` (assumes local dev server mapped to directory name)\n\n## Summary\n\nAfter assessing the pull request on the above qualities, provide a summary explaining the problem this PR addresses and the fix, and why it's a good or bad fix. Do it in plain language as if you are personally advising me on what the PR is and weather or not I should merge it. And if not, what might need to be addressed first. If things need to be addressed, offer to address them yourself.\n\nPlease use code snippets to establish a starting point and and ending point if helpful. For example, when explaining the problem, it is often easier to provide a brief explanation alongside a code snippet of what is currently problematic, then when explaining the solution, showing what new code will allow a fix if applicable."},"files":{"CLAUDE.md":"# Alpine.js Development Guidelines\n\n## Pull Request Evaluation Criteria\n\nWhen evaluating pull requests for Alpine.js, assess the following:\n\n### 1. Tests\n- Are tests provided for the change?\n- Do existing tests still pass?\n- For configuration changes (package.json, build scripts), tests may not be required\n\n### 2. Code Style\n- Does the code match Alpine's existing patterns?\n- Check indentation, naming conventions, and structure\n- For package.json changes, ensure consistency with other packages in the monorepo\n\n### 3. Code Quality\n- Is the code clean and maintainable?\n- Is the change focused and minimal?\n- Are there any unnecessary changes or complexity?\n- Does this PR contain changes that should apply elsewhere?\n\n### 4. Simplicity\n- Is this a simple, focused change?\n- Does it follow Alpine's philosophy of simplicity?\n- Could it be implemented more simply?\n- Are the proposed additions intuitive for users? or do they require extra knowledge that they have to dig for.\n\n### 5. Precedent\n- Does this PR (both public facing additions and internal implementation) follow established precedents in the project\n- Does it use terms that are unfamiliar to the project as of yet?\n\n### 6. Description Quality\n- Is there a clear explanation of what/why/how?\n- Are breaking changes documented?\n- Is backward compatibility addressed?\n\n### 7. Community Engagement\n- Are there comments, reviews, or discussions?\n- Has it been approved by maintainers?\n- Are there any conflicting opinions or unresolved concerns?\n\n### Mergeability Rating\nBased on the above, rate as:\n- **HIGH**: Ready to merge (all criteria met, approved)\n- **MEDIUM**: Needs attention (technically sound but missing reviews/tests)\n- **LOW**: Requires work (has issues or conflicts to resolve)\n\n## Project Structure\n\nAlpine.js is a monorepo with packages in `/packages/`:\n- Each package has its own package.json\n- Build outputs go to `dist/` with `.cjs.js`, `.esm.js`, and `.min.js` versions\n- Browser tests use Cypress, unit tests use Vitest\n- CI runs on GitHub Actions\n\n## Common Commands\n\n```bash\n# Build\nnpm run build                # Build all packages\n\n# Browser tests (Cypress)\nnpm test                     # Run all tests\nnpx cypress run --spec ./tests/cypress/integration/[filename].spec.js  # Run single spec\n\n# Unit tests (Vitest)\nnpx vitest run tests/vitest/[filename].spec.js  # Run single spec\n\n# Review PRs\ngh pr list                   # List open PRs\ngh pr view [number]          # View PR details\ngh pr diff [number]          # View code changes\ngh pr checks [number]        # Check CI status\n```\n\n## Manual Testing\n\n1. Edit `./index.html` at project root\n2. Open in browser at `http://alpine.test/` (assumes local dev server mapped to directory name)\n\n## Summary\n\nAfter assessing the pull request on the above qualities, provide a summary explaining the problem this PR addresses and the fix, and why it's a good or bad fix. Do it in plain language as if you are personally advising me on what the PR is and weather or not I should merge it. And if not, what might need to be addressed first. If things need to be addressed, offer to address them yourself.\n\nPlease use code snippets to establish a starting point and and ending point if helpful. For example, when explaining the problem, it is often easier to provide a brief explanation alongside a code snippet of what is currently problematic, then when explaining the solution, showing what new code will allow a fix if applicable."},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Alpine.js Development Guidelines\n\n## Pull Request Evaluation Criteria\n\nWhen evaluating pull requests for Alpine.js, assess the following:\n\n### 1. Tests\n- Are tests provided for the change?\n- Do existing tests still pass?\n- For configuration changes (package.json, build scripts), tests may not be required\n\n### 2. Code Style\n- Does the code match Alpine's existing patterns?\n- Check indentation, naming conventions, and structure\n- For package.json changes, ensure consistency with other packages in the monorepo\n\n### 3. Code Quality\n- Is the code clean and maintainable?\n- Is the change focused and minimal?\n- Are there any unnecessary changes or complexity?\n- Does this PR contain changes that should apply elsewhere?\n\n### 4. Simplicity\n- Is this a simple, focused change?\n- Does it follow Alpine's philosophy of simplicity?\n- Could it be implemented more simply?\n- Are the proposed additions intuitive for users? or do they require extra knowledge that they have to dig for.\n\n### 5. Precedent\n- Does this PR (both public facing additions and internal implementation) follow established precedents in the project\n- Does it use terms that are unfamiliar to the project as of yet?\n\n### 6. Description Quality\n- Is there a clear explanation of what/why/how?\n- Are breaking changes documented?\n- Is backward compatibility addressed?\n\n### 7. Community Engagement\n- Are there comments, reviews, or discussions?\n- Has it been approved by maintainers?\n- Are there any conflicting opinions or unresolved concerns?\n\n### Mergeability Rating\nBased on the above, rate as:\n- **HIGH**: Ready to merge (all criteria met, approved)\n- **MEDIUM**: Needs attention (technically sound but missing reviews/tests)\n- **LOW**: Requires work (has issues or conflicts to resolve)\n\n## Project Structure\n\nAlpine.js is a monorepo with packages in `/packages/`:\n- Each package has its own package.json\n- Build outputs go to `dist/` with `.cjs.js`, `.esm.js`, and `.min.js` versions\n- Browser tests use Cypress, unit tests use Vitest\n- CI runs on GitHub Actions\n\n## Common Commands\n\n```bash\n# Build\nnpm run build                # Build all packages\n\n# Browser tests (Cypress)\nnpm test                     # Run all tests\nnpx cypress run --spec ./tests/cypress/integration/[filename].spec.js  # Run single spec\n\n# Unit tests (Vitest)\nnpx vitest run tests/vitest/[filename].spec.js  # Run single spec\n\n# Review PRs\ngh pr list                   # List open PRs\ngh pr view [number]          # View PR details\ngh pr diff [number]          # View code changes\ngh pr checks [number]        # Check CI status\n```\n\n## Manual Testing\n\n1. Edit `./index.html` at project root\n2. Open in browser at `http://alpine.test/` (assumes local dev server mapped to directory name)\n\n## Summary\n\nAfter assessing the pull request on the above qualities, provide a summary explaining the problem this PR addresses and the fix, and why it's a good or bad fix. Do it in plain language as if you are personally advising me on what the PR is and weather or not I should merge it. And if not, what might need to be addressed first. If things need to be addressed, offer to address them yourself.\n\nPlease use code snippets to establish a starting point and and ending point if helpful. For example, when explaining the problem, it is often easier to provide a brief explanation alongside a code snippet of what is currently problematic, then when explaining the solution, showing what new code will allow a fix if applicable.","category":"root","tokens":867}]}