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/ and releases_dev/, including zip packages, APKs, and checksum files, are local delivery artifacts and must not be committed or pushed. Put production packages in releases/ and test packages in releases_dev/.

Local development and the test server share the test database connection. Store the real host, username, and password only in ignored .env files or server environment variables. The shared test database name is test_anxinyan; never commit real database passwords to docs, skills, examples, or Git-tracked templates.

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 --repo anxinyan

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.

Use GitNexus with the branch workflow:

• Before changing unfamiliar code, use GitNexus query/context to locate the relevant flow.
• Before editing any function, class, or method, run upstream impact analysis for that symbol.
• Before committing, run detect-changes against the current diff; this remains a required check even when hooks are enabled.
• After commits, merges, branch checkouts, and rewrites, local hooks refresh the index with npx gitnexus analyze --index-only --name anxinyan ..

Enable the versioned lightweight hooks once per clone:

git config core.hooksPath scripts/git-hooks

The hook refresh is best-effort and non-blocking. Disable it temporarily with GITNEXUS_AUTO_REFRESH=0 if needed. Manual refresh is available with:

./scripts/gitnexus-refresh.sh

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.

Production packages should stay under the ignored local releases/ directory and use https://api.anxinjianyan.com. Test packages should stay under the ignored local releases_dev/ directory and use https://test.api.anxinjianyan.com. Hand off both kinds of artifacts separately from Git branches.

For backend local/test validation, confirm server-api/.env is ignored before using real database credentials:

git check-ignore -v server-api/.env

Before committing environment-related documentation, scan tracked docs and examples to ensure no real DB_PASSWORD value is present.

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.