docs(git): delete unused git plugin config file and its read steps

Finding 21: `config.example.json` (and the never-tracked
`.claude/plugins/git/config.json` it documented) was read by
git-orchestrate and git-branches but written by nothing, and the
default-inference fallback (GitHub Flow, with Gitflow inferred from a
`develop`/`release/*` branch) already covered the no-config case.
Removed the config-read step from both, updated git-workflow's
description of the orchestrator to match, dropped the now-dangling
`applied_config` field from git-orchestrate's output shape, and
deleted the config file and its stale example reference in
docs/spec/architecture.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD

plugins/git/.apm/agents/git-orchestrate.agent.md

@@ -63,11 +63,10 @@ When invoked, you:
 1. Validate the request structure and check if operation is known
 2. Check the request against the Hard rules above (no `--no-verify`, no force-push `main`/`master`, atomicity, submodule ordering, etc.) — refuse outright on violation, independent of `confirm`
 3. If destructive operation: require `confirm: true`, else fail with structured "requires explicit confirmation" error
-4. Read plugin config from `.claude/plugins/git/config.json` if present — see `config.example.json` in the plugin root for the expected shape (`branching_pattern`, `commit_style`, `rebase_strategy`) — or fall back to sensible defaults
-5. Invoke the appropriate skill via `Skill` or direct bash call with the operation, parameters, context, and config. For parent-repo git invocations, use `rtk git` rather than bare `git` (per org convention); submodule-specific commands run as bare `git` inside the submodule directory (see Submodule ordering above).
-6. Catch and handle git errors: attempt automatic recovery (offer rebase strategies for conflicts, suggest `--force-with-lease` for rejections)
-7. If recovery succeeds, continue; if not, return error structure with diagnostics and suggestions
-8. Aggregate all outputs and return as structured JSON
+4. Invoke the appropriate skill via `Skill` or direct bash call with the operation, parameters, and context — each domain skill infers its own branching pattern and conventions (e.g. `git-branches` from `develop`/`release/*` branch presence) rather than reading shared config. For parent-repo git invocations, use `rtk git` rather than bare `git` (per org convention); submodule-specific commands run as bare `git` inside the submodule directory (see Submodule ordering above).
+5. Catch and handle git errors: attempt automatic recovery (offer rebase strategies for conflicts, suggest `--force-with-lease` for rejections)
+6. If recovery succeeds, continue; if not, return error structure with diagnostics and suggestions
+7. Aggregate all outputs and return as structured JSON
 
 ## Output
 
