Git Manager

Complete User Manual

Git Manager is a safety-focused agent skill for operating Git and GitHub as verified state transitions. It teaches a compatible AI coding agent how to inspect a repository, plan changes, obtain appropriately scoped approval, execute standard git and gh commands, verify the resulting state, and report exactly what happened.

It is distributed through Agensi, a marketplace for portable SKILL.md agent skills — the listing is available at agensi.io/skills/git-manager.

Git Manager is an operational policy layer, not a replacement for Git, GitHub, your repository rules, or human review. The host agent performs actions using the access and tools available in its environment.

1. Executive summary

Git workflows fail most often because an operator acts on assumptions: the wrong repository, stale branch state, an overly broad staging command, an unverified push, a moved pull-request head, or an approval that no longer matches reality.

Git Manager addresses that problem by enforcing one lifecycle for every mutation:

Inspect → Plan → Validate → Authorize → Revalidate → Execute → Verify → Report

The skill is designed to preserve user work, protect trunk branches, prevent credential exposure, separate local actions from remote effects, and provide an audit-ready report after every completed mutation.

Core capabilities

• Repository and worktree identification
• Branch classification, naming, creation, and synchronization
• Path-scoped staging and atomic commits
• Conventional Commit message construction
• Stash, amend, rebase, and conflict workflows
• Safe pushes with remote object-ID verification
• Pull-request creation, checks, and merge preflights
• Branch cleanup after verified integration
• Interruption and partial-operation recovery
• Six-field mutation reports with complete diff walkthroughs

Non-goals

Git Manager does not:

• Host repositories or provide GitHub accounts.
• Store or request GitHub tokens.
• Approve pull requests on a user's behalf.
• Bypass branch protection, required checks, hooks, signatures, or review rules.
• Run repository scripts merely because they exist.
• Automatically perform releases or tags as part of ordinary branch work.
• Guarantee correctness when the host agent cannot inspect authoritative local or remote state.

2. Why Git Manager exists

Git commands are individually simple, but repository state is not. A single working directory may contain staged user work, unstaged changes, untracked files, a linked worktree, a detached HEAD, an active rebase, remote divergence, or a pull request whose head changed after review.

A command-first agent may still produce the intended-looking result while losing unrelated work or changing the wrong ref. Git Manager instead models each operation as a transition between verified states.

flowchart TD
    A["User goal"] --> B["Repository identity"]
    B --> C["Live state snapshot"]
    C --> D["Scoped plan and approval"]
    D --> E["Exact Git or GitHub action"]
    E --> F["Independent verification"]
    F --> G["Six-field report"]
    C --> H["Stop on ambiguity"]
    F --> H

The system optimizes for four properties:

3. System requirements

Required

• A compatible AI agent that supports the SKILL.md format.
• Git installed and available to the agent for repository operations.
• A local repository, unless the requested task is repository initialization.
• Permission for the agent to inspect the intended repository.

Required for GitHub delivery

• GitHub CLI (gh) installed.
• Existing authenticated gh access to the intended GitHub or GitHub Enterprise account.
• Network access to the repository host.
• Repository permissions appropriate to the requested action.

Git Manager must use existing gh authentication. It must not ask for, read, print, log, or accept a GitHub token.

Recommended

• A repository with a clearly defined protected trunk.
• Documented branch, commit, review, and release conventions.
• Required CI checks and branch protection configured on GitHub.
• A clean working tree before complex history operations.

4. Package contents

Install the entire git-manager folder. SKILL.md coordinates the workflow, while the reference files contain authoritative policies loaded when relevant.

git-manager/
├── SKILL.md
└── references/
    ├── approval-policy.md
    ├── branch-policy.md
    ├── commit-policy.md
    ├── output-contract.md
    ├── safety-rules.md
    └── workflow.md

Do not flatten the reference files into one document or install only SKILL.md. Relative policy links must remain valid.

