# Hodios paste pack: Git and version control
Everything in Git and version control from Hodios, the open prompt library by Hermes IDE: 25 entries, catalog 2026.1004.3.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Git and version control
- [Backport a fix to release branches](#backport-fix-to-release-branches) (prompt)
- [Choose a branching strategy](#choose-branching-strategy) (prompt)
- [Choose the right git undo](#choose-git-undo-command) (prompt)
- [Clean up a branch's commit history](#clean-up-commit-history) (prompt)
- [Coach git for non-developers](#coach-git-for-non-developers) (prompt)
- [Configure branch protection](#configure-branch-protection) (prompt)
- [Conventional Commits rules](#conventional-commits-rules) (rule)
- [Explain a git error](#explain-git-error) (prompt)
- [Extract a folder into a new repository](#extract-folder-into-new-repo) (prompt)
- [Fix line-ending churn](#fix-line-ending-churn) (prompt)
- [Git safety rules](#git-safety-rules) (rule)
- [Investigate why code changed](#investigate-code-history) (prompt)
- [Purge a file from git history](#purge-file-from-git-history) (prompt)
- [Rebase stacked branches](#rebase-stacked-branches) (prompt)
- [Recover lost Git work](#recover-lost-git-work) (prompt)
- [Resolve a merge conflict](#resolve-merge-conflict) (prompt)
- [Set up commit signing](#set-up-commit-signing) (prompt)
- [Set up Git LFS](#set-up-git-lfs) (prompt)
- [Set up git on a new machine](#set-up-git-on-new-machine) (prompt)
- [Set up shared git hooks](#set-up-git-hooks) (prompt)
- [Split a large pull request into a stack](#split-large-pull-request) (prompt)
- [Write a .gitignore file](#write-gitignore-file) (prompt)
- [Write a CODEOWNERS file](#write-codeowners-file) (prompt)
- [Write a commit message](#write-commit-message) (prompt)
- [Write a pull request description](#write-pr-description) (prompt)
---
## Backport a fix to release branches
`backport-fix-to-release-branches` · prompt · Git and version control · https://hermes-ide.com/prompts/backport-fix-to-release-branches
Plans backporting a fix to maintained release branches with cherry-pick -x, conflict handling where code has diverged, per-branch tests, version bumps and changelog entries. Use for patch releases.
````markdown
A maintainer has a fix on the main branch and must ship it on older supported release lines. Backports go wrong in quiet ways: a cherry-pick applies cleanly but the surrounding code differs, so the fix is incomplete or wrong; a refactor on main means the "same" fix needs rewriting; a test that proves the fix is not backported; the commit loses its link to the original; or a security fix is published on main before the patched releases are ready. Each branch is its own small release.
[FIX_DESCRIPTION]
Release branches: [RELEASE_BRANCHES]
1. **Which branches.** For each branch, decide backport or skip based on its support status and whether the bug exists there (check with `git log` or by reading the affected code on that branch; a bug introduced after the branch was cut does not need a backport). For a security fix, note the coordination: patched releases on all affected lines before or together with public disclosure.
2. **Order.** Backport from newest to oldest, each from the previous backport rather than straight from main when branches are close, so conflict fixes carry down.
3. **Per-branch commands:**
- `git switch && git pull`, then `git switch -c backport/-`;
- `git cherry-pick -x ` (the `-x` records "cherry picked from commit"); for several commits, cherry-pick them in original order, or `-m 1` only if picking a merge commit is unavoidable;
- include the regression test commit with the fix;
- run the branch's own test suite and the specific test, and note the test may need adapting to older APIs.
4. **Conflicts and divergence.** For each likely conflict area, say whether to resolve, rewrite the fix by hand for that branch (when the code was refactored), or skip. A clean cherry-pick is not proof: read the surrounding code on the old branch for the same bug in a different form, and check callers that differ.
5. **PRs.** One PR per branch titled `[] `, linking the original PR, labelled for backport, reviewed by someone who knows that line. Mention backport bots or labels only if the user's setup uses them.
6. **Release steps.** Patch version bump per branch (semver patch), changelog entry on each branch referencing the issue, tag and publish, release notes that say which versions contain the fix, and merge-forward or record-keeping so the fix is not reported as missing later.
- Use the real hashes and branch names given; mark placeholders otherwise.
- Never cherry-pick unrelated commits to make a backport apply; if the fix depends on an earlier refactor, say so and propose a minimal hand-written fix instead.
- Do not publish details of a security fix in commit messages or PR titles on public repos before the release; suggest neutral wording.
- If the fix description lacks the commits or which branches are affected, ask for them and stop.
## Which branches
Table: Branch | Status | Affected? | Backport? | Reason.
## Per-branch plan
For each branch, a numbered code block of commands and the tests to run.
## Conflicts and divergence
Bullets per branch: expected conflicts, how to resolve, or the rewrite needed.
## Release steps
Checklist per branch: version, changelog, tag, publish, notes.
````
---
## Choose a branching strategy
`choose-branching-strategy` · prompt · Git and version control · https://hermes-ide.com/prompts/choose-branching-strategy
Recommends a branching and release strategy such as trunk-based, GitHub flow or release branches for a team's size, cadence and environments, with rules, protections and migration steps.
````markdown
A branching strategy is a delivery decision disguised as a git decision. Long-lived branches feel safe but delay integration, so merges get bigger, conflicts get worse and releases get riskier; research on delivery performance (the DORA programme) consistently associates trunk-based development with better outcomes. But trunk-based development only works with fast CI, small changes and a way to hide unfinished work. Teams shipping to app stores, supporting several released versions, or under formal change control genuinely need release branches. The right strategy is the simplest one the team's release model and engineering practices can support today, with a path to simpler.
Recommend a branching and release strategy for this team.
[TEAM]
Release cadence: [RELEASE_CADENCE]
1. Identify the deciding factors: how often and how code reaches production, whether more than one released version must be maintained, whether releases need a stabilisation period, the team's CI speed and test confidence, use of feature flags, and regulatory or approval steps. If a deciding factor is missing, state your assumption.
2. Compare the candidates that fit: trunk-based development (short-lived branches or direct commits, merged at least daily), GitHub flow (feature branches merged to an always-deployable main), trunk plus release branches cut for each release, and Git Flow (develop, release and hotfix branches). Recommend one and say in one line each why the others lose for this team. Recommend Git Flow only when several released versions must be supported in parallel and nothing simpler works.
3. Write the branch rules: branch types and naming, maximum branch lifetime, where branches start and merge, merge method (squash, rebase or merge commit) and why, how unfinished work is hidden (feature flags, branch by abstraction, dark launches), and how environments map to branches or, preferably, to build artifacts promoted between environments.
4. Write the release and hotfix flow step by step: how a release is cut and versioned, how it is tagged, how fixes reach a release branch (fix on main first, then cherry-pick), and how a hotfix goes to production and back to main without regressing.
5. List protections and automation for the code host: required reviews and status checks on main and release branches, linear history if chosen, who may push or force-push, CODEOWNERS, automatic deletion of merged branches, merge queues for busy repos, and release tagging and changelog automation.
6. Write migration steps from the current way of working, in order, with a checkpoint for each: what to change first, how to drain or merge existing long-lived branches, and the practices (CI speed, flags, PR size) that must be in place before shortening branch lifetimes further.
7. Say what would make the team revisit the choice (for example adding a mobile app, a second supported version, or CI getting slower than a set time).
- Fit the recommendation to the stated release model. Do not recommend continuous trunk deploys for a product released through an app store review without explaining how releases are cut.
- Do not prescribe practices the team cannot support yet; put them in the migration steps as prerequisites.
- Commands and settings must be specific to the code host if one was named, and generic otherwise.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Recommendation
The strategy and the three main reasons, in at most 5 lines, plus a Mermaid gitGraph showing a typical feature, release and hotfix.
## Why not the alternatives
One line per alternative.
## Branch rules
Table: branch type, naming, created from, merged into, lifetime, merge method.
## Release and hotfix flow
Numbered steps for each.
## Protections and automation
Checklist per protected branch.
## Migration steps
Numbered, each with its checkpoint.
## When to revisit
Bullets.
````
---
## Choose the right git undo
`choose-git-undo-command` · prompt · Git and version control · https://hermes-ide.com/prompts/choose-git-undo-command
Works out exactly what needs undoing and whether it is shared, then gives the one right command among restore, revert, reset, amend and cherry-pick, with its effect and a check. Use mid-mistake.
````markdown
Someone is in the middle of a git mistake and wants the one right command, not a tutorial. "Undo" in git means at least six different things, and the wrong choice either fails to undo the problem or makes it worse: `reset --hard` on uncommitted work deletes it permanently, and rewriting pushed history breaks everyone who pulled. Two facts decide almost everything: what exactly should be undone (a working-tree change, a staged change, the last commit's message or content, an older commit, a merge, a commit on the wrong branch) and whether it has been shared. Already pushed: false.
[SITUATION]
1. Classify the situation into one case. If two cases fit and they need different commands, ask one short question (for example "Do you want to keep the changes in your files, or throw them away?") and stop. Ask at most two questions in total.
2. Pick the command from this map:
- discard uncommitted changes to a file: `git restore ` (lost for good; say so);
- unstage a file but keep the edits: `git restore --staged `;
- fix the last commit's message or add a forgotten file, not pushed: `git commit --amend`;
- undo the last commit but keep the changes, not pushed: `git reset --soft HEAD~1`;
- throw away the last commit and its changes, not pushed: `git reset --hard HEAD~1`, only after a backup branch;
- undo a commit that is already pushed or shared: `git revert `; for a merge commit, `git revert -m 1 ` and explain what re-merging later requires;
- committed to the wrong branch, not pushed, right branch does not exist yet: `git branch ` (it keeps the commit), then `git reset --keep HEAD~1` on the wrong branch, then `git switch `; when the right branch already exists, `git switch `, `git cherry-pick `, then `git switch ` and `git reset --keep HEAD~1`. Use `--keep`, not `--hard`: it refuses instead of deleting uncommitted edits;
- committed to the wrong branch and pushed: cherry-pick to the right branch and `git revert` on the wrong one;
- undo a rebase or reset that just happened: `git reset --hard ORIG_HEAD` or the reflog entry, after checking it with `git reflog`;
- a lost commit or deleted branch: point to reflog recovery rather than guessing.
3. Treat the change as pushed if false is true or the situation text says it was pushed, merged or pulled by others; if it is unclear and the answer would switch between reset and revert, ask. When pushed, never give a history-rewriting command for a shared branch. If the user insists on rewriting a pushed branch that only they use, give `git push --force-with-lease` with a warning to tell anyone who pulled it.
4. Before any command that moves a branch or discards work, have the user run `git status` and give a one-line safety step: `git branch backup-before-undo` for commits, `git stash` for uncommitted edits they may want back.
5. Show what the result will look like and the command that confirms it.
- One recommended command sequence, not a menu. Mention an alternative only in the last section.
- Use `git restore` and `git switch` (modern commands); mention the older `checkout` equivalent in one parenthesis only if the user used it.
- Replace placeholders such as `` with real values from the pasted output when available; otherwise tell the user exactly where to find them.
- Never say a discard is recoverable when it is not: uncommitted, unstaged changes removed by restore or reset --hard are gone.
- Keep it under about 200 words.
## Your situation
One sentence restating the case and whether it is shared.
## Command
A code block with the safety step and the command or commands, each commented.
## What it changes
Two or three bullets: what happens to the commit, the files, and the remote.
## Check
One command and what it should show.
## If that is not what you meant
One or two lines naming the nearest other case and its command.
````
---
## Clean up a branch's commit history
`clean-up-commit-history` · prompt · Git and version control · https://hermes-ide.com/prompts/clean-up-commit-history
Plans an interactive rebase that turns a messy branch into logical, reviewable commits, with a backup, the exact todo list and a check that the code is unchanged. Use before merging a WIP branch.
````markdown
Reviewers read history commit by commit, and `git bisect` and `git revert` work on commits, so each commit should be one logical change that builds on its own. Work-in-progress history ("wip", "fix typo", "address review") is normal while working and should be reshaped before merge. Interactive rebase is the tool, but it rewrites commits: the risks are losing work, breaking a shared branch, and ending with a final tree that differs from what was tested. A backup and a tree comparison remove those risks.
Plan the clean-up of this branch:
[LOG]
1. Read the log and the files each commit touches. Group the changes into logical commits: one purpose each, ordered so every commit builds and passes tests (refactors and moves before the behaviour that depends on them; tests with the code they test unless the target shape says otherwise). If the log is missing the base branch or file stats, ask for them.
2. Write the target history: the list of final commits with a subject line in the team's convention (imperative mood, under about 72 characters if no convention is given) and which original commits feed each one.
3. Map every original commit to a rebase action: `pick`, `reword`, `squash`, `fixup`, `drop` or `edit` (to split). Reorder lines as needed. Point out where reordering will likely conflict, because a later commit touches the same lines as an earlier one.
4. For commits that mix two purposes, give the split procedure: mark `edit`, `git reset HEAD~`, stage by purpose with `git add -p` or by path, commit each part, then `git rebase --continue`.
5. Mention the fixup alternative for future work: `git commit --fixup=` plus `git rebase -i --autosquash`.
6. Keep the reshape and any update to a newer base apart. Rebase onto the branch's current merge base (`git rebase -i --keep-base `, Git 2.24 or newer, or `git rebase -i $(git merge-base HEAD)`), so the final tree can be compared with the backup. Moving onto the latest base is a separate, later step.
7. Give the verification: the final tree must equal the backup's tree, `git range-diff` shows each old commit's fate, and each commit should build and test.
- The first step is always a backup branch. Never suggest `git reset --hard` or `git push --force` without `--force-with-lease`.
- If the branch is already pushed and others may have based work on it, say so, and recommend agreeing with them before rewriting.
- Never drop a commit whose changes are not present elsewhere in the target history; if a change looks accidental, list it and ask.
- Use only commit hashes and messages from the log. Do not invent commits.
## Target history
Numbered final commits: subject, then the original commits it absorbs.
## Before you start
The backup command (`git branch backup/-`) and a check that the working tree is clean.
## Rebase todo
The `git rebase -i --keep-base ` command and the full todo list exactly as it should be edited, oldest first.
## Splitting and rewording
Step-by-step commands for each `edit` and the new messages for each `reword` or `squash`.
## Verify
`git diff backup/- HEAD` must be empty (any difference is lost or extra work), `git range-diff backup/- HEAD` to review the mapping, and `git rebase -x "" --keep-base ` to build and test each commit.
## Publish
`git push --force-with-lease` and when it is safe.
## Undo
How to return to the backup (or find the old head in `git reflog`) if anything goes wrong.
````
---
## Coach git for non-developers
`coach-git-for-non-developers` · prompt · Git and version control · https://hermes-ide.com/prompts/coach-git-for-non-developers
Teaches writers, designers and researchers the minimum git needed to contribute to a docs or content repo through a web editor, desktop app or terminal, one concept per turn with a small exercise.
````markdown
The learner is not a developer: [ROLE]. They need to contribute changes to a repository that holds documentation, content or design assets, and they will use the web-editor route. Most git tutorials teach far more than they need and use developer metaphors. They need a small, safe workflow they can repeat: get the latest version, make a branch, edit, save a commit with a clear message, open a pull request, respond to review, and keep their branch up to date. They also need to know which situations are normal and which mean "stop and ask someone".
Run a short coaching session, one concept per turn.
1. Open by saying what they will be able to do by the end (about six short lessons, 20 to 30 minutes) and ask one question: have they used any version history before (Google Docs history, Figma versions, track changes)? Use their answer as the anchor analogy.
2. Teach these concepts in order, one per turn, each in under 120 words with an analogy from their own work:
1. **Repository and history:** a shared folder that remembers every saved version and who made it.
2. **Branch:** your own copy to work on without affecting the published version.
3. **Commit:** a saved checkpoint with a message saying what and why; how to write a good one-line message.
4. **Pull request:** asking for your changes to be reviewed and added; what reviewers look for; how to reply to comments and push fixes.
5. **Staying up to date:** updating your branch from main, and what a conflict means (two people changed the same lines) and when to ask for help.
6. **Undo and safety:** what is easy to undo and what to never do (force push, deleting branches that are not yours).
3. After each concept, give one tiny exercise using web-editor: exact clicks described generally for web-editor or desktop-gui (for example "find the pencil icon to edit a file", "choose 'Create a new branch for this commit'"), or exact commands for command-line. Ask them to say what they saw. Correct misunderstandings gently before moving on.
4. If they ask about something beyond scope (rebasing, CI, merge strategies), give a one-sentence answer and say it is safe to leave to the developers.
5. When finished, or when they type "done", give the closing summary.
- One concept per turn, then wait.
- No jargon without a plain explanation; never use "simply" or "just".
- Describe interface elements generally and say labels may differ slightly; do not invent exact menu paths.
- Never suggest destructive commands. If they describe a scary situation (lost work, conflicts, "it says force"), tell them to stop and ask a developer, and what to send them (a screenshot or the message).
- Encourage, do not patronise: they are experts in their own field.
Each turn: the concept in plain words, the analogy, the exercise, and a question to check understanding.
At the end:
## What you learned
Six one-line bullets.
## Your workflow card
A numbered list of 6 to 8 steps for web-editor that they can keep next to them.
## When to ask for help
Bullets of situations that mean stop and ask, with what to send.
````
---
## Configure branch protection
`configure-branch-protection` · prompt · Git and version control · https://hermes-ide.com/prompts/configure-branch-protection
Designs branch protection or rulesets covering required checks, reviews, CODEOWNERS, linear history, signing, bypass, tag protection and merge queue, fitted to team size and release model.
````markdown
A tech lead or repository admin wants protection rules that keep the main and release branches healthy without slowing the team to a crawl. Over-protection fails as badly as none: two required approvals on a three-person team stalls every PR, required checks that are flaky train people to bypass, and admins who can push directly make the rules decorative. Rules should match the release model and include a documented emergency path. Hosting: github.
[TEAM_CONTEXT]
1. Identify the protected targets from the release model: the default branch, release branches (by pattern, for example `release/*`), and release tags (`v*`).
2. For each target, decide and justify:
- **Pull request required,** with the number of approvals: 1 for most teams, 2 for regulated or high-risk repos with enough reviewers; dismiss stale approvals on new commits; require approval of the latest push by someone other than the pusher.
- **Code owner review** for sensitive paths only (infra, auth, payments, CI config), with a fallback owner team so PRs never wait on one person.
- **Required status checks:** the fast, reliable ones by exact job name; require branches to be up to date only if there is no merge queue; flaky checks fixed or kept advisory, never required.
- **Merge queue** when the team merges often enough that "up to date" rebases cause churn (roughly more than a few merges an hour, or a long CI).
- **History:** linear history and allowed merge methods (squash only, or rebase) matched to how the team reads history and generates changelogs.
- **Signed commits** only if the team can support key setup; otherwise note signing of release tags as the minimum.
- **Force-push and deletion** blocked on protected branches.
- **Conversation resolution** required before merge.
3. **Tags:** protect release tags from deletion and update; restrict who can create them to the release automation or maintainers.
4. **Bypass:** who can bypass (a small group or the release bot, never everyone with admin by default), how emergencies are handled (a documented break-glass procedure with a follow-up review), and an audit trail.
5. Use github names for each setting (for example GitHub rulesets and branch protection, GitLab protected branches and approval rules, Bitbucket branch permissions and merge checks). If unsure whether a setting exists on a plan or version, say to check and give the intent. For "other", describe each rule generically.
6. Give a rollout: start in evaluate or audit mode if available, announce, apply to the default branch first, then release branches, review after two weeks.
- Fit rules to team size: never require more approvals than there are regular reviewers minus one.
- Do not invent check names; use those in the context or mark placeholders.
- Do not claim exact menu paths or plan limits; name the setting and say where to verify it.
- If the context lacks team size or release model, ask for them and stop.
## Recommendation
Three or four sentences: the overall approach and the main trade-off.
## Rules by branch and tag
Table: Target (pattern) | Rule | Setting | Why.
## Settings to apply
A checklist in github terms; where the service supports rules as code (for example a ruleset JSON or API payload), a short example marked as a template to check against current docs.
## Exceptions and bypass
Who, when and how it is logged.
## Rollout
Numbered steps.
````
---
## Conventional Commits rules
`conventional-commits-rules` · rule · Git and version control · https://hermes-ide.com/prompts/conventional-commits-rules
Makes the assistant write every commit in Conventional Commits 1.0.0 format, one logical change per commit, with honest breaking-change footers. Use in repos that release from commits.
````markdown
Follow these rules for the rest of this conversation.
When you write a commit message, follow Conventional Commits 1.0.0.
- Write the header as `type(scope): description`. The scope is optional; leave it out unless the repo already uses scopes, and then use the same scope names.
- Use one of these types: `feat` (new behaviour for users), `fix` (a bug fix), `docs`, `style` (formatting only), `refactor` (no behaviour change), `perf`, `test`, `build`, `ci`, `chore`, `revert`. Do not invent new types unless the repo's commitlint config lists them.
- Write the type and scope in lowercase. Write the description in the imperative mood ("add", not "added"), with no trailing period.
- Keep the header under 72 characters.
- Put one logical change in each commit. If the staged changes do two things, say so and suggest splitting them instead of writing a header that joins them with "and".
- After a blank line, add a body that explains why the change was made when the header does not make that obvious. Wrap it at 72 characters. Do not narrate the diff.
- Mark a breaking change in two places: an exclamation mark before the colon (`feat(api)!: drop the v1 endpoints`) and a `BREAKING CHANGE:` footer that says what users must change. Write `BREAKING CHANGE` in uppercase.
- A change is breaking when existing users must change code, configuration or data to keep working. Removing a public function, renaming a CLI flag and changing a default are breaking; internal refactors are not.
- Put footers after the body, one per line, in `Token: value` form (`Refs: #123`, `Reviewed-by: Name`). Only reference issues that exist in the task or the branch; never invent an issue number.
- For a revert, use `revert: ` followed by the reverted header, and a body of `This reverts commit SHA.` with the real sha.
- Remember how release tools read these: `fix` produces a patch release, `feat` a minor release and any breaking change a major release. Choose the type by its effect on users, not by the size of the diff.
- Do not add tool or assistant attribution trailers unless the user asks for them.
````
---
## Explain a git error
`explain-git-error` · prompt · Git and version control · https://hermes-ide.com/prompts/explain-git-error
Explains a git error or confusing state such as detached HEAD, rejected push or divergent branches in plain words, what caused it and the safest command to get out. Use when git stops you.
````markdown
The user hit a git error or a state they do not understand. They may be a student, a junior developer, or a designer or writer who uses git occasionally. Git's messages are accurate but written for people who already know its model, and the commands people find online to "fix" them (`--force`, `reset --hard`, deleting `.git` and recloning) often destroy work. A good answer translates the message, explains the cause in terms of their situation, and gives the least destructive way forward.
[ERROR_OUTPUT]
1. Identify the message. Common ones: detached HEAD; push rejected (non-fast-forward, fetch first); divergent branches needing a pull strategy; refusing to merge unrelated histories; `index.lock` exists; untracked or local changes would be overwritten by checkout, merge or pull; merge or rebase in progress; authentication or permission denied; pathspec did not match; not a git repository; large file or protected branch rejected by the server; line-ending warnings.
2. Explain what git is protecting the user from, in one or two plain sentences, using a simple picture where it helps (for example "your branch and the remote branch each have commits the other does not").
3. Give the cause in their situation if the context allows; otherwise list the two most likely causes and the command that tells them apart (usually `git status`, `git log --oneline --graph --all -n 15` or `git remote -v`).
4. Give the safest way out as numbered commands, one per line, with a short comment on what each does. Prefer commands that keep work: commit or stash first, `git pull --rebase` or merge instead of force, `git switch -c` to keep commits made on a detached HEAD, `git merge --abort` or `git rebase --abort` to get back to where they were.
5. If the only fix is destructive (discarding changes, force-pushing, deleting a lock file while another git process may be running), put a clear **Warning** line before it, say what will be lost, and give a backup step first (`git branch backup-` or copying the folder). For force-push, use `--force-with-lease` and only on a branch nobody else uses.
6. Give one command to confirm they are out of trouble, and what its output should look like.
- Plain language; define any git term the first time you use it (commit, branch, remote, HEAD).
- Never recommend `git push --force` to a shared branch, `git reset --hard`, `git clean -fd` or deleting the `.git` folder without the warning and backup above.
- If the message is cut off or the situation is unclear, say what to paste (the full message, `git status`) rather than guessing.
- If the error is from a hosting service policy (protected branch, required checks, file size limit), say that git cannot override it and who to ask.
- Keep the whole answer under about 250 words unless the situation needs more.
## What it means
One or two sentences.
## Why it happened
Short explanation, or the two likely causes with the command to tell them apart.
## Safest way out
Numbered commands in code blocks with comments, warnings before anything destructive.
## Check it worked
One command and what to look for.
````
---
## Extract a folder into a new repository
`extract-folder-into-new-repo` · prompt · Git and version control · https://hermes-ide.com/prompts/extract-folder-into-new-repo
Plans moving one directory such as a library or service into its own repository with its history, using git filter-repo, then rewires CI, package names, issues and references in the original repo.
````markdown
A maintainer wants to move [FOLDER] out of its current repository into a new one, keeping the commit history so blame and log still work. The git part is short with git filter-repo; the work that goes wrong is everything around it: files moved into the folder from elsewhere lose their earlier history, tags point at commits that no longer exist, CI and release config still assume the old paths, other code imports the folder by relative path, and open issues and PRs are left behind. The original repo also needs a clean removal and pointers to the new home.
[REPO_LAYOUT]
1. **Decisions first.** List the decisions to make before running anything, with a recommendation each: whether to keep full history (default yes) or start fresh; which other paths to include (files that were moved into [FOLDER], shared configs); whether the new package keeps its name and version line; how internal consumers will depend on it (published package, git submodule, or a vendored copy); repository name, visibility and licence; who owns it (CODEOWNERS). If the layout does not show how the folder is built or who depends on it, list those as questions and continue with clearly marked assumptions.
2. **Extract with history.** Give the commands:
- work in a fresh clone (`git clone --no-local extract-tmp`), never the working copy, because filter-repo rewrites everything;
- `git filter-repo --path [FOLDER]/ --path-rename [FOLDER]/:` (plus extra `--path` entries for moved-in history, found with `git log --follow --name-status -- `);
- tag handling: filter-repo keeps only tags that point at kept commits; say whether to rename tags with `--tag-rename` (for example `parser-v1.2.0` to `v1.2.0`);
- verify with `git log --oneline | wc -l`, `git log --follow` on one key file, and a build and test run;
- create the new remote, push all branches you need and tags.
3. **Rewire the new repo.** CI workflows rewritten for the new root paths, release and publishing config, package manifest fields (repository URL, homepage), README, licence file, CODEOWNERS, branch protection, secrets the pipeline needs, issue templates.
4. **Update the original repo.** One PR that removes [FOLDER], switches consumers to the new dependency (published version or submodule) and updates CI, docs and CODEOWNERS; leave a short README or `MOVED.md` at the old path only if people are likely to look there.
5. **Issues and PRs.** Transfer open issues if the hosting service supports it, otherwise close with a link; ask authors of open PRs touching the folder to reopen against the new repo, or port them with `git format-patch --relative=[FOLDER]` in the old repo and `git am` in the new one.
6. **Cutover checklist** in order, with a freeze window: announce, freeze changes to the folder, extract, verify, publish, merge the removal PR, unfreeze.
- Use git filter-repo, not the deprecated `git filter-branch`; say it must be installed separately.
- Never run filter-repo in the only copy of the repository. Backups and a fresh clone are mandatory steps.
- Do not invent build commands, package names or CI providers; use those in the layout or mark placeholders.
- If the folder imports code from elsewhere in the repo, list those dependencies as a blocker to solve before extraction.
## Decisions first
Table: Decision | Recommendation | Why.
## Extract with history
Numbered steps with code blocks.
## Rewire the new repo
Checklist.
## Update the original repo
Checklist, including consumers, issues and PRs.
## Cutover checklist
Ordered checkboxes with who does each if roles are known.
````
---
## Fix line-ending churn
`fix-line-ending-churn` · prompt · Git and version control · https://hermes-ide.com/prompts/fix-line-ending-churn
Diagnoses whole-file diffs caused by CRLF and LF, file mode or encoding differences across operating systems, then writes a .gitattributes, a one-time renormalise commit and per-machine settings.
````markdown
A mixed-OS team sees pull requests where every line of a file changed though nobody edited it. The usual causes are line endings (Windows tools writing CRLF, others LF, with each person's `core.autocrlf` doing something different), executable-bit changes when files pass through Windows or certain file systems (`core.fileMode`), and encoding changes such as a byte-order mark added by an editor. Per-person settings never fix this for good; a committed `.gitattributes` does, followed by one renormalisation commit so the repository content is consistent.
[SYMPTOMS]
Stack:
1. **Diagnose** from the symptoms which cause applies, and give the command that confirms it: `git diff --ignore-cr-at-eol --stat` or `git diff -w --stat` (churn disappears means line endings); `git ls-files --eol` to see index and working-tree endings per file; `old mode`/`new mode` lines in `git diff` for file mode; a BOM visible in a hex dump (`head -c 3 | xxd`) for encoding. If the symptoms do not match any cause, say what output to paste and stop.
2. **Write the .gitattributes** for this stack:
- `* text=auto eol=lf` as the default (or `* text=auto` if some tools need CRLF in the working tree);
- explicit `eol=crlf` for files Windows tools require with CRLF (`*.bat`, `*.cmd`, often `*.sln`, `*.ps1` if the team's tools need it);
- explicit `eol=lf` for shell scripts and anything run in Linux containers (`*.sh`, `Dockerfile`);
- `binary` for binary types in the repo (images, fonts, archives, `*.dll`), and nothing marked text that is not text.
3. **Renormalise once,** in its own commit, on a quiet moment agreed with the team: make sure everyone has pushed; `git add --renormalize .`; review `git status` and `git ls-files --eol`; commit as "Normalise line endings" with no other changes. Add the commit hash to `.git-blame-ignore-revs` and show `git config blame.ignoreRevsFile .git-blame-ignore-revs` so blame skips it.
4. **Open branches:** explain that branches started before the renormalise will conflict on whole files; recommend merging or rebasing onto the normalised main with `-X renormalize` (`git rebase -X renormalize main` or `git merge -X renormalize main`).
5. **Per-machine settings:** with `.gitattributes` in place, recommend `core.autocrlf false` on all machines (or `input` on macOS and Linux) so personal settings do not fight the file; editor settings via `.editorconfig` (`end_of_line`, `charset`, `insert_final_newline`); for file mode churn, `git config core.fileMode false` on affected machines and `git update-index --chmod=+x ` to set the executable bit deliberately; for BOMs, `charset = utf-8` in `.editorconfig`.
6. **Prevent recurrence:** a CI check that fails on CRLF in LF-only files or on mixed endings, and `.editorconfig` committed.
- Do not recommend rewriting history to fix line endings; one forward commit is enough.
- Do not mark a file type as text or binary unless it appears in the stack or the symptoms; mark guesses with `# check:`.
- Warn that the renormalise commit touches many files and should not be mixed with real changes.
- If no stack is given, write a minimal .gitattributes and list the file types to add.
## Diagnosis
The cause, the evidence, and the confirming command.
## .gitattributes
One commented code block.
## Renormalise once
Numbered commands, including the blame-ignore step and the note on open branches.
## Per-machine settings
Commands per OS, and an `.editorconfig` snippet.
## Check
Commands to verify (`git ls-files --eol`, a fresh clone on Windows shows no changes) and the CI check idea.
````
---
## Git safety rules
`git-safety-rules` · rule · Git and version control · https://hermes-ide.com/prompts/git-safety-rules
Standing rules for an assistant or coding agent running git, with no force-push to shared branches, no rewriting published history, backups before rebase or reset, no secrets, and asking before push.
````markdown
Follow these rules for the rest of this conversation.
When you run git commands in someone's repository:
- Run `git status` and `git branch --show-current` before any command that changes the working tree, the index, branches or history, and read the output. Stop and ask if there are uncommitted changes you did not make, a rebase or merge in progress, or you are on a branch you did not expect.
- Never run these without the user's explicit go-ahead for that specific command in this session: `git push --force` or `--force-with-lease`, `git reset --hard`, `git clean` with `-f`, `git checkout -- .` or `git restore .` over changes you did not make, `git branch -D`, `git stash drop` or `clear`, `git rebase` on a pushed branch, `git filter-repo`, `git gc --prune=now`, and deleting remote branches or tags.
- Never force-push to the default branch, a release branch, or any branch other people push to. If a branch must be rewritten and only the user works on it, use `--force-with-lease`, never plain `--force`.
- Never rewrite commits that have been pushed to a shared branch (no amend, rebase, squash or reset of them). Undo shared commits with `git revert`.
- Before a rebase, reset, history rewrite or large merge, create a backup ref (`git branch backup/-`) and tell the user its name. Leave backups in place; let the user delete them.
- Ask before every `git push`, unless the user has said that pushing to this specific branch is fine for this task. Never push to a branch other than the one the task is about.
- Never commit secrets, credentials, `.env` files, private keys, tokens, personal data or large binaries. Check `git diff --cached --stat` before each commit, and stop if a staged file looks like one of these. If a secret was already committed, say so and recommend rotating it; do not try to hide it with another commit.
- Never commit generated or build output (`dist/`, `node_modules/`, compiled files, coverage) unless the repository already tracks it on purpose.
- Stage specific paths (`git add `), not `git add -A` or `git add .`, unless you have checked every file in `git status`.
- Keep each commit to one logical change, with a message that follows the repository's convention. Do not add co-author lines, sign-offs or signatures on someone's behalf unless the user told you to.
- Do not change git config (`user.name`, `user.email`, hooks, signing, credential helpers) or skip hooks with `--no-verify` unless the user asks.
- Work on a branch, not directly on the default branch, unless the user says otherwise.
- When a command fails or produces a conflict, stop and report the exact output. Do not retry with a more forceful variant (adding `--force`, `-D`, `--hard`, `--theirs` for every file) to make the error go away.
- After any operation that changes history, show `git log --oneline -n 10` and `git status` so the user can see the result, and say how to undo it (the backup ref or the reflog entry).
````
---
## Investigate why code changed
`investigate-code-history` · prompt · Git and version control · https://hermes-ide.com/prompts/investigate-code-history
Investigates when and why a piece of code changed using blame, log search, pickaxe and linked pull requests, and writes a short evidence-backed history of the decision and who to ask.
````markdown
`git blame` alone usually points at the wrong commit: a reformat, a file move or a mass rename. The decision you care about is often several commits back, and the reason lives in a commit body, a pull request description, a linked issue or a code review thread. Good code archaeology follows the code through moves, finds the commit that introduced or changed the specific behaviour, reads the surrounding discussion, and separates what the record says from what is inferred.
Answer this question about [FILE_OR_SYMBOL]: [QUESTION]
Access mode: local. In `local` mode, run read-only git commands yourself. In `pasted-log` mode, work only from what the user pasted; if it is not enough, list the exact commands for the user to run and stop.
1. Locate the code today and confirm it exists as described. If it does not, search for it (`git grep`, `git log -S`) and report where it went.
2. Find the change that matters, skipping noise:
- `git blame -w -C -C -M` on the relevant lines, honouring `.git-blame-ignore-revs` if present (`--ignore-revs-file`), to see past whitespace changes, moves and copies.
- The pickaxe: `git log -S''` for when a string or value appeared or disappeared, and `git log -G''` for changes to lines matching a pattern.
- Line history: `git log -L ,:` or `git log -L ::` to see every version of the function.
- `git log --follow -p -- ` across renames.
- For a change that looks reverted or reintroduced, check for revert commits and cherry-picks.
3. For each relevant commit, read the full message (`git show --stat `), and look for a pull request or merge request number, an issue or ticket id, a linked design document, or a co-author. If the hosting CLI is available and authenticated, read the pull request description and review comments; otherwise give the link pattern for the user to open.
4. Reconstruct the decision: what the code did before, what changed, who changed it and when, the stated reason, and any later change that modified the original intent.
5. Name who to ask: the authors and reviewers of the key commits who are still active in recent history (`git shortlog -sne --since= -- `), and the current owners if a CODEOWNERS file exists. Use names or handles as they appear in the repository; do not look people up elsewhere.
6. Before answering, check each claim against a commit, diff or pull request you actually read, and label everything else as inference.
- Read-only: never commit, check out, reset, rebase, stash or modify the working tree or any branch. Do not fetch or push unless the user asks.
- Quote commit messages and pull request text exactly when they are evidence; do not paraphrase them into stronger claims.
- If the record does not explain why, say "the history does not record a reason" instead of inventing one.
- Do not include email addresses in the report; use names or handles.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Answer
Two to four sentences that answer [QUESTION] directly, with the key commit.
## Timeline
| Date | Commit | Author | Change | Stated reason |
## Evidence
Quoted commit messages, pull request or issue excerpts, and short diffs that support the answer.
## Confidence
High, medium or low, and what would raise it. List every inference explicitly.
## Who to ask
Names or handles, their role in the change, and whether they are still active in this area.
## Commands used
The git commands you ran, or the ones the user should run in pasted-log mode.
````
---
## Purge a file from git history
`purge-file-from-git-history` · prompt · Git and version control · https://hermes-ide.com/prompts/purge-file-from-git-history
Removes a large file or committed secret from all git history with git filter-repo, with a backup first, exact commands, force-push coordination and what every collaborator must do.
````markdown
Deleting a file in a new commit does not remove it from history: every clone, fork and cached view still has it. Removing it for real means rewriting every commit since it was added, which changes their hashes, invalidates open pull requests and breaks every collaborator's clone. git filter-repo is the tool the Git project recommends for this (git filter-branch is slow and error-prone, and BFG Repo-Cleaner is an older alternative). For a secret, the rewrite is cleanup, not the fix: anyone who cloned, forked or scraped the repository already has it, so the credential must be revoked and rotated first.
Write a step-by-step plan to remove this from the repository's entire history:
[WHAT_TO_REMOVE]
Hosting: github
Is a secret or sensitive data: false
Treat it as a secret even if this says false when the description shows a credential, token, key, private certificate or personal data, and say that you did.
1. **Before you start.** If it is a secret, the first step is to revoke and rotate the credential and check its access logs for misuse, before touching history; say this plainly and do not let the rewrite delay it. For any rewrite: name the window when nobody may push, list the open pull requests and branches that will need recreating, check whether the file should instead stay in history through Git LFS (`git lfs migrate import --include="" --everything`) if it is a large asset the project still needs, and note that every commit hash after the first affected commit will change, breaking links and signatures on rewritten commits and tags.
2. **Back up.** A mirror clone (`git clone --mirror backup.git`) stored somewhere safe and access-controlled, because for a secret the backup contains it too; say when to delete the backup.
3. **Rewrite.** Install git filter-repo with the platform's package manager or pip, make a fresh mirror clone to work in, and give the exact command for this case:
- a path: `git filter-repo --invert-paths --path ` (repeat `--path`, or use `--path-glob` for patterns);
- large files by size: `git filter-repo --strip-blobs-bigger-than `, after listing the biggest blobs so the user can choose the threshold;
- a secret string inside files that must stay: `git filter-repo --replace-text `, with the file format (`literal:==>***REMOVED***` or `regex:==>***REMOVED***`) and a warning not to commit or share that file.
For sensitive data, mention the `--sensitive-data-removal` option that recent git filter-repo versions provide (it also fetches and rewrites refs such as pull request refs and reports the first changed commits) and tell the user to check `git filter-repo --help` for their version.
4. **Verify** before pushing, with commands that must return nothing: `git log --all --oneline -- ` for a path, `git log --all -S '' --oneline` for a string (run it locally only and keep it out of shell history), and the largest-blobs listing again for size cleanups. Also check the tags.
5. **Push.** Re-add the remote if filter-repo removed it, temporarily allow force pushes on protected branches, then force-push all branches and tags (`git push --force --mirror origin` from the mirror clone, or `git push origin --force --all` and `git push origin --force --tags`). Explain that rejections of read-only refs such as pull request refs are expected on some hosts. Restore branch protection immediately afterwards.
6. **Host cleanup** for github: the host still serves old commits through pull request refs, caches and forks. For GitHub, explain that pull request refs and cached views keep the old commits and that GitHub Support can remove cached views and run garbage collection on request, with the affected commit hashes; forks are separate repositories the owner must handle. For GitLab, use the Repository cleanup setting with the `commit-map` file that filter-repo writes under `.git/filter-repo/`. For other hosts, say to check the host's documentation or support for purging unreachable objects. Also clear CI caches, artifacts and mirrors that may hold the old history.
7. **Tell collaborators.** Write the message to send: stop pushing; after the rewrite, re-clone (the safest option); anyone with unpushed work saves it as patches or rebases it onto the new history with `git rebase --onto`, never merges an old branch, because that brings the purged file back; recreate open pull requests; delete old local clones and forks that contain the file.
8. **Afterwards.** Add the path or pattern to `.gitignore`, add a pre-commit or server-side check (secret scanning or a file-size limit), and for a secret confirm the rotated credential works everywhere.
- Do not run any command yourself. Give commands for the user to run, and label each one read-only or rewrites history or force-pushes.
- Never print, echo or repeat the secret value in the plan; use a placeholder like ``.
- If it is a secret, rotation comes before every other step, and say that a history rewrite alone does not make the secret safe.
- Do not claim the data is gone from the host until the host cleanup step is done; say what may still hold it.
- If you are unsure an option exists in the user's tool version, say how to check instead of asserting it.
## Before you start
## Back up
## Rewrite
## Verify
## Push
## Host cleanup
## Tell collaborators
Include the ready-to-send message in a quote block.
## Afterwards
Each section uses numbered steps with commands in fenced blocks, each command labelled read-only, rewrites history or force-pushes.
````
---
## Rebase stacked branches
`rebase-stacked-branches` · prompt · Git and version control · https://hermes-ide.com/prompts/rebase-stacked-branches
Plans updating a stack of dependent branches after the base moves or a lower PR is squash-merged, using rebase --onto or --update-refs, with commands per branch, conflict expectations and backups.
````markdown
The user maintains a stack of dependent branches, each with its own pull request. When the base moves, or a lower PR is merged, every branch above must be moved. The classic trap: after a lower PR is squash-merged, its original commits still sit at the bottom of the next branch; a plain `git rebase main` tries to replay them on top of the squashed copy and produces confusing conflicts or duplicate changes. The fix is to cut those commits off with `git rebase --onto`. Git 2.38 and later can move all branches in a stack in one rebase with `--update-refs`.
[BRANCH_STACK]
[WHAT_CHANGED]
1. Restate the stack bottom to top and classify the event: base moved (no merges); lower branch squash-merged or rebase-merged (its commits now exist on main under new hashes); lower branch merged with a merge commit (commits are shared, a plain rebase works); a commit in a lower branch was amended or rebased locally.
2. If the commit boundaries are unclear (where each branch starts), give the commands to find them: `git log --oneline --graph main..` and `git merge-base`, and note the old tip of a merged branch can be found in the PR page or `git reflog show `. If the stack or event cannot be identified, ask and stop.
3. Backup: `git fetch`, then a backup ref for every branch (`git branch backup/ `), and a note that reflog also keeps the old positions.
4. Write the commands, branch by branch, using real branch names:
- **Squash-merged lower branch:** `git rebase --onto origin/main `, then for each branch above, `git rebase --onto ` (record each old tip before moving it, for example as the backup ref).
- **Base moved or amended lower commit, git 2.38 or later:** check out the top branch and run `git rebase --update-refs ` (or `--onto` with `--update-refs`), which moves every branch in the stack; show the todo list lines `update-ref` so they know what to expect. Mention `rebase.updateRefs true` as an option.
- **Older git:** rebase each branch in order from the bottom, using `--onto` with the previous old tip.
5. Say where conflicts are likely (files touched by both the new base and a branch) and how to handle them: resolve once at the lowest branch so higher ones inherit the fix; `git rerere` to reuse resolutions; `git rebase --abort` to return to the start.
6. Push and PR updates: `git push --force-with-lease` per branch, bottom first; retarget the next PR's base to main on the hosting service if the merged branch was deleted; check each PR's diff shows only its own commits.
7. Give a verification: `git log --oneline --graph main..` should show each branch's commits once, and `git range-diff` against the backup confirms the content is unchanged.
- Use the user's real branch names and hashes wherever given; otherwise mark placeholders like `` and say how to find them.
- Never recommend force-pushing a branch others commit to without saying so; these are assumed to be the user's own branches.
- Do not tell the user to merge main into each branch as the default; mention it only as an alternative when the team forbids force-pushes.
- If a stacking tool is mentioned (for example Graphite, ghstack, git-branchless, spr), give its command only if you are sure of it, and the plain git commands either way.
## What happened
Two or three sentences: the event and why a plain rebase would go wrong (if it would).
## Backup
A code block.
## Commands
Numbered steps, one code block per branch, with a comment on what each command does.
## Conflicts to expect
Bullets.
## Push and PR updates
Commands and the PR base changes, then the verification commands.
````
---
## Recover lost Git work
`recover-lost-git-work` · prompt · Git and version control · https://hermes-ide.com/prompts/recover-lost-git-work
Recovers commits, branches, stashes and staged files lost to a reset, rebase or dropped stash, using reflog and fsck after a backup, explaining each command. Use right after a git mistake.
````markdown
Git rarely deletes committed work immediately. A reset, rebase, amend or deleted branch only moves references; the old commits stay in the object store and in the reflog until garbage collection removes them (by default reflog entries last 90 days, or 30 for commits no branch can reach). A dropped stash is a dangling commit. Staged but uncommitted files exist as blobs. Only changes that were never committed or staged are outside Git's reach. The danger during recovery is panic: more resets, `git gc`, or re-cloning can destroy what is still recoverable.
Help recover lost work.
What happened:
[WHAT_HAPPENED]
1. Classify the loss: commits lost by reset, rebase or amend; a deleted branch; a dropped or cleared stash; staged files lost by reset or checkout; uncommitted, unstaged changes overwritten; a force-pushed remote branch; or something else. If the description is ambiguous, ask the one question that decides it, and give the read-only commands that will show it.
2. Start with safety: stop running write commands, do not run `git gc` or `git prune`, and make a full copy of the repository directory (including `.git`) before changing anything.
3. Give read-only commands to locate the work, explaining what each one shows:
- `git reflog` and `git reflog show ` for previous positions of HEAD and branches; `ORIG_HEAD` after a reset, rebase or merge;
- `git fsck --lost-found` or `git fsck --unreachable --no-reflogs` for dangling commits and blobs, including dropped stashes (stash commits have messages starting "WIP on" or "On "); list them readably with `git fsck --unreachable --no-reflogs | grep commit | cut -d' ' -f3 | xargs git log --no-walk --format='%h %ci %s'`;
- `git show ` and `git log -p ` to confirm a candidate is the lost work.
If you can run commands in the repository yourself, run only these read-only ones and show their output; otherwise give them to the user and wait for the output.
4. List the candidates with sha, date, subject and a `git show --stat ` summary so the user can recognise their work, ranked by how well each matches the description.
5. Restore without overwriting anything: create a new branch at the found commit (`git branch recovered/ `), apply a stash commit with `git stash apply `, or write a blob to a new file with `git show > recovered-file`. Only then compare and merge into the working branch.
6. If the lost changes were never committed or staged, say so plainly and list the places that might still hold them: editor or IDE local history, editor swap or backup files, OS snapshots or backups, a copy in another clone, CI artifacts, or an open pull request.
7. If the work was pushed before it was lost, the remote or a teammate's clone still has it: fetch it from there. If the remote branch was force-pushed, check other clones and the reflog of whoever pushed, and the hosting service's pull request or activity views for the old head commit.
- Every command you give is read-only until the user has a backup. Label each command read-only or writes.
- Never suggest `git reset --hard`, `git checkout -- .`, `git clean`, `git gc` or `git prune` during recovery.
- Do not claim a commit is the lost work until its contents have been checked with `git show`.
- If you need output you do not have, ask for it with the exact command, and wait.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## What likely happened
Two or three sentences, and the one question to ask if unsure.
## Stop and back up
The backup command for the user's platform.
## Candidates
Numbered read-only commands, each with what to look for in the output, then a table: sha | date | subject | files changed | match (high, medium, low).
## Restore it
Commands to restore onto a new branch or file, then how to bring it back into the working branch.
## If it is not there
Where else the work may survive, in order of likelihood.
````
---
## Resolve a merge conflict
`resolve-merge-conflict` · prompt · Git and version control · https://hermes-ide.com/prompts/resolve-merge-conflict
Resolves merge, rebase or cherry-pick conflicts by reading both sides and their common base, keeps the intent of each, and asks when the intents contradict. Use when git stops on a conflict.
````markdown
A conflict means two changes touched the same lines. Picking one side wholesale silently deletes the other person's work, and keeping both blindly often produces code that compiles but is wrong. A correct resolution keeps the intent of both changes, which you can only know by comparing each side with their common ancestor. Conflicts can also be semantic and outside the markers: one side renames a function while the other adds a new call to the old name.
Resolve the conflicts in the current repository.
1. Run `git status` to see the operation (merge, rebase, cherry-pick, revert or stash pop) and the conflicted files. Remember that during a rebase "ours" is the branch being rebased onto and "theirs" is the commit being replayed, the reverse of a merge.
2. For each conflicted file, read the three versions: base (`git show :1:path`), ours (`:2:path`) and theirs (`:3:path`). Read the commits that touched the file on each side (`git log --oneline --left-right --merge -- path`) to learn the intent of each change.
3. Classify every conflicting hunk:
- independent: both changes can coexist; combine them.
- same intent: both made an equivalent change; keep one, preferring the more complete one.
- contradictory: the changes want different behaviour; do not guess. Leave the markers in that hunk and put it under "Needs your decision".
4. Remove every conflict marker you resolved. Search the whole file for leftover `<<<<<<<`, `=======` and `>>>>>>>`.
5. Look for semantic conflicts beyond the markers: renamed or removed symbols, changed signatures, moved files. Search for usages of anything either side renamed or deleted.
6. For lockfiles and generated files, do not hand-merge. Take one side, then regenerate with the project's own command (for example the package manager's install) and say which command you ran.
7. Run the project's build and the tests nearest to the touched code. Stage the files you resolved with `git add`.
- Do not run `git commit`, `git merge --continue`, `git rebase --continue`, `git push`, or any command that discards work (`reset --hard`, `checkout -- .`, `merge --abort`, `rebase --abort`, `clean`). Stop after staging and let the user continue.
- Never resolve a whole file with `--ours` or `--theirs` unless your hunk analysis shows that one side's changes are fully contained in the other's, and say so.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Resolutions
A table with one row per hunk: `path:line` | ours intended | theirs intended | resolution | confidence (high, medium, low).
## Verification
The build and test commands you ran and their real results, plus any semantic conflicts you found outside the markers.
## Needs your decision
Each contradictory hunk: the two behaviours in one sentence each, and the question to answer. Write "None" if there are none.
End with the command the user should run next (for example `git rebase --continue`).
````
---
## Set up commit signing
`set-up-commit-signing` · prompt · Git and version control · https://hermes-ide.com/prompts/set-up-commit-signing
Sets up commit and tag signing with SSH or GPG keys step by step, with hosting-side verification, CI bot signing, and how a signature differs from a DCO sign-off. Use when signing is required.
````markdown
The user's project requires signed commits, or they want their commits marked as verified. People confuse three things: a cryptographic signature (proves the commit came from a key you control), the `Signed-off-by` trailer added by `git commit -s` (a Developer Certificate of Origin statement, no cryptography), and the author email (anyone can set it). Setups fail in predictable places: the signing key is not added to the hosting account as a signing key, the commit email does not match a verified email on the account, the GPG agent cannot prompt for a passphrase, or CI bots commit unsigned.
Operating system: [OS]
Method: ssh
Guide the setup one step per turn, waiting for the user's result each time.
1. Open with one line on the plan (about 6 steps) and the difference between signing and sign-off in two sentences. Ask for `git --version` (SSH signing needs git 2.34 or later) and whether they already have a key of this type.
2. Steps for **ssh**:
1. Create or reuse a key: `ssh-keygen -t ed25519 -C ""`; a separate signing key is fine.
2. Configure git: `git config --global gpg.format ssh`, `git config --global user.signingkey `, `git config --global commit.gpgsign true`, `git config --global tag.gpgsign true`.
3. Local verification: create `~/.config/git/allowed_signers` with ` ` and set `gpg.ssh.allowedSignersFile`, so `git log --show-signature` works locally.
4. Hosting: add the public key to the account as a **signing key** (it is a separate type from an authentication key on most services), and make sure the commit email is verified on the account.
3. Steps for **gpg**:
1. Install GnuPG for [OS] (Gpg4win on Windows, GnuPG via Homebrew plus a pinentry program on macOS, the package manager on Linux).
2. `gpg --full-generate-key` (ed25519 or RSA 4096, an expiry date, the commit email as a UID), then `gpg --list-secret-keys --keyid-format=long` to get the key id.
3. `git config --global user.signingkey `, `commit.gpgsign true`, `tag.gpgsign true`, and `gpg.program` if git cannot find gpg on [OS].
4. Export the public key with `gpg --armor --export ` and add it to the hosting account; back up the private key and a revocation certificate somewhere safe offline.
4. Test: make a commit, run `git log --show-signature -1`, push to a branch, and check the hosting site shows the commit as verified. Sign a tag with `git tag -s`.
5. Ask whether CI bots or automation commit to the repo. If yes, explain the options: the hosting service's own signed commits when changes are made through its API, or a dedicated bot key stored as a CI secret, never a person's key.
6. If the project requires a DCO, explain `git commit -s` adds the sign-off, that `format.signOff` only affects `format-patch` and not commits, and suggest an alias such as `git config --global alias.cs "commit -s"`. Signing and sign-off are independent; many projects need both.
7. If any step fails, diagnose from the pasted output before continuing.
- One step per turn; give only [OS] commands and only the ssh path unless the user switches.
- Never ask the user to paste a private key, passphrase or full secret key listing. Public keys and key ids are fine.
- Do not invent hosting menu paths; name the setting ("SSH and GPG keys", "signing key") and say to look for the current label.
- Be precise about what verification proves and what it does not (it does not prove the code is safe).
Each turn: the step, one sentence of why, a command block, what success looks like.
At the end:
## Setup summary
A checklist of the steps, done or skipped.
## Your signing config
The expected `git config --global --get-regexp '^(gpg|user.signingkey|commit.gpgsign|tag.gpgsign)'` output with placeholders.
## Troubleshooting
Bullets for the three most likely failures for this method and [OS]: unverified badge, email mismatch, agent or pinentry problems.
````
---
## Set up Git LFS
`set-up-git-lfs` · prompt · Git and version control · https://hermes-ide.com/prompts/set-up-git-lfs
Sets up Git Large File Storage for a repository with tracking patterns, optional migration of existing large files, CI and clone settings, and storage and bandwidth quota considerations.
````markdown
Git LFS replaces large files in the repository with small pointer files and stores the content on an LFS server. Set up badly, it causes more pain than it removes: patterns that miss files or catch source code; `.gitattributes` committed after the files, so they stay in normal history; contributors without LFS installed committing raw binaries or pointer files; CI downloading gigabytes on every job; hosting quotas for storage and bandwidth exhausted without warning; and history rewrites done without warning that strand everyone's local clones and open pull requests. Tracking only affects new commits. Moving files already in history requires a rewrite, which is a team decision.
Plan the Git LFS setup for these files: [FILE_TYPES]
Repository: [REPO_SIZE]
History rewrite agreed: false
1. Decide what belongs in LFS. Recommend LFS for large binaries that change (art, audio, video, models, compiled assets that must be versioned). Say when something should not be in Git at all (build outputs, generated files, very large datasets better kept in object storage or a data versioning tool) and when small text formats should stay as normal files.
2. Write the tracking patterns as `.gitattributes` lines, as specific as possible (by extension and, where useful, by directory). Mark files that cannot be merged as lockable if the team edits them concurrently, and explain file locking briefly.
3. Give the setup steps in order: install and `git lfs install` for every contributor, add the patterns with `git lfs track`, commit `.gitattributes` before or with the first large file, and verify with `git lfs ls-files` and `git lfs status`.
4. Existing large files:
- If false is false: do not rewrite. New versions go to LFS from now on, and existing history keeps its size. Show how to find the largest blobs in history so the team can decide later, and what a rewrite would involve.
- If true: give the rewrite plan with `git lfs migrate import` (with `--include` patterns and `--everything` or specific refs), preceded by a full mirror backup, a freeze on merges, and followed by force-pushing all branches and tags, every contributor re-cloning, and open pull requests being recreated. Note that the old objects stay on the host until it garbage collects them, so the quota may not drop immediately.
5. CI and clones: how to skip or limit LFS downloads in jobs that do not need the files (for example `GIT_LFS_SKIP_SMUDGE=1` then `git lfs pull --include` for the paths a job needs), caching LFS objects between runs, and partial clone or sparse checkout for contributors who need only part of the repository.
6. Quotas and cost: explain that LFS hosting usually meters storage and bandwidth separately, that every CI checkout counts toward bandwidth, and that deleting a file in a commit does not free LFS storage. Tell the user to check their host's current limits rather than relying on numbers from you.
7. Add a team checklist and a safeguard against raw binaries sneaking in (a pre-commit or server-side check for files over a size limit, or a CI check that tracked patterns are pointers).
If [FILE_TYPES] does not say which file types or rough sizes are involved, ask for that and stop, because the patterns depend on it.
- Do not recommend a history rewrite unless false is true, and even then present it with its backup and coordination steps, never as a quick command.
- Do not state current quota figures or prices for any host; tell the user where to check.
- Keep commands copy-pasteable and in a safe order.
## Recommendation
What goes into LFS, what does not, and why, in a short paragraph.
## Tracking patterns
The `.gitattributes` content in a fenced block.
## Setup steps
Numbered commands with one line each on what they do.
## Existing files
The path chosen (no rewrite, or rewrite plan) with steps.
## CI and clones
Configuration snippets and guidance.
## Quotas and cost
What to check and how to keep usage down.
## Team checklist
Checkboxes for every contributor and for the maintainer.
## Risks
What can go wrong and how to detect it.
````
---
## Set up git on a new machine
`set-up-git-on-new-machine` · prompt · Git and version control · https://hermes-ide.com/prompts/set-up-git-on-new-machine
Walks through a clean git setup on a new computer one step at a time, covering identity, default branch, editor, SSH key or credential helper, line endings and a test push, verifying each step.
````markdown
The user has a new computer and wants git set up properly once, without copying a wall of commands they do not understand. They may be a student, a new developer or a designer. Problems later usually trace back to setup: commits under the wrong email, passwords rejected because hosting services require tokens or SSH, Windows line endings rewriting whole files, or an editor that opens Vim when they have never used it. You guide one step at a time and verify each before moving on.
Operating system: [OS]
Hosting: not stated; ask before the authentication step
Run the setup as a short guided session.
1. Open with one line on what you will set up (about 10 minutes, 7 steps) and ask the first question: is git already installed? Have them run `git --version`.
2. Go through these steps in order, one per turn. For each: say why in one sentence, give the command for [OS] in a code block, say what success looks like, and wait for the user to paste the result or say done.
1. **Install or update** git for [OS] (the official installer on Windows with sensible defaults, Homebrew or the Xcode command line tools on macOS, the distribution's package manager on Linux).
2. **Identity:** `git config --global user.name` and `user.email`. Explain that the email should match the hosting account so commits are linked, and mention the hosting service's private no-reply address as an option for privacy. For separate work and personal identities, offer `includeIf` per folder.
3. **Defaults:** `init.defaultBranch main`, `pull.rebase false` or `true` with a one-line explanation of the choice, `fetch.prune true`.
4. **Editor:** set `core.editor` to an editor they already use (for example `"code --wait"`), so commit messages do not drop them into an unfamiliar editor.
5. **Line endings:** Windows `core.autocrlf true`; macOS and Linux `core.autocrlf input`; mention that a repo's `.gitattributes` overrides this and is the better long-term fix.
6. **Authentication** for not stated; ask before the authentication step: recommend SSH keys (`ssh-keygen -t ed25519 -C ""`, add to the agent, copy the public key, add it in the hosting settings, test with `ssh -T`) or HTTPS with the credential manager. Explain that account passwords no longer work for git over HTTPS on most hosts and a token or credential manager is needed. If hosting is empty, ask which service they use before this step.
7. **Test:** clone a repository they own (or create a test one), make a small commit, push it, and check it appears on the hosting site with their name.
3. Offer two or three safe aliases as optional (`git config --global alias.st status`, `alias.lg "log --oneline --graph --decorate -20"`). Skip anything that changes behaviour silently.
4. If a step fails, diagnose from the pasted output before moving on. Do not skip ahead.
5. When finished or when the user says "stop", give the summary.
- One step per turn. Wait for the result before the next step.
- Only give commands for [OS]. Use the shell they will actually use (PowerShell or Git Bash on Windows; say which).
- Never ask the user to paste a private key, token or password. Only the public key (`.pub`) is ever shared.
- Do not invent menu paths in hosting settings that may have changed; describe them generally ("Settings, then SSH keys") and say to look for the current label.
- Plain language; explain each term once.
Each turn: the step name, one sentence of why, the command block, what success looks like.
At the end:
## Setup summary
A checklist of the steps with done or skipped.
## Your config
The expected output of `git config --global --list` with their values (email partly masked).
## Next steps
Two or three bullets: for example commit signing, a global ignore file, learning branches.
````
---
## Set up shared git hooks
`set-up-git-hooks` · prompt · Git and version control · https://hermes-ide.com/prompts/set-up-git-hooks
Sets up git hooks a whole team gets automatically, covering formatting, linting, secret scanning and commit messages, kept fast and mirrored in CI. Use when bad commits keep reaching review.
````markdown
Git does not version the `.git/hooks` folder, so hooks only reach a team through a hook manager committed to the repository and installed automatically during setup. Hooks fail teams in two ways: they are slow (running the whole test suite on every commit), so people learn to skip them with `--no-verify`; or they are the only enforcement, so anything skipped reaches main. Fast hooks on staged files catch mistakes early; CI runs the same checks and is what actually enforces them. Secret scanning belongs in the pre-commit stage, because a secret in a pushed commit has to be rotated, not just removed.
Set up shared git hooks for:
[STACK]
1. If you can read the repository, find the existing formatters, linters, their configs and any hook setup, and reuse them. If no tool is given, choose one in a sentence: Husky with lint-staged for JavaScript-first repositories, pre-commit for Python or mixed-language repositories, Lefthook when speed or a polyglot monorepo matters.
2. Hooks:
- **pre-commit**: format and lint only staged files, auto-fixing where the tool can and re-staging the fixes; scan staged changes for secrets (gitleaks or detect-secrets with a committed baseline); block files over a size limit and merge conflict markers. Target under five seconds on a typical commit.
- **commit-msg**: enforce the team's message convention (for example Conventional Commits with commitlint) only if the team has one; otherwise ask.
- **pre-push** (optional): type check or a fast test subset, under a minute; skip if CI covers it cheaply.
3. Pin every hook and tool version in config so everyone runs the same thing.
4. Automatic install: a `prepare` script, a setup or bootstrap command, or documented `pre-commit install`, depending on the tool. Make it work on macOS, Linux and Windows (Git Bash or WSL), and inside dev containers if the team uses them.
5. CI parity: a CI job that runs the same checks on all changed files (for pre-commit, `pre-commit run --all-files` or on the diff), so skipped hooks are still caught.
6. Document the escape hatch (`--no-verify` for emergencies) and how to update the secret-scanning baseline after a false positive.
- Never run the full test suite or network-dependent checks in pre-commit.
- Hooks must not change files that are not staged.
- Do not add a second formatter or linter that overlaps with existing ones.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Choice
Tool and why, in one or two sentences.
## Hooks
Table: hook, checks, scope (staged or all), expected time.
## Config files
Fenced blocks with file paths.
## Team setup
What a new teammate runs, and what happens automatically.
## CI parity
The CI job snippet.
## Troubleshooting
Bullets: slow hooks, Windows line endings or paths, false positives in secret scanning, bypassing in an emergency.
````
---
## Split a large pull request into a stack
`split-large-pull-request` · prompt · Git and version control · https://hermes-ide.com/prompts/split-large-pull-request
Splits a large pull request into a stack of small, independently reviewable PRs with their order, dependencies and the branch commands to build them. Use when a PR is too big to review well.
````markdown
Review quality drops sharply as pull requests grow: big PRs get skimmed and approved, and their defects ship. Most large PRs combine several kinds of change that can be reviewed separately: mechanical changes (renames, moves, formatting, generated code), preparatory refactors, new code that is not yet called, schema or infrastructure changes, and the behaviour change itself. Split along those lines, each PR has one purpose, builds and passes tests on its own, and can merge independently or as a short stack.
Propose how to split this pull request:
[DIFF_SUMMARY]
1. Inventory the changes, grouping files and hunks by kind: mechanical, preparatory refactor, new isolated code (not yet wired in), schema or migration, configuration or infrastructure, behaviour change, tests, docs. Note which groups depend on which.
2. Propose the stack, usually in this order: mechanical changes; preparatory refactors with no behaviour change; additive schema changes (expand) and new code behind a flag or not yet called; the behaviour change that wires it in; clean-up and contract steps. Each PR must compile and pass tests on its own, contain the tests for its own code, and have a single purpose stated in its title. Aim for each PR to be reviewable in under 30 minutes; say when a PR stays large and why that is acceptable (for example a generated file or a pure rename).
3. Mark which PRs are independent (can branch from main and merge in any order) and which must stack.
4. Give the commands to build the branches from the existing one without rewriting it: create each branch from the right base and bring over files with `git restore --source= -- ` or hunks with `git checkout -p -- `, then commit. For stacked branches, show how to keep them in sync when an earlier PR changes: `git rebase --update-refs` (Git 2.38 or newer) or `git rebase --onto`.
5. Describe how to verify the split lost nothing: the tip of the stack must have no diff against the original branch.
6. Write the merge plan: order, what each reviewer should focus on, and whether to retarget each PR to main after its parent merges.
- Base the plan on the files and changes in the input. If you only have a file list, say which groupings are guesses and ask for the diff of the files that matter.
- Keep anything that must change atomically in the same PR (a schema change and the code that requires it in the same deploy, a public API change and its callers in the same repository) and say why.
- Do not suggest splitting tests from the code they verify unless the team asks for it.
## Change inventory
Table: Group | Kind | Files | Approx. lines | Depends on.
## Proposed stack
Table: Order | PR title | Contents | Base branch | Independent or stacked | Reviewer focus.
## Branch commands
Code block with the commands to create each branch, plus the final check that nothing was lost.
## Merge plan
Numbered merge order and retargeting steps.
## What stays together
Bullets: changes that must stay in one PR and why.
````
---
## Write a .gitignore file
`write-gitignore-file` · prompt · Git and version control · https://hermes-ide.com/prompts/write-gitignore-file
Writes a commented .gitignore for a stack and toolchain, keeps personal editor files in a global excludes file, never ignores lockfiles, and shows how to untrack files already committed.
````markdown
The user is starting a repository or cleaning one up. Copy-pasted mega-templates ignore hundreds of things the project never produces and sometimes ignore things that must be committed (lockfiles, `.env.example`, IDE settings the team shares). A good .gitignore lists only what this stack generates, is grouped and commented, keeps each developer's editor and OS files out of the shared file, and comes with the commands to stop tracking files already committed, since .gitignore does not affect tracked files.
Stack: [STACK]
Tools and problems:
1. List what the stack and tools generate or download: dependency folders (`node_modules/`, `.venv/`, `vendor/` when not vendored on purpose), build output (`dist/`, `build/`, `target/`, `bin/` and `obj/`), caches (`__pycache__/`, `.pytest_cache/`, `.gradle/`, `.next/`), test and coverage output, logs, local environment and secret files (`.env`, `.env.local`, `*.pem`, `*.tfstate` and `.terraform/`), and engine or tool folders (for example Unity `Library/`, `Temp/`, `Logs/`).
2. Write the .gitignore grouped by section with a one-line comment each. Use anchored patterns (`/dist/`) when the folder only exists at the root, and trailing slashes for directories.
3. Keep tracked, and say so in a comment: lockfiles (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `poetry.lock`, `uv.lock`, `Cargo.lock` for applications, `go.sum`, `Gemfile.lock`), example env files (add `!.env.example`), shared editor config the team agrees on (for example `.vscode/extensions.json`, `.editorconfig`), and engine files that must be versioned (Unity `.meta` files).
4. Put OS and personal editor files (`.DS_Store`, `Thumbs.db`, `.idea/` if not shared, `*.swp`) in a personal global excludes file instead, with the commands: `git config --global core.excludesFile ~/.gitignore_global`, then create that file. If the team prefers them in the repo file, add a short commented section.
5. For files already committed that should now be ignored, give `git rm -r --cached ` followed by a commit. Warn that when teammates pull that commit, git deletes those files from their working copies, so anyone who needs a local copy (for example their own `.env`) should back it up first; and that secrets already committed must be rotated and purged from history, not just untracked.
6. Give a check: `git status --ignored` and `git check-ignore -v ` to see which rule matches.
- Include only patterns this stack and these tools produce; no generic 300-line template.
- Never ignore lockfiles for applications, and never ignore files the build needs.
- If the stack is too vague to know what it generates (for example "web app"), ask for the languages and package managers and stop.
- Do not invent tool names or folder names; if unsure whether a tool writes a folder, mark the line with a `# check:` comment.
## .gitignore
One code block, grouped and commented.
## Personal ignores
The `core.excludesFile` command and a short code block for the global file.
## Already committed files
Commands, plus the warning about secrets, or "Nothing to untrack" if none were mentioned.
## Check
The two verification commands and what to look for.
````
---
## Write a CODEOWNERS file
`write-codeowners-file` · prompt · Git and version control · https://hermes-ide.com/prompts/write-codeowners-file
Writes a CODEOWNERS file from the repository layout and team structure, with ordered ownership rules, fallbacks, protection for sensitive paths and a check for files nobody owns.
````markdown
A CODEOWNERS file routes reviews and, with branch protection, decides who must approve a change. Common mistakes defeat it: rules in the wrong order (the last matching pattern wins for a path, on GitLab within each section, so a broad rule at the bottom overrides every specific rule above it); handles of teams that lack write access, which the platform silently ignores; one person owning everything, which blocks every merge while they are away; no owner for CI workflows, infrastructure or the CODEOWNERS file itself, which lets anyone change the rules; and paths that match nothing, so changes merge without the right review.
Write a CODEOWNERS file for this repository on github.
Layout notes: [LAYOUT]
Teams and ownership: [TEAMS]
1. Read the actual repository tree (for example `git ls-files` and a directory listing to depth two or three) and any existing CODEOWNERS file. Prefer what is in the repository over the notes when they disagree, and report the difference. If a CODEOWNERS file already exists, edit it rather than replacing it, and keep rules that are still valid.
2. Build an ownership map: each meaningful path, its owning team, and a second owner or team where possible so no path depends on one person.
3. Write the file in github syntax and in the right place (`.github/CODEOWNERS` on GitHub, `.gitlab/CODEOWNERS` or the repository root on GitLab, or wherever the repository already keeps it):
- Order rules from general to specific: a catch-all default owner first, then directories, then specific files, because the last match wins.
- Use team handles rather than individuals wherever a team exists.
- Give explicit owners to sensitive paths: CI and workflow definitions, infrastructure and deployment config, dependency manifests and lock files where the team wants that, security-related code, and the CODEOWNERS file itself.
- On GitLab, use sections (with optional approval counts) where they help group rules; on GitHub, keep it a flat ordered list.
- Comment each block briefly with what it covers.
4. Check coverage: list every tracked path whose only owner is the catch-all rule, and every directory that matches no rule at all if there is no catch-all. Check handle formats and flag any handle you cannot confirm has write access (the platform ignores those).
5. If the platform's own CODEOWNERS validation is available to you (for example the error view on GitHub, or a CLI or API check), use it; otherwise say that the platform check still has to be done after pushing.
6. Recommend branch protection settings that make the file enforceable (require review from code owners, and the approval count), but do not change repository settings yourself.
- Write only the CODEOWNERS file. Do not change branch protection, team membership or other files.
- Do not invent team handles. If a path has no clear owner in the notes or history, assign it to the catch-all owner and list it under Open questions.
- Do not commit or push; leave the change in the working tree for review.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Ownership map
| Path | Owners | Backup | Source (notes, history or assumption) |
## CODEOWNERS
The complete file in a fenced block, with its path.
## Unowned paths
Paths that fall through to the catch-all or match nothing.
## Branch protection settings
The settings to enable, as a short list for the repository admin.
## Open questions
Paths with unclear ownership and handles to confirm.
## Verification
Commands run, what the coverage check found, and whether a platform validation was run.
````
---
## Write a commit message
`write-commit-message` · prompt · Git and version control · https://hermes-ide.com/prompts/write-commit-message
Writes a commit message that states what changed and why, in the repo's own convention, and flags staged changes that should be split. Use before committing.
````markdown
A commit message is read months later by someone running `git log`, `git blame` or `git bisect` who needs to know why a line exists. The subject says what changed in words a reader can scan; the body says why, because the diff already shows how. A message that narrates the diff, or one that bundles unrelated changes behind "and", fails that reader.
Write a commit message for this change:
If no change is given above, read the staged changes (`git diff --staged`). If nothing is staged, say so in one line and stop.
1. Read the whole diff and name its single purpose in one sentence. If the diff mixes unrelated purposes (a fix plus a refactor, two features), do not write one message. Propose a split instead: list each commit with its files or hunks and its subject line.
2. Pick the convention: match-repo.
- `match-repo`: read the last 20 subjects (`git log --format=%s -20`) and copy their pattern: type prefixes, scopes, capitalisation, ticket references. If there is no history or no clear pattern, use `plain`.
- `conventional`: Conventional Commits 1.0.0. `type(scope): description`, with type one of feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Use the scope only if the repo has clear modules. Mark a breaking change with an exclamation mark before the colon (`feat(api)!: ...`) and a `BREAKING CHANGE:` footer that says what users must do.
- `plain`: a capitalised imperative subject with no prefix.
3. Subject: imperative mood ("Fix", not "Fixed" or "Fixes"), names the thing that changed, no trailing period, at most 72 characters and ideally under 50.
4. Body, after one blank line, wrapped at 72 characters: the problem, why this approach, and any side effect or follow-up a reviewer must know. Skip the body when the subject says everything (typo fixes, version bumps).
5. Footers only for facts you have: issue references from the input, `BREAKING CHANGE:`, or trailers the repo already uses.
- Never invent a reason, ticket number, issue link, benchmark or test result. If the motivation is not in the diff or the input, write a body with only what the diff proves and add one line after the message asking for the reason.
- Do not add tool or assistant attribution trailers (such as `Co-authored-by`) unless the author asks.
- Do not run `git commit` or change the index. Output the message only.
- Describe behaviour, not files: "Reject expired tokens at login" beats "Update auth.ts".
The message inside one fenced `text` block, exactly as it should be committed.
After the block, at most two lines starting with `Note:` for a proposed split or missing information. Nothing else.
For a split, output one fenced block per proposed commit, each preceded by the files or hunks it contains.
Input: a diff that changes `retry.ts` so that `fetchWithRetry` stops retrying on HTTP 4xx responses, with a new test.
```text
Stop retrying client errors in fetchWithRetry
A 4xx response means the request itself is wrong, so retrying it only
adds latency and load: a bad token was retried 5 times per call before
failing. Retry only network errors and 5xx responses, and add a test
that a 401 fails on the first attempt.
```
````
---
## Write a pull request description
`write-pr-description` · prompt · Git and version control · https://hermes-ide.com/prompts/write-pr-description
Writes a pull request description that tells reviewers why the change exists, what to look at first, how to test it and what could break. Use when opening a PR.
````markdown
A PR description is for the reviewer, who has less context than the author and limited time. A good one answers, in order: what does this do, why now, where should I look first, how do I know it works, and what could go wrong. It is not a changelog of every file and not a sales pitch. Its length should follow the size and risk of the change: two lines for a typo fix, a full page for a migration.
Write the description for . If no change is given, diff the current branch against the default branch (`git merge-base` with `origin/HEAD`, then `git diff` and `git log` from there).
1. Read every commit message and the full diff before writing. Check the repo for a PR template (`.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE/`, `docs/`) and use it if one exists.
2. State the purpose in one or two sentences a reviewer could repeat.
3. Group the changes by intent, not by file. Point to the one or two places that carry the risk ("start with `billing/proration.ts`; the rest is wiring").
4. Write test steps a reviewer can follow: commands, inputs and expected results. Include only tests and checks you can see in the diff or the input.
5. List what could break: behaviour changes, migrations, config or environment changes, feature flags, performance, and how to roll back.
- Never claim that tests pass, that something was tested manually, or that metrics improved unless the input says so. Write `TODO(author): ...` for anything only the author can confirm.
- Link issues only when the id appears in the branch name, commits or input. Never invent one.
- Call out breaking changes and required deploy steps (migrations, new env vars) at the top of Risks, in bold.
- No filler ("This PR aims to..."), no restating the title, no emoji unless the template uses them.
- Do not create or edit the PR yourself; output the text.
First line: a proposed PR title in the repo's commit style, under 72 characters.
Then, unless a template replaces them, these sections, omitting any that would be empty for a small change:
## Summary
One or two sentences.
## Why
The problem or ticket, with the link if known.
## Changes
Bullets grouped by intent. Name the files to review first.
## How to test
Numbered steps with expected results.
## Risks
Breaking changes, migrations, rollout and rollback, or "Low: ..." with the reason.
````