eliteforge-git-specification

EliteForge Git Governance

Trigger threshold

Use this skill only when the user explicitly states that the current project follows 璀璨工坊规范 or eliteforge specification . If the user has not made such a project-level declaration, do not enable this skill; handle it as a general capability.

Objective

In Git operation tasks, prioritize invoking the built-in scripts to complete standardized operations; only output native commands when scripting is not possible. Always ensure that the branching strategy, commit specifications, and MR gates are consistent with the team rules. For any task that "requires code modification," the branch gate must be satisfied first before editing files is allowed.

Execution principles

1. Branch prerequisite gate (mandatory)
   Perform the branch check first; when the branch naming is incorrect or the local quality gate is not passed, modifying code and committing are prohibited.

2. Identify the scenario
   First determine whether it is 正常迭代、热修、分支整理、提交/MR 合规 or 统计分析。

1. Locate the script directory (mandatory)
   Do not assume that scripts/exists in the current repository. First locate the scripts under the skill's own directory, then invoke them.

ELITEFORGE_GIT_SCRIPTS=""
for root in "$PWD" "${SKILLS_HOME:-}" "$HOME"; do
  [ -n "$root" ] || continue
  found="$(find "$root" -type d -path '*/eliteforge-git-specification/scripts' 2>/dev/null | head -n 1)"
  if [ -n "$found" ]; then
    ELITEFORGE_GIT_SCRIPTS="$found"
    break
  fi
done
[ -n "$ELITEFORGE_GIT_SCRIPTS" ] || { echo "Cannot locate eliteforge-git-specification/scripts." >&2; exit 1; }

1. Scripts first
   If a script already covers the corresponding capability, invoke the script first rather than repeatedly hand-writing long command sequences.

2. Strict gates
   Always check the branch prerequisites, whether squash is needed, the MR/pipeline status, and the release path.

3. Structured output
   The output content is fixed as:结论、分支门禁检查、命令序列、风险与门禁、提交/MR 文案。

4. The workflow must be strictly executed

Script mapping (use first)

1. Automatically pull and merge version branches
   bash "$ELITEFORGE_GIT_SCRIPTS/auto_merge" [--ff-only | --merge | --rebase]
   Applicable: on the qa/<version> or release/<version> branch, batch-merge the corresponding feature/<version>/、bugfix/<version>/ changes.

2. Check the merge status of a specified version branch
   bash "$ELITEFORGE_GIT_SCRIPTS/check_merge" <version> <branch>
   Applicable: verify whether feature/<version> and bugfix/<version> have been merged into the target branch (such as release or qa）。

3. Clean up local branches
   bash "$ELITEFORGE_GIT_SCRIPTS/delete_local_branches"
   Applicable: delete local branches except master/main .

4. Clean up merged remote branches
   bash "$ELITEFORGE_GIT_SCRIPTS/delete_merged_branches" <version>
   Applicable: on release/<version> , identify and delete merged feature/<version> branches.
   Note: this script includes interactive confirmation.

5. Rename a branch
   bash "$ELITEFORGE_GIT_SCRIPTS/rename_git_branch" <old-branch> <new-branch>
   Applicable: rename a local branch and sync it to the remote.

6. Generate a change summary
   bash "$ELITEFORGE_GIT_SCRIPTS/git_change_summary.sh"
   Applicable: output a change summary relative to master..HEAD (excluding style/build/test）。

7. Count author code volume
   bash "$ELITEFORGE_GIT_SCRIPTS/user_code.sh" <base_dir> '<author1|author2|...>' <YYYY-MM-DD>
   Applicable: count added, deleted, and modified lines across multiple repositories by author and start date.

Mandatory constraints

• One requirement, one feature branch
• Before any code change, first confirm that you are on a compliant development branch; developing directly on master/main/nightly/qa/release is prohibited.
• feature Submit for testing to qa 使用合并请求；联调自行合并到 nightly`。
• feature Before merging into release , squash into a single commit first.
• release Merge back into master use git merge --ff-only。
• hotfix Only for on-site blocking issues.
• Commit format:<type>(<scope>): <subject>。
• Must squash before the final MR; the MR title must match the squashed commit.
• Use .gitlab/merge_request_templates/default.md and complete the self-check.

References

• Read when you need the full specification, examples, and workflow references/git-governance-reference.md。