8cec6ceebb
## Summary This PR integrates Claude Code AI assistant capabilities into the Nx repository through GitHub Actions and workspace configuration. ## Changes Made ### 🤖 GitHub Actions Integration - **Added `.github/workflows/claude.yml`**: GitHub Actions workflow that triggers Claude Code on: - Issue comments containing `@claude` - Pull request review comments containing `@claude` - Pull request reviews containing `@claude` - New issues with `@claude` in title or body - Configured appropriate permissions for repository access and PR/issue management - See [Claude Code GitHub Actions documentation](https://docs.anthropic.com/en/docs/claude-code/cli-usage#github-actions) for usage details ### 📝 Project Documentation & Configuration - **Added `CLAUDE.md`**: Comprehensive instructions for Claude Code including: - Repository-specific guidance and best practices - Essential commands for development workflow - Testing procedures (individual projects → affected projects → e2e tests) - GitHub issue resolution workflow - Pre-push validation requirements - **Added `.claude/settings.json`**: Claude Code permissions and environment configuration - **Added `.mcp.json`**: Model Context Protocol server configuration for Nx workspace integration ### 🔧 Workspace Setup - **Updated `package.json`**: Added `nx-mcp` dependency for enhanced workspace integration - **Updated `pnpm-lock.yaml`**: Lock file changes for new dependency - **Updated `.gitignore`**: Added Claude-specific ignore patterns - **Updated `CODEOWNERS`**: Assigned ownership of Claude-related files to @FrozenPandaz - **Updated `CONTRIBUTING.md`**: Enhanced contribution guidelines with technology stack information ## Benefits - Enables AI-assisted development and issue resolution through GitHub - Provides Claude with deep understanding of Nx workspace structure via MCP - Establishes clear development workflows and validation procedures - Maintains security through configured permissions and environment settings ## Usage After this PR is merged, team members and contributors can: 1. Comment `@claude` in issues or PRs to get AI assistance 2. Use Claude Code locally with enhanced Nx workspace understanding 3. Follow established workflows for testing and validation For more information, see the [Claude Code documentation](https://docs.anthropic.com/en/docs/claude-code). ## Test Plan - [x] Verify GitHub Actions workflow syntax is valid - [x] Confirm Claude Code configuration files are properly structured - [x] Validate new dependency integration - [x] Test workflow triggers on issue/PR interactions 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
158 lines
5.2 KiB
Markdown
158 lines
5.2 KiB
Markdown
When responding to queries about this repository:
|
|
|
|
1. Use the `nx_workspace` mcp tool for understanding the workspace architecture when appropriate
|
|
2. Suggest relevant commands from the "Essential Commands" section when applicable
|
|
3. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph analysis
|
|
4. Mention the plugin ecosystem and support for various frameworks when relevant
|
|
5. Emphasize the importance of running the full validation suite before committing changes
|
|
|
|
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this file.
|
|
|
|
## GitHub Issue Response Mode
|
|
|
|
When responding to GitHub issues, determine your approach based on how the request is phrased:
|
|
|
|
### Plan-First Mode (Default)
|
|
|
|
Use this approach when users ask you to:
|
|
|
|
- "analyze", "investigate", "assess", "review", "examine", or "plan"
|
|
- Or when the request is ambiguous
|
|
|
|
In this mode:
|
|
|
|
1. Provide a detailed analysis of the issue
|
|
2. Create a comprehensive implementation plan
|
|
3. Break down the solution into clear steps
|
|
4. Then please post the plan as a comment on the issue
|
|
|
|
### Immediate Implementation Mode
|
|
|
|
Use this approach when users ask you to:
|
|
|
|
- "fix", "implement", "solve", "build", "create", "update", or "add"
|
|
- Or when they explicitly request immediate action
|
|
|
|
In this mode:
|
|
|
|
1. Analyze the issue quickly
|
|
2. Implement the complete solution immediately
|
|
3. Make all necessary code changes. Please make multiple commits so that the changes are easier to review.
|
|
4. Run appropriate tests and validation
|
|
5. If the tests, are not passing, please fix the issues and continue doing this up to 3 more times until the tests pass
|
|
6. Once the tests pass, push a branch and then suggest opening a PR which has a description of the changes made, and that
|
|
it make sure that it explicitly says "Fixes #ISSUE_NUMBER" to automatically close the issue when the PR is merged.
|
|
|
|
## Avoid making changes to generated files
|
|
|
|
Files under `generated` directories are generated based on a different source file and should not be modified directly.
|
|
Find the underlying source and modify that instead.
|
|
|
|
## Essential Commands
|
|
|
|
### Code Formatting
|
|
|
|
After code changes are made, please make sure to format the files with prettier via `npx prettier -- FILE_NAME`
|
|
|
|
### Pre-push Validation
|
|
|
|
```bash
|
|
# Full validation suite - run before committing
|
|
pnpm nx prepush
|
|
```
|
|
|
|
If the prepush validation suite fails, please fix the issues before proceeding with your work. This ensures that all code adheres to the project's standards and passes all tests.
|
|
|
|
### Testing Changes
|
|
|
|
After code changes are made, first test the specific project where the changes were made:
|
|
|
|
```bash
|
|
nx run-many -t test,build,lint -p PROJECT_NAME
|
|
```
|
|
|
|
After verifying the individual project, validate that the changes in projects which have been affected:
|
|
|
|
```bash
|
|
# Test only affected projects (recommended for development)
|
|
nx affected -t build,test,lint
|
|
```
|
|
|
|
As the last step, run the e2e tests to fully ensure that changes are valid:
|
|
|
|
```bash
|
|
# Run affected e2e tests (recommended for development)
|
|
nx affected -t e2e-local
|
|
```
|
|
|
|
## Fixing GitHub Issues
|
|
|
|
When working on a GitHub issue, follow this systematic approach:
|
|
|
|
### 1. Get Issue Details
|
|
|
|
```bash
|
|
# Get issue details using GitHub CLI (replace ISSUE_NUMBER with actual number)
|
|
gh issue view ISSUE_NUMBER
|
|
```
|
|
|
|
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
|
|
|
|
### 2. Analyze the Plan
|
|
|
|
- Look for a plan or implementation details in the issue description
|
|
- Check comments for additional context or clarification
|
|
- Identify affected projects and components
|
|
|
|
### 3. Implement the Solution
|
|
|
|
- Follow the plan outlined in the issue
|
|
- Make focused changes that address the specific problem
|
|
- Ensure code follows existing patterns and conventions
|
|
|
|
### 4. Run Full Validation
|
|
|
|
Use the testing workflow from the "Essential Commands" section.
|
|
|
|
### 5. Submit Pull Request
|
|
|
|
- Create a descriptive PR title that references the issue
|
|
- Include "Fixes #ISSUE_NUMBER" in the PR description
|
|
- Provide a clear summary of changes made
|
|
- Request appropriate reviewers
|
|
|
|
## Pull Request Template
|
|
|
|
When creating a pull request, follow the template found in `.github/PULL_REQUEST_TEMPLATE.md`. The template includes:
|
|
|
|
### Required Sections
|
|
|
|
1. **Current Behavior**: Describe the behavior we have today
|
|
2. **Expected Behavior**: Describe the behavior we should expect with the changes in this PR
|
|
3. **Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
|
|
|
|
### Template Format
|
|
|
|
```markdown
|
|
## Current Behavior
|
|
|
|
<!-- This is the behavior we have today -->
|
|
|
|
## Expected Behavior
|
|
|
|
<!-- This is the behavior we should expect with the changes in this PR -->
|
|
|
|
## Related Issue(s)
|
|
|
|
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
|
|
|
|
Fixes #ISSUE_NUMBER
|
|
```
|
|
|
|
### Guidelines
|
|
|
|
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
|
|
- Read the submission guidelines in CONTRIBUTING.md before posting
|
|
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
|
|
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
|