feat(git-plugin): add complete git workflow automation suite

## Why
The git plugin only covered a partial slice of common git workflows.
This adds the remaining skill set (branches, commits, history, remotes,
submodules, workflow, worktrees) plus a git-orchestrate agent so the
plugin can handle end-to-end git automation instead of a handful of
commands.

## Implementation Notes
Each new skill was validated against its research docs and org
conventions after initial authoring, which surfaced hallucinated
version pins, factual errors, and completeness gaps that were
corrected in the same pass rather than left for follow-up.

## Impact
Bumps the git plugin to 1.3.0.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-04 18:41:09 +00:00
parent 05bb9d6e9f
commit 0239b00944
48 changed files with 2306 additions and 19 deletions

View File

@@ -0,0 +1,66 @@
---
source_keys:
- org-commit-conventions
---
# Commit Message Body Template
Use this structure for the body/footer of any non-trivial commit (skip sections that don't apply — do not leave placeholders in the actual commit).
```
<type>(<scope>): <concise summary>
```
The header is required. Describe the intended outcome, not the implementation.
## Why
Explain why this change exists. This is the most valuable part of the commit — the diff already shows *what* changed; future maintainers (human or AI) need *why*.
Include, where applicable:
- Problem being solved
- User or business need
- Bug or root cause
- Important context not visible in the code
Omit if the reason is immediately obvious.
## Implementation Notes
Capture decisions that are difficult to infer from the code:
- Why this approach was chosen
- Important assumptions or invariants
- Constraints imposed by external systems
- Tradeoffs or intentional compromises
- Non-obvious implementation details
- Workarounds or temporary solutions
Do NOT describe the diff ("renamed X", "added Y"). Omit if there's nothing worth preserving.
## Impact
Document effects future developers should know about:
- Behavior changes
- Breaking changes
- Performance implications
- Security considerations
- Migration or deployment requirements
- Compatibility concerns
- Follow-up work or known limitations
Omit if there are no noteworthy impacts.
## Trailers
Structured metadata for traceability and tooling. Use only the trailers that apply:
```
Fixes:
Refs:
ADR:
RFC:
Design:
Co-authored-by:
Reviewed-by:
Signed-off-by:
BREAKING CHANGE:
```