keel-work-blocklisted

# keel-work-block Use this skill when the user asks to run the keel command `work-block` (e.g. `keel work-block ...`, `work-block <args>`, or `/keel:work-block`). It reads every project value from `.keel/project.yaml` via the `keel` CLI. # /keel:work-block ## Live progress — stamp this run (required) So this run shows live on `keel-visual`'s board, record it with `keel activity` **as you go**. This command's phases are: `config` → `snapshot` → `loop` → `report`. Pick one stable `--run-id` for the whole run (e.g. `work-block-<issue-or-pr>`): - **Right now, before the work below**, stamp the first phase: `keel activity .keel/project.yaml --root . --write --command work-block --run-id "$RUN" --phase config` - Re-run with the next `--phase` (`snapshot`, …) **as you advance** through the flow. - At the end: `keel activity .keel/project.yaml --root . --run-id "$RUN" --done` Treat this like any other contractual step — do not skip it. The one allowed exception is a core too old to ship `keel activity` (keel < 1.6.0): then skip it silently and never block the command. ## Command step evidence Every numbered step in this command is contractual. Complete the step, record the evidence it asks for, or explicitly mark it `N/A — <reason>` before moving on. Any GitHub comment, review, issue label, branch, PR, merge, report, or queue write must be posted or written through the selected transport and cited in the final summary. Never silently skip a step because the runtime, agent,