feat: initial opencode config with commands, skills and MCP services
This commit is contained in:
234
command/auto-commit.md
Normal file
234
command/auto-commit.md
Normal file
@@ -0,0 +1,234 @@
|
||||
---
|
||||
description: Auto-generate commit message, commit and create tag
|
||||
agent: build
|
||||
---
|
||||
|
||||
# auto-commit
|
||||
|
||||
Auto-generate commit message for staged files, commit to local repository.
|
||||
|
||||
## Features
|
||||
|
||||
- **Create tag**: Automatically generate version number and create tag by default
|
||||
- **Skip tag**: Skip creating tag when user inputs "skip" or "skip tag"
|
||||
|
||||
> Version number update is **consistent** with git tag: AI will automatically update version number based on project type and changes, and create tag with the same version number.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Check Staging Area
|
||||
|
||||
Run `git diff --cached --name-only` to check if there are files in staging area.
|
||||
|
||||
**If staging area is empty**:
|
||||
- Output prompt: "No files in staging area, please use `git add` to add files first."
|
||||
- **Terminate command execution**, do not continue
|
||||
|
||||
### 2. Collect Information (Execute in parallel)
|
||||
|
||||
- Run `git status` to view current status
|
||||
- Run `git diff --cached` to view specific changes in staging area
|
||||
- Run `git log --oneline -10` to view recent commit history, understand project's commit style
|
||||
- Run `git tag --list | sort -V | tail -5` to view recent tags
|
||||
- Read `AGENTS.md` file (if exists), understand project type, structure and **version update rules**
|
||||
|
||||
### 3. Detect Repository Type
|
||||
|
||||
**Detect repository type (polyrepo or monorepo)**:
|
||||
|
||||
- Check if `AGENTS.md` file indicates **monorepo**, if `AGENTS.md` doesn't exist or doesn't clearly indicate, default to **polyrepo**
|
||||
|
||||
**If monorepo, analyze change scope**:
|
||||
|
||||
- Based on changed files from step 1, analyze if changes only affect a specific subproject
|
||||
- If only single subproject is affected, record subproject name (e.g., extract `user-service` from path `packages/user-service/src/index.ts`)
|
||||
|
||||
### 4. Detect Project Type and Determine Version Number
|
||||
|
||||
**Prioritize reading version update rules from AGENTS.md**:
|
||||
|
||||
If `AGENTS.md` defines version update rules (such as version file path, version field name, etc.), prioritize using that rule.
|
||||
|
||||
**Auto-detect project type** (when AGENTS.md is not defined):
|
||||
|
||||
AI needs to intelligently identify project type and determine version file, common project types include but not limited to:
|
||||
|
||||
| Project Type | Version File | Version Field/Location |
|
||||
| --- | --- | --- |
|
||||
| iOS | `*.xcodeproj/project.pbxproj` | `MARKETING_VERSION` |
|
||||
| npm/Node.js | `package.json` | `version` |
|
||||
| Android (Groovy) | `app/build.gradle` | `versionName` |
|
||||
| Android (Kotlin DSL) | `app/build.gradle.kts` | `versionName` |
|
||||
| Python (pyproject) | `pyproject.toml` | `[project] version` or `[tool.poetry] version` |
|
||||
| Python (setup) | `setup.py` | `version` parameter |
|
||||
| Rust | `Cargo.toml` | `[package] version` |
|
||||
| Go | Usually only uses git tag | - |
|
||||
| Flutter | `pubspec.yaml` | `version` |
|
||||
| .NET | `*.csproj` | `<Version>` or `<PackageVersion>` |
|
||||
|
||||
> AI should determine project type based on files that actually exist in repository, can check multiple possible version files if necessary.
|
||||
|
||||
**Read current version number**:
|
||||
|
||||
1. Read current version number from identified version file
|
||||
2. Parse as `major.minor.patch`:
|
||||
- If parsing fails or doesn't exist: treat as `0.1.0`
|
||||
- If current version only has `major.minor` format, auto-complete to `major.minor.0`
|
||||
|
||||
**Calculate new version number** (based on change type):
|
||||
|
||||
Version number uses **semantic versioning format**: `0.1.0`, `0.2.0`, ..., `0.9.0`, `1.0.0`, `1.1.0`, `1.1.1`...
|
||||
- **Default starting version**: `0.1.0`
|
||||
- **Increment rules**:
|
||||
- **Major/breaking changes**: `1.2.3` -> `2.0.0` (major +1, minor and patch reset to zero)
|
||||
- **New feature (feat)**: `1.2.3` -> `1.3.0` (minor +1, patch reset to zero)
|
||||
- **Bug fix (fix)**: `1.2.3` -> `1.2.4` (patch +1)
|
||||
|
||||
**Determine if version number update is needed**:
|
||||
|
||||
> Core principle: **Version number reflects "user-perceivable changes"**. Ask yourself: Has the product that users download/use changed?
|
||||
|
||||
**Need to update version number** (packaged into final product, user-perceivable):
|
||||
|
||||
| commit type | version change | description |
|
||||
| --- | --- | --- |
|
||||
| `feat` | minor +1 | new feature |
|
||||
| `fix` | patch +1 | user-perceivable bug fix |
|
||||
| `perf` | patch +1 | performance optimization (user-perceivable improvement) |
|
||||
| breaking change (`!`) | major +1 | API/protocol incompatible changes |
|
||||
|
||||
**No need to update version number** (doesn't affect final product, user-imperceptible):
|
||||
|
||||
| commit type | description | example |
|
||||
| --- | --- | --- |
|
||||
| `chore` | miscellaneous/toolchain | build scripts, CI config, dependency updates |
|
||||
| `ci` | CI/CD config | `.github/workflows/*.yml`, `release.mjs` |
|
||||
| `docs` | documentation | README, comments, API docs |
|
||||
| `test` | test code | unit tests, E2E tests |
|
||||
| `refactor` | refactoring | code reorganization without changing external behavior |
|
||||
| `style` | code style | formatting, spaces, semicolons |
|
||||
| `build` | build config | `tsconfig.json`, `biome.json`, `webpack.config.js` |
|
||||
|
||||
**Judgment tips**:
|
||||
|
||||
1. **Will the file be packaged into final product?**
|
||||
- `scripts/`, `.github/`, `*.config.js` -> No -> Don't update version
|
||||
- `src/`, `lib/`, `app/` -> Yes -> May need to update version
|
||||
|
||||
2. **Does the change only affect developers?**
|
||||
- Dev tool config, CI scripts, build process -> Only affects developers -> Don't update version
|
||||
- Feature code, UI, API -> Affects users -> Update version
|
||||
|
||||
3. **If project type cannot be identified or no version file** -> Only create git tag, don't update version file
|
||||
|
||||
### 5. Generate Commit Message
|
||||
|
||||
Based on changes in staging area, **analyze and generate meaningful commit message by AI**:
|
||||
|
||||
- Analyze changed code content, understand the purpose and intent of this modification
|
||||
- Reference project's commit history style
|
||||
- Use [Conventional Commits](https://www.conventionalcommits.org/) specification
|
||||
- Commit message should concisely but accurately describe "why" rather than just "what"
|
||||
- Common types: `feat` (new feature), `fix` (fix), `docs` (documentation), `refactor` (refactoring), `chore` (miscellaneous), `test` (test), etc.
|
||||
- **If monorepo and this commit only affects single subproject, include subproject name in commit message**:
|
||||
- Format: `<type>(<scope>): <description>`, where `<scope>` is subproject name
|
||||
- Example: `feat(ios): support OGG Opus upload` or `fix(electron): fix clipboard injection failure`
|
||||
- If affecting multiple subprojects or entire repository, no need to add scope
|
||||
|
||||
### 6. Update Project Version Number
|
||||
|
||||
> Only execute when step 4 determines version number update is needed and version file is identified
|
||||
|
||||
**Execution steps**:
|
||||
|
||||
1. Based on version file and field identified in step 4, update version number to calculated new version
|
||||
2. Add version file to staging area: `git add <version file>`
|
||||
3. **Verify staging area**: Run `git diff --cached --name-only` to confirm version file is in staging area
|
||||
|
||||
### 7. Execute Commit
|
||||
|
||||
Execute commit with generated commit message (staging area now includes user's changes and version number update).
|
||||
|
||||
**Windows encoding issue solution:**
|
||||
|
||||
Cursor's Shell tool has encoding issues when passing Chinese parameters on Windows, causing garbled Git commit messages.
|
||||
|
||||
**Correct approach**: Use **English** commit message
|
||||
|
||||
```powershell
|
||||
# Single line commit
|
||||
git commit -m "feat(android): add new feature"
|
||||
|
||||
# Multi-line commit (use --message multiple times)
|
||||
git commit --message="fix(android): fix code review issues" --message="- Fix syntax error" --message="- Use JSONObject instead of manual JSON"
|
||||
```
|
||||
|
||||
**Prohibited methods** (will cause garbled text):
|
||||
- No Chinese commit messages - Cursor Shell tool encoding error when passing Chinese parameters
|
||||
- No `Out-File -Encoding utf8` - writes UTF-8 with BOM
|
||||
- No Write tool to write temp files - encoding uncontrollable
|
||||
- No PowerShell here-string `@"..."@` - newline parsing issues
|
||||
|
||||
**For Chinese commit messages**: Please manually execute `git commit` in terminal, or use Git GUI tools other than Cursor.
|
||||
|
||||
**macOS/Linux alternative** (supports Chinese):
|
||||
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
feat(android): new feature description
|
||||
|
||||
- Detail 1
|
||||
- Detail 2
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
### 8. Create Tag
|
||||
|
||||
> **Executed by default**. Only skip this step when user explicitly inputs "skip" or "skip tag".
|
||||
> Only create tag when step 4 determines version number update is needed (docs/chore types don't create tag).
|
||||
|
||||
**Tag annotation content requirements**:
|
||||
|
||||
- **Use the same content as commit message for tag annotation**
|
||||
- Tag annotation will be used as Release notes by CI/CD scripts, should include detailed change content
|
||||
- If commit message has multiple lines, tag annotation should also be multi-line
|
||||
|
||||
**polyrepo**:
|
||||
```bash
|
||||
git tag -a "<version>" -m "<commit title>" -m "" -m "<commit body line 1>" -m "<commit body line 2>" ...
|
||||
```
|
||||
|
||||
**monorepo**:
|
||||
```bash
|
||||
git tag -a "<subproject>-<version>" -m "<commit title>" -m "" -m "<commit body line 1>" -m "<commit body line 2>" ...
|
||||
```
|
||||
|
||||
Examples (single line commit):
|
||||
- polyrepo: `git tag -a "1.2.0" -m "feat: add user authentication"`
|
||||
- monorepo: `git tag -a "android-1.2.0" -m "feat(android): add user authentication"`
|
||||
|
||||
Examples (multi-line commit, more recommended):
|
||||
- polyrepo:
|
||||
```bash
|
||||
git tag -a "1.2.1" -m "fix: resolve bluetooth connection timeout" -m "" -m "- Increase connection timeout to 30s" -m "- Add retry mechanism for failed connections" -m "- Improve error messages"
|
||||
```
|
||||
- monorepo:
|
||||
```bash
|
||||
git tag -a "android-1.2.1" -m "fix(android): resolve bluetooth connection timeout" -m "" -m "- Increase connection timeout to 30s" -m "- Add retry mechanism for failed connections" -m "- Improve error messages"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **Staging area check first**: Must check if staging area has files first, if not, terminate immediately, don't execute any subsequent operations.
|
||||
- **AGENTS.md priority**: If `AGENTS.md` defines version update rules, prioritize using that rule; otherwise AI auto-detects project type.
|
||||
- **Smart detection**: AI should intelligently determine project type and version file location based on files that actually exist in repository.
|
||||
- **Version number and tag consistency**: Project version number and git tag use the same version number, ensure consistency.
|
||||
- **Version number format**: Use `major.minor.patch` semantic versioning format (e.g., `0.1.0`, `1.1.0`, `1.1.1`), default starting `0.1.0`.
|
||||
- **Create tag by default**: Unless user inputs "skip" or "skip tag", create tag by default.
|
||||
- **Update version before commit**: First determine version number and modify version file, then commit at once, avoid using `--amend`.
|
||||
- **Version file must be verified**: After updating version number and `git add`, must run `git diff --cached --name-only` to confirm version file is in staging area before executing commit.
|
||||
- **Windows encoding issues**: Cursor Shell tool garbles Chinese parameters, must use **English** commit messages. For Chinese, please manually execute in terminal.
|
||||
- **monorepo scope**: If staging area only affects single subproject, commit message should have scope; if affecting multiple subprojects, no scope needed.
|
||||
- **monorepo tag format**: Use `<subproject>-<version>` format (e.g., `ios-0.1.0`, `android-1.1.0`).
|
||||
- **No version file case**: If project type cannot be identified or no version file (like pure Go project), only create git tag, don't update any files.
|
||||
253
command/commit-push.md
Normal file
253
command/commit-push.md
Normal file
@@ -0,0 +1,253 @@
|
||||
---
|
||||
description: Auto-generate commit, create tag, and push to remote
|
||||
agent: build
|
||||
---
|
||||
|
||||
# commit-push
|
||||
|
||||
Auto-generate commit message for staged files, commit to local repository, then push to remote repository origin.
|
||||
|
||||
## Features
|
||||
|
||||
- **Create tag**: Automatically generate version number and create tag by default, push to remote
|
||||
- **Skip tag**: Skip creating tag when user inputs "skip" or "skip tag"
|
||||
|
||||
> Version number update is **consistent** with git tag: AI will automatically update version number based on project type and changes, and create tag with the same version number.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Check Staging Area
|
||||
|
||||
Run `git diff --cached --name-only` to check if there are files in staging area.
|
||||
|
||||
**If staging area is empty**:
|
||||
- Output prompt: "No files in staging area, please use `git add` to add files first."
|
||||
- **Terminate command execution**, do not continue
|
||||
|
||||
### 2. Collect Information (Execute in parallel)
|
||||
|
||||
- Run `git status` to view current status
|
||||
- Run `git diff --cached` to view specific changes in staging area
|
||||
- Run `git log --oneline -10` to view recent commit history, understand project's commit style
|
||||
- Run `git tag --list | sort -V | tail -5` to view recent tags
|
||||
- Read `AGENTS.md` file (if exists), understand project type, structure and **version update rules**
|
||||
|
||||
### 3. Detect Repository Type
|
||||
|
||||
**Detect repository type (polyrepo or monorepo)**:
|
||||
|
||||
- Check if `AGENTS.md` file indicates **monorepo**, if `AGENTS.md` doesn't exist or doesn't clearly indicate, default to **polyrepo**
|
||||
|
||||
**If monorepo, analyze change scope**:
|
||||
|
||||
- Based on changed files from step 1, analyze if changes only affect a specific subproject
|
||||
- If only single subproject is affected, record subproject name (e.g., extract `user-service` from path `packages/user-service/src/index.ts`)
|
||||
|
||||
### 4. Detect Project Type and Determine Version Number
|
||||
|
||||
**Prioritize reading version update rules from AGENTS.md**:
|
||||
|
||||
If `AGENTS.md` defines version update rules (such as version file path, version field name, etc.), prioritize using that rule.
|
||||
|
||||
**Auto-detect project type** (when AGENTS.md is not defined):
|
||||
|
||||
AI needs to intelligently identify project type and determine version file, common project types include but not limited to:
|
||||
|
||||
| Project Type | Version File | Version Field/Location |
|
||||
| --- | --- | --- |
|
||||
| iOS | `*.xcodeproj/project.pbxproj` | `MARKETING_VERSION` |
|
||||
| npm/Node.js | `package.json` | `version` |
|
||||
| Android (Groovy) | `app/build.gradle` | `versionName` |
|
||||
| Android (Kotlin DSL) | `app/build.gradle.kts` | `versionName` |
|
||||
| Python (pyproject) | `pyproject.toml` | `[project] version` or `[tool.poetry] version` |
|
||||
| Python (setup) | `setup.py` | `version` parameter |
|
||||
| Rust | `Cargo.toml` | `[package] version` |
|
||||
| Go | Usually only uses git tag | - |
|
||||
| Flutter | `pubspec.yaml` | `version` |
|
||||
| .NET | `*.csproj` | `<Version>` or `<PackageVersion>` |
|
||||
|
||||
> AI should determine project type based on files that actually exist in repository, can check multiple possible version files if necessary.
|
||||
|
||||
**Read current version number**:
|
||||
|
||||
1. Read current version number from identified version file
|
||||
2. Parse as `major.minor.patch`:
|
||||
- If parsing fails or doesn't exist: treat as `0.1.0`
|
||||
- If current version only has `major.minor` format, auto-complete to `major.minor.0`
|
||||
|
||||
**Calculate new version number** (based on change type):
|
||||
|
||||
Version number uses **semantic versioning format**: `0.1.0`, `0.2.0`, ..., `0.9.0`, `1.0.0`, `1.1.0`, `1.1.1`...
|
||||
- **Default starting version**: `0.1.0`
|
||||
- **Increment rules**:
|
||||
- **Major/breaking changes**: `1.2.3` -> `2.0.0` (major +1, minor and patch reset to zero)
|
||||
- **New feature (feat)**: `1.2.3` -> `1.3.0` (minor +1, patch reset to zero)
|
||||
- **Bug fix (fix)**: `1.2.3` -> `1.2.4` (patch +1)
|
||||
|
||||
**Determine if version number update is needed**:
|
||||
|
||||
> Core principle: **Version number reflects "user-perceivable changes"**. Ask yourself: Has the product that users download/use changed?
|
||||
|
||||
**Need to update version number** (packaged into final product, user-perceivable):
|
||||
|
||||
| commit type | version change | description |
|
||||
| --- | --- | --- |
|
||||
| `feat` | minor +1 | new feature |
|
||||
| `fix` | patch +1 | user-perceivable bug fix |
|
||||
| `perf` | patch +1 | performance optimization (user-perceivable improvement) |
|
||||
| breaking change (`!`) | major +1 | API/protocol incompatible changes |
|
||||
|
||||
**No need to update version number** (doesn't affect final product, user-imperceptible):
|
||||
|
||||
| commit type | description | example |
|
||||
| --- | --- | --- |
|
||||
| `chore` | miscellaneous/toolchain | build scripts, CI config, dependency updates |
|
||||
| `ci` | CI/CD config | `.github/workflows/*.yml`, `release.mjs` |
|
||||
| `docs` | documentation | README, comments, API docs |
|
||||
| `test` | test code | unit tests, E2E tests |
|
||||
| `refactor` | refactoring | code reorganization without changing external behavior |
|
||||
| `style` | code style | formatting, spaces, semicolons |
|
||||
| `build` | build config | `tsconfig.json`, `biome.json`, `webpack.config.js` |
|
||||
|
||||
**Judgment tips**:
|
||||
|
||||
1. **Will the file be packaged into final product?**
|
||||
- `scripts/`, `.github/`, `*.config.js` -> No -> Don't update version
|
||||
- `src/`, `lib/`, `app/` -> Yes -> May need to update version
|
||||
|
||||
2. **Does the change only affect developers?**
|
||||
- Dev tool config, CI scripts, build process -> Only affects developers -> Don't update version
|
||||
- Feature code, UI, API -> Affects users -> Update version
|
||||
|
||||
3. **If project type cannot be identified or no version file** -> Only create git tag, don't update version file
|
||||
|
||||
### 5. Generate Commit Message
|
||||
|
||||
Based on changes in staging area, **analyze and generate meaningful commit message by AI**:
|
||||
|
||||
- Analyze changed code content, understand the purpose and intent of this modification
|
||||
- Reference project's commit history style
|
||||
- Use [Conventional Commits](https://www.conventionalcommits.org/) specification
|
||||
- Commit message should concisely but accurately describe "why" rather than just "what"
|
||||
- Common types: `feat` (new feature), `fix` (fix), `docs` (documentation), `refactor` (refactoring), `chore` (miscellaneous), `test` (test), etc.
|
||||
- **If monorepo and this commit only affects single subproject, include subproject name in commit message**:
|
||||
- Format: `<type>(<scope>): <description>`, where `<scope>` is subproject name
|
||||
- Example: `feat(ios): support OGG Opus upload` or `fix(electron): fix clipboard injection failure`
|
||||
- If affecting multiple subprojects or entire repository, no need to add scope
|
||||
|
||||
### 6. Update Project Version Number
|
||||
|
||||
> Only execute when step 4 determines version number update is needed and version file is identified
|
||||
|
||||
**Execution steps**:
|
||||
|
||||
1. Based on version file and field identified in step 4, update version number to calculated new version
|
||||
2. Add version file to staging area: `git add <version file>`
|
||||
3. **Verify staging area**: Run `git diff --cached --name-only` to confirm version file is in staging area
|
||||
|
||||
### 7. Execute Commit
|
||||
|
||||
Execute commit with generated commit message (staging area now includes user's changes and version number update).
|
||||
|
||||
**Windows encoding issue solution:**
|
||||
|
||||
Cursor's Shell tool has encoding issues when passing Chinese parameters on Windows, causing garbled Git commit messages.
|
||||
|
||||
**Correct approach**: Use **English** commit message
|
||||
|
||||
```powershell
|
||||
# Single line commit
|
||||
git commit -m "feat(android): add new feature"
|
||||
|
||||
# Multi-line commit (use --message multiple times)
|
||||
git commit --message="fix(android): fix code review issues" --message="- Fix syntax error" --message="- Use JSONObject instead of manual JSON"
|
||||
```
|
||||
|
||||
**Prohibited methods** (will cause garbled text):
|
||||
- No Chinese commit messages - Cursor Shell tool encoding error when passing Chinese parameters
|
||||
- No `Out-File -Encoding utf8` - writes UTF-8 with BOM
|
||||
- No Write tool to write temp files - encoding uncontrollable
|
||||
- No PowerShell here-string `@"..."@` - newline parsing issues
|
||||
|
||||
**For Chinese commit messages**: Please manually execute `git commit` in terminal, or use Git GUI tools other than Cursor.
|
||||
|
||||
**macOS/Linux alternative** (supports Chinese):
|
||||
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
feat(android): new feature description
|
||||
|
||||
- Detail 1
|
||||
- Detail 2
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
### 8. Create Tag
|
||||
|
||||
> **Executed by default**. Only skip this step when user explicitly inputs "skip" or "skip tag".
|
||||
> Only create tag when step 4 determines version number update is needed (docs/chore types don't create tag).
|
||||
|
||||
**Tag annotation content requirements**:
|
||||
|
||||
- **Use the same content as commit message for tag annotation**
|
||||
- Tag annotation will be used as Release notes by CI/CD scripts, should include detailed change content
|
||||
- If commit message has multiple lines, tag annotation should also be multi-line
|
||||
|
||||
**polyrepo**:
|
||||
```bash
|
||||
git tag -a "<version>" -m "<commit title>" -m "" -m "<commit body line 1>" -m "<commit body line 2>" ...
|
||||
```
|
||||
|
||||
**monorepo**:
|
||||
```bash
|
||||
git tag -a "<subproject>-<version>" -m "<commit title>" -m "" -m "<commit body line 1>" -m "<commit body line 2>" ...
|
||||
```
|
||||
|
||||
Examples (single line commit):
|
||||
- polyrepo: `git tag -a "1.2.0" -m "feat: add user authentication"`
|
||||
- monorepo: `git tag -a "android-1.2.0" -m "feat(android): add user authentication"`
|
||||
|
||||
Examples (multi-line commit, more recommended):
|
||||
- polyrepo:
|
||||
```bash
|
||||
git tag -a "1.2.1" -m "fix: resolve bluetooth connection timeout" -m "" -m "- Increase connection timeout to 30s" -m "- Add retry mechanism for failed connections" -m "- Improve error messages"
|
||||
```
|
||||
- monorepo:
|
||||
```bash
|
||||
git tag -a "android-1.2.1" -m "fix(android): resolve bluetooth connection timeout" -m "" -m "- Increase connection timeout to 30s" -m "- Add retry mechanism for failed connections" -m "- Improve error messages"
|
||||
```
|
||||
|
||||
### 9. Push to Remote Repository
|
||||
|
||||
```bash
|
||||
# Push current branch
|
||||
git push origin $(git branch --show-current)
|
||||
```
|
||||
|
||||
**If tag was created, also push tag**:
|
||||
|
||||
**polyrepo**:
|
||||
```bash
|
||||
git push origin <version>
|
||||
```
|
||||
|
||||
**monorepo**:
|
||||
```bash
|
||||
git push origin <subproject>-<version>
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **Staging area check first**: Must check if staging area has files first, if not, terminate immediately, don't execute any subsequent operations.
|
||||
- **AGENTS.md priority**: If `AGENTS.md` defines version update rules, prioritize using that rule; otherwise AI auto-detects project type.
|
||||
- **Smart detection**: AI should intelligently determine project type and version file location based on files that actually exist in repository.
|
||||
- **Version number and tag consistency**: Project version number and git tag use the same version number, ensure consistency.
|
||||
- **Version number format**: Use `major.minor.patch` semantic versioning format (e.g., `0.1.0`, `1.1.0`, `1.1.1`), default starting `0.1.0`.
|
||||
- **Create tag by default**: Unless user inputs "skip" or "skip tag", create and push tag by default.
|
||||
- **Update version before commit**: First determine version number and modify version file, then commit at once, avoid using `--amend`.
|
||||
- **Version file must be verified**: After updating version number and `git add`, must run `git diff --cached --name-only` to confirm version file is in staging area before executing commit.
|
||||
- **Windows encoding issues**: Cursor Shell tool garbles Chinese parameters, must use **English** commit messages. For Chinese, please manually execute in terminal.
|
||||
- **monorepo scope**: If staging area only affects single subproject, commit message should have scope; if affecting multiple subprojects, no scope needed.
|
||||
- **monorepo tag format**: Use `<subproject>-<version>` format (e.g., `ios-0.1.0`, `android-1.1.0`).
|
||||
- **No version file case**: If project type cannot be identified or no version file (like pure Go project), only create git tag, don't update any files.
|
||||
130
command/create-gitea-repo.md
Normal file
130
command/create-gitea-repo.md
Normal file
@@ -0,0 +1,130 @@
|
||||
---
|
||||
description: Create a new Git repository on Gitea
|
||||
agent: build
|
||||
---
|
||||
|
||||
# create-gitea-repo
|
||||
|
||||
Create a new Git repository on Gitea.
|
||||
|
||||
## Features
|
||||
|
||||
- Create new repository under specified organization or user via Gitea API
|
||||
- Support creating private or public repositories
|
||||
- Automatically add remote repository address after successful creation
|
||||
|
||||
## User Input Format
|
||||
|
||||
User can specify parameters in the following format:
|
||||
|
||||
```
|
||||
<owner>/<repo> [private|public]
|
||||
```
|
||||
|
||||
- `owner`: Organization name or username (required)
|
||||
- `repo`: Repository name (required)
|
||||
- `private|public`: Visibility (optional, default `private`)
|
||||
|
||||
**Examples**:
|
||||
- `ai/my-project` - Create private repository my-project under ai organization
|
||||
- `ai/my-project public` - Create public repository my-project under ai organization
|
||||
- `voson/test private` - Create private repository test under voson user
|
||||
|
||||
## Configuration
|
||||
|
||||
Use the following configuration when executing command:
|
||||
|
||||
| Config Item | Value |
|
||||
| --- | --- |
|
||||
| Gitea Server URL | `https://git.digitevents.com/` |
|
||||
| API Token | `{env:GITEA_API_TOKEN}` |
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Parse User Input
|
||||
|
||||
Parse from user input:
|
||||
- `owner`: Organization name or username
|
||||
- `repo`: Repository name
|
||||
- `visibility`: `private` (default) or `public`
|
||||
|
||||
**Input validation**:
|
||||
- If user didn't provide `owner/repo` format input, prompt user for correct format and terminate execution
|
||||
- Repository name can only contain letters, numbers, underscores, hyphens and dots
|
||||
|
||||
### 2. Call Gitea API to Create Repository
|
||||
|
||||
Use curl to call Gitea API:
|
||||
|
||||
```bash
|
||||
curl -s -X POST "https://git.digitevents.com/api/v1/orgs/<owner>/repos" \
|
||||
-H "Authorization: token $GITEA_API_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "<repo>",
|
||||
"private": <true|false>
|
||||
}'
|
||||
```
|
||||
|
||||
> Note: If owner is personal user instead of organization, API path should be `/api/v1/user/repos`, but usually try organization API first.
|
||||
|
||||
### 3. Handle Response
|
||||
|
||||
**Success** (HTTP 201):
|
||||
- Extract repository info from response:
|
||||
- `html_url`: Repository web URL
|
||||
- `clone_url`: HTTPS clone URL
|
||||
- `ssh_url`: SSH clone URL
|
||||
- Output creation success message
|
||||
|
||||
**Failure**:
|
||||
- If 404 error, owner may not exist or no permission
|
||||
- If 409 error, repository already exists
|
||||
- Output error message and terminate
|
||||
|
||||
### 4. Ask Whether to Add Remote Repository
|
||||
|
||||
Ask user whether to add the newly created repository as current project's remote repository.
|
||||
|
||||
**If user confirms**:
|
||||
|
||||
1. Check if current directory is a Git repository:
|
||||
```bash
|
||||
git rev-parse --is-inside-work-tree
|
||||
```
|
||||
|
||||
2. If not a Git repository, ask whether to initialize:
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
3. Check if origin remote already exists:
|
||||
```bash
|
||||
git remote get-url origin
|
||||
```
|
||||
|
||||
4. Add or update remote repository:
|
||||
- If no origin: `git remote add origin <clone_url>`
|
||||
- If origin exists: Ask whether to overwrite, after confirmation execute `git remote set-url origin <clone_url>`
|
||||
|
||||
### 5. Output Result Summary
|
||||
|
||||
Output creation result summary table:
|
||||
|
||||
```
|
||||
Repository created successfully!
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Repository Name | owner/repo |
|
||||
| Web URL | https://git.digitevents.com/owner/repo |
|
||||
| Clone URL (HTTPS) | https://git.digitevents.com/owner/repo.git |
|
||||
| Clone URL (SSH) | git@git.digitevents.com:owner/repo.git |
|
||||
| Private | Yes/No |
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **Permission check**: Ensure Token has permission to create repository
|
||||
- **Organization vs User**: Creating organization repository and user repository use different API endpoints
|
||||
- **Repository naming**: Follow Gitea naming rules, avoid special characters
|
||||
16
command/review.md
Normal file
16
command/review.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
description: Review code or documentation and provide suggestions
|
||||
agent: plan
|
||||
---
|
||||
|
||||
# review
|
||||
|
||||
## Actions to Execute
|
||||
|
||||
1. Review the code or documentation mentioned by user
|
||||
2. Provide suggestions and content that needs modification
|
||||
3. Ask user if modifications are needed, if there's content that doesn't need modification; if user doesn't specify, modify all
|
||||
|
||||
## Notes
|
||||
|
||||
- If user doesn't mention documentation or code, prompt user to provide documentation or code.
|
||||
81
command/sync-oc-pull.md
Normal file
81
command/sync-oc-pull.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
description: Pull latest OpenCode config changes from remote
|
||||
agent: build
|
||||
---
|
||||
|
||||
# sync-oc-pull
|
||||
|
||||
Pull latest changes for OpenCode configuration from remote repository.
|
||||
|
||||
## Use Cases
|
||||
|
||||
When you updated OpenCode configuration on another device, or team members shared new commands/configurations, use this command to sync to local.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Switch to OpenCode Config Directory
|
||||
|
||||
```bash
|
||||
cd ~/.config/opencode
|
||||
```
|
||||
|
||||
### 2. Check Local Status
|
||||
|
||||
Run `git status` to check if there are uncommitted local changes.
|
||||
|
||||
**If there are uncommitted changes**:
|
||||
- List changed files
|
||||
- Ask user how to handle:
|
||||
- **Stash**: `git stash` to save local changes, restore after pull
|
||||
- **Discard**: `git checkout -- .` to discard local changes
|
||||
- **Cancel**: Terminate operation, let user handle manually
|
||||
|
||||
### 3. Pull Remote Changes
|
||||
|
||||
```bash
|
||||
git pull origin master
|
||||
```
|
||||
|
||||
### 4. Handle Conflicts (if any)
|
||||
|
||||
If conflicts occur during pull:
|
||||
|
||||
1. List conflicting files
|
||||
2. Open conflict files, analyze conflict content
|
||||
3. Ask user to choose:
|
||||
- **Keep local version**: Use `git checkout --ours <file>`
|
||||
- **Use remote version**: Use `git checkout --theirs <file>`
|
||||
- **Manual merge**: Prompt user to manually edit then execute `git add <file>`
|
||||
|
||||
4. After resolving all conflicts, complete merge:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "chore: resolve merge conflicts"
|
||||
```
|
||||
|
||||
### 5. Restore Stashed Changes (if any)
|
||||
|
||||
If `git stash` was used in step 2:
|
||||
|
||||
```bash
|
||||
git stash pop
|
||||
```
|
||||
|
||||
If conflicts occur during restore, handle according to step 4.
|
||||
|
||||
### 6. Show Update Summary
|
||||
|
||||
After pull completes, show update content:
|
||||
|
||||
```bash
|
||||
git log --oneline -5
|
||||
```
|
||||
|
||||
List newly added or modified command files to help user understand what new configurations are available.
|
||||
|
||||
## Notes
|
||||
|
||||
- **Backup important configs**: If there are local modifications before pull, suggest backing up or using `git stash` first.
|
||||
- **Conflict handling**: Config file conflicts usually prioritize keeping local version, unless explicitly needing remote's new config.
|
||||
- **Verify config**: After pull, suggest checking if `opencode.json` and other config files work correctly.
|
||||
75
command/sync-oc-push.md
Normal file
75
command/sync-oc-push.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
description: Commit and push OpenCode config changes to remote
|
||||
agent: build
|
||||
---
|
||||
|
||||
# sync-oc-push
|
||||
|
||||
Commit and push OpenCode configuration repository changes to remote repository.
|
||||
|
||||
## Use Cases
|
||||
|
||||
When you modified config files in `~/.config/opencode` directory (such as `command/`, `skill/`, `opencode.json`, etc.), use this command to sync changes to remote repository.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Switch to OpenCode Config Directory
|
||||
|
||||
```bash
|
||||
cd ~/.config/opencode
|
||||
```
|
||||
|
||||
### 2. Check Change Status
|
||||
|
||||
Run `git status` to view current changes.
|
||||
|
||||
**If there are no changes**:
|
||||
- Output prompt: "No changes to commit."
|
||||
- **Terminate command execution**
|
||||
|
||||
### 3. Collect Information (Execute in parallel)
|
||||
|
||||
- Run `git diff` to view unstaged changes
|
||||
- Run `git diff --cached` to view staged changes
|
||||
- Run `git log --oneline -5` to view recent commit history
|
||||
|
||||
### 4. Add Changes to Staging Area
|
||||
|
||||
Add all relevant config files to staging area:
|
||||
|
||||
```bash
|
||||
git add command/ skill/ opencode.json
|
||||
```
|
||||
|
||||
> Only add config files that need to be synced, ignore other local files.
|
||||
|
||||
### 5. Generate Commit Message and Commit
|
||||
|
||||
Generate concise commit message based on change content:
|
||||
|
||||
- Use [Conventional Commits](https://www.conventionalcommits.org/) specification
|
||||
- Common types:
|
||||
- `feat`: New command or config
|
||||
- `fix`: Fix command or config issues
|
||||
- `docs`: Documentation update
|
||||
- `chore`: Miscellaneous adjustments
|
||||
|
||||
**Examples**:
|
||||
|
||||
```bash
|
||||
git commit -m "feat: add new developer command for Vue.js"
|
||||
git commit -m "fix: correct MCP server configuration"
|
||||
git commit -m "docs: update review command instructions"
|
||||
```
|
||||
|
||||
### 6. Push to Remote Repository
|
||||
|
||||
```bash
|
||||
git push origin master
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **Only sync config files**: Only add `command/`, `skill/` and `opencode.json`, don't commit other local data.
|
||||
- **Sensitive info**: `opencode.json` may contain API keys, ensure remote repository access permissions are set correctly.
|
||||
- **English commit**: To avoid encoding issues, suggest using English commit messages.
|
||||
Reference in New Issue
Block a user