The former v2 branch has merged into main, making the old "main is frozen,
submit to v2" guidance backwards. Update all contributor-facing entry points
to the current model: main is the active v2 development line; v1 maintenance
fixes target the v1 branch.
- CLAUDE.md: add a v2 "Current state" callout and a branch-targeting
Operational Rule (the AI-facing context).
- gh-create-pr skill: route v1 maintenance PRs to base v1.
- PR template: replace the stale hidden comment with a visible branch
callout and add a branch checklist item.
- CONTRIBUTING.md / docs/guides/contributing.md: rewrite the branch strategy
section to the new model.
- docs/guides/branching-strategy.md: add a current-model note and fix the PR
target guideline.
<!-- Template from
https://github.com/kubevirt/kubevirt/blob/main/.github/PULL_REQUEST_TEMPLATE.md?-->
<!-- Thanks for sending a pull request! Here are some tips for you:
1. Consider creating this PR as draft:
https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md
-->
### What this PR does
Before this PR: The PR checklist had no reminder for authors to
self-review their code before requesting review.
After this PR: A new "Self-review" checklist item reminds PR authors to
review their own code using `/gh-pr-review`, `gh pr diff`, or the GitHub
UI before requesting review from others.
### Why we need it and why it was done in this way
Self-review catches obvious issues before reviewer time is spent,
improving review efficiency.
The following tradeoffs were made: N/A
The following alternatives were considered: N/A
Links to places where the discussion took place: N/A
### Breaking changes
None
### Special notes for your reviewer
The link to `/gh-pr-review` points to the skill definition at
`/.claude/skills/gh-pr-review/SKILL.md`.
### Checklist
This checklist is not enforcing, but it's a reminder of items that could
be relevant to every PR.
Approvers are expected to review this list.
- [x] PR: The PR description is expressive enough and will help future
contributors
- [x] Code: [Write code that humans can
understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans)
and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle)
- [x] Refactor: You have [left the code cleaner than you found it (Boy
Scout
Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
- [ ] Upgrade: Impact of this change on upgrade flows was considered and
addressed if required
- [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com)
was considered and is present (link) or not required. Check this only
when the PR introduces or changes a user-facing feature or behavior.
- [x] Self-review: I have reviewed my own code (e.g., via
[`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`,
or GitHub UI) before requesting review from others
### Release note
```release-note
NONE
```
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
### What this PR does
Before this PR:
The `gh-create-pr` skill had no guidance on when to write a release note
vs `NONE`, or when to check the Documentation checkbox. The PR template
also lacked explicit guidance on release note scope.
After this PR:
- A lookup table is added to the skill so the model can match change
types to the correct release note and documentation checkbox behavior.
- The PR template is updated to clarify that only user-facing changes
belong in release notes, and the documentation checkbox should only be
checked for user-facing features/behavior changes.
### Why we need it and why it was done in this way
The following tradeoffs were made:
A concise example table was chosen over verbose text rules, following
the "concise examples over verbose explanations" principle from the
skill-creator guide. This makes it easier for the model to pattern-match
rather than reason about abstract rules.
The following alternatives were considered:
- Separate detailed text descriptions for release note and documentation
rules — rejected as harder for the model to follow consistently.
- Keeping guidance only in the skill without updating the PR template —
rejected to keep both in sync for human contributors as well.
### Breaking changes
None.
### Special notes for your reviewer
This is a docs/config-only change. No application code is affected.
### Checklist
- [x] PR: The PR description is expressive enough and will help future
contributors
- [ ] Code: [Write code that humans can
understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans)
and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle)
- [ ] Refactor: You have [left the code cleaner than you found it (Boy
Scout
Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
- [ ] Upgrade: Impact of this change on upgrade flows was considered and
addressed if required
- [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com)
was considered and is present (link) or not required. Check this only
when the PR introduces or changes a user-facing feature or behavior.
### Release note
```release-note
NONE
```
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* docs: update PR template and README with feature PR restrictions
Add temporary hold notice for Redux/IndexedDB feature PRs in both pull request template and README
Fix whitespace and formatting inconsistencies in README
* docs: update contributing guidelines with temporary PR restrictions
Add important notice about temporary restrictions on data-changing feature PRs
Clarify acceptable contribution types during v2.0.0 development phase
* docs: remove warning about feature PR restrictions
The warning about temporary restrictions on feature PRs involving Redux or IndexedDB changes has been removed as it is no longer relevant
* docs: remove core developer membership section from contributing guides
- Introduced a new English version of the contributor guide (CONTRIBUTING_EN.md) to enhance accessibility for non-Chinese speakers.
- Updated issue templates to use more specific labels (kind/bug, kind/enhancement, kind/question) for better categorization.
- Added a testing section in the developer guide to clarify testing procedures.