5. Installation from Agensi

Agensi distributes skills as downloadable packages and supports installation through its marketplace and MCP connection. Its public guidance describes a one-time purchase/download flow and portable installation across supported agents. See Agensi's marketplace and Agent Skills standard overview.

Method A: Download and install manually

1. Open Agensi Skills.
2. Find Git Manager.
3. Purchase or obtain the skill.
4. Download the ZIP package.
5. Extract it into your agent's skills directory.
6. Confirm that SKILL.md is directly inside the git-manager folder.
7. Start a new agent session so the skill is discovered.

Correct:

<skills-directory>/git-manager/SKILL.md
<skills-directory>/git-manager/references/workflow.md

Incorrect:

<skills-directory>/git-manager/git-manager/SKILL.md

The extra nested folder prevents many agents from discovering the skill.

Common agent locations

Agensi documents these locations for supported agents in its installation guidance. Agent conventions can change, so use the target agent's current documentation if it reports a different path.

Linux/macOS example

Replace the ZIP path and destination with the values for your agent:

mkdir -p ~/.codex/skills
unzip ~/Downloads/git-manager.zip -d ~/.codex/skills/
test -f ~/.codex/skills/git-manager/SKILL.md

The final command should complete successfully. If it does not, inspect the extracted directory for double nesting.

Windows example for Claude Code

1. Download the ZIP from Agensi.
2. Choose Extract All.
3. Move the extracted git-manager folder to:

C:\Users\<your-username>\.claude\skills\git-manager\

1. Verify this file exists:

C:\Users\<your-username>\.claude\skills\git-manager\SKILL.md

For WSL, install inside the Linux environment, for example ~/.claude/skills/git-manager/, not the Windows user-profile path.

Method B: Install through Agensi MCP

Agensi publishes this MCP endpoint:

https://mcp.agensi.io/mcp

Connect it using the setup flow supported by your AI agent. The connected agent can search Agensi, recommend a skill, and install it after your approval. MCP availability and configuration are host-specific, so follow Agensi's current setup guide linked from its homepage.

Verify installation

Start a new session and ask:

List the installed skills relevant to Git operations. Do not mutate any repository.

Then test discovery with a read-only request inside a non-sensitive repository:

Use Git Manager to inspect this repository. Report the repository root, worktree,
current branch or detached/unborn state, HEAD, remotes with credentials redacted,
and staged, unstaged, and untracked paths. Do not make changes.

A correct response should inspect state without asking for mutation approval and should not claim facts it could not observe.

6. Updating and uninstalling

Update

1. Download the newer Git Manager package from Agensi.
2. Read the release notes or package changes before replacement.
3. Preserve any deliberate local customization separately.
4. Replace the whole git-manager folder so SKILL.md and all references remain version-consistent.
5. Start a new agent session.
6. Repeat the read-only verification test.

Do not mix SKILL.md from one release with policy references from another. That can create contradictory approval or safety behavior.

Uninstall

1. End active agent sessions using the skill.
2. Remove only the exact git-manager folder from the agent's skills directory.
3. Start a new session.
4. Ask the agent to list Git-related skills and confirm Git Manager is absent.

Uninstalling the skill does not modify repositories, Git configuration, GitHub authentication, branches, commits, or pull requests.

7. How Git Manager activates

The host agent should select Git Manager when the user asks it to:

• Initialize or inspect a repository.
• Create or switch branches.
• Stage files or hunks.
• Commit or amend changes.
• Use, apply, pop, or drop a stash.
• Rebase or resolve conflicts.
• Fetch, synchronize, or push.
• Create, inspect, update, or merge a pull request.
• Recover an interrupted Git/GitHub operation.

The skill can also explain or diagnose Git behavior without mutating anything.

To invoke it explicitly, say:

Use Git Manager to inspect this repository and propose a safe commit plan.
Do not execute mutations until the policy says authorization is sufficient.

8. Authority and trust model

