docs: add branch workflow management rules

.claude/skills/project-management/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: project-management
+description: Use when managing the Anxinyan project at /Users/wushumin/www/biyou/anxinyan, especially Git branch workflow, collaboration rules, commits, pre-submit checks, GitNexus detect-changes, release branch handling, or deciding where project-management rules belong.
+---
+
+# 安心验项目管理规范
+
+Project root: `/Users/wushumin/www/biyou/anxinyan`.
+
+Use the outer repository as the single source of truth for all project work. Do not create separate Git branch systems inside `server-api`, `admin-web`, `user-app`, or `work-app`.
+
+Do not manage release artifacts in Git. Files under `releases/`, including zip packages, APKs, and checksum files, are local delivery artifacts and must not be committed or pushed.
+
+## Branch Model
+
+- `master`: stable, release-ready mainline. Do not do daily development directly here.
+- `develop`: integration branch for normal multi-person development.
+- `feature/<scope>-<name>`: feature or improvement branches created from `develop`.
+- `release/<version-or-date>`: release stabilization branches created from `develop`.
+- `hotfix/<name>`: urgent production fixes created from `master`.
+
+After repository initialization, keep the local checkout on `develop` for daily work.
+
+## Standard Workflows
+
+For normal work:
+
+1. Start from updated `develop`.
+2. Create a `feature/<scope>-<name>` branch.
+3. Commit focused changes with clear Conventional Commits messages.
+4. Open a merge request back to `develop`.
+5. Include changed surfaces, verification commands, and risk notes in the merge request.
+
+For releases:
+
+1. Create `release/<version-or-date>` from `develop`.
+2. Keep the release branch limited to release blockers, verification fixes, and docs.
+3. Merge the verified release branch to `master`.
+4. Merge `master` back into `develop`.
+
+For hotfixes:
+
+1. Create `hotfix/<name>` from `master`.
+2. Fix only the production issue.
+3. Merge to `master` for release.
+4. Merge `master` back into `develop`.
+
+## Required Checks
+
+Before committing, run:
+
+```bash
+git status -sb
+git diff --check
+npx gitnexus detect-changes --scope all
+```
+
+Before changing code symbols, follow the repository `AGENTS.md` GitNexus rule: run upstream impact analysis for the target symbol and report the blast radius. Before committing any change, run GitNexus detect changes.
+
+For release packaging or deployment preparation, also follow the release checklist and packaging skill. At minimum, run the relevant backend smoke/audit scripts and frontend checks for the surfaces touched.
+
+Release packages should stay under the ignored local `releases/` directory and be handed off separately from Git branches.
+
+## Documentation Source
+
+The human-readable branch workflow is documented in:
+
+```text
+docs/development/branch-workflow.md
+```
+
+Keep this skill and that document aligned when branch rules change.