القائمة
Add keel to a repository by running the one-command setup flow, then verify config, adapters, and the rendered plan.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Check the latest CI run's status; on failure, locate the failing job/step, diagnose the root cause, and propose one fix — never auto-apply.
Compute and post the per-PR test-coverage delta (base → head), flag low-coverage × high-risk hot spots, and open issues to close gaps — routed to keel:ship.
On-demand dependency security + licence audit across the project's ecosystems; classify security vs. routine, append findings to today's tracking issue, and route fixes to keel:ship.
Detect intermittently-failing tests from recent CI history (or repeated local runs); dedupe against tracked flakes and open one tracking issue per newly-detected flake — routed to keel:ship.
Delegate a single issue to the right implementer and drive the s4 implement step standalone. Project-neutral — every project specific is read from .keel/project.yaml via the keel CLI.
Daily morning briefing — cross-session deferrals, shipped-since-last-brief, production/health signals, GitHub status, and a ranked focus list. Project-neutral; reads .keel/project.yaml.
| name | keel-onboard |
| description | Add keel to a repository by running the one-command setup flow, then verify config, adapters, and the rendered plan. |
Use this skill when the user asks to add keel to a project, install keel command adapters,
set up /keel:<command> for Claude, create the shared keel-<command> skills for other
agents, or migrate a repository onto keel without copying command bodies.
Work in a dedicated git worktree or otherwise confirm the active checkout is safe for generated file changes.
Confirm the keel CLI is available:
keel version
If it is missing, install a pinned release:
pip install keel-workflow
Run the one-command setup from the target repository root:
keel setup --root .
Use --wizard when the project should choose base branch, build command, timezone, or
merge window interactively. Use --adapter-target claude or --adapter-target skills
only when the user wants one surface. Use --force only when intentionally replacing
existing generated config and adapter files; it still must not delete or rewrite
.keel/extensions/*.
Review .keel/project.yaml and keep project-specific behavior in config, policy packs,
or .keel/extensions/. Do not copy or fork the packaged /keel:<command> bodies.
Run the deterministic verification checks:
keel validate .keel/project.yaml --root .
keel plan .keel/project.yaml --root .
keel adapter-status all --root .
Commit the generated config and adapter files in a normal PR. When keel is later upgraded, upgrade the installed package first, then sync generated adapters:
pipx upgrade keel-workflow
# or: python -m pip install --upgrade keel-workflow
keel sync --root .
keel validate .keel/project.yaml --root .
keel plan .keel/project.yaml --root .
keel setup is the preferred onboarding command because it wraps init,
install-adapter, strict validate, and plan.keel sync uses the installed keel package; it does not download the latest PyPI package..keel/project.yaml files are reused unless --force is supplied.