Menu
koopa git workflow — develop→main PR pattern, merge conflict resolution, tag management, and how to avoid rebase hell. Use when dealing with PR conflicts, moving tags, or pushing a release branch.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Acid Genomics R package development conventions — per-project air.toml, global ~/.lintr only, roxygen2 8.x @importFrom split, S4 linter tuning, AcidDevTools::check() gate. Use when writing or checking an acidgenomics R package, configuring air/lintr, or fixing roxygen/lint failures.
koopa R package release — cloud-native S3 + CloudFront, acidgenomics profile, koopa app r publish/reindex/archive, sonoma-arm64 binaries, pre-release AcidDevTools::check() gate. Use when releasing, publishing, reindexing, or archiving an Acid Genomics R package.
PowerShell (pwsh 7+) activation architecture, starship integration, and color-mode sync in koopa. Use when writing or debugging lang/powershell/ files, editing activate-*.ps1 functions, adding prompt-tool support (starship, zoxide), integrating OS appearance detection, or porting shell logic from bash/zsh/fish to PowerShell.
koopa AWS environment configuration — the gitignored <koopa-root>/.env, load_dotenv()/aws_account_id()/koopa_s3_bucket() helpers in aws.py, required vars, bucket naming, lazy-eval rule. Use when adding an AWS secret, wiring a bucket/CloudFront ID, or debugging a missing AWS env var in release tooling.
How koopa manages home dotfiles via chezmoi — source-of-truth layout, the explicit --source flag, template-vs-generator ordering, XDG path derivation in templates, symlink_ source files for App Support bridges, diagnosing chezmoi status contamination from stale env, and the correct re-run command. Use when editing a dotfile, working in opt/dotfiles/chezmoi/, debugging a file that reverts on chezmoi apply, wiring a chezmoi template, or bridging XDG paths to macOS Library/Application Support.
How koopa propagates and applies dark/light color mode across SSH, tmux, shells, and chezmoi-rendered theme files. Use when debugging wrong-palette or stale-theme symptoms after a dark↔light flip, working on color-mode sync jobs or watchers, editing the chezmoi color-mode apply path, or investigating why bat/starship/delta renders the wrong theme while fzf/LS_COLORS look correct.
| name | koopa-git |
| description | koopa git workflow — develop→main PR pattern, merge conflict resolution, tag management, and how to avoid rebase hell. Use when dealing with PR conflicts, moving tags, or pushing a release branch. |
develop — active development. All work lands here.main — release snapshots only. Updated exclusively via PR from develop.vX.Y.Z) sit on develop at the bumpver commit (or the
"Prepare release" commit if bumpver ran first — see koopa-release).After the CHANGELOG + bumpver commits are on develop:
git push origin develop
git push origin vX.Y.Z # or --force if re-tagging (see below)
Then open (or merge) the develop→main PR on GitHub.
The tag points to a merge commit on main (the previous PR), so
vPREV..HEAD looks enormous — that's expected, not a real conflict.
The actual conflict is almost always just CHANGELOG.md (and occasionally
pyproject.toml), because main lags behind develop by one or more
release cycles. develop's version is always the correct one — it is a
strict superset.
Fix: merge main into develop with -X ours
git fetch origin
git merge -X ours origin/main
git push origin develop
-X ours auto-resolves every conflict by keeping develop's version.
No interactive editor, no rebase, no cherry-pick warnings.
Never use git rebase origin/main here — the branch history is shared
with the remote and has already been merged into main multiple times.
Rebasing causes every previously-merged commit to be "skipped" as a
cherry-pick duplicate, then explodes on the first real conflict.
If bumpver ran before the "Prepare release" commit, the tag sits one commit behind HEAD. Re-tag and force-push:
git tag -f vX.Y.Z # moves tag to current HEAD
git push origin vX.Y.Z --force
If the remote already has the tag at the right SHA, git push reports
"Everything up-to-date" — that's fine, no action needed.
git rev-parse vX.Y.Z # SHA the tag points to
git log --oneline -1 # current HEAD
The tag should sit on the bumpver commit (Bump version to vX.Y.Z.).
If you accidentally started a rebase, abort immediately:
git rebase --abort
This restores the autostash and puts you back on develop at HEAD.
The [!] dirty-tree indicator afterward is normal — just the stashed
todo.org changes coming back.