PR Submission Skill
Workflow
- Identify the scope of your change (feature, bug fix, docs, test, refactor, chore)
- Format PR title and commits using the conventions below
- Run the pre-PR checklist commands
- Open the PR with a descriptive body
PR Title Format
Use conventional commit style:
<type>(<scope>): <description>
Types:
| Type |
When to Use |
feat |
New feature or capability |
fix |
Bug fix |
docs |
Documentation changes only |
test |
Adding or updating tests |
refactor |
Code restructuring with no behavior change |
chore |
Build, CI, tooling, or maintenance tasks |
Scopes: Use module or domain names: auth, search, publish, review, namespace, governance, deploy, ci, frontend, scanner
Examples:
feat(auth): add local account login with password reset
fix(publish): resolve null pointer when skill metadata is missing name
docs(deploy): clarify runtime image usage
test(namespace): add membership service edge case tests
refactor(review): extract query repository for governance list
chore(ci): add parallel workflow scripts for multi-agent development
Commit Message Format
Same convention as PR titles. One logical change per commit.
Types:
- feat: A new feature for the user
- fix: A bug fix for the user
- docs: Documentation changes only
- test: Adding or updating tests
- refactor: Code change that neither fixes a bug nor adds a feature
- chore: Changes to build process, CI, or maintenance tasks
Examples:
fix(auth): resolve session cookie conflict in device flow
feat(publish): support security scan before review submission
docs(skill-protocol): add nested SKILL.md discovery rules
test(search): verify jieba analysis with Chinese skill descriptions
refactor(storage): simplify LocalFile path normalization
Pre-PR Checklist
PR Body Structure
When creating a PR, include:
- What — Summary of the change
- Why — Motivation (link to issue if applicable)
- How — Key implementation details (especially for non-obvious decisions)
- Testing — How to verify the change works
- Impact — Breaking changes, migration notes, or rollout considerations
Review Conventions
- When reviewing, cite the specific AGENTS.md rule that applies if suggesting a convention change
- For backend code, check dependency direction does not violate clean architecture rules
- For frontend code, check OpenAPI types are regenerated if API changed
1---2name: pr-submission3description: PR title format, commit conventions, and pre-PR checklist for SkillHub. Use when preparing or reviewing pull requests.4license: Apache-2.05---67# PR Submission Skill89## Workflow10111. Identify the scope of your change (feature, bug fix, docs, test, refactor, chore)122. Format PR title and commits using the conventions below133. Run the pre-PR checklist commands144. Open the PR with a descriptive body1516## PR Title Format1718Use conventional commit style:1920```21<type>(<scope>): <description>22```2324**Types:**2526| Type | When to Use |27|------|-------------|28| `feat` | New feature or capability |29| `fix` | Bug fix |30| `docs` | Documentation changes only |31| `test` | Adding or updating tests |32| `refactor` | Code restructuring with no behavior change |33| `chore` | Build, CI, tooling, or maintenance tasks |3435**Scopes:** Use module or domain names: `auth`, `search`, `publish`, `review`, `namespace`, `governance`, `deploy`, `ci`, `frontend`, `scanner`3637**Examples:**38```39feat(auth): add local account login with password reset40fix(publish): resolve null pointer when skill metadata is missing name41docs(deploy): clarify runtime image usage42test(namespace): add membership service edge case tests43refactor(review): extract query repository for governance list44chore(ci): add parallel workflow scripts for multi-agent development45```4647## Commit Message Format4849Same convention as PR titles. One logical change per commit.5051**Types:**5253- **feat**: A new feature for the user54- **fix**: A bug fix for the user55- **docs**: Documentation changes only56- **test**: Adding or updating tests57- **refactor**: Code change that neither fixes a bug nor adds a feature58- **chore**: Changes to build process, CI, or maintenance tasks5960**Examples:**61```62fix(auth): resolve session cookie conflict in device flow63feat(publish): support security scan before review submission64docs(skill-protocol): add nested SKILL.md discovery rules65test(search): verify jieba analysis with Chinese skill descriptions66refactor(storage): simplify LocalFile path normalization67```6869## Pre-PR Checklist7071- [ ] Backend tests pass: `make test-backend-app`72- [ ] Frontend typecheck passes: `make typecheck-web`73- [ ] If API changed: `make generate-api` was run and `web/src/api/generated/schema.d.ts` is committed74- [ ] Smoke test passes: `make staging`75- [ ] Follow existing module boundaries and dependency direction76- [ ] Add/update tests for new behavior77- [ ] Update design docs when APIs, auth flows, deployment, or operator workflows change7879## PR Body Structure8081When creating a PR, include:82831. **What** — Summary of the change842. **Why** — Motivation (link to issue if applicable)853. **How** — Key implementation details (especially for non-obvious decisions)864. **Testing** — How to verify the change works875. **Impact** — Breaking changes, migration notes, or rollout considerations8889## Review Conventions9091- When reviewing, cite the specific AGENTS.md rule that applies if suggesting a convention change92- For backend code, check dependency direction does not violate clean architecture rules93- For frontend code, check OpenAPI types are regenerated if API changed
iflytek