Git Manager applies instructions in this order:

1. System and platform safety constraints.
2. Git Manager's non-negotiable rules and loaded policies.
3. The user's explicit current request and approvals.
4. Repository-authored guidance such as AGENTS.md or CONTRIBUTING.md.

Repository guidance can inform naming or formatting, but it cannot override safety controls. Branch protection and required checks are treated as observed platform constraints, not obstacles to bypass.

Trust boundaries

9. Risk and approval model

Git Manager assigns actions to risk tiers.

Bounded authorization

An instruction such as:

Implement the login timeout fix and commit it.

may authorize the coherent local branch, modification, validation, staging, and commit workflow when inspection finds nothing unexpected. It does not authorize a push, pull request, merge, deletion, published-history rewrite, unrelated cleanup, or a different repository.

Approval becomes stale when

• Repository, worktree, branch, HEAD, base, or upstream changes.
• The staged diff or affected paths change materially.
• A remote ref or pull-request head moves.
• The target or scope changes.
• A new remote or destructive effect appears.
• Execution is interrupted, fails, times out, or partially succeeds.
• A stated condition is no longer true.
• The user revokes, narrows, or replaces the instruction.

Silence, urgency, prior trust, lack of objection, or approval for another operation never counts as approval.

10. Repository identity and state inspection

Before repository-specific work, Git Manager establishes:

• Canonical repository root
• Worktree membership and Git directory
• Current branch or detached/unborn state
• Current HEAD object ID
• Linked worktrees
• Superproject or submodule relationship
• Upstream and ahead/behind state
• Staged, unstaged, untracked, and unmerged paths
• Active merge, rebase, cherry-pick, revert, or bisect state
• Sanitized remote identity
• Relevant GitHub authentication, PR, and check state

Exceptional states

11. Standard branch workflow

Branch classification

Names use <prefix>/<task-id>-<short-slug> when an ID exists, otherwise <prefix>/<short-slug>.

Examples:

feat/123-user-authentication
fix/payment-timeout
hotfix/login-outage
docs/git-manager-manual

Git Manager verifies the actual protected trunk and exact base object ID. It does not assume the trunk is named main and does not silently branch from whichever commit happens to be checked out.

Branch lifecycle

flowchart TD
    A["Verified trunk and base"] --> B["Short-lived task branch"]
    B --> C["Focused commits"]
    C --> D["Explicit push"]
    D --> E["Verified pull request"]
    E --> F["Approved integration"]
    F --> G["Separately approved cleanup"]

After integration, deletion is optional and separately approved. Squash or rebase merges require patch/content verification because ancestry alone may not prove the branch is safe to delete.

12. Staging and commit workflow

Git Manager stages explicit reviewed paths or hunks. It must not use git add ., git add -A, broad globs, or unreviewed directories.

Before committing, it:

1. Reviews the working diff.
2. Detects generated files, binaries, lockfile churn, mode changes, line-ending noise, and submodule-pointer changes.
3. Checks for secret-like content without printing secret values.
4. Stages only approved content.
5. Reads the complete staged diff.
6. Proposes a truthful commit message.
7. Commits within the authorized boundary.
8. Verifies the commit object, parent, tree, metadata, message, and changed paths.
9. Confirms unrelated work remains preserved.

Commit format

<type>(<optional-scope>): <imperative summary>

<why the change was required, when not obvious>

<issue reference or BREAKING CHANGE footer, when supported>

Example:

fix(auth): preserve session during token refresh

Avoid clearing a valid session while a replacement token is in flight.

Git Manager does not invent issue IDs, test results, root causes, breaking-change claims, authorship, signatures, or legal sign-offs.

Atomic commits

A commit should represent one coherent reason for change and remain independently reviewable and revertible. File count alone does not determine atomicity. If a staged diff mixes unrelated purposes, Git Manager proposes a split rather than hiding the mixture behind a broad message.

