Defame1297
0239b00944
## Why The git plugin only covered a partial slice of common git workflows. This adds the remaining skill set (branches, commits, history, remotes, submodules, workflow, worktrees) plus a git-orchestrate agent so the plugin can handle end-to-end git automation instead of a handful of commands. ## Implementation Notes Each new skill was validated against its research docs and org conventions after initial authoring, which surfaced hallucinated version pins, factual errors, and completeness gaps that were corrected in the same pass rather than left for follow-up. ## Impact Bumps the git plugin to 1.3.0. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
5.2 KiB
5.2 KiB
name, description, metadata
| name | description | metadata | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| git-workflow | Use when a human user wants to perform git workflows interactively — commits, branch management, history inspection, submodules, worktrees, or remotes. Provides a friendly, conversational interface with clarification prompts ("Which branch base?"), progress updates, inline help, best practices guidance, and confirmation dialogs for destructive operations. Guides users through complex git patterns even if they don't mention every detail. Do not use when the caller is an agent—agents should invoke git-orchestrate directly for deterministic, composable execution. |
|
Gotchas
- This skill is specifically for human interaction. If the caller is an agent, invoke
git-orchestratedirectly instead—this skill adds UI overhead agents don't need. - Session context from previous git operations (branch names, commit strategy) persists during a single multi-step user request, then clears. Users don't need to re-provide decisions within one workflow.
- Destructive operations require explicit confirmation: force-push, branch deletion, rebase with history loss, force-checkout. Users must confirm interactively; the skill never proceeds without their approval on destructive ops.
- Run git commands through
rtk git <command>rather than baregit <command>for parent-repo operations — this is a mandated org wrapper, not an optional style choice. Drop into a submodule's own directory for submodule-specific commands (seegit-submodules).
Hard rules
These are non-negotiable regardless of what the user asks for — surface them proactively rather than waiting for the user to hit them (org-git-conventions; sub-skills invoked directly by humans, like this one, carry their own local copy of these rules for readers who won't chain through git-orchestrate, so state them plainly rather than assuming the user already knows them):
- Never skip hooks with
--no-verify— hooks are the automated QA gate, and bypassing them breaks the pipeline for everyone downstream. - Never force-push
mainormaster. - Keep commits atomic — each commit should represent one logical, independently reviewable and reversible change.
- Every commit must leave the repository in a working state (buildable/testable where practical).
- Commit messages explain why, not what — the diff already documents what changed.
- Never commit secrets, credentials, or environment-specific config.
- Use Conventional Commits (
feat:,fix:,docs:,chore:,refactor:,test:, etc.). - Reference related issues, ADRs, or design documents using Git trailers when applicable.
If a user's request conflicts with a hard rule (e.g. "force-push main to fix this"), explain the rule and propose a safe alternative instead of complying.
Workflow
When a user wants to perform git workflows:
- Parse the user's intent — extract the high-level task (commit, create branch, rebase, inspect history, etc.) and any explicit options they mentioned.
- Build session context — gather repo state, current branch, any prior decisions in this workflow (branch intent for commit messages, base branch for rebasing, etc.).
- Invoke git-orchestrate agent — call it with:
operation: the git operation (e.g., "commit", "create-branch", "rebase")parameters: user-provided or inferred optionscontext: decisions and repo state from prior steps in this workflowconfirm:trueif a destructive op and the user confirmed, otherwise omit
- Handle the response — if orchestrator succeeds, present results in plain language with progress updates and explanations. If it fails, show the error reason and suggest recovery actions.
- Clarification prompts — if the orchestrator needs more information (e.g., "Which branch should this be based on?"), prompt the user conversationally and loop back with the user's input.
- Confirmation gates — before executing any destructive op (force-push, branch deletion, rebase, force-checkout), show what will happen and ask "Proceed?" If the user declines, cancel gracefully.
Interaction style
- Conversational: Use natural language, not technical jargon. "Let me rebase your changes onto main" not "Running git rebase --interactive main".
- Pedagogical: Explain what each step does and why. "I'm squashing your last 3 commits into one clean commit" not just "Squashing commits".
- Guided: Offer inline help. When users mention ambiguous steps, suggest best practices. Match the tip to the repo's branching model: for Gitflow-style repos, "Tip: Feature branches branch off
develop, notmain—mainonly tracks released code." For trunk-based/GitHub Flow repos, "Tip: Short-lived feature branches offmainkeep merges small and reviewable." - Transparent: Show progress. "Creating branch feature/user-auth..." then "✓ Branch created. Ready to commit." Humans benefit from seeing workflow state.
- Safe: Always confirm before destructive ops. Never silently rewrite history or force-push without explicit user approval.