Straight to main

Straight to Main

Use this skill when the requested change is small enough to publish directly to the repository default branch, but the current checkout is dirty, on the wrong branch, or carrying drift from previous work.

Do not assume the default branch is named main. Determine it from the remote hosting provider, preferably with GitHub CLI for GitHub repositories.

Required Preflight

Before any command that changes history, reads or writes remotes, or depends on a hosting account:

1. Identify the active repository root with git rev-parse --show-toplevel.
2. Read the repository instructions, especially any AGENTS.md guidance for direnv, generated files, staging, and remote identity.
3. Check for an applicable .envrc in the repository root or parent path.
4. If .envrc exists and direnv is available, load it in the shell used for GitHub and git remote operations.
5. If direnv is blocked, stale, or not allowed, stop before remote or history-changing actions and ask the user how to proceed.
6. Verify identity before acting:
   • git config user.name
   • git config user.email
   • git remote -v
   • gh auth status or the relevant hosting CLI account
7. Continue only when the identity and remote match the intended repository account.

Never print secrets, tokens, private keys, or credential-helper output.

Default Branch Discovery

For GitHub repositories, use the active repository identity to ask GitHub for the default branch:

gh repo view --json defaultBranchRef --jq .defaultBranchRef.name

If the repository has a required direnv context for GitHub commands, run the query inside that context. For example:

direnv exec /path/to/repo gh repo view --json defaultBranchRef --jq .defaultBranchRef.name

If the hosting CLI cannot verify the default branch, stop before committing or pushing unless there is another authoritative repository source for the default branch.

Clean Worktree Path

Use a separate clean worktree when the current checkout has unrelated edits, is on a drifted branch, or has generated output that would mix with the requested change.

1. Confirm the current checkout's dirty state so unrelated edits are known and preserved.
2. Create a temporary worktree from the verified default branch.
3. Pull or fetch/rebase the temporary worktree so it is current with the remote default branch.
4. Apply only the requested small change in the temporary worktree.
5. Run the repository's required validation or build commands.
6. Inspect the diff and ensure only the requested source files and required generated follow-up files changed.
7. Stage explicit paths only; never use git add . or git commit -a.
8. Commit with the repository's existing message style.
9. Run git pull --rebase --autostash, then git push.
10. Check git status --short --branch.

When the temporary worktree lacks ignored local files such as .envrc, run hosting and push-sensitive commands through the original repository's direnv context, for example:

direnv exec /path/to/original/repo git -C /path/to/temp-worktree push

Cleanup

After a successful push:

1. Remove only this session's duplicated change from the original dirty checkout, if it was first applied there.
2. Leave unrelated existing edits and untracked files untouched.
3. Remove the temporary worktree.
4. Re-check the original checkout status and confirm it no longer contains the just-published change.

Do not reset, checkout, or delete unrelated local work unless the user explicitly asks for that cleanup.

Reporting

In the final response, include:

• The commit hash and message.
• The verified default branch name and how it was discovered.
• The files included in the commit.
• The validation/build command that passed.
• Whether the original drifted checkout was cleaned back to unrelated local changes only.