Defame1297
3c74beb280
Description 566 -> 249 chars, body 644 -> 398 words, Gotchas 12 -> 2. The eight organisational hard rules move to references/hard-rules.md. Its load trigger enumerates operations rather than rule topics: the first draft keyed on 'commit message form', which left the atomicity and working-state rules unreachable when a caller supplied a conventional message. Also promotes the destructive-op confirmation ahead of the orchestrator invocation, which it previously followed.
3.0 KiB
3.0 KiB
name, description, metadata
| name | description | metadata | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| git-workflow | 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`. |
|
Gotchas
- 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 baregit <command>. This is a mandated org wrapper, not a style preference. Submodule-specific commands run from inside the submodule's own directory instead.
Workflow
- Parse intent — extract the operation (commit, create branch, rebase, inspect history, …) and any options the user named.
- 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. - Read the repo — current branch, working-tree state, and which branching model the repo
follows (the orchestrator reads
branching_patternfrom plugin config; infer from branch names if absent); the last of those decides which tips are worth offering. - 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
mainormaster. - Invoke the
git-orchestrateagent withoperation,parameters(user-provided or inferred),context(step 3 plus the session context), andconfirm: trueonly for a destructive op the user approved in step 4. - 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.
- Report the outcome — on success, the result and what changed, in plain language; on failure, the error reason and a recovery action.
Interaction style
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.