tomevault-io GitHub Workflow
This skill guides the process of moving local changes to a GitHub Pull Request.
Prerequisites
gitmust be installed and configured.gh(GitHub CLI) must be installed and authenticated.
Commit Message Format
Use Conventional Commits with this required format:
<type>(<scope>): <summary>
typeREQUIRED. Common values:feat,fix,docs,refactor,chore,test,perf,ci,build,style.scopeREQUIRED. Short noun for the changed area (for example:config,api,ui,docs).summaryREQUIRED. Imperative, <= 72 chars, no trailing period.
Rules:
- Never add AI attribution anywhere in the GitHub workflow. Do not write
Generated by ...,Co-authored-by: Claude,Co-authored-by: Opus,Co-authored-by: Sonnet, or any other AI/model/agent attribution. - This ban applies to commit subjects, commit bodies, commit footers, PR titles, PR bodies, and PR comments. Do not add it even if a default template, tool, model habit, or previous workflow suggests it.
- Do not add sign-offs or breaking-change footers unless the user requests them.
Workflow Steps
Follow this order exactly: confirm branch state, stage, commit, push, then handle the PR.
Branch Check / Creation
- Check the current branch before doing anything else.
- If already on a suitable non-default working branch, stay on it.
- If on a default branch such as
mainormaster, create a feature branch first. - Identify the scope of changes (e.g.,
feat,fix,docs,chore). - Propose a branch name following the pattern
<type>/<kebab-case-description>. - Execute when a new branch is needed:
git checkout -b <branch-name>
Review & Stage Changes
- Review changes with
git statusandgit diff. - By default, stage only the files that belong to the current requested change.
- If the user provided file paths/globs, stage only those files.
- If there are ambiguous extra changed files, ask before staging/committing and leave them unstaged unless the user explicitly includes them.
- Stage the intended files with
git add .... - Optionally inspect recent subjects for local scope patterns:
git log -n 10 --pretty=format:%s.
- Review changes with
Commit
- Propose a message in exact format:
<type>(<scope>): <summary>. - Execute:
git commit -m "<message>" - If pre-commit hooks fail, diagnose and fix the issues before re-staging and re-committing.
- Do not move on to PR actions until the commit succeeds.
- Propose a message in exact format:
Push
- Push the committed branch to the remote before any PR creation or review trigger.
- If this is the first push for the branch, use:
git push -u origin <branch-name> - If the upstream is already set, use:
git push - Never post
/gemini reviewbefore the push succeeds for the latest commit.
Pull Request Handling
- Only after a successful push, check whether a PR for the current branch already exists.
- Use
gh pr view --json url,number,headRefNameto detect an existing PR for the checked-out branch. - If no PR exists:
- Create the PR using
gh pr create. - Provide a concise title (often the commit message) and a body summarizing the changes.
- Execute:
gh pr create --title "<title>" --body "<body>" - Share the generated PR URL with the user.
- Create the PR using
- If a PR already exists:
- Do not open a duplicate PR.
- After the push succeeds, add a PR comment containing exactly
/gemini reviewto trigger the code quality review. - Execute:
gh pr comment <number-or-url> --body "/gemini review" - Share the existing PR URL with the user and mention that the review trigger comment was added after pushing the new commit.
Common Failures
- Pre-commit hooks: If hooks fail, fix the files and stage them again before committing.
- Untracked files: Ensure new files are added.
- Remote branch already exists: If the branch exists, ask the user if they want to overwrite or use a different name.
Source: mfmezger/ai_agent_dotfiles — distributed by TomeVault.