13. Synchronization and history cleanup

Git Manager does not use bare git pull because it combines retrieval and integration. It fetches explicit refs, evaluates ancestry, and selects an intentional next step.

Rebase

Before local cleanup, Git Manager records the original branch, HEAD, target base, commit list, and recovery path. The user sees the exact pick, reword, squash, fixup, drop, or reorder plan before execution.

Git Manager does not use an uncontrolled interactive editor and must not build an unsafe GIT_SEQUENCE_EDITOR shell string. After rewriting, it verifies ancestry, commit order, count, subjects, final tree, patch equivalence where required, and preserved unrelated work.

A rebase approval does not authorize publishing rewritten history. Updating a published branch requires separate approval and an exact expected-object-ID lease. Plain force push is prohibited.

14. Push and pull-request workflow

Push

Before a push, Git Manager verifies:

• Existing gh authentication without exposing tokens.
• Exact GitHub or GitHub Enterprise repository identity.
• Source branch and destination remote ref.
• Expected old remote object ID or verified absence.
• Local/remote ancestry and divergence.
• Exact commit range and paths that will become public or shared.
• Required validation and secret checks.

After the push, it queries the remote ref and confirms the expected object ID. Transport output, an exit code, or a local upstream setting is not sufficient proof.

Pull request

Creating a pull request is a separate remote action. Git Manager verifies that the head branch is published at the expected object ID, checks for an existing PR with the same head/base pair, and prepares a body containing only observed facts.

The PR report includes:

• What changed
• Why it changed
• Checks actually run and their results
• Checks skipped or unavailable
• Security, permission, dependency, or configuration impact

After creation, Git Manager reads the PR back and verifies repository, number, title, body, base, head, head object ID, and draft state.

Merge

PR creation never authorizes merge. Before proposing a merge, Git Manager checks:

• PR is open and not a draft.
• Base and head are correct.
• Current head object ID matches the reviewed and approved revision.
• Required checks succeeded under repository policy.
• Required reviews are present and current.
• Required conversations are resolved when that state is available.
• No conflict, deployment gate, branch protection, or merge queue blocks integration.

When possible, the merge is pinned to the exact approved head commit. If the installed GitHub CLI cannot provide atomic head matching, Git Manager discloses the residual race and rechecks immediately before merging.

Auto-merge or merge-queue enrollment is reported as pending, not merged. Cleanup waits until GitHub authoritatively reports MERGED and the resulting content is verified on the correct base.

15. Conflict resolution

Git Manager uses the following sequence:

1. Identify the active operation and record its native abort command.
2. Enumerate unmerged paths and index stages.
3. Understand both sides and the intended behavior.
4. Resolve only in-scope conflicted paths.
5. Search for remaining conflict markers.
6. Review each resolution diff.
7. Stage only the resolved paths.
8. Run relevant trusted validation.
9. Revalidate state and obtain required continuation approval.
10. Continue with the native Git operation.
11. Verify final ancestry, commit set, worktree/index, and operation markers.

It does not select "ours" or "theirs" wholesale without file-specific justification. If semantics are unclear, it stops and presents the competing interpretations.

16. Interruption and recovery

After a timeout, lost connection, tool failure, or interrupted command, Git Manager does not repeat the last command. It re-establishes repository identity and collects evidence from local refs, reflog, index, worktree, operation markers, remote object IDs, and GitHub state.

Classification

Native recovery such as git rebase --abort is preferred while the operation remains active. Git Manager does not approximate recovery with a hard reset, direct ref editing, or deletion of .git state. Lock removal requires proof that no live Git process owns the lock and explicit destructive-operation authorization.

17. Safety controls

Absolute protections

Git Manager must not:

