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

name, description

name	description
project-management	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:

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:

docs/development/branch-workflow.md

Keep this skill and that document aligned when branch rules change.