菜单
Restore selected paths, integrate or abort one history operation, manage stashes, reset state, or clean untracked content after exact Git inspection.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Register AgentImage packages, publish checkpoint-derived images, or replace the current process image. Use when creating reusable runtime configurations or deliberately changing process code, tools, prompt identity, memory, or authority.
Diagnose this process's Capability authority and request one exact Human policy decision when a protected operation lacks requestable authority. Do not use it for intent questions, validation errors, provider failures, or speculative privilege expansion.
Delegate one attenuated Capability to a known direct child or revoke one exact Capability. Do not create children, grant peers or grandchildren, amplify authority, or treat revocation as rollback of completed effects.
Capture, inspect, compare, restore, or fork durable process-subtree checkpoints. Use for recoverable internal-state milestones, isolated replay, or deliberate rollback of reconstructable Agent libOS state.
Spawn or fork direct AgentProcess children, coordinate their lifecycle and messages, then import selected results. Use for bounded parallel delegation, isolated exploration, or structured parent-child collaboration.
Run one policy-governed, non-interactive host command through the argv-only Shell boundary. Use for builds, tests, searches, or utilities lacking a narrower tool; not for general Git, TTY/streaming work, ad hoc remotes, or attempts to evade policy.
| name | agent-libos-git-integration-recovery |
| description | Restore selected paths, integrate or abort one history operation, manage stashes, reset state, or clean untracked content after exact Git inspection. |
| allowed-tools | git_restore git_integrate git_stash git_reset git_clean |
Activate agent-libos-git-inspection first. Read untruncated status, worktree and staged diffs, HEAD/history, and the exact selected worktree_id; retain its latest state.token and relevant full OIDs. These tools can rewrite HEAD, index, worktree, stash, or untracked content. They do not provide a general Git command, automatic backup, rollback, integration continue/skip, or permission to erase unrelated state.
All calls are side-effecting and non-idempotent. Success returns a GitOperationResult with post-state digest after.token, operation-specific created_oid, reconciliation paths, and details. Tokens are not consumed and can remain equal across a verified no-op. created_oid can mean a resulting/selected OID rather than a newly allocated object. Capability grants are necessary but remain subject to data-flow policy and state revalidation. Always verify through inspection.
git_restoregit_restore requires one or more literal paths, a fresh token, at least one destination, and an optional exact commit source:
staged | worktree | source=null meaning | Effect |
|---|---|---|---|
| false | true | index | Replace selected worktree bytes from the index |
| true | false | HEAD | Replace selected index entries from HEAD |
| true | true | HEAD | Replace both index and worktree from HEAD |
When source is supplied, staged-only or staged+worktree restore uses that resolved commit. Source-specific worktree-only restore is unsupported; set staged=true as well or choose a supported workflow. staged=false,worktree=false is invalid. An unborn repository without an available HEAD/source fails rather than inventing a source.
Every restore is classified destructive and requires repository write/delete/admin plus mandatory one-use Human approval. A worktree destination additionally requires filesystem write/delete subtree authority for each selected path; staged-only restore requires no checkout filesystem grant. Restore does not save discarded bytes and does not accept patterns. For renames and directory paths, inspect the complete affected subtree before approval.
git_integrategit_integrate supports exactly one operation:
operation="merge", "rebase", "cherry_pick", or "revert" requires one exact ref resolving to a commit and no abort_kind.operation="abort" requires ref=null and an abort_kind exactly matching merge, rebase, cherry_pick, or revert.Merge has no strategy/ff selector on this tool: graph and validated effective configuration determine whether it fast-forwards or creates a merge commit. Rebase uses no autostash. Cherry-pick and revert accept only one commit and have no merge-mainline selector. There is no continue, skip, multi-ref, interactive rebase, custom strategy, conflict favoring, or message option.
All integration variants require repository write and selected-worktree filesystem read/write/delete. Rebase and every abort are destructive and additionally require repository delete/admin plus one-use approval. Merge, cherry-pick, and revert can still ask under ordinary policy. Dirty changes are not automatically stashed and may block or coexist according to Git; inspect them first.
On success, created_oid is the final HEAD, which may equal an existing commit after fast-forward/no-op. Merge commits, cherry-picks, reverts, and rebases that create commits require usable Host/repository identity; the tool has no identity override. After a conflict, the Host effect may already have written index/worktree/control metadata.
The built-in read schemas do not expose MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, rebase directories, or sequencer state, and the state digest does not certify their absence. An ordinary edit → stage → commit can finish a known one-step merge/cherry-pick/revert, but git_commit itself does not guard against doing so. Continue only when the active kind is known from the operation just attempted and finishing it is explicitly intended; otherwise stop. Rebase usually needs unavailable continue/skip controls, so stop or explicitly abort the known kind rather than invoking shell Git.
git_stashgit_stash captures/applies bytes in the selected worktree, but its refs/stash reflog and numeric stack are shared by every worktree and process in the repository common directory. A push/drop/pop/clear elsewhere can shift every ordinal. worktree_id selects where checkout changes are read/written; it does not select an isolated stash stack.
operation="push" stashes the whole tracked staged and unstaged state; there is no path selector. include_untracked=true broadens it to untracked content. The operation removes saved tracked state from index/worktree even when it does not require mandatory destructive approval. A clean push can succeed with created_oid=null.operation="apply" applies the selected numeric index and keeps its stash entry. reinstate_index=true also attempts to restore staged state.operation="pop" applies the selected entry and removes it only on success. On conflict Git normally keeps recovery evidence, but inspect rather than assume.operation="drop" deletes one numeric entry. operation="clear" deletes the whole stash stack.Only apply/pop use reinstate_index; only push uses include_untracked; index has meaning only for apply/pop/drop. Omit irrelevant fields instead of relying on them being ignored.
There is no stash-list tool. git_list_refs(kind="all") can expose only the current shared refs/stash tip, not the reflog/ordinal mapping. git_show accepts an exact retained stash commit OID, not stash@{n} revision syntax. Save a successful push's created_oid; before every ordinal-based apply/pop/drop, account for cross-worktree/process changes. Stop if the exact intended entry cannot be identified confidently.
Push/apply/pop require repository write plus filesystem read/write/delete. Pop/drop/clear and push with untracked content require repository delete/admin and mandatory one-use approval; other variants can ask under policy.
git_resetgit_reset resolves exact target to a commit:
mode="soft" moves HEAD only and leaves index/worktree as they are.mode="mixed" moves HEAD and resets the index to target, leaving worktree bytes.mode="hard" moves HEAD and resets index plus tracked checkout state; obstructing untracked paths can also be lost during materialization. It is not a substitute for git_clean and does not promise removal of all untracked/ignored content.All reset modes are deliberately classified destructive and require repository write/delete/admin with one-use approval. Hard additionally requires filesystem read/write/delete; soft/mixed require no checkout filesystem grant. created_oid is the selected target commit and details.old_head_oid records the previous tip; it is not a newly created commit.
git_cleangit_clean removes eligible untracked content, never tracked modifications. paths are optional literal restrictions; an empty list broadens scope to every eligible untracked path in the selected worktree. directories=true includes untracked directories. ignored=true includes ignored content in addition to ordinary untracked content.
The Runtime performs an internal bounded dry-run and candidate manifest before authorization, then recomputes that manifest immediately before dispatch. Candidate drift yields stale_state. The digest/count in approval evidence are not a substitute for the caller inspecting status and literal paths. Success details include preview and candidate hashes/count, while changed_paths supplies reconciliation paths.
Clean requires repository write/delete/admin, filesystem read/delete, and mandatory one-use approval. Do not pair hard reset and clean as a generic “make clean” recipe: they affect different domains and each needs separate explicit intent, inspection, authority, and verification.
force, a broader path list, hard reset, clean, or stash clear.stale_state means re-read and re-decide. For clean, it can specifically mean candidate bytes/types changed after approval. Never replace only the token.repository_busy requires a later fresh observation, not repeated mutation calls.command_failed—must be treated as possibly dispatched and reconciled before another mutation.abort_kind only when it matches the operation known to have started; never guess from status alone. If completion requires unavailable continue/skip/mainline control or the active kind is uncertain, stop.refs/stash; compare any saved old/new stash OIDs. Blind push can create duplicates or hide already-saved state. After apply/pop/drop/clear unknown, do not trust the old ordinal index; reconcile visible tip plus checkout/index and stop if deeper stack identity is unknowable.unsafe_repository, unsafe configuration, truncated evidence, unsupported control, or an unidentifiable stash entry is a stop condition. Shell Git is not a supported escape hatch.Finish only when the exact requested state is proven:
If shared-stash identity cannot be proven, the active integration kind is unknown, an integration needs unavailable continuation, any unrelated content disappeared, or recovery evidence remains ambiguous, stop and report the exact limit instead of applying another destructive operation.