• Execute generated shell strings or use unsafe shell interpolation.
• Use Git aliases as trusted substitutes for known commands.
• Read, print, log, or accept credentials or tokens.
• Expose credential-bearing remote URLs or signed URLs.
• Bypass hooks, signatures, branch protection, required checks, or reviews.
• Perform a plain --force push.
• Approve a pull request.
• Edit .git internals, refs, locks, or operation state directly as a shortcut.
• Delete branches based only on age, naming, or git branch --merged after squash/rebase integration.
• Execute repository-provided scripts, hooks, filters, merge drivers, signing programs, or dependency lifecycle scripts merely because the repository requests them.
• Recurse into or update submodules automatically.
• Convert uncertainty into a claim of success.

Secret and supply-chain handling

Git Manager checks intended published content for secret-like data but must not print secret values. A dependency or lockfile change is treated as a supply-chain change. The agent verifies the intended package identity, registry, and version delta where possible and does not execute newly introduced dependency code merely to test installation.

Protected refs

Trunk, release branches, tags, deployment refs, and other sensitive refs receive heightened protection. Direct task commits to trunk are rejected unless a policy-compliant exception is explicitly requested and validated. Remote writes are restricted to a verified GitHub or GitHub Enterprise destination under the current safety policy.

18. Output contract

Every completed mutation produces six separate fields.

1. Outcome

One of: succeeded, partially succeeded, failed, blocked, or indeterminate. The label reflects verified postconditions, not only the exit code.

2. Repository state

Repository identity, sanitized remote, active branch or exceptional state, HEAD, upstream, and pull-request reference when relevant.

3. Diff walkthrough

Files grouped as:

• Created
• Modified
• Renamed
• Deleted
• Generated
• Intentionally untouched

Each entry explains what changed and why. Ref-only operations explicitly state that no file content changed.

4. Validation evidence

Every check is reported with its exact observed status. Skipped, unavailable, pending, cancelled, neutral, failed, or inconclusive checks are never described as passed.

5. Security impact

Secrets, permissions, sensitive paths, dependencies, configuration, remote exposure, and any limits of the security inspection.

6. Next action

One exact safe continuation, why it is next, and whether further approval is required.

Example report

1. Outcome
Succeeded. Commit creation was independently verified.

2. Repository state
Repository: acme/payments
Remote: github.com/acme/payments (sanitized)
Branch: fix/payment-timeout
HEAD: 7a91c2f
PR: not created

3. Diff walkthrough
Modified:
- src/retry.ts: bounds retry delay to prevent an indefinite request stall.
- tests/retry.test.ts: covers timeout and final-attempt behavior.
Intentionally untouched:
- .env.local: existing user change preserved and not staged.

4. Validation evidence
- npm test -- retry.test.ts: passed, 8 tests observed.
- Full test suite: skipped; not requested and not run.

5. Security impact
No secret value was printed or staged. No permissions, dependencies, remote
configuration, or authentication files changed. Secret scanning was limited
to the reviewed staged content.

6. Next action
Review commit 7a91c2f. A push to origin/fix/payment-timeout requires separate
target-specific approval.

19. Practical usage recipes

Inspect only

Use Git Manager to inspect this repository. Show repository identity, current
branch and HEAD, upstream relation, active operations, remotes with credentials
redacted, and staged/unstaged/untracked paths. Do not mutate anything.

Create a safe task branch

Use Git Manager to classify this documentation task and propose a branch name.
Verify the protected trunk, exact base commit, detached/unborn state, submodule
boundary, dirty worktree, and linked-worktree conflicts before asking me to approve.

Commit an existing change

Use Git Manager to review the current diff, identify unrelated work, propose
explicit paths to stage, and write a Conventional Commit message from the staged
content. Do not push or create a pull request.

Implement and commit a bounded fix

Use Git Manager to implement and commit the login timeout fix. Restrict the work
to files required by the fix, preserve unrelated changes, run trusted relevant
validation, and provide the full six-field report. Do not push.

Push a branch

