Kilagen
Git-native, AI-first framework to build and run a full security program — GRC and security engineering — as Markdown and YAML in a Git repository.
This repository is the framework. You do not run your security program from here: you instantiate it into your own repository, which gets a program/ layer holding your organization's content.
Using Kilagen
You install the package and scaffold a program in a repository you own. You never clone this one.
mkdir acme-security && cd acme-security
git init
pip install kilagen
kilagen init --name "Acme Corp" # or --guided, to be asked
init also takes --deployment (which CI to wire up, default github) and --agent (which agent integration to render, default claude). Both accept none. It records everything it copied, with a checksum per file, in .kilagen-manifest.yml.
Day to day:
| Command | What it does |
|---|---|
kilagen new <type> <slug> |
Writes a document from its template, in the folder of its type |
kilagen check |
Frontmatter, layout, vocabularies, cross-references, evidence freshness and what is falling due |
kilagen build |
Validate and build the dashboard |
kilagen build && kilagen serve |
The same, then serve it at localhost:8000 |
kilagen check reviews |
What expires: reviews, exceptions, gaps left open |
kilagen check evidence |
What each requirement can prove, and what has gone stale |
kilagen update evidence |
Run the collectors and record where the proof now lives |
check takes a target — frontmatter, refs, evidence or reviews — and runs all four without one. evidence and reviews report rather than fail, which is what makes them worth running; --strict is how a CI asks for the opposite. serve takes --port.
Keeping up with new releases:
| Command | What it changes |
|---|---|
pip install -U kilagen |
The framework itself: schemas, validators, dashboard |
kilagen update config |
The configuration init copied into your repo. Reports by default, writes with --apply, and leaves anything you edited alone. Never touches program/ |
kilagen update content |
Your program/ content, when a release changes what content must look like. Never touches the configuration |
Full walkthrough in keel/content/instantiation.md.
Working on Kilagen
This repository builds the package the section above installs.
git clone git@github.com:kilagenhq/kilagen.git
cd kilagen
./scripts/dev-setup.sh # virtualenv, dependencies, git hooks, editable install
source .venv/bin/activate
| Command | What it does |
|---|---|
python -m unittest discover -s tests |
The framework's own test suite |
npm test --prefix keel/dashboard |
The dashboard's test suite |
pre-commit run --all-files |
Markdown lint and spell check, as CI runs them |
./scripts/vendor-libs.sh |
Refresh the dashboard's vendored libraries after a version bump |
The dashboard's runtime libraries are committed under keel/dashboard/vendor/, so a fresh clone works immediately. They are refreshed only when package.json moves, and CI fails if the two disagree.
To exercise a change end to end, instantiate a throwaway program against your working tree:
mkdir /tmp/probe && cd /tmp/probe && git init
kilagen init --name "Probe" && kilagen check && kilagen build && kilagen serve
Releasing:
- Decide the version. A major means the rules changed: content that was valid before is not, and a migration ships with it. A validator that starts catching something it always should have is a minor.
- Edit
versioninpyproject.toml. It is the only place:kilagen --versionreads it from the installed metadata. - If the major changed, update the pin in the seed's workflows. A test fails if you forget, because a stale pin freezes every instance on the old major.
- Move the release's entries out of
UnreleasedinCHANGELOG.md. - Verify, build, tag, publish:
python -m unittest discover -s tests && npm test --prefix keel/dashboard
rm -rf build dist *.egg-info # setuptools caches the old file list in SOURCES.txt
python -m build
git tag v0.2.0 && git push --tags
- What Kilagen is and why it is shaped this way →
keel/content/design.md - The decisions behind it →
keel/content/adrs/ - Standards, requirements and framework coverage →
keel/content/compliance.md
Metadata
Release files for kilagen 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| kilagen-0.1.0.tar.gz | 325.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| kilagen-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 676.0 kB
Release files / kilagen-0.1.0.tar.gz
| Download URL | kilagen-0.1.0.tar.gz |
|---|---|
| Size | 325.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
d23a506ae94f13318566176c03166b3cd46f9e804d66b40c906aa2ba3c8918d8
|
|
BLAKE2b-256 checksum How to use checksums |
eabeb4b97cb799002d0b7f754d4e43b5954e5f2866acf676a667a93dc42210f1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|
Release files / kilagen-0.1.0-py3-none-any.whl
| Download URL | kilagen-0.1.0-py3-none-any.whl |
|---|---|
| Size | 350.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
8867a074c5f12af85d8b0cb505128543ad5b6a9475c52012f80d8c85dbed9ba3
|
|
BLAKE2b-256 checksum How to use checksums |
a3dc4a09442dc17ed493187be4bc797036dea368a06c5c5f54f11bd80bb6797c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|