步步为营
ReviewAudited by ClawScan on May 10, 2026.
Overview
This DevOps skill is mostly purpose-aligned, but its safety/checking scripts can falsely reassure users and may modify project files without clear approval.
Install only if you are comfortable reviewing the helper script before use. Treat it as DevOps guidance, not a fully reliable safety gate: verify git diffs yourself, run tests/builds directly when needed, avoid automatic lint fixes unless approved, and confirm Docker/Kubernetes context before any deployment or rollback command.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user or agent could trust a green result even though unrelated files changed or tests/builds failed.
The scope check counts matches for the target file rather than checking whether other files changed, so it can claim only the target file changed even when unrelated files changed. The test/build commands are piped through tail without pipefail, so failures can be masked while the script still prints completion success.
local file_count=$(echo "$changed_files" | grep -c "$target_file" || true)
...
else
log_success "修正范围正常，仅修改了目标文件"
...
npm test 2>&1 | tail -20
npm run build 2>&1 | tail -10
log_success "完整检查完成"Fix the script to compare the full changed-file list against the allowed target set, use exact path matching, enable pipefail or explicitly check command exit codes, and avoid success messages unless validation truly passed.
Running the helper may change dependencies or source files when the user expected only validation.
The dev-check workflow is described as a check, but it runs package installation and falls back to lint:fix, which can execute project-defined scripts and modify project files without an explicit prompt.
npm install 2>&1 | tail -5 ... npm run lint 2>/dev/null || npm run lint:fix 2>/dev/null || log_warn "Lint 配置未找到"
Separate check-only and fix modes, ask before running lint:fix or install steps, and clearly document that npm lifecycle scripts may execute project code.
If the active kubectl context points to production or another sensitive cluster, the rollback can affect live services.
Rollback is purpose-aligned and has a confirmation prompt, but it uses whatever Kubernetes credentials and current context are available to the user.
read -p "确认回滚到上一个稳定版本? (y/n) " -n 1 -r ... kubectl rollout undo deployment/"$deployment" -n "$namespace"
Before using rollback, verify the current cluster, namespace, and deployment; consider adding a context display, dry-run option, and explicit production confirmation.
Users may encounter unexpected runtime requirements or accidentally run commands against local Docker/Kubernetes environments they did not prepare for.
The script depends on additional tools beyond the declared bash/git/npm requirements, including Docker, curl, kubectl, and optional Trivy.
trivy image --ignore-unfixed alpine:latest
...
docker build -t "${image_name}:${image_tag}" .
...
local response=$(curl -s -w "\n%{http_code}" "http://${host}:${port}${endpoint}" 2>/dev/null)
...
kubectl rollout undo deployment/"$deployment" -n "$namespace"Declare all required and optional binaries in metadata or documentation, and make commands fail clearly when prerequisites are absent.