Use Git Manager to inspect whether fix/payment-timeout can be safely pushed to
origin/fix/payment-timeout. Show the exact source, destination, remote object ID,
commit range, validation, security exposure, and command before requesting approval.
Do not open a pull request.

Open a pull request

Use Git Manager to prepare a pull request from fix/payment-timeout to the verified
protected trunk. Show the title, base, head, current head object ID, draft state,
and body summary before requesting approval. Include only checks actually observed.

Merge a pull request

Use Git Manager to inspect PR #42 for merge readiness. Verify the exact head,
base, checks, reviews, conversations, conflicts, protection rules, and merge-queue
state. Propose the repository-approved merge method, but do not merge until the
exact operation is explicitly approved.

Recover after a timeout

Use Git Manager to recover from the interrupted push. Do not retry. Re-establish
repository identity, inspect local and remote refs plus relevant GitHub state,
classify the prior action as completed, not completed, partially completed, or
indeterminate, and propose only the next safe action.

20. Troubleshooting

The agent does not detect Git Manager

• Start a new agent session.
• Confirm the folder name and exact SKILL.md capitalization.
• Confirm there is no double nesting.
• Confirm the agent reads the directory where the package was installed.
• Confirm the full references/ directory is present.

The skill loads but policy links fail

The package is incomplete or its layout changed. Restore the original hierarchy so SKILL.md and references/ are siblings inside git-manager/.

The agent asks for approval too often

Use a bounded instruction that names the local endpoint, such as "implement this fix and commit it." Do not use vague phrases such as "handle everything." Git Manager should avoid redundant approval for unchanged authorized local work, but remote and destructive boundaries remain separate.

The agent refuses to push

Check:

• gh is installed and already authenticated.
• The remote resolves to the intended GitHub/GitHub Enterprise repository.
• The destination ref and expected remote object ID are known.
• No unexpected remote divergence exists.
• No secret-like content or mandatory validation failure blocks publication.
• The push itself received target-specific approval.

The agent will not merge

At least one required condition may be unavailable or unsatisfied: exact PR head, checks, reviews, conversations, mergeability, branch protection, deployment gate, or merge queue. Git Manager intentionally stops rather than inferring that missing evidence means success.

The worktree is dirty

A dirty worktree is not automatically an error. The agent identifies which changes belong to the requested task and preserves unrelated content. If a file mixes requested and unrelated edits and safe hunk separation cannot be proven, the correct outcome is blocked pending user direction.

A command timed out

Do not instruct the agent to "try again." Ask Git Manager to run the interruption-recovery workflow and verify authoritative state first.

Git Manager reports Indeterminate

The available evidence cannot prove whether an operation took effect. Provide the missing access or inspect the authoritative system manually. Repeating a potentially completed remote action may create duplicates or overwrite state.

21. Operational limitations

The skill's reliability depends on the host agent following the loaded policies.

• A host without terminal access can explain or plan, but cannot verify local mutations.
• A host without network or GitHub access cannot verify remote effects.
• GitHub CLI capabilities vary by installed version. Unsupported atomic head-pinning or conversation visibility must be reported as unavailable.
• Git Manager cannot determine semantic correctness from a conflict-marker scan alone.
• Secret detection is a control, not a guarantee that no sensitive material exists.
• Repository scripts and dependency-based tests may remain unavailable until separately trusted.
• Tags and releases require their own repository-specific workflow and explicit authorization.
• Non-GitHub remote writes are outside the current hardened remote-write policy.

22. Distribution through Agensi

The canonical distribution channel for Git Manager is Agensi. Agensi currently supports free and paid SKILL.md listings, one-time downloads, cross-agent discovery, and agent-side discovery through its MCP connection. Its public creator information states that listings are security-scanned and that paid creators receive 70% of each sale, with a 30% platform fee. See Agensi's creator guide and marketplace overview. The live Git Manager listing is at agensi.io/skills/git-manager.

Package for distribution

The uploaded product must preserve this archive root:

