Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
cloudsen avatar

Eliteforge Git Feature Oriented Spec

  • 33 installs
  • Updated July 24, 2026
  • cloudsen/eliteforge-skills

Full Git spec for feature-oriented development with feature/bugfix/hotfix types, SemVer versions, and single- and multi-agent branch and worktree naming.

About

Defines the full feature-oriented branching model with feature/bugfix/hotfix types, SemVer versions, and release-flow branches, plus templates for non-multi-agent, base, and Codex subagent branches. A developer uses it to name branches and worktrees for EliteForge feature work.

  • Branch templates include type, SemVer version, developer, and taskName
  • Release-flow branches keep nightly, qa/<version>, release/<version>

Eliteforge Git Feature Oriented Spec by the numbers

  • 33 all-time installs (skills.sh)
  • Ranked #348 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
  • Data as of Jul 29, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cloudsen/eliteforge-skills --skill eliteforge-git-feature-oriented-spec

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs33
Last updatedJuly 24, 2026
Repositorycloudsen/eliteforge-skills

What it does

Full Git spec for feature-oriented development with feature/bugfix/hotfix types, SemVer versions, and single- and multi-agent branch and worktree naming.

Files

SKILL.mdMarkdownGitHub ↗

EliteForge Git Feature-Oriented Spec

Environment Variables

  • ELITEFORGE_SKILL_GIT_WORKTREE_ROOT [optional] Root directory for generated git worktrees; defaults to ${CODEX_HOME:-$HOME/.codex}/worktrees.

Branch Spec

main and master are equivalent

Follow the feature-oriented branching model. Continuously develop and test features.

Release-flow branches keep their project convention, such as nightly, qa/<version>, and release/<version>. Working branches only use feature, bugfix, or hotfix as <type>.

Non multi-agent branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>.

Multi-agent base branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>/base.

Codex subagent branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>/<agentId>/<subtaskName>.

  • the type attribute only belongs to:
  • feature: new requirements
  • bugfix: bugs does not stuck the main process
  • hotfix: serious bugs requiring urgent fix
  • the version attribute follows SemVer Spec x.y.z
  • developer is the name of the developer from git config, use email prefix if the name is not set.
  • agentId is not used in non multi-agent branches and is required for Codex subagents or parallel agents.
  • Subagent agentId must use the role name only, for example backend, frontend, test, review, or docs.
  • Put scope and target details in taskName or subtaskName, not in agentId.
  • Do not use pure numbers, weak semantic names, numbered variants, or role-plus-target names such as agent-01, backend-01, frontend-02, worker-a, tmp, work, backend-login-api, frontend-login-page, or test-auth-flow.
  • taskId is optional, only used for non multi-agent branches when the project has task management system and the task can be easily linked to the branch name.
  • taskName and subtaskName should be concise and descriptive, use hyphen to separate words, avoid using special characters.
  • Normalize each branch segment to lowercase filesystem-safe text using only a-z, 0-9, ., _, and -.
  • Do not use /base for non multi-agent workflows. Use /base only as the integration branch leaf after a task enters multi-agent workflow.
  • If a task starts on a non multi-agent branch and later needs subagents, rename the existing branch to the matching /base branch before creating subagent branches. Do not keep both forms for the same task.
origin branchtarget branchopsnotes
masterfeature/<version>/<developer>[/<taskId>]/<taskName>feature/<version>/<developer>[/<taskId>]/<taskName>/baseqa/<version>release/<version>create from masterdevelopment and unit testing
masterfeature/<version>/...qa/<version>release/<version>git rebasealways rebase master latest commits
<type>/<version>/<developer>[/<taskId>]/<taskName>/base<type>/<version>/<developer>[/<taskId>]/<taskName>/<agentId>/<subtaskName>create from multi-agent base branchsubtask implementation in isolated worktree
<type>/<version>/<developer>[/<taskId>]/<taskName>/<agentId>/<subtaskName><type>/<version>/<developer>[/<taskId>]/<taskName>/basegit mergesubtask branch must merge back to its corresponding multi-agent base branch after completion
featurenightlygit mergecoding complete,no compilation errors
featureqacreate merge requestsubmit to testing, ensure version consistency
featurefeaturegit rebase -i (squash commits) && git push -fsquash mutiple commits of one feature
feature(squashed)releasegit mergeensure completed testing
releasereleasegit tag <version>ensure no snapshot/dev dependencies
releasemasterFast-forward only mergeafter merge completed,ensure all other branches for the current version are cleaned up

