split-and-ship-4d7356 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited split-and-ship-4d7356 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Ship an approved split plan so each change group becomes its own reviewable unit, either as a separate branch and PR or as a sequential commit on the current branch.
A split plan must exist in the conversation. The plan specifies an ordered list of groups, each with a name, file list, and any dependencies on earlier groups.
At the start, use TaskCreate to create a task for each phase:
Detect the repository state:
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'gh pr view)Sample the prevailing workflow from recent default-branch history (git log --first-parent origin/<default-branch> -n 30 --pretty=%s): judge whether changes mostly land through pull requests (merge-PR commits or (#N)-suffixed squash commits) or are committed directly to the default branch.
Output a one-line summary of the detected state as text. Then use AskUserQuestion to choose how to ship the groups:
Recommend the option that fits this repo by listing it first and labeling it (Recommended): a PR-based history recommends separate branches and PRs; a direct-commit history recommends committing each group on the current branch.
If the user declines (chooses the free-form "Other" option or asks to abort), leave the changes staged and do not commit.
Take this step only when the user chose separate branches and PRs.
Stash all changes including untracked files (git stash --include-untracked) without unstaging first.
Verify git stash list shows the saved changes and git status --short lists nothing the stash should have taken before proceeding. Entries for a submodule, a nested repository, or files a stashed ignore rule had hidden may remain. When either check fails, stop and report where the changes now are.
Use TaskCreate to create a task for each group. Process groups in order.
For each group:
AskUserQuestion to confirm the proposed branch name and create it from the appropriate base:git checkout 'stash^2' -- <files> restores and stages in one operation). For files with hunks belonging to different groups, restore the file, use Edit to remove the unwanted hunks, then re-stage it (git add <file>): for an independent group, remove every other group's hunks; for a stacked group, remove only later groups' hunks (earlier groups' hunks are already in its base). Before committing a stacked group, check its staged diff against HEAD and restore from HEAD any earlier group's content it would revert. After committing, reset the working tree (git checkout -- .) to clean up before the next group./commit-rules skill to load commit message rules, then commit the staged changes following them/update-pr skill, then git pushgit push, then run the /create-pr skill targeting the appropriate base (default branch for independent groups, previous group's branch for stacked groups)Then use the TaskList tool and proceed to any remaining task.
Take this step only when the user chose to commit each group. This path stays on the current branch and creates no branches or PRs.
Stash all changes including untracked files (git stash --include-untracked) without unstaging first.
Verify git stash list shows the saved changes and git status --short lists nothing the stash should have taken before proceeding. Entries for a submodule, a nested repository, or files a stashed ignore rule had hidden may remain. When either check fails, stop and report where the changes now are.
Run the /commit-rules skill to load commit message rules. Use TaskCreate to create a task for each group. Process groups in order.
For each group:
git checkout 'stash^2' -- <files> restores and stages in one operation). For files with hunks belonging to different groups, restore the file, use Edit to remove the hunks that belong to later groups, then re-stage it (git add <file>).git checkout -- .) to clean up before the next group.git push)Then use the TaskList tool and proceed to any remaining task.
/commit-rules skill before every commit; do not commit without loading it first.git diff 'stash^2' stash | git apply --3way --allow-empty, restore untracked files with git checkout 'stash^3' -- <files>, then unstage everything with git reset -q. Report any hunk that does not apply. If any step fails (commit hook, push, PR creation), stop and report the failure, which groups have been shipped, and that the stash still contains all changes for recovery. A group whose PR was handed over for editing rather than posted is not a failure; record it in the summary and continue..turbo/ content (filenames, acceptance criteria, step numbers, headings) in branch names. .turbo/ is gitignored, so these references would be opaque to anyone reading without local copies.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.