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

Eliteforge Feature Oriented Release Flow

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

Stateful release workflow controller for EliteForge feature-oriented Git projects, advancing one release-boundary action at a time.

About

Drives the EliteForge feature-oriented Git release process as a strict state machine, handling iteration branches, dev/QA publishing, feature squashing, release merges, snapshot/formal deploys, and tagging. A developer uses it only for release-boundary actions, not ordinary coding.

  • Advances one release workflow state at a time
  • Scoped to boundary actions like QA submit, squash, release merge, deploy

Eliteforge Feature Oriented Release Flow by the numbers

  • 13 all-time installs (skills.sh)
  • Ranked #177 of 248 Release Management 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-feature-oriented-release-flow

Add your badge

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

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

What it does

Stateful release workflow controller for EliteForge feature-oriented Git projects, advancing one release-boundary action at a time.

Files

SKILL.mdMarkdownGitHub ↗

EliteForge Feature-Oriented Release Flow

Overview

Advance one release workflow state at a time for the full EliteForge Feature-Oriented Git process. Keep the state machine strict at release boundaries, but leave normal development work outside this skill.

Invocation Boundary

Always follow the EliteForge Git Feature-Oriented Spec. Use this skill only for workflow boundary actions:

  • Initialize iteration branches.
  • Publish feature work to dev through nightly.
  • Submit, verify, or deploy QA through qa/<version>.
  • Return from failed QA to feature fixes.
  • Squash the feature branch after QA passes.
  • Merge approved feature branches into release/<version>.
  • Rebase/push release, deploy snapshot, tag, deploy formal version, and merge back to master.

Do not use this skill for ordinary feature coding, routine commits, local tests, linting, formatting, dependency bumps, or generic Git questions.

Inputs

  • version: required release version, for example 1.0.0.
  • developer: required developer segment, for example clouds3n.
  • taskName: required branch-safe task name, for example demo.
  • taskId: optional task identifier, for example #123.
  • multiAgent: optional mode. Use it only when the task has entered the EliteForge Git Feature-Oriented Spec multi-agent workflow.

When taskId exists, derive non multi-agent branch feature/<version>/<developer>/<taskId>/<taskName> and state file docs/tasks/release-flow/<version>/<taskId>-<taskName>.json.

When taskId is absent, derive non multi-agent branch feature/<version>/<developer>/<taskName> and state file docs/tasks/release-flow/<version>/<taskName>.json.

When multiAgent is active, the release-flow feature_branch is the matching multi-agent base branch: feature/<version>/<developer>[/<taskId>]/<taskName>/base. Subagent branches must already be merged into this /base branch before release-flow promotion states run.

Operating Rules

  • Execute exactly one state transition per user request unless the user explicitly asks for a larger run.
  • Before risky transitions, run scripts/release_flow_state.sh --version <version> --developer <developer> --task-name <taskName> from the target repository; add --task-id <taskId> only when a task ID exists, and add --multi-agent only when the release-flow feature branch must be .../<taskName>/base.
  • Use references/release-flow-state-machine.md when command details, transition guards, or failure handling are needed.
  • Persist workflow state in docs/tasks/release-flow/<version>/<taskId>-<taskName>.json. This state file is required, not optional.
  • taskId is optional. If taskId is absent, persist workflow state in docs/tasks/release-flow/<version>/<taskName>.json.
  • Use the literal taskId and taskName in the state file name. Do not strip # from task IDs such as #123; quote the path in shell commands. Do not add a leading hyphen when taskId is absent.
  • Stop if version, taskId when present, or taskName contains /, because each value must remain one path segment.
  • Do not use /base for non multi-agent release flows. If a task starts non multi-agent and later enters multi-agent mode, rename the existing feature branch to the matching /base branch before creating or promoting subagent work.
  • Update the state file only after the command sequence and guard checks for the new state have succeeded. Use scripts/persist_release_flow_state.py for the write.

Invariants

  • Stop if git status --porcelain contains non-state-file changes before switching, merging, rebasing, tagging, deploying, or pushing, except when intentionally committing user changes.
  • Never skip MR approval before QA deployment.
  • Never force push except after feature squash or release rebase.
  • Never deploy from an ambiguous or wrong branch.
  • Never continue automatically through merge conflicts, rebase conflicts, missing remote branches, existing tags, failed deploys, or unclear protected-branch rules.
  • Treat master and main as equivalent only for branch policy; follow the repository's actual default branch in commands. If this release flow names master, verify whether the repo uses master or main before executing.

Compact State Table

StateExpected branchBoundary actionNext
READYany clean branchFetch, prune, verify default branchINIT_BRANCHES
INIT_BRANCHESdefault branch refsCreate feature, qa, and release from defaultFEATURE_DEV
FEATURE_DEVfeature/... or feature/.../baseCommit normal feature or fix workDEV_PUBLISH
DEV_PUBLISHnightly, then featureMerge feature into nightly, push, deploy dev, push featureQA_MR
QA_MRGitLabCreate or verify MR from feature to qa/<version>QA_DEPLOY
QA_DEPLOYqa/<version>Pull QA, deploy VERSION=<version>-SNAPSHOTFEATURE_FIX or SQUASH
FEATURE_FIXfeature/... or feature/.../baseCommit QA fixDEV_PUBLISH
SQUASHfeature/... or feature/.../baseInteractive rebase from merge-base, force push featureRELEASE_MERGE
RELEASE_MERGErelease/<version>Merge approved squashed feature branchesRELEASE_REBASE
RELEASE_REBASErelease/<version>Rebase onto default remote, force push releaseSNAPSHOT_DEPLOY
SNAPSHOT_DEPLOYrelease/<version>Deploy VERSION=<version>-SNAPSHOTTAG
TAGrelease/<version>Create and push tag <version>PROD_DEPLOY
PROD_DEPLOYrelease/<version>Deploy VERSION=<version>MASTER_BACKMERGE
MASTER_BACKMERGEdefault branchFast-forward merge release/<version> or create protected-branch MRDONE

Resources

  • references/release-flow-state-machine.md: Complete state machine, command templates, guards, and blocked states.
  • scripts/release_flow_state.sh: Read-only Git diagnostic helper for current branch, cleanliness, derived branches, state file path, upstreams, remote refs, local tag existence, optional remote tag existence, and state hints.
  • scripts/persist_release_flow_state.py: Deterministically create or update the required state JSON after a successful state transition.

Related skills

This week in AI coding

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

unsubscribe anytime.