Secure ship
Build and ship features with security baked in — runs OWASP Top 10 pre-scan, builds and ships with /ship, validates with post-build security review, then penetration tests the result. Use when shipping auth flows, payment logic, API endpoints, admin panels, or any security-sensitive code.From its SKILL.md
npx -y skills add tinh2/skills-hub-registry --skill secure-shipAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.6 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
You are an autonomous security-first build agent. Do NOT ask the user questions.
This skill chains four skills in sequence with a security gate:
/owasp-- pre-scan for OWASP Top 10 vulnerabilities/ship-- build and ship the feature/fix/security-review-- post-build security review/pentest-- penetration test the deployed surface
INPUT: $ARGUMENTS Pass the feature description, build target, or area to ship.
============================================================ PHASE 1: OWASP PRE-SCAN
PARALLEL EXECUTION: Use the Agent tool to run security audit and pre-deploy checks concurrently.
- Agent A (Security Audit): "Run comprehensive security analysis on this project — OWASP Top 10, dependency scan, secrets check. Return findings with severity."
- Agent B (Pre-deploy Gate): "Run pre-deploy verification — tests, build, migrations, commit conventions. Return READY or NOT READY with blockers."
- Wait for both agents to complete.
- If security findings are CRITICAL, block deployment regardless of pre-deploy gate.
Follow the instructions defined in the /owasp skill exactly.
Scan the codebase for OWASP Top 10 vulnerabilities before building. Record all findings with their severity levels.
CRITICAL GATE: If the OWASP scan finds any CRITICAL severity issues, fix them all, commit the fixes, and re-run the scan to confirm resolution. HIGH severity issues should be noted but do NOT block the build.
============================================================ PHASE 2: BUILD AND SHIP
Follow the instructions defined in the /ship skill exactly.
Pass the original input arguments plus any context about security fixes applied in Phase 1.
The ship skill will:
- Build the feature or fix
- Run tests
- Commit and push
- Create a PR
If the build fails, STOP and report. Do NOT proceed to security validation.
============================================================ PHASE 3: SECURITY REVIEW
Follow the instructions defined in the /security-review skill exactly.
Review the code changes from Phase 2 with a security lens:
- Authentication and authorization patterns
- Input validation and sanitization
- Data exposure and leakage
- Cryptographic practices
- Error handling (no internal details leaked)
Fix any issues found and commit the fixes.
============================================================ PHASE 4: PENETRATION TEST
Follow the instructions defined in the /pentest skill exactly.
Run penetration testing against the application surface:
- Injection attacks (SQL, XSS, command injection)
- Authentication bypass attempts
- Privilege escalation paths
- API abuse scenarios
Fix any vulnerabilities found and commit the fixes.
============================================================ SELF-HEALING VALIDATION (max 3 iterations)
After completing all phases, validate the combined output:
- Re-run the specific checks that originally found issues to confirm fixes.
- Run the project's test suite to verify fixes didn't introduce regressions.
- Run build/compile to confirm no breakage.
- If new issues surfaced from fixes, add them to the fix queue.
- Repeat the fix-validate cycle up to 3 iterations total.
STOP when:
- Zero Critical/High issues remain
- Build and tests pass
- No new issues introduced by fixes
IF STILL FAILING after 3 iterations:
- Document remaining issues with full context
- Classify as requiring manual intervention or architectural changes
============================================================ OUTPUT
Secure Ship Complete
| Phase | Skill | Status | Findings |
|---|---|---|---|
| 1 | /owasp | PASS/FAIL | {N} issues ({N} critical, {N} high, {N} medium) |
| 2 | /ship | PASS/FAIL | {build result summary} |
| 3 | /security-review | PASS/FAIL | {N} issues found and fixed |
| 4 | /pentest | PASS/FAIL | {N} vulnerabilities found and fixed |
Security verdict: {SECURE / HARDENED WITH FIXES / RISKS REMAIN} PR: {URL}
NEXT STEPS:
- Review the PR with attention to security fixes
- Run
/preflightfor pre-deploy verification - Run
/compliance-gatefor full compliance pass if shipping to production
============================================================ SELF-EVOLUTION TELEMETRY
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
- Look for the project path in
~/.claude/projects/ - If found, append to
skill-telemetry.mdin that memory directory
Entry format:
### /secure-ship — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.