zoushiyang/page-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #423 from alibaba/chore/update-dev-guide-and-pr-skill

Browse Source 
chore: update dev guide and PR skill
This commit is contained in:
Simon
2026-04-12 03:29:38 +08:00
committed by GitHub
parent b5ec9c4406 c3720ce6b3
commit 4b6b591849
2 changed files with 20 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
.agents/skills/submit-pr-from-current-changes/SKILL.md
View File

@@ -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. 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. 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): 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. - **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. - **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. - **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. - **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. - **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: 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 - Large diff with no description of intent provided
- Changes touch core lib or extension (where vibe coding is prohibited per `CONTRIBUTING.md`) - Changes touch core lib or extension (where vibe coding is prohibited per `CONTRIBUTING.md`)
- Multiple unrelated concerns in one diff - Multiple unrelated concerns in one diff
- No validation has been run at all - 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."* - 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: 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 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 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 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. 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`. 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. 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 ## 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. They need to test the changes themselves in the browser.
> 1. Test your changes in the browser yourself 2. They need to go to the PR page and check the Testing and Requirements checkboxes only after verifying each item.
> 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 review until those checkboxes are checked.
> 3. The PR will not enter the review process until all 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.
>
> This project does not accept PRs generated autonomously by AI. Make sure you can truthfully check the AI declaration.
## Branch Naming ## Branch Naming
@@ -101,4 +99,4 @@ After successfully opening the PR, ALWAYS remind the user:
- The PR body follows the template structure completely. - 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. - 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 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.

2
docs/developer-guide.md
View File

@@ -10,7 +10,7 @@ For contribution rules and expectations, see [../CONTRIBUTING.md](../CONTRIBUTIN
1. **Prerequisites** 1. **Prerequisites**
- `macOS` / `Linux` / `WSL` - `macOS` / `Linux` / `WSL`
- `node.js >= 20` with `npm >= 10` - `node.js >= 24` with `npm >= 11`
- An editor that supports `ts/eslint/prettier` - An editor that supports `ts/eslint/prettier`
- Make sure `eslint`, `prettier` and `commitlint` work well. Un-linted code won't pass the CI. - Make sure `eslint`, `prettier` and `commitlint` work well. Un-linted code won't pass the CI.