ship

Name: ship
Author: tomevault-io

Security Community

Repo stars 0
Author repo skills-registry

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assumes code is already committed and…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Phase 1: Create PR”, “Phase 2: CI Monitor”, “Phase 3: SonarCloud Check”, “Phase 4: Code Review”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name ship directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Phase 1: Create PR / Phase 2: CI Monitor / Phase 3: SonarCloud Check” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Ship Current Branch

Assumes code is already committed and pushed. Handles: PR creation, CI monitoring, SonarCloud, code review, security review, fixing all issues, and merging.

IMPORTANT: NEVER include Co-Authored-By, "Generated with Claude Code", or any Claude/AI attribution in commit messages, PR descriptions, or any other artifacts.

Phase 1: Create PR

Determine the current branch: git branch --show-current
Check if a PR already exists: gh pr list --head <branch> --json number,url

If no PR exists, create one:

gh pr create --base dev --title "<concise title>" --body "<description>"

Note the PR number.

Phase 2: CI Monitor

Find the latest workflow run: gh run list --branch <branch> --limit 1 --json status,conclusion,databaseId
If the run is in progress, watch it: gh run watch <id>
If it failed:
- Get failed logs: gh run view <id> --log-failed
- Diagnose and fix the issue.
- git add, git commit, git push.
- Go back to step 1.
If it succeeded, proceed.

Phase 3: SonarCloud Check

Wait 60 seconds for SonarCloud analysis to propagate.
Use get_project_quality_gate_status with project key Brad-Edwards_aptl to check the quality gate.
Use search_sonar_issues_in_projects to find new issues on the current branch.
If issues found:
- Fix them.
- git add, git commit, git push.
- Re-run Phase 2.
If clean, proceed.

Phase 4: Code Review

CRITICAL: You MUST use the Skill tool to invoke the built-in review skill.

Merge dev into the current branch: git fetch origin dev && git merge origin/dev
If there are merge conflicts, resolve them, commit, and push.
Call the Skill tool with skill="review" to invoke the real built-in code review.
After the review completes, fix ALL issues it identified.
- Do NOT defer ANY issues.
- Do NOT categorize issues as "low priority" to avoid work.
- You are an LLM. You have no time constraints. Fix everything.
- The ONLY reason to stop and escalate to the user is if a fix requires a significant architectural change touching 5+ files outside the current feature scope.
After fixing, re-read all findings and confirm each one was addressed.

Phase 5: Security Review

CRITICAL: You MUST use the Skill tool to invoke the built-in security-review skill.

Call the Skill tool with skill="security-review" to invoke the real built-in security review.
After the review completes, fix ALL issues it identified.
- Same rules as Phase 4: fix everything, defer nothing.
After fixing, confirm all findings were addressed.

Phase 6: Final Commit & CI

If ANY fixes were made in Phases 4-5:

git add all changed files.
git commit -m "Fix code review and security review findings"
git push
Re-run Phase 2 (CI Monitor).
Re-run Phase 3 (SonarCloud).

Phase 7: Report (DO NOT MERGE)

You MUST NOT merge the PR. You MUST NOT run gh pr merge. The user reviews and merges.

Summary of all changes made during the ship process
Review findings and what was fixed
Security review findings and what was fixed
Confirmation: CI green, SonarCloud passed, PR ready for user review
PR URL

Source: Brad-Edwards/aptl — distributed by TomeVault.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Security
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @tomevault-io · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: External requests
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview ship-tomevault-io.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Ship Current Branch

Assumes code is already committed and pushed. Handles: PR creation, CI monitoring, SonarCloud, code review, security review, fixing all issues, and merging.

**IMPORTANT:** NEVER include Co-Authored-By, "Generated with Claude Code", or any Claude/AI attribution in commit messages, PR descriptions, or any other artifacts.

## Phase 1: Create PR

1. Determine the current branch: `git branch --show-current`
2. Check if a PR already exists: `gh pr list --head <branch> --json number,url`
3. If no PR exists, create one:
   ```
   gh pr create --base dev --title "<concise title>" --body "<description>"
   ```
4. Note the PR number.

## Phase 2: CI Monitor

1. Find the latest workflow run: `gh run list --branch <branch> --limit 1 --json status,conclusion,databaseId`
2. If the run is in progress, watch it: `gh run watch <id>`
3. If it failed:
   - Get failed logs: `gh run view <id> --log-failed`
   - Diagnose and fix the issue.
   - `git add`, `git commit`, `git push`.
   - Go back to step 1.
4. If it succeeded, proceed.

## Phase 3: SonarCloud Check

1. Wait 60 seconds for SonarCloud analysis to propagate.
2. Use `get_project_quality_gate_status` with project key `Brad-Edwards_aptl` to check the quality gate.
3. Use `search_sonar_issues_in_projects` to find new issues on the current branch.
4. If issues found:
   - Fix them.
   - `git add`, `git commit`, `git push`.
   - Re-run Phase 2.
5. If clean, proceed.

## Phase 4: Code Review

**CRITICAL: You MUST use the Skill tool to invoke the built-in review skill.**

1. Merge dev into the current branch: `git fetch origin dev && git merge origin/dev`
2. If there are merge conflicts, resolve them, commit, and push.
3. Call the Skill tool with `skill="review"` to invoke the real built-in code review.

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Phase 1: Create PR → Phase 2: CI Monitor → Phase 3: SonarCloud Check → Phase 4: Code Review → Phase 5: Security Review → Phase 6: Final Commit & CI
terms    -> IMPORTANT · CRITICAL: You MUST use the Skill tool to invoke the built-in review skill. · Assumes code is already committed and pushed. · 1. Determine the current branch: git branch --show-current 2. · 1. Find the latest workflow run: gh run list --branch <branch> --limit 1 --json status,conclusion,databaseId 2. · 1. Wait 60 seconds for SonarCloud analysis to propagate. · 1. Merge dev into the current branch: git fetch origin dev && git merge origin/dev 2. · CRITICAL: You MUST use the Skill tool to invoke the built-in security-review skill.
files/cmd -> git branch --show-current · gh pr list --head <branch> --json number,url · gh run list --branch <branch> --limit 1 --json status,conclusion,databaseId · gh run watch <id> · gh run view <id> --log-failed · git add · git commit · git push
body sha256 -> 69ebf2b96acb