Use when running claudikins-kernel:ship, preparing PRs, writing changelogs, deciding merge strategy, or handling CI failures — enforces GRFP-style iterative approval, code integrity validation, and human-gated merges
Enforces GRFP-style iterative approval and code integrity validation for shipping code.
/plugin marketplace add elb-pr/claudikins-kernel/plugin install elb-pr-claudikins-kernel@elb-pr/claudikins-kernelThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/breaking-change-detection.mdreferences/changelog-merge-strategy.mdreferences/ci-failure-handling.mdreferences/commit-message-patterns.mdreferences/deployment-checklist.mdreferences/force-push-protection.mdreferences/gate-failure-recovery.mdreferences/grfp-checklist.mdreferences/message-generation-fallback.mdreferences/pr-creation-strategy.mdUse this skill when you need to:
claudikins-kernel:ship command"Ship with confidence, not hope." - Shipping philosophy
Shipping is the final gate. Apply GRFP-style iterative workflow to every stage.
Show what's being shipped. Human confirms ready.
| Check | What to Show |
|---|---|
| Verification status | All phases PASS from claudikins-kernel:verify |
| Branches to merge | List all execute/task-* branches |
| Evidence summary | Screenshots, curl responses from catastrophiser |
| Code delta | Lines added/removed, files changed |
Checkpoint:
Ready to ship?
Verified: ✓ All checks passed
Branches: 3 branches to merge
Changes: +450 / -120 lines
[Continue] [Back to Verify] [Abort]
Draft commit message(s). Human approves.
Decision:
How should we commit?
[Squash into single commit] [Preserve commit history]
Squash (recommended for features):
Preserve (for large multi-part work):
Checkpoint:
Commit message:
feat(auth): Add authentication middleware
- JWT token validation
- Role-based access control
- Session management
Closes #42
[Accept] [Revise] [Back]
Update README, CHANGELOG, version. GRFP-style.
git-perfectionist uses github-readme plugin:
Files to update:
| File | What to Update |
|---|---|
| README.md | Features, usage, installation if changed |
| CHANGELOG.md | Add entry in Keep a Changelog format |
| package.json / Cargo.toml / pyproject.toml | Version bump if needed |
Checkpoint:
Documentation updates:
README.md:
- Added: Authentication section
- Updated: Installation (new deps)
CHANGELOG.md:
- Added: v1.2.0 entry
Version: 1.1.0 → 1.2.0 (minor)
[Accept] [Revise] [Skip]
Draft PR title and body. Section-by-section approval.
PR Title Pattern:
feat(scope): Short description
PR Body Structure:
## Summary
[2-3 bullet points of what changed]
## Changes
[Detailed breakdown]
## Testing
[How it was verified]
## Screenshots
[If applicable]
Checkpoint:
PR ready to create:
Title: feat(auth): Add authentication middleware
Body:
## Summary
- Added JWT token validation
- Implemented role-based access control
...
[Create PR] [Revise] [Back]
CI passes. Human approves. Merge and cleanup.
CI Status Check:
CI Status: ⏳ Running...
[Wait for CI] [View logs] [Merge anyway]
On CI pass:
CI Status: ✓ All checks passed
Ready to merge PR #42 to main?
[Merge] [Request review first] [Cancel]
After merge:
Final output:
Done! Shipped to main.
PR #42 merged ✓
Branches cleaned up ✓
Version: 1.1.0 → 1.2.0
Nice work!
Agents under pressure find excuses. These are all violations:
| Excuse | Reality |
|---|---|
| "Verify passed yesterday, close enough" | Stale verification = no verification. Re-run claudikins-kernel:verify. |
| "Just a tiny fix after verify, no big deal" | Any change after verify invalidates it. Re-run claudikins-kernel:verify. |
| "CI is flaky, I'll merge anyway" | Flaky CI hides real failures. Fix or explicitly skip with caveat. |
| "It's just a typo, skip the PR" | All changes go through PR. No exceptions. |
| "Both reviewers passed, auto-merge is fine" | Human approves final merge. Always. |
| "I'll update the changelog later" | Changelog is part of shipping. Do it now. |
| "Force push is fine, it's my branch" | Never force push to protected branches. Ever. |
| "Skip docs, nobody reads them" | Docs are part of shipping. GRFP them. |
| "The gate check is too strict" | The gate exists for a reason. Pass it properly. |
All of these mean: Follow the methodology. Shortcuts create incidents.
If you're thinking any of these, you're about to violate the methodology:
All of these mean: STOP. Gate check exists. Human decides. Follow the stages.
The ship-init.sh hook enforces the claudikins-kernel:verify gate with code integrity validation.
# 1. Verify state exists
if [ ! -f "$VERIFY_STATE" ]; then
echo "ERROR: claudikins-kernel:verify has not been run"
exit 2
fi
# 2. Unlock flag is set
UNLOCK=$(jq -r '.unlock_ship // false' "$VERIFY_STATE")
if [ "$UNLOCK" != "true" ]; then
echo "ERROR: claudikins-kernel:verify did not pass or was not approved"
exit 2
fi
Ensure we ship exactly what was verified:
# C-5: Commit hash validation
VERIFY_COMMIT=$(jq -r '.verified_commit_sha' "$VERIFY_STATE")
CURRENT_COMMIT=$(git rev-parse HEAD)
if [ "$VERIFY_COMMIT" != "$CURRENT_COMMIT" ]; then
echo "ERROR: Code changed since verification"
exit 2
fi
# C-7: File manifest validation
VERIFIED_MANIFEST=$(jq -r '.verified_manifest' "$VERIFY_STATE")
CURRENT_MANIFEST=$(sha256sum "$MANIFEST_FILE" | cut -d' ' -f1)
if [ "$VERIFIED_MANIFEST" != "$CURRENT_MANIFEST" ]; then
echo "ERROR: Source files changed after verification"
exit 2
fi
If integrity check fails:
Code has changed since verification.
Verified commit: abc123
Current commit: def456
[Re-run claudikins-kernel:verify] [Abort]
feat(scope): Short description
- Bullet point of what changed
- Another change
Closes #123
fix(scope): Short description
Root cause: What was wrong
Fix: What we did
Fixes #456
feat(scope)!: Short description
BREAKING CHANGE: What breaks and migration path
- Change 1
- Change 2
chore(scope): Short description
- Internal refactor
- Dependency update
See commit-message-patterns.md for full guide.
Follow Keep a Changelog format:
## [Unreleased]
## [1.2.0] - 2026-01-17
### Added
- Authentication middleware with JWT support (#42)
### Changed
- Updated error messages for clarity
### Fixed
- Token refresh race condition (#38)
## [1.1.0] - 2026-01-10
...
See changelog-merge-strategy.md for merging entries.
PR creation failed.
Error: GitHub API returned 503
Retry 1/3...
Pattern: Max 3 retries with exponential backoff.
If persistent:
GitHub API unavailable after 3 retries.
[Try again] [Save as draft PR] [Manual merge]
Save state with pending_merge: true for recovery.
CI failed.
Failed checks:
- lint: 2 errors
- test: 1 failure
[View logs] [Fix and retry] [Skip CI] [Abort]
See ci-failure-handling.md for recovery patterns.
Never force push to protected branches.
# Check if target is protected
PROTECTED_BRANCHES="main master release"
if echo "$PROTECTED_BRANCHES" | grep -q "$TARGET"; then
if [ "$FORCE" = "true" ]; then
echo "ERROR: Cannot force push to $TARGET"
exit 2
fi
fi
See force-push-protection.md for safeguards.
Detect breaking changes before shipping:
| Signal | Indicates |
|---|---|
| Removed public function | Breaking |
| Changed function signature | Breaking |
| Removed config option | Breaking |
| Changed default behaviour | Potentially breaking |
If breaking change detected:
Breaking change detected!
- Removed: authenticate() function
- Changed: login() now requires email
This requires a MAJOR version bump.
[Acknowledge and continue] [Abort]
See breaking-change-detection.md for detection patterns.
Don't do these:
{
"session_id": "ship-2026-01-17-1130",
"verify_session_id": "verify-2026-01-17-1100",
"target": "main",
"phases": {
"pre_ship_review": { "status": "APPROVED" },
"commit_strategy": { "status": "APPROVED", "strategy": "squash" },
"documentation": { "status": "APPROVED", "files_updated": ["README.md", "CHANGELOG.md"] },
"pr_creation": { "status": "CREATED", "pr_number": 42 },
"merge": { "status": "MERGED", "sha": "abc123" }
},
"cleanup": {
"branches_deleted": ["execute/task-1-auth", "execute/task-2-routes"]
},
"shipped_at": "2026-01-17T11:46:00Z"
}
Full documentation in this skill's references/ folder:
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.