commit d738304a7c4431f3a015b516dea858e3db9523aa Author: voson Date: Tue Jan 6 17:27:42 2026 +0800 feat: initial opencode config with commands, skills and MCP services diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..4154681 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +node_modules/ +package.json +bun.lock +*.log \ No newline at end of file diff --git a/command/auto-commit.md b/command/auto-commit.md new file mode 100644 index 0000000..1843b35 --- /dev/null +++ b/command/auto-commit.md @@ -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` | `` or `` | + +> 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: `(): `, where `` 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 ` +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 "" -m "" -m "" -m "" -m "" ... +``` + +**monorepo**: +```bash +git tag -a "-" -m "" -m "" -m "" -m "" ... +``` + +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 `-` 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. diff --git a/command/commit-push.md b/command/commit-push.md new file mode 100644 index 0000000..f9f1783 --- /dev/null +++ b/command/commit-push.md @@ -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` | `` or `` | + +> 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: `(): `, where `` 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 ` +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 "" -m "" -m "" -m "" -m "" ... +``` + +**monorepo**: +```bash +git tag -a "-" -m "" -m "" -m "" -m "" ... +``` + +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 +``` + +**monorepo**: +```bash +git push origin - +``` + +## 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 `-` 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. diff --git a/command/create-gitea-repo.md b/command/create-gitea-repo.md new file mode 100644 index 0000000..5b19927 --- /dev/null +++ b/command/create-gitea-repo.md @@ -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: + +``` +/ [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//repos" \ + -H "Authorization: token $GITEA_API_TOKEN" \ + -H "Content-Type: application/json" \ + -d '{ + "name": "", + "private": + }' +``` + +> 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 ` + - If origin exists: Ask whether to overwrite, after confirmation execute `git remote set-url origin ` + +### 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 diff --git a/command/review.md b/command/review.md new file mode 100644 index 0000000..f57c527 --- /dev/null +++ b/command/review.md @@ -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. diff --git a/command/sync-oc-pull.md b/command/sync-oc-pull.md new file mode 100644 index 0000000..fd85a85 --- /dev/null +++ b/command/sync-oc-pull.md @@ -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 ` + - **Use remote version**: Use `git checkout --theirs ` + - **Manual merge**: Prompt user to manually edit then execute `git add ` + +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. diff --git a/command/sync-oc-push.md b/command/sync-oc-push.md new file mode 100644 index 0000000..ee3726e --- /dev/null +++ b/command/sync-oc-push.md @@ -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. diff --git a/env.sh b/env.sh new file mode 100644 index 0000000..e71cb56 --- /dev/null +++ b/env.sh @@ -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" diff --git a/opencode.json b/opencode.json new file mode 100644 index 0000000..bd61761 --- /dev/null +++ b/opencode.json @@ -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}" + } + } + } +} diff --git a/skill/android-developer/SKILL.md b/skill/android-developer/SKILL.md new file mode 100644 index 0000000..42053c5 --- /dev/null +++ b/skill/android-developer/SKILL.md @@ -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 diff --git a/skill/electron-developer/SKILL.md b/skill/electron-developer/SKILL.md new file mode 100644 index 0000000..3af88f9 --- /dev/null +++ b/skill/electron-developer/SKILL.md @@ -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` +
Hello, ${this.name}!
+ + `; + } + + 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); +}); +``` diff --git a/skill/go-developer/SKILL.md b/skill/go-developer/SKILL.md new file mode 100644 index 0000000..97e6e04 --- /dev/null +++ b/skill/go-developer/SKILL.md @@ -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 + +# 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 /... +``` + +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 diff --git a/skill/ios-developer/SKILL.md b/skill/ios-developer/SKILL.md new file mode 100644 index 0000000..da51993 --- /dev/null +++ b/skill/ios-developer/SKILL.md @@ -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/)