refactor(git-workflow): retrofit to the ADR-0020 context contract

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.

plugins/git/.apm/skills/git-workflow/SKILL.md

@@ -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.