ship

Name: ship
Author: tomevault-io

Security Community

Repo stars 0
Author updated Live
Author repo skills-registry

Fluxly profile Facts only: domain, agents, trust score, runtime, permissions and network

Domain: Security
Compatible agents: Claude Code
Cursor
Cline
Codex
Windsurf
Gemini CLI

+20
Trust score: 88 / 100 · community maintained
Author / version / license: @tomevault-io · no license declared
Token usage: Lean
Setup complexity: Plug-and-play
External API key: Not required
Operating systems: Unspecified (assume cross-platform)
Runtime requirements: No special requirements
Permissions: Read-only
Write / modify
Network behavior: External requests
Install commands: 26 variants

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

---
name: ship
description: Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assum…
category: security
runtime: no special runtime
---

# ship output preview

## PART A: Task fit
- Use case: Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assumes code is already committed and pushed. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Phase 1: Create PR / Phase 2: CI Monitor / Phase 3: SonarCloud Check” and do not present inference as author intent.

## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assumes code is already committed and pushed. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Phase 1: Create PR / Phase 2: CI Monitor / Phase 3: SonarCloud Check” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.

## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.

SKILL.md SKILL.md

---
name: ship
description: Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assum…
category: security
source: tomevault-io/skills-registry
---

# ship

## When to use
- Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assumes code is already com…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.

## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.

## Execution rules
- Organize steps around “Phase 1: Create PR / Phase 2: CI Monitor / Phase 3: SonarCloud Check” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.

## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.

Evidence boundary and execution chain

The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.

skill "ship" {
  input      -> user goal + target files + boundaries + acceptance criteria
  context    -> Phase 1: Create PR / Phase 2: CI Monitor / Phase 3: SonarCloud Check
  rules      -> SKILL.md triggers / order / output contract
  runtime    -> no special runtime | read files, write/modify files | may access external network resources
  guardrails -> usually needs no extra API key + small-sample validation + diff/log review
  output     -> copyable result + checklist + next iteration
}

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.

Install command

One-click installPick a runner, click Copy, paste into your terminal, press enter

npx skills add tomevault-io/skills-registry/brad-edwards--aptl--ship -y

Open general install guide

View skill source

Works with

Claude Code
Cursor
Cline
Codex
Windsurf
Gemini
OpenCode
Roo Code
AAide
+Augment
GitHub Copilot
OpenClaw
KKiro
Junie
WWarp
Goose
Trae
Kilo Code
OpenHands
Amp
Zencoder
CContinue
AIAider
CodeBuddy
CodeGeeX
Replit Agent

Security audit

88 / 100

Community

未声明 license/许可。
未声明 version。
未限定 allowed-tools，默认拥有全部工具权限。

Metadata

Source: github
tomevault-io/skills-registry
中文

More by @tomevault-io

Category & tags

Category Security