القائمة
Commit and/or push workflow for easy-db-lab. Run this skill before every git push. Runs ktlintFormat, handles commit confirmation, then pushes. Pass -a to stage all files without prompting.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Interactively generate a new workload install.yaml with typed lifecycle steps. Researches the workload's helm chart, CRDs, and readiness conditions, proposes a draft for review, refines with user feedback, and writes files only on explicit approval.
Run an integration test against a real AWS cluster. Use when the user says anything like "test it in AWS", "fire up a cluster and test", "run the presto test", "test on a real cluster", or names a specific test. Handles provisioning, surfaces the tail command, monitors progress, and reports results. Does NOT tear down on failure — leaves the cluster running for debugging.
Dynamic end-to-end test runner for easy-db-lab that calls easy-db-lab commands directly. Analyzes branch changes, proposes a test plan, executes commands step-by-step, and investigates failures inline. Use instead of bin/end-to-end-test when you want intelligent, adaptive testing with real-time debugging.
Comprehensive debugging for easy-db-lab environments. Diagnose cluster issues, service failures, connectivity problems, K8s pod failures, SSH issues, and configuration problems. Use when troubleshooting any easy-db-lab deployment or runtime issue.
Kubernetes expert specialized in easy-db-lab's K3s cluster, Fabric8 manifest builders, and K8s-based deployments. Use for K8s architecture questions, manifest building, pod debugging, or understanding how easy-db-lab uses Kubernetes. This is a Q&A expert, not an executor.
Use when archiving an OpenSpec change that adds or modifies specs, or when the user asks to review specs for overlap. Finds specs that describe the same system from different angles and proposes merging them under a more general name.
| name | commit-and-push |
| description | Commit and/or push workflow for easy-db-lab. Run this skill before every git push. Runs ktlintFormat, handles commit confirmation, then pushes. Pass -a to stage all files without prompting. |
| allowed-tools | Bash(*) Read Edit AskUserQuestion |
You are executing the commit/push workflow for easy-db-lab. Follow the phases below based on what the user asked for.
If the user asked to commit (with or without push), start at Phase 1. If the user asked only to push (no commit needed), skip to Phase 3.
Check the args passed to this skill. If -a is present, set AUTO_STAGE=true.
Before every push, run:
./gradlew ktlintFormat
Run in parallel:
git status
git diff --stat
git diff
Summarize the changes to the user in plain language — what files changed and why (infer from the diff). Keep it concise: one line per logical group of changes.
Then:
-A), or select specific files?" and wait for the answer.Once scope is confirmed:
Run ./gradlew ktlintFormat to auto-fix style issues before staging.
Stage files (run git add -A for AUTO_STAGE=true, or add the user-selected files).
Draft a commit message following the project's conventional commit style:
type(scope): short descriptionfeat, fix, refactor, test, docs, choreShow the proposed commit message and ask for approval. Wait for the user to say yes (or a variant) before committing. Use a menu so the user can just hit enter.
Run git commit with the approved message. Use a HEREDOC to pass the message:
git commit -m "$(cat <<'EOF'
<message here>
EOF
)"
Run:
git push
Report success or failure. If the push is rejected (non-fast-forward), explain why and ask the user how to proceed — never force-push without explicit instruction.