0x0w1/jig/github-release

GitHub Release

Use this repository skill for release execution.

Release Model

• A release promotes the current origin/develop to main with a fast-forward push: git push origin develop:main. There is no release PR and no release/* branch.
• develop must already contain every intended release change, squash-merged through develop-task-flow.
• The bump is graded against this project's version rubric, not against a rule inside this skill. See Version Rubric.
• The next version is computed from the latest vX.Y.Z tag using the graded bump type. See Version Format.
• The release tag and GitHub release are created from the CLI with git tag and gh release create.
• Release notes are written by the agent from the commits in <previous tag>..<new tag>, categorized by conventional commit prefix.

GitHub Profile

Before any gh command, resolve the host from JIG_GITHUB_HOST, local jig.githubHost, then github.com, and resolve the profile from JIG_GITHUB_PROFILE, then local jig.githubProfile. If a profile is configured, read its credential with gh auth token --hostname <host> --user <profile> without printing it and run every gh command with that credential through GH_TOKEN (github.com or *.ghe.com) or GH_ENTERPRISE_TOKEN (other hosts). Verify gh api user --jq .login matches the profile. Do not use gh auth switch; fall back to the globally active account only when neither the environment nor local config selects a profile.

Version Rubric

The grading rubric is not in this skill. It is a project-owned file, so every project grades by its own axis. The version-rubric skill owns that file.

Resolve the rubric path in this order:

1. JIG_VERSION_RUBRIC environment variable (session-only override).
2. git config --local --get jig.versionRubric (repository override).
3. .jig/versioning.md (the convention).

Apply it like this:

• Grade with the rubric's ## Decision Order: ask its questions in order and stop at the first match. That ordering is fixed; a rubric cannot change it.
• Check the graded bump against the rubric's ## Grade Definitions before computing the version, and quote the deciding question in the report.
• Apply ## Hard Rules after the ordered questions. A rubric without that section has no escalation rule.
• A missing optional section (## Hard Rules, ## Interface Paths, ## Release Notes, ## Version Format, ## Pre-Release Checks) means that rule does not apply.
• Rubrics written before the contract switched to English carry Korean titles, and they stay valid. Accept either spelling for every section: ## 판정 순서, ## 등급 정의, ## 강경 규칙, ## 인터페이스 경로, ## 릴리즈 노트, ## 버전 형식, ## 릴리즈 전 검증, and > 기준: for > Basis:. Read the file as it is; never retitle it during a release.
• Read sections beyond the contract as grading context; a project may list what counts as its public interface there.
• Report the rubric path, its source, and whether it records the adopted default or a project-specific rubric.
• Never edit the rubric file from this skill.

Recorded Task Grades

develop-task-flow grades each task as it is squash-merged and records the verdict as a Release-Grade trailer. Read those first: they were decided with the diff in hand, which this step no longer has.

git log <previous>..HEAD --no-merges --format='%h %(trailers:key=Release-Grade,valueonly)'

• The release floor is the highest grade recorded in the range, ordered patch < minor < major. Name the commit that set it in the report.
• Grade any commit with no trailer from its subject and body, then fold that verdict into the floor. A range with no trailers at all grades exactly as it did before.
• The floor is a starting point, not the verdict. Apply the rubric once more to the range as a whole: a combination of tasks can cost more than any one of them did alone, and ## Hard Rules still runs against the composed notes in step 6.
• Never settle the release below the floor. Raising it is a normal outcome; lowering it discards evidence that is no longer available.

Interface Path Floor

When the rubric has an ## Interface Paths table, compute a second floor from the changed paths:

git diff --name-only <previous>..HEAD

• Each changed path takes the floor of the first row it matches; rows are read top to bottom. The path floor is the highest floor any changed path took. A path matching no row contributes nothing.
• Report the floor and the path that set it, so the reader can see which interface the range touched.
• This floor is advisory, unlike a recorded task grade. Paths say what changed, never how. Releasing below it is allowed and must state the reason in the report — for example, that the only change under a public path was a comment. Releasing above it needs no justification.
• A rubric with no such table skips this step entirely; do not invent globs for a project that did not write any.

When the rubric is missing or unusable:

• Missing file: run the version-rubric skill to settle it, then continue the release. Do not stop the release for this.
• `version-rubric` not installed: grade with the fallback below, say so in the report, and continue.
• Contract broken (neither spelling of the decision-order or grade-definition section is present, or fewer than three ordered questions): stop and point at version-rubric. Grading with a broken rubric silently is worse than stopping.

The fallback rubric, used only in the two cases above. It matches the default version-rubric writes, so a project grades the same whether or not that skill is installed:

1. Is this a fix inside what the project already does? → patch
2. Can people do something new, or did a generation turn over, while everything they already do keeps working? → minor
3. Does it break an existing usage contract, or must a human step in to keep using it? → major

With these escalation rules, applied after the ordered questions:

A silent change is major only when it breaks an existing usage contract, changes authorization or data-handling boundaries incompatibly, or requires manual migration. A different response alone does not establish a break.

A compatible skill or prompt enhancement, including improved default responses or additional guidance, is minor. Wording-only changes and fixes that restore the documented contract are patch.

Version Format

Defaults, each overridable by the rubric's ## Version Format section:

• The version must match ^v[0-9]+\.[0-9]+\.[0-9]+$.
• patch: vX.Y.Z → vX.Y.(Z+1); minor: → vX.(Y+1).0; major: → v(X+1).0.0.
• While the major version is 0, a major grade raises the minor position instead: v0.Y.Z → v0.(Y+1).0. Grade exactly as after 1.0 and state the verdict in the report, so the rule is exercised before it becomes binding.
• An explicit vX.Y.Z from the user overrides the computed version.

Release Notes

• ## Changes, then one section per commit type present in the range, each only when it has items, separated by horizontal rules.
• Section titles derive from the commit prefix: feat → ### 🚀 Enhancements, fix → ### 🐛 Fixes, chore → ### 🧰 Chores. Any other prefix becomes its own section named after it (docs: → ### 📚 Documentation). Never fold an unlisted prefix into chores.
• The rubric's ## Release Notes section overrides section order and titles.
• One - <commit subject without type prefix> line per commit.
• ### Summary: user-perspective bullet items written from the commit subjects and bodies, release-note ready, with technical terms in backticks. Write them in the language the repository already uses for its release notes and commit bodies, defaulting to English.
• The Release-Grade trailer is grading input, not prose. Keep it out of every note section.
• ### Migration: only when downstream projects must take action that re-running an update does not cover.

Migration Blocks

The ### Migration section is not prose. It is the input an updating agent executes, so it is written as marker-delimited blocks:

### Migration
 
<!-- jig:start migration-auto -->
-`rm -f .github/workflows/drafter.yaml`
-Move `.agents/skills/github-sync/` to `.agents/skills/jig-github-sync/` when it exists
<!-- jig:end migration-auto -->
 
<!-- jig:start migration-manual -->
-Decide whether `develop` keeps its required status checks; jig no longer sets them.
<!-- jig:end migration-manual -->

• migration-auto: mechanical steps an agent finishes unattended. Every item must be idempotent and be either a single command or an unambiguous file operation. A target that is already absent counts as done.
• migration-manual: steps needing a human judgement, a choice, or an irreversible action. jig-update presents these and does not run them without approval.
• When in doubt, an item is manual. Either block may be omitted; omit the whole section when neither applies.
• A marker counts only when it is the entire line, matching ^<!-- jig:(start|end) migration-(auto|manual) -->$. Release notes routinely name these markers in prose, so a mention inside backticks or mid-sentence is text, not a marker. Keep marker lines flush left with nothing else on them, and always close a block with its matching end marker.
• A rubric may key an escalation rule off these blocks; jig's own rubric grades any migration-manual block as major. When applying such a rule, count line-anchored markers only.

Safety Rules

• Do not force push.
• Do not bypass git hooks: never pass --no-verify to git push.
• If git push origin develop:main would not fast-forward, stop and report that main has commits develop lacks; never resolve this by force-pushing. The usual cause is a hotfix that landed on main without returning to develop — hotfix-flow step 8 restores the invariant with git merge main into develop.
• Do not release while the worktree has uncommitted changes to tracked files.
• Do not create a tag that already exists locally or on origin.
• Do not release while local develop differs from origin/develop.
• Do not delete branches.
• The release must only promote already-merged develop state; complete pending work through develop-task-flow first.
• Show the release note draft to the user before publishing, unless the user already asked for the release to be executed end to end.
• Preserve unrelated user changes.

Develop-First Gate

• If the release request includes unfinished implementation, config, docs, generated dist, or workflow changes, stop release execution.
• Complete those changes first with develop-task-flow: create a feature/*, fix/*, or chore/* branch from origin/develop, squash-merge it into develop, and push develop.
• Resume release only after origin/develop contains every intended change.
• If the user has not explicitly asked to release, stop after develop is pushed.

Release Procedure