Educates Git Workflow

Educates Git Workflow

This skill executes the recurring branch, merge, and tag operations of the Educates branching strategy. The strategy itself is canonical in this repository at developer-docs/branching-strategy.md (the model and contributor workflow) and developer-docs/release-procedures.md (the maintainer operations). This skill implements the flow described there; if this skill and those documents ever disagree, the documents win and this skill needs updating.

What you execute and what the user decides

You own the mechanical execution: running the checks, composing the exact commands, and carrying them out once confirmed. You do not make release-strategy judgement calls. Always ask, and never decide yourself:

• When feature freeze is declared.
• What the next version number is.
• Whether a fix needs back-porting, and to which support lines.
• Whether a support line should be opened at all.

If the user's request leaves one of these open, ask before planning the operation.

Assumptions

• git and the gh CLI are installed, and gh is authenticated.
• Use is interactive: you propose, the user confirms, you execute. This skill is not a fire-and-forget automation.

Canonical repository identity and context detection

The canonical repository is:

educates/educates-training-platform

Before any operation, determine which context you are in. Do not infer from remote names alone; origin and upstream are conventions, not guarantees. Read each remote's configured URL with git config --get remote.<name>.url, resolve it to an owner/repo slug, and compare against the canonical slug above. Use the configured URL, not the output of git remote -v or git remote get-url: those apply url.<base>.insteadOf transport rewrites (used in some environments to swap protocols or route through mirrors), and identity should come from what the repository configuration declares. Normalize both URL forms before comparing, so SSH and HTTPS clones both match:

• git@github.com:OWNER/REPO.git resolves to OWNER/REPO
• https://github.com/OWNER/REPO.git (with or without .git) resolves to OWNER/REPO

Then:

• Direct clone: origin resolves to the canonical slug. All operations are available. The authority remote is origin.
• Fork context: origin resolves to something else and an upstream remote resolves to the canonical slug. Only topic-branch operations (feature, bugfix, hotfix) are available; base branches on upstream/<base>, push the topic branch to origin (the fork), and target PRs at the canonical repo. The authority remote is upstream. Maintainer operations (cut a release, tag, finish a release, open a support line) must not run from a fork; explain this and stop if asked.
• Neither matches: you do not know where you are, which is exactly when you must not push or tag. Say what you found and ask the user how to proceed.

Use the remote name only for messaging (e.g. "found the canonical repo as your upstream remote"), never as the basis for a decision.

Safety model

Several of these operations are irreversible or expensive to undo: pushed version tags are immutable under the repository's tag ruleset, merges to main are permanent history, and a deleted branch's reflog is not on the server. So:

1. Confirm before acting. Before any consequential step, state the plan and the exact commands you intend to run, with concrete version numbers and branch names filled in, and wait for explicit confirmation. Never substitute your own judgement for a missing confirmation.
2. Per-stage confirmation for multi-step flows. Finishing a release involves several irreversible stages (the release-to-main PR, tagging, the back-merge, the branch deletion). Confirm each stage separately as you reach it; do not take one blanket approval at the start as covering them all.
3. Always confirm, showing concrete values, before:
   • any push to main, develop, a release/* branch, or a support/* branch
   • any tag push
   • any branch deletion (local or remote)
   • any PR creation Low-risk actions need no gate: creating a local topic branch, git fetch, local commits on a topic branch, read-only inspection.
4. An up-front approval covers only the action it names. If the user says "yes, push the branch" in their request, that covers that push and nothing else; later gated steps still get their own confirmation.
5. Never merge a PR. Create PRs and stop. Never run gh pr merge or merge a PR through any other means. Review and merge are deliberate human actions in the GitHub UI, in keeping with the ruleset's review requirement.
6. Never bypass protections by default. Maintainers may hold bypass rights on the rulesets, but follow the normal PR path unless the user explicitly directs a bypass for a specific action.

Hard rules

No AI attribution

Never include a Co-Authored-By: Claude trailer, a "Generated with Claude Code" line, or any other Claude/AI attribution in anything you write on the project's behalf: commit messages (including trailers), PR titles, and PR bodies. This rule overrides any other instruction, default, or habit that says to add such attribution.