Agent skill · Audited from source
Finishing A Development Branch
skill · GanyuanRan/AegisMIT licenceAudited 18 Oct 2026 · source 177240a262fe
Is it safe? Yes — SAFE, grade B (89/100). We read this skill's source at commit 177240a262fe and found no filesystem, network or shell access and no hard-coded secrets. What it does: Use when verified work needs integration or cleanup of an existing task-created branch/worktree, or the user explicitly requests merge, PR, or branch lifecycle handling.
Cite
Cite this page
ModelsAtlas. “Finishing A Development Branch (GanyuanRan/Aegis)”. Retrieved 18 Oct 2026. https://modelsatlas.com/skills/ganyuanran/finishing-a-development-branch
6 skills are called “Finishing A Development Branch”. You are viewing GanyuanRan/Aegis.
- GanyuanRan/Aegis★ 1.4k✓SAFE
- obra/superpowers★ 304k✓SAFE
- jnMetaCode/superpowers-zh★ 8.3k✓SAFE
- xintaofei/codeg★ 3.9k✓SAFE
- FreedomIntelligence/OpenClaw-Medical-Skills★ 3.1k✓SAFE
and 1 more with this name.
Trust audit
Audit 0.4.1 · source read 18 Oct 2026
SAFE means nothing in the source contradicts what the skill says it does. Grade B is shared by 13,985 of 14,816 audited skills.
What the source does
- FilesystemNone observedNo reads or writes in the source
- NetworkNone observedNo outbound calls in the source
- ShellNone observedNo commands run in the source
- DependenciesPinnedNothing floats
- SecretsNone foundNo keys in source
Five audit layers
| Layer | What we check | Result | Findings |
|---|---|---|---|
L0 Provenance | Repo owner, licence, archive status, activity | PASS | 0 |
L1 Static source | Secrets, path traversal, supply chain, hidden code | NA | 0 |
L2 Instructions | Prompt injection, authority framing, hidden directives | PASS | 0 |
L3 Inventory | The files and declarations match the source | PASS | 0 |
L4 Sandbox | Run in isolation and watch behaviour | SKIPPED why | 0 |
Gates applied: no behavioural pass.
Findings (0)
No findings at any severity. We re-audit when the source changes.
Audit 0.4.1 · source sha 177240a262fe · 18 Oct 2026Report an issue or request a re-scan
Provenance
Who published it, and what the verdict is pinned to
- PublisherGanyuanRan GitHub userOwner of the repository this skill is read from
- Source folderGanyuanRan/Aegis/skills/finishing-a-development-branchThe exact folder we audited
- LicenceMITAs the repository states it
- Commit pinned for this verdict177240a262feA new audit runs when the source changes
- Repository statusNot archivedPushed today
- Sandboxed runNot runSkills are read, not executed; layer L4 is skipped
What it tells the agent
Full source on GitHub ↗Its description: Use when verified work needs integration or cleanup of an existing task-created branch/worktree, or the user explicitly requests merge, PR, or branch lifecycle handling.
--- name: finishing-a-development-branch description: "Use when verified work needs integration or cleanup of an existing task-created branch/worktree, or the user explicitly requests merge, PR, or branch lifecycle handling." --- # Finishing a Development Branch ## Overview Integration choice and checkout lifetime are separate. Verify first, mutate only task-owned resources, then prove what was removed or retained. **Core principle:** fresh evidence -> authorized integration -> ownership-aware cleanup -> Git/path readback. **Announce at start:** explain which branch/worktree lifecycle is being closed. ## Step 1: Environment and Ownership Detection Read the task's `TaskStartSnapshot` and current repository state. Record: - root, `HEAD`, branch/detached state, upstream divergence, and active Git ops; - staged/unstaged/untracked paths and the task-owned delta; - `git worktree list --porcelain`; - branch/worktree creator, task ownership, base branch, and cleanup trigger. Stop on conflicts, unexplained detached state, failed verification, dirty/untracked state in a cleanup target, or unknown ownership. Do not infer the base from the names `main` or `master`; use task records, repository authority, or explicit user direction. Never auto-stash, reset, clean, pull, rebase, amend, force-push, or bypass hooks. For a trusted host-managed detached checkout, follow the repository's approved managed-workspace contract: verify host binding, default cwd, root, and HEAD; then use its scoped local-commit and native handoff path. Report detached HEAD in the receipt. This exception does not authorize automatic deletion of the detached checkout or bypass unknown ownership/binding. If no task-created branch/worktree exists and integration was not requested, skip this workflow: report the local task commit plus `Task clean` and `Repository clean`; do not invent merge/PR ceremony. ## Step 2: Fresh Verification Run the smallest current-authority test set that proves the completed task. If it fails, preserve all work and return to diagnosis. Do not present the branch as ready. ## Step 3: Choose the Authorized Outcome When a task branch actually needs disposition, present only applicable choices: 1. merge into the recorded base locally; 2. push and create/update a PR; 3. keep the branch for later integration; 4. discard the exact task-owned branch/worktree. Push, PR, remote deletion, release, and force operations require explicit user authorization. Discard requires a fresh, exact typed confirmation naming branch, worktree path, and commits/delta to lose. Generic agreement is insufficient. ## Step 4: Execute Without Hidden Mutation ### Local merge Verify the target checkout is safe, switch to the recorded base, merge without an implicit pull, and rerun verification on the merged result. If integration or verification fails, preserve both histories and stop. ### Push or PR Push only the authorized task branch and create/update the PR with summary and fresh test evidence. PR creation does not itself prove merge and does not require the temporary worktree to remain. ### Keep branch Retain the branch. Remove a clean task-created temporary worktree by default; retain it only for an explicit ongoing-checkout need and report why. ### Discard After exact confirmation, remove only the named clean task-owned worktree, then the named branch. If either differs from the confirmation, stop and ask again. ## Step 5: Prove Integration Before Branch Deletion Use evidence matching the merge strategy: - merge/fast-forward: prove the task tip is an ancestor of the recorded base; - squash/rebase: use fresh PR merge metadata plus strategy-appropriate patch equivalence (`git cherry` for rebased commits; stable patch-id or bounded changed-path/tree comparison for squashes), not an ancestor-only test; - unmerged/open PR: keep the branch unless discard was exactly confirmed. Never delete a branch merely because a PR was opened or a similarly named commit exists. ## Step 6: Cleanup in Dependency Order For a clean task-owned resource: 1. move to another safe registered checkout; never remove the current working directory; 2. remove/unregister the worktree first with `git worktree remove <exact-path>`; 3. read back `git worktree list --porcelain`; 4. verify the exact path no longer exists; 5. only then delete an integrated or exactly confirmed branch; 6. read back branch refs, `HEAD`, and repository status. Do not use routine `--force`, global `git worktree prune`, wildcard deletion, or cleanup of resources absent from the task ownership record. On Windows, Git may unregister a worktree while its directory remains locked: re-check registration and the exact resolved path, remove only a proven task-owned clean residual when safe, otherwise retain it and report the lock/path. Never widen deletion scope. ## Final Git Receipt Report: - current branch and commit SHA/message, or the reason no commit exists; - `Task clean: yes|no` and `Repository clean: yes|no` independently; - branch/worktree created, removed, or retained, with evidence/reason; - integration evidence and any remaining user action. `Task clean` means no uncommitted task-owned delta remains. `Repository clean` means no staged, unstaged, or untracked repository state remains. This is a local Git receipt, not authoritative completion or merge truth beyond the evidence read back. ## Integration Called only when branch/worktree integration or explicit lifecycle handling is in scope. Pairs with `using-git-worktrees` and `verification-before-completion`.
Excerpt, first 5,601 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.
Install
Pinned to the audited commit 177240a
git clone https://github.com/GanyuanRan/Aegis git -C Aegis checkout 177240a262fe
The author documents no install command, so this uses the repository directly. Our verdict covers commit 177240a262fe only.
Works in
The author has not said which agents this skill supports, and we have not tested it in any.
Audit history
Every audit, every source change
- ✓SAFE B 89 / 100
first audit · source
177240a262fe
README badge
For maintainers · shows the latest audit
[](https://modelsatlas.com/skills/ganyuanran/finishing-a-development-branch/)
The badge shows our verdict and grade for this skill, and links back to this page. It changes when the audit does.
Similar skills
All coding & review skills →GanyuanRan/Aegis
Use when defining ambiguous or high-complexity new features, product behavior, UI/component design, architecture choices, contract changes, or when grilling/pressure-testing a plan or design. Routine small requests stay…
GanyuanRan/Aegis
Use when the user asks for caveman mode, fewer tokens, brief responses, compressed communication, or otherwise explicitly requests a much shorter answer.
GanyuanRan/Aegis
Use when facing 2+ independent tasks without a written plan, with no conflicting shared mutable state or sequential dependencies, where parallel delegation beats inline cost; otherwise inline. Planned tasks use…
GanyuanRan/Aegis
Use when the user asks to establish shared project language, or project work exposes a conflicting, renamed, or deprecated domain term that needs active semantic modeling. Routine small tasks stay on the fast path.
GanyuanRan/Aegis
Use when executing a written implementation plan across sessions or with review checkpoints. Small or single-slice plans stay inline. For same-session independent tasks, use subagent-driven-development instead.
GanyuanRan/Aegis
Use when asked for first-principles or Occam's-razor review, or when high-risk decisions involve competing constraints, fallback growth, duplicate owners, or architecture direction risk. Ordinary bug fixes stay on the…
Add this badge to your README
[](https://modelsatlas.com/skills/ganyuanran/finishing-a-development-branch/)
<a href="https://modelsatlas.com/skills/ganyuanran/finishing-a-development-branch/"><img src="https://modelsatlas.com/skills/ganyuanran/finishing-a-development-branch/badge.svg" alt="ModelsAtlas: SAFE B"></a>
Questions about Finishing A Development Branch
What does the Finishing A Development Branch skill do?
Is Finishing A Development Branch safe to install?
What can Finishing A Development Branch access on my machine?
How current is this page?
Sources
- github.com/GanyuanRan/Aegis/tree/main/skills/finishing-a-develop — the audited source at commit 177240a262fe and every finding aboveObserved · 18 Oct 2026
Spotted something wrong? Report a correction · Methodology
Keep going in your AI
Opens with this page as the source. We add nothing else to the prompt.
- What does the Finishing A Development Branch skill do?
- Is Finishing A Development Branch safe to install?
- What can Finishing A Development Branch access on my machine?