secure-ship— agent skill

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:

1. /owasp -- pre-scan for OWASP Top 10 vulnerabilities
2. /ship -- build and ship the feature/fix
3. /security-review -- post-build security review
4. /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:

1. Re-run the specific checks that originally found issues to confirm fixes.
2. Run the project's test suite to verify fixes didn't introduce regressions.
3. Run build/compile to confirm no breakage.
4. If new issues surfaced from fixes, add them to the fix queue.
5. 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

Security verdict: {SECURE / HARDENED WITH FIXES / RISKS REMAIN} PR: {URL}

NEXT STEPS:

• Review the PR with attention to security fixes
• Run /preflight for pre-deploy verification
• Run /compliance-gate for 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.md in 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.