zhongwei/gh-neolabhq-context-engineering-kit-plugins-git
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:42:52 +08:00
commit c370ff4d24
8 changed files with 1002 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "git",
"description": "Introduces commands for commit and PRs creation.",
"version": "1.0.0",
"author": {
"name": "Vlad Goncharov",
"email": "vlad.goncharov@neolab.finance"
},
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# git
Introduces commands for commit and PRs creation.

78
commands/analyze-issue.md Normal file
View File

@@ -0,0 +1,78 @@
---
description: Analyze a GitHub issue and create a detailed technical specification
argument-hint: Issue number (e.g., 42)
---
Please analyze GitHub issue #$ARGUMENTS and create a technical specification.
Follow these steps:
1. Check if the issue is already loaded:
- Look for the issue file in `./specs/issues/` folder
- File naming pattern: `<number-padded-to-3-digits>-<kebab-case-title>.md`
- If not found, fetch the issue details from GitHub (see step 2)
2. Fetch the issue details (if not already loaded):
- Read `.claude/commands/load-issues.md` to understand how to fetch issue details
- Save the issue file following the load-issues.md format
3. Understand the requirements thoroughly
4. Review related code and project structure
5. Create a technical specification with the format below
# Technical Specification for Issue #$ARGUMENTS
## Issue Summary
- Title: [Issue title from GitHub]
- Description: [Brief description from issue]
- Labels: [Labels from issue]
- Priority: [High/Medium/Low based on issue content]
## Problem Statement
[1-2 paragraphs explaining the problem]
## Technical Approach
[Detailed technical approach]
## Implementation Plan
1. [Step 1]
2. [Step 2]
3. [Step 3]
## Test Plan
1. Unit Tests:
- [test scenario]
2. Component Tests:
- [test scenario]
3. Integration Tests:
- [test scenario]
## Files to Modify
- [file path]: [changes]
## Files to Create
- [file path]: [purpose]
## Existing Utilities to Leverage
- [utility name/path]: [purpose]
## Success Criteria
- [ ] [criterion 1]
- [ ] [criterion 2]
## Out of Scope
- [item 1]
- [item 2]
Remember to follow our strict TDD principles, KISS approach, and 300-line file limit.
IMPORTANT: After completing your analysis, SAVE the full technical specification to:
`./specs/issues/<number-padded-to-3-digits>-<kebab-case-title>.specs.md`
For example, for issue #7 with title "Make code review trigger on any *.SQL and .sh file changes", save to:
`./specs/issues/007-make-code-review-trigger-on-sql-sh-changes.specs.md`
After saving, provide a brief summary to the user confirming:
- Issue number and title analyzed
- File path where the specification was saved
- Key highlights from the specification (2-3 bullet points)

500
commands/attach-review-to-pr.md Normal file
View File

