home / skills / theonelee / theone_claude_skill / git_pre_release_skill

git_pre_release_skill skill

safe

This skill helps you manage pre-release Git workflows by guiding branch syncing, conflict resolution, and safe status reporting.

npx playbooks add skill theonelee/theone_claude_skill --skill git_pre_release_skill

Review the files below or copy the command above to add this skill to your agents.

Files (3)

SKILL.md

1.0 KB

---
name: git-pre-release-conflict
description: Use when asked to publish or sync a feature branch to pre in this repo, or to resolve complex git conflicts that occur in that release flow.
---

# Git Pre Release + Conflict Resolution

## When to use
- Requests like "publish to pre", "sync branch to pre", or "rebuild pre".
- Any complex Git conflict resolution in this repo, especially during release merges.

## Quick start
1. Confirm `<main_branch>` and `<feature_branch>` with the user.
2. For the release/sync workflow, follow `references/flow.md`.
3. If conflicts occur, follow `references/conflict_playbook.md`.

## Safety gates
- Do not delete or force-push branches without explicit user confirmation.
- If network access is blocked, request approval before any `git fetch`/`git push`.
- Preserve unrelated changes; avoid `git add .` unless explicitly told.

## Output expectations
- Report branch names, stash actions, and conflict file list.
- Summarize conflict decisions (ours/theirs/manual merge).
- Provide final `git status` summary and next steps.

Overview

This skill helps publish or sync a feature branch to the pre (pre-release) environment and resolve complex Git conflicts that arise in that flow. It guides interactive decision-making, preserves unrelated work, and produces clear, auditable steps. Use it when you need a safe, repeatable process to move changes into the pre branch or to recover from merge conflicts during release merges.

How this skill works

I confirm the main branch and feature branch names, then follow the repo's release/sync flow. I inspect local and remote refs, run targeted fetches, and attempt merges or rebases per the flow document. If conflicts occur, I enumerate conflict files, propose resolution choices (ours/theirs/manual), and record stash/unstash actions and final status before any push.

When to use it

When asked to "publish to pre", "sync branch to pre", or "rebuild pre"
When merging a long-lived feature branch into pre and conflicts are non-trivial
When automated CI for pre is failing due to merge conflicts
When you need a documented, reversible conflict resolution plan before pushing changes

Best practices

Confirm <main_branch> and <feature_branch> explicitly before any destructive actions
Do not delete or force-push branches without explicit user approval
Avoid broad commands like git add .; stage only intended files during conflict resolution
Create a stash or backup branch before attempting risky merges or interactive rebases
Report all stash actions, conflicted files, and the chosen resolution strategy for auditing

Example use cases

Syncing feature/foo into pre to run integration tests before a release
Resolving a three-way conflict where generated files differ between pre and the feature branch
Recovering a partially merged working tree and producing a safe push plan
Coordinating a manual merge where multiple developers expect specific conflict outcomes

FAQ

Will you ever force-push branches?

Not without explicit user confirmation. I recommend creating a backup branch before any force-push.

What do you report after resolution?

I list branch names, stash operations, conflicted files, per-file resolution decisions (ours/theirs/manual), and a final git status with next steps.