commit c370ff4d24addb973341ec36161c14f0ca416c8a
Author: Zhongwei Li <lizhongwei.nkcs@gmail.com>
Date:   Sun Nov 30 08:42:52 2025 +0800

    Initial commit

diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
new file mode 100644
index 0000000..2548424
--- /dev/null
+++ b/.claude-plugin/plugin.json
@@ -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"
+  ]
+}
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..7bf49e7
--- /dev/null
+++ b/README.md
@@ -0,0 +1,3 @@
+# git
+
+Introduces commands for commit and PRs creation.
diff --git a/commands/analyze-issue.md b/commands/analyze-issue.md
new file mode 100644
index 0000000..e1552f1
--- /dev/null
+++ b/commands/analyze-issue.md
@@ -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)
\ No newline at end of file
diff --git a/commands/attach-review-to-pr.md b/commands/attach-review-to-pr.md
new file mode 100644
index 0000000..780595f
--- /dev/null
+++ b/commands/attach-review-to-pr.md
@@ -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
diff --git a/commands/commit.md b/commands/commit.md
new file mode 100644
index 0000000..6a775d2
--- /dev/null
+++ b/commands/commit.md
@@ -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
\ No newline at end of file
diff --git a/commands/create-pr.md b/commands/create-pr.md
new file mode 100644
index 0000000..24893c4
--- /dev/null
+++ b/commands/create-pr.md
@@ -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/)
\ No newline at end of file
diff --git a/commands/load-issues.md b/commands/load-issues.md
new file mode 100644
index 0000000..96d0620
--- /dev/null
+++ b/commands/load-issues.md
@@ -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.
diff --git a/plugin.lock.json b/plugin.lock.json
new file mode 100644
index 0000000..c22da9c
--- /dev/null
+++ b/plugin.lock.json
@@ -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": []
+  }
+}
\ No newline at end of file