|
|
|
|
@@ -2,12 +2,9 @@
|
|
|
|
|
name: git-workflow
|
|
|
|
|
|
|
|
|
|
description: >
|
|
|
|
|
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.
|
|
|
|
|
Use when a human wants to work through local git interactively — commits, branches, history,
|
|
|
|
|
submodules, worktrees, or remotes. Not an agent caller needing deterministic execution ->
|
|
|
|
|
`git-orchestrate`. Not server-side Gitea work -> `gitea-workflow`.
|
|
|
|
|
|
|
|
|
|
metadata:
|
|
|
|
|
category: git
|
|
|
|
|
@@ -21,45 +18,41 @@ metadata:
|
|
|
|
|
|
|
|
|
|
## Gotchas
|
|
|
|
|
|
|
|
|
|
- This skill is specifically for **human interaction**. If the caller is an agent, invoke `git-orchestrate` directly 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 bare `git <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 (see `git-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 `main` or `master`.
|
|
|
|
|
- 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.
|
|
|
|
|
- Session context built during one multi-step request — branch names, the chosen base, the commit
|
|
|
|
|
strategy — persists for that request and then clears. Do not re-ask the user for a decision they
|
|
|
|
|
already gave you earlier in the same workflow.
|
|
|
|
|
- Run parent-repo commands through `rtk git <command>`, never bare `git <command>`. This is a
|
|
|
|
|
mandated org wrapper, not a style preference. Submodule-specific commands run from inside the
|
|
|
|
|
submodule's own directory instead.
|
|
|
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
|
|
When a user wants to perform git workflows:
|
|
|
|
|
|
|
|
|
|
1. **Parse the user's intent** — extract the high-level task (commit, create branch, rebase, inspect history, etc.) and any explicit options they mentioned.
|
|
|
|
|
2. **Build session context** — gather repo state, current branch, any prior decisions in this workflow (branch intent for commit messages, base branch for rebasing, etc.).
|
|
|
|
|
3. **Invoke git-orchestrate agent** — call it with:
|
|
|
|
|
- `operation`: the git operation (e.g., "commit", "create-branch", "rebase")
|
|
|
|
|
- `parameters`: user-provided or inferred options
|
|
|
|
|
- `context`: decisions and repo state from prior steps in this workflow
|
|
|
|
|
- `confirm`: `true` if a destructive op and the user confirmed, otherwise omit
|
|
|
|
|
4. **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.
|
|
|
|
|
5. **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.
|
|
|
|
|
6. **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.
|
|
|
|
|
1. **Parse intent** — extract the operation (commit, create branch, rebase, inspect history, …)
|
|
|
|
|
and any options the user named.
|
|
|
|
|
2. **Check the hard rules** — if the request creates, amends, or rewrites a commit, pushes, or
|
|
|
|
|
touches hooks, config, or credentials, read `references/hard-rules.md`. Raise the relevant rule
|
|
|
|
|
before acting, not after.
|
|
|
|
|
3. **Read the repo** — current branch, working-tree state, and which branching model the repo
|
|
|
|
|
follows (the orchestrator reads `branching_pattern` from plugin config; infer from branch names
|
|
|
|
|
if absent); the last of those decides which tips are worth offering.
|
|
|
|
|
4. **Gate destructive operations** — before force-push, branch deletion, rebase, or
|
|
|
|
|
force-checkout, show what will happen and ask "Proceed?". Cancel gracefully if the user
|
|
|
|
|
declines. Never supply the confirmation on the user's behalf. Some operations are refusals, not
|
|
|
|
|
confirmations: never offer "Proceed?" for a force-push of `main` or `master`.
|
|
|
|
|
5. **Invoke the `git-orchestrate` agent** with `operation`, `parameters` (user-provided or
|
|
|
|
|
inferred), `context` (step 3 plus the session context), and `confirm: true` only for a
|
|
|
|
|
destructive op the user approved in step 4.
|
|
|
|
|
6. **Clarify when the orchestrator asks for more** — put its question to the user in plain
|
|
|
|
|
language ("Which branch should this be based on?") and loop back to step 5 with the answer.
|
|
|
|
|
7. **Report the outcome** — on success, the result and what changed, in plain language; on
|
|
|
|
|
failure, the error reason and a recovery action.
|
|
|
|
|
|
|
|
|
|
## 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`, not `main` — `main` only tracks released code." For trunk-based/GitHub Flow repos, "Tip: Short-lived feature branches off `main` keep 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.
|
|
|
|
|
The caller is a human, so the interaction is the point. Explain each step and why it happens ("I'm
|
|
|
|
|
squashing your last 3 commits into one clean commit" beats "Squashing commits"), show progress as
|
|
|
|
|
you go, and prefer natural language to raw command lines.
|
|
|
|
|
|
|
|
|
|
Match tips to the repo's branching model rather than offering generic advice: on a Gitflow repo,
|
|
|
|
|
feature branches come off `develop` and `main` tracks only released code; on a trunk-based or
|
|
|
|
|
GitHub Flow repo, short-lived branches off `main` keep merges small and reviewable.
|
|
|
|
|
|
