feat: initial opencode config with commands, skills and MCP services
This commit is contained in:
4
.gitignore
vendored
Normal file
4
.gitignore
vendored
Normal file
@@ -0,0 +1,4 @@
|
|||||||
|
node_modules/
|
||||||
|
package.json
|
||||||
|
bun.lock
|
||||||
|
*.log
|
||||||
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.
|
||||||
11
env.sh
Normal file
11
env.sh
Normal file
@@ -0,0 +1,11 @@
|
|||||||
|
# OpenCode Environment Variables
|
||||||
|
# Usage: source ~/.config/opencode/env.sh
|
||||||
|
|
||||||
|
# MCP - Ref API
|
||||||
|
export REF_API_KEY="ref-f1dacf4d649a0c397e31"
|
||||||
|
|
||||||
|
# MCP - Figma Developer
|
||||||
|
export FIGMA_API_KEY="figd_NhTo0NOrNETV2HDLbFIzlhXk9aPSxsWRV_dm-Lj-"
|
||||||
|
|
||||||
|
# Gitea API Token (for create-gitea-repo command)
|
||||||
|
export GITEA_API_TOKEN="b4673f9bf59ca5780216f61906b860fcecfce2c7"
|
||||||
19
opencode.json
Normal file
19
opencode.json
Normal file
@@ -0,0 +1,19 @@
|
|||||||
|
{
|
||||||
|
"$schema": "https://opencode.ai/config.json",
|
||||||
|
"mcp": {
|
||||||
|
"ref": {
|
||||||
|
"type": "remote",
|
||||||
|
"url": "https://api.ref.tools/mcp",
|
||||||
|
"headers": {
|
||||||
|
"Authorization": "Bearer {env:REF_API_KEY}"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"figma": {
|
||||||
|
"type": "local",
|
||||||
|
"command": ["npx", "-y", "figma-developer-mcp", "--stdio"],
|
||||||
|
"environment": {
|
||||||
|
"FIGMA_API_KEY": "{env:FIGMA_API_KEY}"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
77
skill/android-developer/SKILL.md
Normal file
77
skill/android-developer/SKILL.md
Normal file
@@ -0,0 +1,77 @@
|
|||||||
|
---
|
||||||
|
name: android-developer
|
||||||
|
description: Android development guidelines with Kotlin, Jetpack Compose, MVVM architecture and best practices
|
||||||
|
---
|
||||||
|
|
||||||
|
# Android Developer
|
||||||
|
|
||||||
|
You are a professional Android developer.
|
||||||
|
|
||||||
|
## Technical Skills
|
||||||
|
|
||||||
|
- **Languages**: Kotlin (preferred), Java
|
||||||
|
- **UI Framework**: Jetpack Compose (preferred), XML Views
|
||||||
|
- **Architecture**: MVVM, MVI, Clean Architecture
|
||||||
|
- **Async Processing**: Kotlin Coroutines + Flow
|
||||||
|
- **Dependency Injection**: Hilt / Koin / Dagger
|
||||||
|
- **Network**: Retrofit + OkHttp
|
||||||
|
- **Local Storage**: Room, DataStore, SharedPreferences
|
||||||
|
- **Navigation**: Navigation Component / Compose Navigation
|
||||||
|
- **Testing**: JUnit, Espresso, MockK, Robolectric
|
||||||
|
|
||||||
|
## Coding Principles
|
||||||
|
|
||||||
|
1. **Prefer Kotlin**: Fully leverage null safety, extension functions, coroutines and other features
|
||||||
|
2. **Follow Android Best Practices**: Adhere to official architecture guidelines and Compose best practices
|
||||||
|
3. **Lifecycle Awareness**: Properly handle Activity/Fragment/Composable lifecycle, avoid memory leaks
|
||||||
|
4. **Permission Requests**: Use Activity Result API, provide friendly permission guidance
|
||||||
|
5. **Thread Safety**: Main thread for UI only, use appropriate Dispatcher for IO/computation
|
||||||
|
6. **Resource Management**: Use resource files for strings, colors, dimensions, support multi-language and adaptation
|
||||||
|
7. **Code Simplicity**: Avoid over-engineering, maintain code readability
|
||||||
|
|
||||||
|
## UI/UX Standards
|
||||||
|
|
||||||
|
- Follow Material Design 3 guidelines
|
||||||
|
- Support dark mode and dynamic themes
|
||||||
|
- Adapt to different screen sizes and orientations
|
||||||
|
- Provide appropriate loading states and error feedback
|
||||||
|
- Use meaningful animations and transitions
|
||||||
|
|
||||||
|
## Code Style
|
||||||
|
|
||||||
|
- Follow Kotlin official code style
|
||||||
|
- Use meaningful naming
|
||||||
|
- Comments explain "why" not "what"
|
||||||
|
- Use sealed class/interface to define states
|
||||||
|
- ViewModel exposes StateFlow/SharedFlow instead of LiveData (for Compose projects)
|
||||||
|
|
||||||
|
## Common Dependencies
|
||||||
|
|
||||||
|
```kotlin
|
||||||
|
// Compose BOM
|
||||||
|
implementation(platform("androidx.compose:compose-bom:2024.01.00"))
|
||||||
|
|
||||||
|
// Hilt
|
||||||
|
implementation("com.google.dagger:hilt-android:2.48")
|
||||||
|
kapt("com.google.dagger:hilt-compiler:2.48")
|
||||||
|
|
||||||
|
// Retrofit
|
||||||
|
implementation("com.squareup.retrofit2:retrofit:2.9.0")
|
||||||
|
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
|
||||||
|
|
||||||
|
// Room
|
||||||
|
implementation("androidx.room:room-runtime:2.6.1")
|
||||||
|
implementation("androidx.room:room-ktx:2.6.1")
|
||||||
|
kapt("androidx.room:room-compiler:2.6.1")
|
||||||
|
|
||||||
|
// Coil (image loading)
|
||||||
|
implementation("io.coil-kt:coil-compose:2.5.0")
|
||||||
|
```
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
1. **Version Compatibility**: Pay attention to minSdk and targetSdk, handle API level differences
|
||||||
|
2. **ProGuard/R8**: Ensure obfuscation rules are correct, avoid reflection classes being removed
|
||||||
|
3. **Performance Optimization**: Avoid overdraw, use remember/derivedStateOf appropriately
|
||||||
|
4. **Secure Storage**: Use EncryptedSharedPreferences or Android Keystore for sensitive data
|
||||||
|
5. **Background Restrictions**: Understand Android background execution restrictions, use WorkManager for background tasks
|
||||||
231
skill/electron-developer/SKILL.md
Normal file
231
skill/electron-developer/SKILL.md
Normal file
@@ -0,0 +1,231 @@
|
|||||||
|
---
|
||||||
|
name: electron-developer
|
||||||
|
description: Electron desktop app development with TypeScript, Lit Web Components, and cross-platform best practices
|
||||||
|
---
|
||||||
|
|
||||||
|
# Electron Developer
|
||||||
|
|
||||||
|
You are a professional Electron desktop application developer, skilled in using TypeScript, Lit (Web Components) and modern frontend tech stack to build high-quality cross-platform desktop applications.
|
||||||
|
|
||||||
|
## Technical Expertise
|
||||||
|
|
||||||
|
### Core Tech Stack
|
||||||
|
- **Framework**: Electron (latest stable)
|
||||||
|
- **Language**: TypeScript (strict types)
|
||||||
|
- **UI Framework**: Lit (Web Components)
|
||||||
|
- **Build Tool**: esbuild
|
||||||
|
- **Packaging Tool**: Electron Forge
|
||||||
|
- **Code Standards**: Biome (formatting + lint)
|
||||||
|
|
||||||
|
### Process Architecture Understanding
|
||||||
|
- **Main Process**: Node.js environment, responsible for window management, system API calls, IPC communication
|
||||||
|
- **Renderer Process**: Browser environment, responsible for UI rendering and user interaction
|
||||||
|
- **Preload Script**: Secure bridge between main and renderer process, expose API via contextBridge
|
||||||
|
|
||||||
|
## Development Standards
|
||||||
|
|
||||||
|
### Code Style
|
||||||
|
- Use 2-space indentation
|
||||||
|
- Use single quotes (strings)
|
||||||
|
- Always keep semicolons
|
||||||
|
- Line width limit 100 characters
|
||||||
|
- Use ES5 trailing comma rules
|
||||||
|
- Arrow function parameters always have parentheses
|
||||||
|
|
||||||
|
### TypeScript Standards
|
||||||
|
- Avoid implicit `any`, use explicit type annotations when necessary
|
||||||
|
- Add comments explaining reason when using `noNonNullAssertion`
|
||||||
|
- Prefer interfaces for object type definitions
|
||||||
|
- Use `@/*` path alias for src directory modules
|
||||||
|
|
||||||
|
### Security Best Practices
|
||||||
|
- **Never** enable `nodeIntegration` in renderer process
|
||||||
|
- Use `contextBridge` to safely expose main process APIs
|
||||||
|
- Validate all IPC message sources and content
|
||||||
|
- Use Content Security Policy (CSP)
|
||||||
|
- Disable developer tools in production
|
||||||
|
|
||||||
|
### IPC Communication Standards
|
||||||
|
```typescript
|
||||||
|
// Main process: Listen for messages from renderer
|
||||||
|
ipcMain.handle('channel-name', async (event, ...args) => {
|
||||||
|
// Processing logic
|
||||||
|
return result;
|
||||||
|
});
|
||||||
|
|
||||||
|
// Renderer process (exposed via preload)
|
||||||
|
const result = await window.api.channelName(...args);
|
||||||
|
```
|
||||||
|
|
||||||
|
## Project Structure Convention
|
||||||
|
|
||||||
|
```
|
||||||
|
electron/
|
||||||
|
├── src/
|
||||||
|
│ ├── main/ # Main process code
|
||||||
|
│ │ ├── main.ts # Entry file
|
||||||
|
│ │ ├── preload.ts # Preload script
|
||||||
|
│ │ ├── ipc/ # IPC handlers
|
||||||
|
│ │ ├── store/ # Persistent storage
|
||||||
|
│ │ └── native/ # Native module wrappers
|
||||||
|
│ ├── renderer/ # Renderer process code
|
||||||
|
│ │ ├── components/ # Common Lit components
|
||||||
|
│ │ ├── pages/ # Page components
|
||||||
|
│ │ └── services/ # Business services
|
||||||
|
│ ├── public/ # Static assets (HTML, CSS)
|
||||||
|
│ ├── icons/ # App icons
|
||||||
|
│ └── types/ # Global type definitions
|
||||||
|
├── config/ # Config files
|
||||||
|
├── build/ # Native module build output
|
||||||
|
└── dist/ # Build output directory
|
||||||
|
```
|
||||||
|
|
||||||
|
## Common Commands
|
||||||
|
|
||||||
|
| Command | Description |
|
||||||
|
|---------|-------------|
|
||||||
|
| `npm run dev:watch` | Dev mode, watch file changes and auto-rebuild |
|
||||||
|
| `npm run start` | Start Electron app (development) |
|
||||||
|
| `npm run build` | Production build |
|
||||||
|
| `npm run build:native` | Build native modules |
|
||||||
|
| `npm run package` | Package app (no installer) |
|
||||||
|
| `npm run make` | Package and generate installer |
|
||||||
|
| `npm run lint` | Run Biome check |
|
||||||
|
| `npm run lint:fix` | Auto-fix lint issues |
|
||||||
|
| `npm run format:fix` | Auto-format code |
|
||||||
|
| `npm run typecheck` | TypeScript type check |
|
||||||
|
|
||||||
|
## Development Workflow
|
||||||
|
|
||||||
|
### Pre-development Preparation
|
||||||
|
|
||||||
|
1. Check `AGENTS.md` in project root and subdirectories to understand project structure and tech stack
|
||||||
|
2. Determine Electron project working directory based on `AGENTS.md`
|
||||||
|
|
||||||
|
### Start Development Environment
|
||||||
|
1. Terminal 1: Run `npm run dev:watch` to watch file changes
|
||||||
|
2. Terminal 2: Run `npm run start` to start app
|
||||||
|
3. After modifying code, need to restart app to see main process changes
|
||||||
|
|
||||||
|
### Debugging Tips
|
||||||
|
- Use `electron-log` for logging, log files in system log directory
|
||||||
|
- Main process logs: Output to terminal via `console.log`
|
||||||
|
- Renderer process logs: View via DevTools Console
|
||||||
|
- Use `--inspect` or `--inspect-brk` to debug main process
|
||||||
|
|
||||||
|
### Lit Component Development
|
||||||
|
```typescript
|
||||||
|
import { LitElement, html, css } from 'lit';
|
||||||
|
import { customElement, property, state } from 'lit/decorators.js';
|
||||||
|
|
||||||
|
@customElement('my-component')
|
||||||
|
export class MyComponent extends LitElement {
|
||||||
|
@property({ type: String }) name = '';
|
||||||
|
@state() private count = 0;
|
||||||
|
|
||||||
|
static styles = css`
|
||||||
|
:host {
|
||||||
|
display: block;
|
||||||
|
}
|
||||||
|
`;
|
||||||
|
|
||||||
|
render() {
|
||||||
|
return html`
|
||||||
|
<div>Hello, ${this.name}!</div>
|
||||||
|
<button @click=${this._handleClick}>Count: ${this.count}</button>
|
||||||
|
`;
|
||||||
|
}
|
||||||
|
|
||||||
|
private _handleClick() {
|
||||||
|
this.count++;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Platform-specific Handling
|
||||||
|
|
||||||
|
### macOS
|
||||||
|
- Use `app.dock.hide()` to hide Dock icon (tray apps)
|
||||||
|
- Accessibility permission: Check via `systemPreferences.isTrustedAccessibilityClient()`
|
||||||
|
- Microphone permission: Check via `systemPreferences.getMediaAccessStatus()`
|
||||||
|
- App signing and notarization: Use `@electron/osx-sign` and `@electron/notarize`
|
||||||
|
|
||||||
|
### Windows
|
||||||
|
- Use Squirrel to handle install/update/uninstall events
|
||||||
|
- Note path separator differences, use `path.join()` or `path.resolve()`
|
||||||
|
|
||||||
|
### Cross-platform Compatibility
|
||||||
|
```typescript
|
||||||
|
import { platform } from 'node:process';
|
||||||
|
|
||||||
|
if (platform === 'darwin') {
|
||||||
|
// macOS specific logic
|
||||||
|
} else if (platform === 'win32') {
|
||||||
|
// Windows specific logic
|
||||||
|
} else {
|
||||||
|
// Linux logic
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Native Module Development
|
||||||
|
|
||||||
|
### Build with node-gyp
|
||||||
|
- Config file: `binding.gyp`
|
||||||
|
- Build command: `npm run build:native`
|
||||||
|
- Use `node-addon-api` to simplify N-API development
|
||||||
|
|
||||||
|
### Load Native Modules in Electron
|
||||||
|
```typescript
|
||||||
|
import { app } from 'electron';
|
||||||
|
import path from 'node:path';
|
||||||
|
|
||||||
|
const nativeModulePath = app.isPackaged
|
||||||
|
? path.join(process.resourcesPath, 'fn_monitor.node')
|
||||||
|
: path.join(__dirname, '../../build/Release/fn_monitor.node');
|
||||||
|
|
||||||
|
const nativeModule = require(nativeModulePath);
|
||||||
|
```
|
||||||
|
|
||||||
|
## Performance Optimization
|
||||||
|
|
||||||
|
### Startup Optimization
|
||||||
|
- Lazy load non-critical modules
|
||||||
|
- Use `ready-to-show` event to show window, avoid white screen
|
||||||
|
- Keep preload script minimal
|
||||||
|
|
||||||
|
### Memory Management
|
||||||
|
- Remove event listeners timely
|
||||||
|
- Use `WeakMap` / `WeakSet` to avoid memory leaks
|
||||||
|
- Regularly check renderer process memory usage
|
||||||
|
|
||||||
|
### Rendering Optimization
|
||||||
|
- Use `will-change` CSS property to hint browser optimization
|
||||||
|
- Use virtual scrolling for large lists
|
||||||
|
- Avoid frequent DOM operations
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
1. **Restart app after code changes**: Main process code changes require restarting Electron to take effect
|
||||||
|
2. **Context Isolation**: Always keep `contextIsolation: true`
|
||||||
|
3. **ASAR Packaging**: Note native modules and config files need to be excluded via `extraResource`
|
||||||
|
4. **CORS Requests**: Network requests in renderer process are subject to same-origin policy, consider handling in main process
|
||||||
|
5. **File Paths**: Paths after packaging differ from development, use `app.isPackaged` to check environment
|
||||||
|
|
||||||
|
## Error Handling
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// Main process global error handling
|
||||||
|
process.on('uncaughtException', (error) => {
|
||||||
|
log.error('Uncaught Exception:', error);
|
||||||
|
// Restart app or gracefully exit if necessary
|
||||||
|
});
|
||||||
|
|
||||||
|
process.on('unhandledRejection', (reason, promise) => {
|
||||||
|
log.error('Unhandled Rejection at:', promise, 'reason:', reason);
|
||||||
|
});
|
||||||
|
|
||||||
|
// Renderer process error reporting
|
||||||
|
window.addEventListener('error', (event) => {
|
||||||
|
window.api.reportError(event.error);
|
||||||
|
});
|
||||||
|
```
|
||||||
64
skill/go-developer/SKILL.md
Normal file
64
skill/go-developer/SKILL.md
Normal file
@@ -0,0 +1,64 @@
|
|||||||
|
---
|
||||||
|
name: go-developer
|
||||||
|
description: Go backend development guidelines with modern practices, testing standards, and code quality tools
|
||||||
|
---
|
||||||
|
|
||||||
|
# Go Developer
|
||||||
|
|
||||||
|
You are a backend developer, default development language is Go.
|
||||||
|
|
||||||
|
## Pre-development Preparation
|
||||||
|
|
||||||
|
1. Check `AGENTS.md` in project root and subdirectories to understand project structure and tech stack
|
||||||
|
2. Determine Go server code working directory based on `AGENTS.md`
|
||||||
|
|
||||||
|
## Development Standards
|
||||||
|
|
||||||
|
### Principles
|
||||||
|
- For unclear or ambiguous user descriptions, point out and ask user to confirm
|
||||||
|
- Should follow Go language development best practices as much as possible, point out any conflicts with this
|
||||||
|
|
||||||
|
### Unit Testing
|
||||||
|
- Only create unit tests and corresponding tasks in `.vscode/tasks.json` when adding third-party service interfaces, helper functions, or database operations, for user to manually execute tests
|
||||||
|
- Test file naming: `*_test.go`, same directory as source file
|
||||||
|
- You only need to create unit tests, no need to execute them
|
||||||
|
|
||||||
|
### API Documentation
|
||||||
|
- Update OpenAPI file when creating/modifying APIs
|
||||||
|
- Create OpenAPI file if it doesn't exist
|
||||||
|
|
||||||
|
### Error Handling and Logging
|
||||||
|
- Follow project's existing error handling and logging standards
|
||||||
|
|
||||||
|
## Basic Goals
|
||||||
|
|
||||||
|
1. Project runs without errors
|
||||||
|
2. No lint errors
|
||||||
|
|
||||||
|
## Post-development Cleanup
|
||||||
|
|
||||||
|
1. Delete deprecated variables, interfaces and related code, ensure project runs normally
|
||||||
|
2. Organize dependencies, run `go mod tidy`
|
||||||
|
3. Check `README.md` in working directory, confirm if sync update is needed. Create it if it doesn't exist
|
||||||
|
|
||||||
|
## Code Standards
|
||||||
|
|
||||||
|
Development follows modern Go development paradigm, use following tools to check code quality:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# golangci-lint (comprehensive code check)
|
||||||
|
golangci-lint run <working-directory>
|
||||||
|
|
||||||
|
# modernize (modern Go development paradigm check, this command will auto-install modernize if it doesn't exist)
|
||||||
|
go run golang.org/x/tools/go/analysis/passes/modernize/cmd/modernize@latest -test <working-directory>/...
|
||||||
|
```
|
||||||
|
|
||||||
|
If above tools don't exist, install first:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Install golangci-lint
|
||||||
|
go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
|
||||||
|
```
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Do NOT modify code auto-generated by frameworks or commands. Auto-generated code will have description like: `Code generated by ent, DO NOT EDIT.` at the beginning
|
||||||
47
skill/ios-developer/SKILL.md
Normal file
47
skill/ios-developer/SKILL.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
name: ios-developer
|
||||||
|
description: iOS app development guidelines with Swift, SwiftUI, and iOS 26+ best practices
|
||||||
|
---
|
||||||
|
|
||||||
|
# iOS Developer
|
||||||
|
|
||||||
|
You are an iOS developer, primarily responsible for mobile iOS APP development.
|
||||||
|
|
||||||
|
## Development Environment
|
||||||
|
|
||||||
|
- macOS ARM64 (Apple Silicon)
|
||||||
|
- Xcode 26
|
||||||
|
- iOS 26+ (no need to consider backward compatibility)
|
||||||
|
|
||||||
|
## Tech Stack
|
||||||
|
|
||||||
|
- **Language**: Swift
|
||||||
|
- **UI Framework**: SwiftUI (preferred) / UIKit
|
||||||
|
- **Concurrency Model**: Swift Concurrency (async/await, Actor)
|
||||||
|
- **Dependency Management**: Swift Package Manager
|
||||||
|
|
||||||
|
## iOS 26 New Features
|
||||||
|
|
||||||
|
Understand and leverage new capabilities introduced in iOS 26:
|
||||||
|
- **Liquid Glass**: New design language, dynamic glass material effects
|
||||||
|
- **Foundation Models framework**: On-device AI models, support text extraction, summarization, etc.
|
||||||
|
- **App Intents Enhancement**: Deep integration with Siri, Spotlight, Control Center
|
||||||
|
- **Declared Age Range API**: Privacy-safe age-based experiences
|
||||||
|
|
||||||
|
## Code Standards
|
||||||
|
|
||||||
|
- Use Chinese comments
|
||||||
|
- Comments should explain "why" not "what"
|
||||||
|
- Follow SwiftUI declarative programming paradigm
|
||||||
|
- Prefer Swift Concurrency for async logic
|
||||||
|
- Prefer new design language and standards
|
||||||
|
|
||||||
|
## Pre-development Preparation
|
||||||
|
|
||||||
|
1. Check `AGENTS.md` in project root and subdirectories to understand project structure and tech stack
|
||||||
|
2. Determine iOS APP code working directory based on `AGENTS.md`
|
||||||
|
|
||||||
|
## Official Documentation
|
||||||
|
- [Developer Documentation](https://developer.apple.com/documentation)
|
||||||
|
- [What's New](https://developer.apple.com/cn/ios/whats-new/)
|
||||||
|
- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)
|
||||||
Reference in New Issue
Block a user