git-manager/
├── SKILL.md
└── references/
    ├── approval-policy.md
    ├── branch-policy.md
    ├── commit-policy.md
    ├── output-contract.md
    ├── safety-rules.md
    └── workflow.md

Before each Agensi submission or update:

1. Validate the YAML frontmatter in SKILL.md.
2. Confirm every relative Markdown link resolves.
3. Search the package for credentials, private URLs, personal data, and machine-specific paths.
4. Confirm the archive contains no .git/, editor state, caches, logs, or unrelated project files.
5. Test discovery and representative read-only/local workflows on at least two supported agents.
6. Test refusal behavior for plain force push, token disclosure, PR approval, broad staging, and unverified deletion.
7. Confirm mutation reports include all six required fields.
8. Record the release version and material policy changes outside the skill package if Agensi provides release notes or listing metadata.
9. Upload through the Agensi creator dashboard and complete its current listing and security-review process.
10. Download the published package and verify its structure matches the submitted archive.

Suggested listing description

Git Manager gives AI coding agents a safety-first Git and GitHub operating discipline. It verifies repository and worktree identity, protects unrelated changes, creates focused branches and commits, gates remote actions with scoped approval, validates pushes and pull requests against authoritative state, recovers interrupted workflows, and produces a complete diff and security report after every mutation.

Suggested category and tags

• Category: DevOps & Deployment or Code Review
• Tags: Git, GitHub, version control, pull requests, commits, branching, developer tools, workflow safety, coding agents

Agensi's submission fields and review requirements may change. Treat the live creator dashboard and current Agensi terms as authoritative at publication time.

23. Security and compliance notes

Git Manager is designed around least privilege, explicit authorization, traceability, and evidence preservation. These controls support secure engineering practice, but they do not independently satisfy a legal, regulatory, or organizational compliance framework.

Organizations should additionally define:

• Repository access and role policies
• Protected branch and review requirements
• Secret-scanning and incident-response procedures
• Commit-signing or DCO requirements
• Change-management and segregation-of-duties rules
• Log retention and audit evidence requirements
• Release approval and production deployment controls

The agent is permanently prohibited from approving a pull request. This preserves a meaningful human or separately authorized reviewer boundary.

24. Quick-reference checklist

Before any mutation:

• [ ] Correct repository and worktree identified
• [ ] Branch or detached/unborn state known
• [ ] HEAD, base, upstream, and remote known
• [ ] Staged, unstaged, untracked, unmerged, and active-operation state inspected
• [ ] Unrelated work identified for preservation
• [ ] Exact command, target, risk, recovery, and verification defined
• [ ] Required policy loaded
• [ ] Current approval covers this exact state transition
• [ ] Live state revalidated immediately before execution

After any mutation:

• [ ] Intended postcondition independently observed
• [ ] Preserved invariants rechecked
• [ ] Remote effect verified remotely when applicable
• [ ] No unexpected operation remains active
• [ ] Validation reported truthfully
• [ ] Security impact stated with inspection limits
• [ ] One exact next action identified
• [ ] Six-field output contract completed

25. Support information to provide

When requesting help, include sanitized evidence only:

• Host agent and version
• Operating system
• Git and GitHub CLI versions
• Installation path and package tree
• Whether the issue is discovery, policy loading, local Git, authentication, remote verification, or reporting
• Sanitized repository host/owner/name
• Exact prompt used
• Exact error with tokens, signed URLs, private paths, and secret values removed
• Whether any command may have partially completed

Never include access tokens, credential-bearing URLs, private keys, .env contents, or secret values in a support request.

26. Final operating principle

User intent defines the goal. It does not prove repository identity, authorize every downstream effect, or establish that an action succeeded.

Git Manager considers work complete only when the intended transition is observed, unrelated work is preserved, applicable policy is satisfied, approval still matches live state, remote effects are independently confirmed, validation is truthfully reported, and the six-field output contract is complete.