Worktree Spec

When using git worktree, the worktree path must mirror the branch tree and have a one-to-one relationship with the checked-out branch.

Worktree root is resolved dynamically:

worktree_root="${ELITEFORGE_SKILL_GIT_WORKTREE_ROOT:-${CODEX_HOME:-$HOME/.codex}/worktrees}"
  • One worktree checks out exactly one spec-compliant branch.
  • One spec-compliant branch must not be reused by multiple worktrees at the same time.
  • Non multi-agent worktrees follow the non multi-agent branch tree: <root>/<repo>/<type>/<version>/<developer>[/<taskId>]/<taskName>.
  • Multi-agent base worktree path follows template: <root>/<repo>/<type>/<version>/<developer>[/<taskId>]/<taskName>/base.
  • Subagent worktree path follows template: <root>/<repo>/<type>/<version>/<developer>[/<taskId>]/<taskName>/<agentId>/<subtaskName>.
  • Use the same semantic fields as the branch name; do not flatten path separators into a basename.
  • Do not use project-ambiguous or weak worktree names such as temp, new, work, scratch, or feature-clouds3n-add-login.
  • If converting an existing non multi-agent worktree to multi-agent mode, move or recreate the worktree at the /base path before adding subagent worktrees. Do not create subagent worktrees inside an existing non multi-agent worktree.

Examples:

  • non multi-agent branch feature/1.2.0/clouds3n/add-login uses worktree <root>/<repo>/feature/1.2.0/clouds3n/add-login.
  • multi-agent base branch feature/1.2.0/clouds3n/add-login/base uses worktree <root>/<repo>/feature/1.2.0/clouds3n/add-login/base.
  • subagent branch feature/1.2.0/clouds3n/add-login/backend/session-token uses worktree <root>/<repo>/feature/1.2.0/clouds3n/add-login/backend/session-token.

Subagent Merge Spec

  • The multi-agent /base branch is the integration branch for the task.
  • A subagent branch must merge back into its corresponding /base branch after the subtask is complete.
  • A subagent branch must not bypass the /base branch and merge directly into default, nightly, qa, release, or another release-flow branch.
  • The coordinating agent owns conflict resolution, final acceptance, and release-flow promotion.

Commit Spce

Follow Conventional Commits specification.

Merge Request Spce

Always use the default MR/PR template from current project.

Useful CLI Commands

Learn more from the scripts/ directory in this skil
  • auto_merge: Merge the current version branches into the current branch
  • check_merge: Check all branches for the current version are merged into the current branch
  • delete_local_branches: Delete all branches except the main/master.ensure all branches are pushed
  • rename_git_branch: Rename the branch both locally and remotely

Quality Gates

  • Check branch before coding. DO NOT develop directly on master,main,nightly,qa,release branch
  • Non multi-agent branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>
  • Multi-agent base branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>/base
  • Subagent branch name follows template: <type>/<version>/<developer>[/<taskId>]/<taskName>/<agentId>/<subtaskName>
  • Worktree path must mirror the branch tree under ${ELITEFORGE_SKILL_GIT_WORKTREE_ROOT:-${CODEX_HOME:-$HOME/.codex}/worktrees}
  • Worktree and branch must have a one-to-one relationship
  • Subagent branches must merge back to the corresponding /base branch
  • Subagent agentId must use a role name and must not include numeric suffixes, scope, or target details
  • Version follows SemVer
  • Commit message follows Conventional Commits

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.