Defame1297/holocron
0
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

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

Browse Source 
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
This commit is contained in:
Defame1297
2026-09-12 19:46:20 +00:00
parent 198eafd790
commit f5e4d0d082
9 changed files with 23 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
plugins/git/agents/git-orchestrate.agent.md
View File

@@ -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>",