@@ -0,0 +1,500 @@
---
description: Add line-specific review comments to pull requests using GitHub CLI API
argument-hint: PR number or URL (optional - can work with current branch)
---
# How to Attach Line-Specific Review Comments to Pull Requests
This guide explains how to add line-specific review comments to pull requests using the GitHub CLI (`gh`) API, similar to how the GitHub UI allows commenting on specific lines of code.
## Overview
While `gh pr review` provides basic review functionality (approve, request changes, general comments), it **does not support line-specific comments directly**. To add comments on specific lines of code, you must use the lower-level `gh api` command to call GitHub's REST API directly.
## Prerequisites
1. GitHub CLI installed and authenticated:
```bash
gh auth status
```
2. Access to the repository and pull request you want to review
## Understanding GitHub's Review Comment System
GitHub has two types of PR comments:
1. **Issue Comments** - General comments on the PR conversation
2. **Review Comments** - Line-specific comments on code changes
Review comments can be added in two ways:
- **Single comment** - Using the `/pulls/{pr}/comments` endpoint
- **Review with multiple comments** - Using the `/pulls/{pr}/reviews` endpoint
## Adding a Single Line-Specific Comment
### Basic Syntax
```bash
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
-f body='Your comment text here' \
-f commit_id='<commit-sha>' \
-f path='path/to/file.js' \
-F line=42 \
-f side='RIGHT'
```
### Parameters Explained
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `body` | string | Yes | The text of the review comment (supports Markdown) |
| `commit_id` | string | Yes | The SHA of the commit to comment on |
| `path` | string | Yes | Relative path to the file being commented on |
| `line` | integer | Yes | The line number in the diff (use `-F` for integers) |
| `side` | string | Yes | `RIGHT` for new/modified lines, `LEFT` for deleted lines |
| `start_line` | integer | No | For multi-line comments, the starting line |
| `start_side` | string | No | For multi-line comments, the starting side |
### Parameter Flags
- `-f` (--field) - For string values
- `-F` (--field) - For integer values (note the capital F)
### Complete Example
```bash
# First, get the latest commit SHA for the PR
gh api repos/NeoLabHQ/learning-platform-app/pulls/4 --jq '.head.sha'
# Then add your comment
gh api repos/NeoLabHQ/learning-platform-app/pulls/4/comments \
-f body='Consider adding error handling here. Should we confirm the lesson was successfully marked as completed before navigating away?' \
-f commit_id='e152d0dd6cf498467eadbeb638bf05abe11c64d4' \
-f path='src/components/LessonNavigationButtons.tsx' \
-F line=26 \
-f side='RIGHT'
```
### Understanding Line Numbers
The `line` parameter refers to the **position in the diff**, not the absolute line number in the file:
- For **new files**: Line numbers match the file's line numbers
- For **modified files**: Use the line number as it appears in the "Files changed" tab
- For **multi-line comments**: Use `start_line` and `line` to specify the range
### Response
On success, returns a JSON object with comment details:
```json
{
"id": 2532291222,
"pull_request_review_id": 3470545909,
"path": "src/components/LessonNavigationButtons.tsx",
"line": 26,
"body": "Consider adding error handling here...",
"html_url": "https://github.com/NeoLabHQ/learning-platform-app/pull/4#discussion_r2532291222",
"created_at": "2025-11-16T22:40:46Z"
}
```
## Adding Multiple Line-Specific Comments Together
To add multiple comments across different files in a single review, use the `/reviews` endpoint with JSON input.
### Why Use Reviews for Multiple Comments?
- **Atomic operation** - All comments are added together
- **Single notification** - Doesn't spam with multiple notifications
- **Better UX** - Appears as one cohesive review
- **Same mechanism as GitHub UI** - "Start a review" → "Finish review"
### Basic Syntax
```bash
cat <<'EOF' | gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --input -
{
"event": "COMMENT",
"body": "Overall review summary (optional)",
"comments": [
{
"path": "file1.tsx",
"body": "Comment on file 1",
"side": "RIGHT",
"line": 15
},
{
"path": "file2.tsx",
"body": "Comment on file 2",
"side": "RIGHT",
"line": 30
}
]
}
EOF
```
### Review Event Types
| Event | Description | When to Use |
|-------|-------------|-------------|
| `COMMENT` | General review comment | Just leaving feedback without approval |
| `APPROVE` | Approve the PR | Changes look good, ready to merge |
| `REQUEST_CHANGES` | Request changes | Issues that must be fixed before merge |
### Complete Example
```bash
cat <<'EOF' | gh api repos/NeoLabHQ/learning-platform-app/pulls/4/reviews --input -
{
"event": "COMMENT",
"body": "Testing multiple line-specific comments via gh api",
"comments": [
{
"path": "src/components/CourseCard.tsx",
"body": "Test comment generated by Claude",
"side": "RIGHT",
"line": 15
},
{
"path": "src/components/CourseProgressWidget.tsx",
"body": "Test comment generated by Claude",
"side": "RIGHT",
"line": 30
},
{
"path": "src/components/LessonProgressTracker.tsx",
"body": "Test comment generated by Claude",
"side": "RIGHT",
"line": 20
}
]
}
EOF
```
### Response
```json
{
"id": 3470546747,
"state": "COMMENTED",
"html_url": "https://github.com/NeoLabHQ/learning-platform-app/pull/4#pullrequestreview-3470546747",
"submitted_at": "2025-11-16T22:42:43Z",
"commit_id": "e152d0dd6cf498467eadbeb638bf05abe11c64d4"
}
```
## Common Issues and Solutions
### Issue 1: "user_id can only have one pending review per pull request"
**Error Message:**
```
gh: Validation Failed (HTTP 422)
{"message":"Validation Failed","errors":[{"resource":"PullRequestReview","code":"custom","field":"user_id","message":"user_id can only have one pending review per pull request"}]}
```
**Cause:** GitHub only allows one pending (unsubmitted) review per user per PR. If you previously started a review through the UI or API and didn't submit it, it blocks new review creation.
**Solution 1: Submit the pending review**
```bash
# Check for pending reviews
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews | jq '.[] | select(.state=="PENDING")'
# Submit it through the UI or ask the user to submit it
```
**Solution 2: Use the single comment endpoint instead**
```bash
# Add individual comments without creating a review
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
-f body='Comment text' \
-f commit_id='<sha>' \
-f path='file.tsx' \
-F line=26 \
-f side='RIGHT'
```
### Issue 2: Array syntax not working with --raw-field
**Failed Attempt:**
```bash
# This does NOT work - GitHub API receives an object, not an array
gh api repos/{owner}/{repo}/pulls/{pr}/reviews \
--raw-field 'comments[0][path]=file1.tsx' \
--raw-field 'comments[0][line]=15' \
--raw-field 'comments[1][path]=file2.tsx' \
--raw-field 'comments[1][line]=30'
```
**Error:**
```
Invalid request. For 'properties/comments', {"0" => {...}, "1" => {...}} is not an array.
```
**Solution:** Use JSON input via heredoc:
```bash
cat <<'EOF' | gh api repos/{owner}/{repo}/pulls/{pr}/reviews --input -
{
"comments": [...]
}
EOF
```
### Issue 3: Invalid line number
**Error Message:**
```
Pull request review thread line must be part of the diff
```
**Cause:** The line number doesn't exist in the diff for this file.
**Solutions:**
- Verify the file was actually changed in this PR
- Check the "Files changed" tab to see actual line numbers in the diff
- Ensure you're using the correct `commit_id` (the latest commit in the PR)
### Issue 4: Wrong commit_id
**Error Message:**
```
commit_sha is not part of the pull request
```
**Solution:** Get the latest commit SHA:
```bash
gh api repos/{owner}/{repo}/pulls/{pr_number} --jq '.head.sha'
```
## Best Practices
### 1. Get PR Information First
Before adding comments, gather necessary information:
```bash
# Get PR details
gh pr view {pr_number} --json headRefOid,files
# Or use the API
gh api repos/{owner}/{repo}/pulls/{pr_number} --jq '{commit: .head.sha, files: [.changed_files]}'
# List files changed
gh api repos/{owner}/{repo}/pulls/{pr_number}/files --jq '.[] | {filename: .filename, additions: .additions, deletions: .deletions}'
```
### 2. Check for Pending Reviews
```bash
# Check if you have a pending review
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \
--jq '.[] | select(.state=="PENDING" and .user.login=="YOUR_USERNAME")'
```
### 3. Use Meaningful Comment Text
- Be specific and constructive
- Reference documentation or best practices
- Suggest alternatives when requesting changes
- Use code blocks for code suggestions:
```markdown
Consider using async/await:
\`\`\`typescript
async function getData() {
const result = await fetch(url);
return result.json();
}
\`\`\`
```
### 4. Batch Related Comments
Use the review endpoint to group related comments:
- All comments for a single file/area
- All comments for a specific concern (security, performance, etc.)
- Complete review session
### 5. Choose the Right Event Type
```bash
# For feedback during development
"event": "COMMENT"
# When approving
"event": "APPROVE"
# When blocking merge
"event": "REQUEST_CHANGES"
```
## Workflow Examples
### Example 1: Quick Single Comment
```bash
#!/bin/bash
OWNER="NeoLabHQ"
REPO="learning-platform-app"
PR=4
# Get latest commit
COMMIT=$(gh api repos/$OWNER/$REPO/pulls/$PR --jq '.head.sha')
# Add comment
gh api repos/$OWNER/$REPO/pulls/$PR/comments \
-f body='Consider extracting this into a separate function for better testability' \
-f commit_id="$COMMIT" \
-f path='src/utils/validation.ts' \
-F line=45 \
-f side='RIGHT'
```
### Example 2: Comprehensive Review
```bash
#!/bin/bash
OWNER="NeoLabHQ"
REPO="learning-platform-app"
PR=4
# Create review with multiple comments
cat <<EOF | gh api repos/$OWNER/$REPO/pulls/$PR/reviews --input -
{
"event": "COMMENT",
"body": "Thanks for the PR! I've reviewed the changes and have a few suggestions.",
"comments": [
{
"path": "src/components/CourseCard.tsx",
"body": "Consider memoizing this component to prevent unnecessary re-renders",
"side": "RIGHT",
"line": 25
},
{
"path": "src/utils/courseProgress.ts",
"body": "This function could benefit from error handling for invalid course IDs",
"side": "RIGHT",
"line": 12
},
{
"path": "src/state/CourseProgressState.ts",
"body": "Consider adding JSDoc comments to document the expected behavior",
"side": "RIGHT",
"line": 8
}
]
}
EOF
```
### Example 3: Multi-line Comment
```bash
# Comment on a range of lines (e.g., lines 10-15)
gh api repos/$OWNER/$REPO/pulls/$PR/comments \
-f body='This entire block could be simplified using array destructuring' \
-f commit_id="$COMMIT" \
-f path='src/utils/parser.ts' \
-F start_line=10 \
-f start_side='RIGHT' \
-F line=15 \
-f side='RIGHT'
```
## Helpful Helper Scripts
### Get PR Files and Lines
```bash
#!/bin/bash
# pr-files.sh - List all files changed in a PR with line counts
OWNER="$1"
REPO="$2"
PR="$3"
gh api repos/$OWNER/$REPO/pulls/$PR/files --jq '.[] | "\(.filename): +\(.additions)/-\(.deletions)"'
```
### Check Review Status
```bash
#!/bin/bash
# check-reviews.sh - Check review status for a PR
OWNER="$1"
REPO="$2"
PR="$3"
echo "=== Reviews ==="
gh api repos/$OWNER/$REPO/pulls/$PR/reviews --jq '.[] | "\(.user.login): \(.state) at \(.submitted_at)"'
echo -e "\n=== Pending Reviews ==="
gh api repos/$OWNER/$REPO/pulls/$PR/reviews --jq '.[] | select(.state=="PENDING") | "\(.user.login): \(.state)"'
```
## Related Documentation
- [GitHub API: Pull Request Review Comments](https://docs.github.com/rest/pulls/comments)
- [GitHub API: Pull Request Reviews](https://docs.github.com/rest/pulls/reviews)
- [GitHub CLI Manual](https://cli.github.com/manual/)
- [Create PR Command](./create-pr.md)
- [Commit Command](./commit.md)
## API Reference
### POST /repos/{owner}/{repo}/pulls/{pull_number}/comments
Creates a review comment on a specific line.
**Endpoint:** `https://api.github.com/repos/{owner}/{repo}/pulls/{pull_number}/comments`
**Parameters:**
- `body` (string, required): Comment text
- `commit_id` (string, required): SHA of commit
- `path` (string, required): Relative file path
- `line` (integer, required): Line number in diff
- `side` (string, required): "LEFT" or "RIGHT"
- `start_line` (integer, optional): Start line for multi-line
- `start_side` (string, optional): Start side for multi-line
### POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews
Creates a review with optional line-specific comments.
**Endpoint:** `https://api.github.com/repos/{owner}/{repo}/pulls/{pull_number}/reviews`
**Parameters:**
- `event` (string, required): "APPROVE", "REQUEST_CHANGES", or "COMMENT"
- `body` (string, optional): Overall review comment
- `comments` (array, optional): Array of comment objects
- `commit_id` (string, optional): SHA of commit to review
**Comment Object:**
- `path` (string, required): Relative file path
- `body` (string, required): Comment text
- `line` (integer, required): Line number in diff
- `side` (string, required): "LEFT" or "RIGHT"
- `start_line` (integer, optional): Start line for multi-line
- `start_side` (string, optional): Start side for multi-line

166
commands/commit.md Normal file
View File

@@ -0,0 +1,166 @@
---
description: Create well-formatted commits with conventional commit messages and emoji
argument-hint: Optional flags like --no-verify to skip pre-commit checks
---
# Claude Command: Commit
This command helps you create well-formatted commits with conventional commit messages and emoji.
## Usage
To create a commit, just type:
```
/commit
```
Or with options:
```
/commit --no-verify
```
## What This Command Does
1. Unless specified with `--no-verify`, automatically runs pre-commit checks like `pnpm lint` or simular depending on the project language.
2. Checks which files are staged with `git status`
3. If 0 files are staged, automatically adds all modified and new files with `git add`
4. Performs a `git diff` to understand what changes are being committed
5. Analyzes the diff to determine if multiple distinct logical changes are present
6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
## Best Practices for Commits
- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
- **Atomic commits**: Each commit should contain related changes that serve a single purpose
- **Split large changes**: If changes touch multiple concerns, split them into separate commits
- **Conventional commit format**: Use the format `<type>: <description>` where type is one of:
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation changes
- `style`: Code style changes (formatting, etc)
- `refactor`: Code changes that neither fix bugs nor add features
- `perf`: Performance improvements
- `test`: Adding or fixing tests
- `chore`: Changes to the build process, tools, etc.
- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
- **Concise first line**: Keep the first line under 72 characters
- **Emoji**: Each commit type is paired with an appropriate emoji:
- ✨ `feat`: New feature
- 🐛 `fix`: Bug fix
- 📝 `docs`: Documentation
- 💄 `style`: Formatting/style
- ♻️ `refactor`: Code refactoring
- ⚡️ `perf`: Performance improvements
- ✅ `test`: Tests
- 🔧 `chore`: Tooling, configuration
- 🚀 `ci`: CI/CD improvements
- 🗑️ `revert`: Reverting changes
- 🧪 `test`: Add a failing test
- 🚨 `fix`: Fix compiler/linter warnings
- 🔒️ `fix`: Fix security issues
- 👥 `chore`: Add or update contributors
- 🚚 `refactor`: Move or rename resources
- 🏗️ `refactor`: Make architectural changes
- 🔀 `chore`: Merge branches
- 📦️ `chore`: Add or update compiled files or packages
- ➕ `chore`: Add a dependency
- ➖ `chore`: Remove a dependency
- 🌱 `chore`: Add or update seed files
- 🧑‍💻 `chore`: Improve developer experience
- 🧵 `feat`: Add or update code related to multithreading or concurrency
- 🔍️ `feat`: Improve SEO
- 🏷️ `feat`: Add or update types
- 💬 `feat`: Add or update text and literals
- 🌐 `feat`: Internationalization and localization
- 👔 `feat`: Add or update business logic
- 📱 `feat`: Work on responsive design
- 🚸 `feat`: Improve user experience / usability
- 🩹 `fix`: Simple fix for a non-critical issue
- 🥅 `fix`: Catch errors
- 👽️ `fix`: Update code due to external API changes
- 🔥 `fix`: Remove code or files
- 🎨 `style`: Improve structure/format of the code
- 🚑️ `fix`: Critical hotfix
- 🎉 `chore`: Begin a project
- 🔖 `chore`: Release/Version tags
- 🚧 `wip`: Work in progress
- 💚 `fix`: Fix CI build
- 📌 `chore`: Pin dependencies to specific versions
- 👷 `ci`: Add or update CI build system
- 📈 `feat`: Add or update analytics or tracking code
- ✏️ `fix`: Fix typos
- ⏪️ `revert`: Revert changes
- 📄 `chore`: Add or update license
- 💥 `feat`: Introduce breaking changes
- 🍱 `assets`: Add or update assets
- ♿️ `feat`: Improve accessibility
- 💡 `docs`: Add or update comments in source code
- 🗃️ `db`: Perform database related changes
- 🔊 `feat`: Add or update logs
- 🔇 `fix`: Remove logs
- 🤡 `test`: Mock things
- 🥚 `feat`: Add or update an easter egg
- 🙈 `chore`: Add or update .gitignore file
- 📸 `test`: Add or update snapshots
- ⚗️ `experiment`: Perform experiments
- 🚩 `feat`: Add, update, or remove feature flags
- 💫 `ui`: Add or update animations and transitions
- ⚰️ `refactor`: Remove dead code
- 🦺 `feat`: Add or update code related to validation
- ✈️ `feat`: Improve offline support
## Guidelines for Splitting Commits
When analyzing the diff, consider splitting commits based on these criteria:
1. **Different concerns**: Changes to unrelated parts of the codebase
2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
4. **Logical grouping**: Changes that would be easier to understand or review separately
5. **Size**: Very large changes that would be clearer if broken down
## Examples
Good commit messages:
- ✨ feat: add user authentication system
- 🐛 fix: resolve memory leak in rendering process
- 📝 docs: update API documentation with new endpoints
- ♻️ refactor: simplify error handling logic in parser
- 🚨 fix: resolve linter warnings in component files
- 🧑‍💻 chore: improve developer tooling setup process
- 👔 feat: implement business logic for transaction validation
- 🩹 fix: address minor styling inconsistency in header
- 🚑️ fix: patch critical security vulnerability in auth flow
- 🎨 style: reorganize component structure for better readability
- 🔥 fix: remove deprecated legacy code
- 🦺 feat: add input validation for user registration form
- 💚 fix: resolve failing CI pipeline tests
- 📈 feat: implement analytics tracking for user engagement
- 🔒️ fix: strengthen authentication password requirements
- ♿️ feat: improve form accessibility for screen readers
Example of splitting commits:
- First commit: ✨ feat: add new solc version type definitions
- Second commit: 📝 docs: update documentation for new solc versions
- Third commit: 🔧 chore: update package.json dependencies
- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
- Sixth commit: 🚨 fix: resolve linting issues in new code
- Seventh commit: ✅ test: add unit tests for new solc version features
- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
## Command Options
- `--no-verify`: Skip running the pre-commit checks (lint, build, generate:docs)
## Important Notes
- By default, pre-commit checks (`pnpm lint`, `pnpm build`, `pnpm generate:docs`) will run to ensure code quality
- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
- If specific files are already staged, the command will only commit those files
- If no files are staged, it will automatically stage all modified and new files
- The commit message will be constructed based on the changes detected
- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
- If suggesting multiple commits, it will help you stage and commit the changes separately
- Always reviews the commit diff to ensure the message matches the changes

130
commands/create-pr.md Normal file
View File

@@ -0,0 +1,130 @@
---
description: Create pull requests using GitHub CLI with proper templates and formatting
argument-hint: None required - interactive guide for PR creation
---
# How to Create a Pull Request Using GitHub CLI
This guide explains how to create pull requests using GitHub CLI in our project.
**Important**: All PR titles and descriptions should be written in English.
## Prerequisites
Check if `gh` is installed, if not follow this instruction to install it:
1. Install GitHub CLI if you haven't already:
```bash
# macOS
brew install gh
# Windows
winget install --id GitHub.cli
# Linux
# Follow instructions at https://github.com/cli/cli/blob/trunk/docs/install_linux.md
```
2. Authenticate with GitHub:
```bash
gh auth login
```
## Creating a New Pull Request
1. First, prepare your PR description following the template in @.github/pull_request_template.md
2. Use the `gh pr create --draft` command to create a new pull request:
```bash
# Basic command structure
gh pr create --draft --title "✨(scope): Your descriptive title" --body "Your PR description" --base main
```
For more complex PR descriptions with proper formatting, use the `--body-file` option with the exact PR template structure:
```bash
# Create PR with proper template structure
gh pr create --draft --title "✨(scope): Your descriptive title" --body-file .github/pull_request_template.md --base main
```
## Best Practices
1. **Language**: Always use English for PR titles and descriptions
2. **PR Title Format**: Use conventional commit format with emojis
- Always include an appropriate emoji at the beginning of the title
- Use the actual emoji character (not the code representation like `:sparkles:`)
- Examples:
- `✨(supabase): Add staging remote configuration`
- `🐛(auth): Fix login redirect issue`
- `📝(readme): Update installation instructions`
3. **Description Template**: Always use our PR template structure from @.github/pull_request_template.md:
4. **Template Accuracy**: Ensure your PR description precisely follows the template structure:
- Don't modify or rename the PR-Agent sections (`pr_agent:summary` and `pr_agent:walkthrough`)
- Keep all section headers exactly as they appear in the template
- Don't add custom sections that aren't in the template
5. **Draft PRs**: Start as draft when the work is in progress
- Use `--draft` flag in the command
- Convert to ready for review when complete using `gh pr ready`
### Common Mistakes to Avoid
1. **Using Non-English Text**: All PR content must be in English
2. **Incorrect Section Headers**: Always use the exact section headers from the template
3. **Adding Custom Sections**: Stick to the sections defined in the template
4. **Using Outdated Templates**: Always refer to the current @.github/pull_request_template.md file
### Missing Sections
Always include all template sections, even if some are marked as "N/A" or "None"
## Additional GitHub CLI PR Commands
Here are some additional useful GitHub CLI commands for managing PRs:
```bash
# List your open pull requests
gh pr list --author "@me"
# Check PR status
gh pr status
# View a specific PR
gh pr view <PR-NUMBER>
# Check out a PR branch locally
gh pr checkout <PR-NUMBER>
# Convert a draft PR to ready for review
gh pr ready <PR-NUMBER>
# Add reviewers to a PR
gh pr edit <PR-NUMBER> --add-reviewer username1,username2
# Merge a PR
gh pr merge <PR-NUMBER> --squash
```
## Using Templates for PR Creation
To simplify PR creation with consistent descriptions, you can create a template file:
1. Create a file named `pr-template.md` with your PR template
2. Use it when creating PRs:
```bash
gh pr create --draft --title "feat(scope): Your title" --body-file pr-template.md --base main
```
## Related Documentation
- [PR Template](.github/pull_request_template.md)
- [Conventional Commits](https://www.conventionalcommits.org/)
- [GitHub CLI documentation](https://cli.github.com/manual/)

52
commands/load-issues.md Normal file
View File

@@ -0,0 +1,52 @@
---
description: Load all open issues from GitHub and save them as markdown files
argument-hint: None required - loads all open issues automatically
---
Load all open issues from the current GitHub repository and save them as markdown files in the `./specs/issues/` directory.
Follow these steps:
1. Use the gh CLI to list all open issues in the current repository:
- Run `gh issue list --limit 100` to get all open issues
2. For each open issue, fetch detailed information:
- Run `gh issue view <number> --json number,title,body,state,createdAt,updatedAt,author,labels,assignees,url`
- Extract all relevant metadata
3. Create the issues directory:
- Run `mkdir -p ./specs/issues` to ensure the directory exists
4. Save each issue as a separate markdown file:
- File naming pattern: `<number-padded-to-3-digits>-<kebab-case-title>.md`
- Example: `007-make-code-review-trigger-on-sql-sh-changes.md`
5. Use the following markdown template for each issue file:
```markdown
# Issue #<number>: <title>
**Status:** <state>
**Created:** <createdAt>
**Updated:** <updatedAt>
**Author:** <author.name> (@<author.login>)
**URL:** <url>
## Description
<body>
## Labels
<labels or "None">
## Assignees
<assignees or "None">
```
6. After all issues are saved, provide a summary of:
- Total number of issues loaded
- List of created files with their issue numbers and titles
IMPORTANT: Execute all steps in the correct order and ensure all issue data is properly formatted in the markdown files.

61
plugin.lock.json Normal file
View File

@@ -0,0 +1,61 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:NeoLabHQ/context-engineering-kit:plugins/git",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "a5de871f892702e55e02b4cd7c8c83c1cb6148c0",
"treeHash": "fbc0f07b854a82e2bcf7334a109f101de205407d434d5ddd78582a75feb2d7a8",
"generatedAt": "2025-11-28T10:12:10.173808Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "git",
"description": "Introduces commands for commit and PRs creation.",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "a17d76457036a2e54c0c0ba214185ab0039b119e8add5c741b67534f77b88208"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "936dcbf05b288d198334450bc2452fc43979fc79228749170c57a762129af06a"
},
{
"path": "commands/load-issues.md",
"sha256": "488ac73c0dc1beba9351cc4638ac2c8bb609edafe91be6387adb1458883bf804"
},
{
"path": "commands/attach-review-to-pr.md",
"sha256": "94bde1cd43fed90648517055367b33bf39e37f0d087fe71daf01389b8d014500"
},
{
"path": "commands/create-pr.md",
"sha256": "c35cbd8e8625aee986231c17dee9bbbce1730eadbe8ec3e29d884dddbefe3f1c"
},
{
"path": "commands/commit.md",
"sha256": "3cfb46adc3e4097c296cd67208b1a881893af6b4582e455f0e9fc7152b2e9705"
},
{
"path": "commands/analyze-issue.md",
"sha256": "ed6cd06fedf20df017d5a6cc171a2d1ab636dc0a3ef0b4bb4a69246004351d3e"
}
],
"dirSha256": "fbc0f07b854a82e2bcf7334a109f101de205407d434d5ddd78582a75feb2d7a8"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}