@@ -77,8 +76,7 @@ When invoked, you:
   "operation": "<operation_name>",
   "result": {
     "output": "<command output or result>",
-    "context": { "current_branch": "...", "workflow_intent": "..." },
-    "applied_config": { "commit_style": "...", "rebase_strategy": "..." }
+    "context": { "current_branch": "...", "workflow_intent": "..." }
   },
   "error": {
     "message": "<human-readable error>",

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

@@ -9,7 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
-  version: "1.0.2"
+  version: "1.0.3"
   category: git
   source_keys:
     - context7-git-htmldocs
@@ -26,7 +26,7 @@ metadata:
 
 ## Step 1 — Determine the branching pattern
 
-Read `branching_pattern` from the git plugin config (`.claude/plugins/git/config.json`; the plugin root's `config.example.json` shows the shape). Default: `github-flow`. With no config, infer Gitflow from the presence of a `develop` or `release/*` branch, and GitHub Flow otherwise.
+Infer the branching pattern from the repo: Gitflow if a `develop` or `release/*` branch exists, GitHub Flow otherwise (the default).
 
 The two patterns are not mixable, and the wrong merge rule silently damages history. If the action touches a base branch, a name prefix, or a merge rule, read `references/branch-patterns.md`.
 

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

@@ -8,7 +8,7 @@ description: >
   agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
 
 metadata:
-  version: "1.0.0"
+  version: "1.0.1"
   category: git
   source_keys:
     - nvie-gitflow-post
@@ -55,8 +55,8 @@ owns the request.
    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.
+   follows (`git-branches` infers this from branch names: Gitflow if `develop`/`release/*` exists,
+   GitHub Flow otherwise); 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

plugins/git/agents/git-orchestrate.agent.md

@@ -63,11 +63,10 @@ When invoked, you:
 1. Validate the request structure and check if operation is known
 2. Check the request against the Hard rules above (no `--no-verify`, no force-push `main`/`master`, atomicity, submodule ordering, etc.) — refuse outright on violation, independent of `confirm`
 3. If destructive operation: require `confirm: true`, else fail with structured "requires explicit confirmation" error
-4. Read plugin config from `.claude/plugins/git/config.json` if present — see `config.example.json` in the plugin root for the expected shape (`branching_pattern`, `commit_style`, `rebase_strategy`) — or fall back to sensible defaults
-5. Invoke the appropriate skill via `Skill` or direct bash call with the operation, parameters, context, and config. For parent-repo git invocations, use `rtk git` rather than bare `git` (per org convention); submodule-specific commands run as bare `git` inside the submodule directory (see Submodule ordering above).
-6. Catch and handle git errors: attempt automatic recovery (offer rebase strategies for conflicts, suggest `--force-with-lease` for rejections)
-7. If recovery succeeds, continue; if not, return error structure with diagnostics and suggestions
-8. Aggregate all outputs and return as structured JSON
+4. Invoke the appropriate skill via `Skill` or direct bash call with the operation, parameters, and context — each domain skill infers its own branching pattern and conventions (e.g. `git-branches` from `develop`/`release/*` branch presence) rather than reading shared config. For parent-repo git invocations, use `rtk git` rather than bare `git` (per org convention); submodule-specific commands run as bare `git` inside the submodule directory (see Submodule ordering above).
+5. Catch and handle git errors: attempt automatic recovery (offer rebase strategies for conflicts, suggest `--force-with-lease` for rejections)
+6. If recovery succeeds, continue; if not, return error structure with diagnostics and suggestions
+7. Aggregate all outputs and return as structured JSON
 
 ## Output
 
@@ -77,8 +76,7 @@ When invoked, you:
   "operation": "<operation_name>",
   "result": {
     "output": "<command output or result>",
-    "context": { "current_branch": "...", "workflow_intent": "..." },
-    "applied_config": { "commit_style": "...", "rebase_strategy": "..." }
+    "context": { "current_branch": "...", "workflow_intent": "..." }
   },
   "error": {
     "message": "<human-readable error>",

plugins/git/config.example.json

@@ -1,5 +0,0 @@
-{
-  "branching_pattern": "github-flow",
-  "commit_style": "conventional",
-  "rebase_strategy": "interactive"
-}

plugins/git/skills/git-branches/SKILL.md

@@ -9,7 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
-  version: "1.0.2"
+  version: "1.0.3"
   category: git
   source_keys:
     - context7-git-htmldocs
@@ -26,7 +26,7 @@ metadata:
 
 ## Step 1 — Determine the branching pattern
 
-Read `branching_pattern` from the git plugin config (`.claude/plugins/git/config.json`; the plugin root's `config.example.json` shows the shape). Default: `github-flow`. With no config, infer Gitflow from the presence of a `develop` or `release/*` branch, and GitHub Flow otherwise.
+Infer the branching pattern from the repo: Gitflow if a `develop` or `release/*` branch exists, GitHub Flow otherwise (the default).
 
 The two patterns are not mixable, and the wrong merge rule silently damages history. If the action touches a base branch, a name prefix, or a merge rule, read `references/branch-patterns.md`.
 

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

@@ -8,7 +8,7 @@ description: >
   agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
 
 metadata:
-  version: "1.0.0"
+  version: "1.0.1"
   category: git
   source_keys:
     - nvie-gitflow-post
@@ -55,8 +55,8 @@ owns the request.
    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.
+   follows (`git-branches` infers this from branch names: Gitflow if `develop`/`release/*` exists,
+   GitHub Flow otherwise); 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