ship-readiness
Check install-to-first-finding metrics, funnel stage, findings state, proofs, and approvals before calling a session ready to ship.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Check install-to-first-finding metrics, funnel stage, findings state, proofs, and approvals before calling a session ready to ship.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run objective, repeatable improvement work under an immutable verifier and hard iteration, cost, time, and no-progress limits. Use for approved experiments with an automated metric and sandboxed worker.
Write concise, calm technical responses whose structure matches the decision, evidence, or sequence being communicated. Use when drafting substantial plans, reviews, findings, documentation, or completion summaries.
Operate inside a ControlKeel-governed session. Use this before code edits, shell execution, delegation, deploy work, or any task that needs CK validation, findings, budget, proof, or routing context.
Keep a governed session within budget. Use this before long-running agent work, bulk processing, or any task where spend pressure could change the plan.
Close a governed work session with validation, proof, findings, budget, digest, learning, and handoff checks. Use when the user asks to wrap up, stop for the day, or leave work ready for another agent.
Audit tests that may pass without proving the claimed behavior. Use for periodic test-quality reviews or when coverage looks healthy but regressions still escape.
| name | ship-readiness |
| description | Check install-to-first-finding metrics, funnel stage, findings state, proofs, and approvals before calling a session ready to ship. |
| when_to_use | Use before declaring a release, PR, or feature done. Activate when the user says 'ready to ship', 'done', 'merge this', or asks to verify completeness. |
| argument-hint | [feature, PR, or release to check] |
| disable-model-invocation | true |
| license | Apache-2.0 |
| compatibility | ["codex","claude-standalone","claude-plugin","copilot-plugin","github-repo","open-standard","cline-native","cursor-native","windsurf-native","continue-native","letta-code-native","pi-native","roo-native","goose-native","opencode-native","gemini-cli-native","kiro-native","kilo-native","amp-native","augment-native","hermes-native","multica-native","openclaw-native","devin-terminal-native","warp-native","droid-bundle","forge-acp"] |
| metadata | {"author":"controlkeel","version":"2.0","category":"release","ck_mcp_tools":["ck_observability","ck_context","ck_deployment_advisor"]} |
Use this skill when the operator asks whether a mission or session is ready for release.
ck_deployment_advisor (Dockerize, CI pipes) for the relevant stack (Phoenix, etc.).Before calling a feature ready, check whether relevant local observability evidence exists. Use ck_observability reports for benchmark_history and promotions to summarize readiness, uncovered scenarios, missed runs, and advisory promotion candidates. A ready advisory candidate is not a policy/router/prompt promotion; it still requires explicit human review.
Before calling a session ready to ship, inspect ck_observability with report: "loop_status" when available. Treat it as read-only evidence: unresolved blockers, uncovered observability benchmarks, or non-ready promotion candidates mean the operator should keep the release human-gated.