Tools and workflow
Adding KLOD to Spec Kit and OpenSpec
Where the two KLOD steps fit in a Spec Kit or OpenSpec workflow, and the exact commands to install them from the public repository.

Most teams I talk to that build with coding agents plan a feature in a spec-first tool before the agent writes any code. The two I meet most often are Spec Kit, GitHub's toolkit with its specify command line and /speckit commands, and OpenSpec, which takes a change through a proposal, specs, design and tasks. Both are good at making the agent plan before it builds.
The plan is where the takeover decisions belong. If the feature calls a model while it runs, someone has to decide who can stop it, who finishes the work by hand, and which screens, data and permissions that person needs. I packaged KLOD for both tools so those decisions land in the plan and the check runs after implementation. Everything installs from the public repository at its release tag. There is nothing separate to download from this site.
KLOD adds two steps, whichever tool you use:
- The plan step writes the human path into the feature plan: how an authorised person finds unfinished work, reads what was saved, completes the task and stops further AI actions. It also adds checks that a late AI result cannot overwrite that person's decision.
- The check step reads the implemented code and the records you have, then writes
klod_report.mdwith evidence, gaps and what is missing. It reads test results and drill records. It does not run tests or drills.
Both apply to models the running application calls, including models you run yourself. A coding agent used only during development is not a runtime dependency and needs nothing here.
Spec Kit
You need a project already initialised with Spec Kit, version 1.0.6 or a later 1.x release. Every command below runs from that project's root, not from a KLOD checkout.
- Install the extension. The archive is attached to the KLOD release on GitHub, and Spec Kit asks you to confirm before it installs from a URL.
specify extension add klod --from https://github.com/AlexandruGirlea/keepthelightson/releases/download/v0.1.1/klod-spec-kit.zip
specify extension list
The list shows KLOD with two commands and two hooks. If your coding agent does not show the new commands, restart it.
-
Write the feature as usual with
/speckit-specifyand/speckit-plan. -
Before you generate tasks, run the KLOD plan step:
/speckit-klod-plan
It updates the feature's spec.md and plan.md and writes klod-plan.md next to them. It does not implement anything.
-
Carry on as usual with
/speckit-tasksand/speckit-implement. -
When the implementation is done, run the check:
/speckit-klod-check
The report lands in klod_report.md at the project root.
Those spellings are Claude Code's. Codex shows $speckit-klod-plan and $speckit-klod-check, and agents with dotted names show /speckit.klod.plan and /speckit.klod.check. Use whatever your agent lists.
Spec Kit also asks after plan and after implement whether to run the KLOD step. Say no if you want to run it later. To remove the extension, run specify extension remove klod. Your plans and reports stay where they are.
Tested with Spec Kit v1.0.6 and KLOD 0.1.1. The Spec Kit guide covers installing from a local checkout, updating, and what the compatibility checks do and do not prove.
OpenSpec
OpenSpec picks a schema for each change, and the schema decides which documents the agent produces and in what order. KLOD is a custom schema. OpenSpec has no command yet for fetching a schema from a repository, so the schema ships with a small installer.
You need a project already initialised with OpenSpec 1.13.0, plus Python 3.10 or later and Git.
- Clone the KLOD repository at the release tag next to your project, which keeps the checkout out of your own repository. Then run the installer from your project directory:
git clone --depth 1 --branch v0.1.1 https://github.com/AlexandruGirlea/keepthelightson.git ../keepthelightson
python3 ../keepthelightson/integrations/openspec/install.py --project .
openspec schema validate klod
The installer copies the schema into openspec/schemas/klod/ and changes nothing else: not your config, other schemas or existing changes. Commit the folder so the team works from the same version.
- Propose a change with the klod schema. In Claude Code, OpenSpec's own command takes the change name and the schema in one line:
/opsx:propose add-support-drafting with the klod schema
In other assistants, ask in plain words: "Use OpenSpec to propose add-support-drafting with the klod schema." To use KLOD for every new change instead, set schema: klod in openspec/config.yaml and stop naming it. Existing changes keep the schema they started with.
-
Read the proposal, specs, design and tasks it produces. Then start the implementation with
/opsx:apply add-support-drafting, or ask the assistant to apply the change. The apply instructions point at the bundled verification guide, so the assistant knows to run the change's tests and record what it could not check. -
To audit the whole repository rather than one change, ask:
Read openspec/schemas/klod/skills/klod-check/SKILL.md and follow it to audit this project. Write klod_report.md.
Tested with OpenSpec 1.13.0 and KLOD 0.1.1. The OpenSpec guide covers updates and what the installer refuses to overwrite.
Then run the drill
A plan and a report show what was designed. They cannot show that your team can do the work while the model is down. That takes a drill on real tasks with the AI switched off, and KLOD's L2 and L3 levels require that evidence. The two integrations give you the plan to drill against and the tools the drill needs.
If a step feels awkward, tell me. The integrations are a day old and I would rather fix a rough edge than have you work around it. I wrote about keeping the team ready in keep the people who keep you running.

