Menú
Add keel to a repository by running the one-command setup flow, then verify config, adapters, and the rendered plan.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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.