From c3720ce6b3ff4f9ca01e60f644453028e355d048 Mon Sep 17 00:00:00 2001 From: Simon <10131203+gaomeng1900@users.noreply.github.com> Date: Thu, 9 Apr 2026 03:51:13 +0800 Subject: [PATCH] chore(repo): update dev guide and PR skill --- .../submit-pr-from-current-changes/SKILL.md | 40 +++++++++---------- docs/developer-guide.md | 2 +- 2 files changed, 20 insertions(+), 22 deletions(-) diff --git a/.agents/skills/submit-pr-from-current-changes/SKILL.md b/.agents/skills/submit-pr-from-current-changes/SKILL.md index 5190ae6..9ecbf48 100644 --- a/.agents/skills/submit-pr-from-current-changes/SKILL.md +++ b/.agents/skills/submit-pr-from-current-changes/SKILL.md @@ -30,21 +30,21 @@ Before attempting to push or open a PR, verify that the necessary tools are avai 2. **Inspect the diff.** Review changed files, scope, and impact. Understand what the change does before writing anything. 3. **Inspect repo conventions.** Check recent branch names (`git branch -r --sort=-committerdate | head -20`), recent commit messages (`git log --oneline -20`), and the PR template. 4. **Pre-submission health checks** (run all before creating the PR): - - **Unified theme**: All changes should serve one purpose. If unrelated changes are mixed in, ask the user to split or confirm. - - **Commit hygiene**: Every new commit must follow the repo's conventional commit style. Squash or reword if needed. - - **Author identity**: Verify `git config user.name` and `git config user.email` are set and the email looks real (not empty, not `noreply` unless intentional). Warn the user if not. - - **No leftover artifacts**: Check for debug logs, `.only` in tests, conflict markers, or temp files in the diff. - - **Lint and build**: Run lint/build for the affected area. Record results honestly. + - **Unified theme**: All changes should serve one purpose. If unrelated changes are mixed in, ask the user to split or confirm. + - **Commit hygiene**: Every new commit must follow the repo's conventional commit style. Squash or reword if needed. + - **Author identity**: Verify `git config user.name` and `git config user.email` are set and the email looks real (not empty, not `noreply` unless intentional). Warn the user if not. + - **No leftover artifacts**: Check for debug logs, `.only` in tests, conflict markers, or temp files in the diff. + - **Lint and build**: Run lint/build for the affected area. Record results honestly. 5. **Warn if the PR looks too hasty.** If any of these are true, pause and warn the user before proceeding: - - Large diff with no description of intent provided - - Changes touch core lib or extension (where vibe coding is prohibited per `CONTRIBUTING.md`) - - Multiple unrelated concerns in one diff - - No validation has been run at all - - Remind the user: *"This project does not accept low-quality or AI-generated PRs without meaningful human review. Please review your changes carefully."* + - Large diff with no description of intent provided + - Changes touch core lib or extension (where vibe coding is prohibited per `CONTRIBUTING.md`) + - Multiple unrelated concerns in one diff + - No validation has been run at all + - Remind the user: _"This project does not accept low-quality or AI-generated PRs without meaningful human review. Please review your changes carefully."_ 6. **Branch.** Check the current branch first: - - If already on a non-main feature branch with a valid name (matching `type/topic` convention), reuse it. - - If the branch name does not follow repo conventions (e.g. missing prefix, unclear topic), ask the user whether to rename or create a new one. - - If on `main` or a default branch, create a new branch from it with a short kebab-case name: prefix (`fix/`, `feat/`, `docs/`, `refactor/`, `chore/`) + concrete topic words. + - If already on a non-main feature branch with a valid name (matching `type/topic` convention), reuse it. + - If the branch name does not follow repo conventions (e.g. missing prefix, unclear topic), ask the user whether to rename or create a new one. + - If on `main` or a default branch, create a new branch from it with a short kebab-case name: prefix (`fix/`, `feat/`, `docs/`, `refactor/`, `chore/`) + concrete topic words. 7. **Stage and commit.** Stage only the intended files. Use `type(scope): subject` format. Keep the subject specific and compact. 8. **Push.** Push with `-u origin HEAD`. 9. **Open PR.** Use `gh pr create` with the full PR template structure. Fill in "What" and "Type" sections based on the actual diff. Leave all "Testing" and "Requirements" checkboxes unchecked. @@ -52,14 +52,12 @@ Before attempting to push or open a PR, verify that the necessary tools are avai ## Post-Submission Reminder -After successfully opening the PR, ALWAYS remind the user: +After successfully opening the PR, ALWAYS give a brief reminder in the user's language. Keep it concise and natural, but make sure it clearly tells the user: -> **This project requires human authorship declarations.** Please: -> 1. Test your changes in the browser yourself -> 2. Go to the PR page on GitHub and check the Testing and Requirements checkboxes after you've verified each item -> 3. The PR will not enter the review process until all checkboxes are checked -> -> This project does not accept PRs generated autonomously by AI. Make sure you can truthfully check the AI declaration. +1. They need to test the changes themselves in the browser. +2. They need to go to the PR page and check the Testing and Requirements checkboxes only after verifying each item. +3. The PR will not enter review until those checkboxes are checked. +4. The project does not accept autonomously AI-generated PRs, so they should only check the AI declaration if it is truthful. ## Branch Naming @@ -101,4 +99,4 @@ After successfully opening the PR, ALWAYS remind the user: - The PR body follows the template structure completely. - All "Requirements" and "Testing" checkboxes are unchecked (`- [ ]`) in the PR body. Double-check: if any `- [x]` appears in these sections, it is a violation — fix it before submitting. - The reported validation is accurate — nothing fabricated. -- The post-submission reminder has been printed verbatim to the user. +- The post-submission reminder was delivered in the user's language, concisely and accurately. diff --git a/docs/developer-guide.md b/docs/developer-guide.md index 8e34ce0..634b213 100644 --- a/docs/developer-guide.md +++ b/docs/developer-guide.md @@ -10,7 +10,7 @@ For contribution rules and expectations, see [../CONTRIBUTING.md](../CONTRIBUTIN 1. **Prerequisites** - `macOS` / `Linux` / `WSL` - - `node.js >= 20` with `npm >= 10` + - `node.js >= 24` with `npm >= 11` - An editor that supports `ts/eslint/prettier` - Make sure `eslint`, `prettier` and `commitlint` work well. Un-linted code won't pass the CI.