ISO 9001 quality management — deployed in one command.
A reusable deployment kit that scaffolds an audit-ready QMS into your tool of choice on day one. Fill in your organisation's content over the following two weeks.
Setting up a QMS shouldn't take three consultants and two months. The structure — document tree, record trackers, review workflows, dashboards — is the same for every client. Only the content differs.
qms-kit deploys the structure. You fill in the content.
One command wires up spaces, document templates, issue trackers, and KPI dashboards for ISO 9001 clauses 4–10 — in XWiki + Redmine (self-hosted), Confluence + Jira (Atlassian), or SharePoint + Power Automate (M365). Reuse the same kit for every client; swap the overlay config.
⚠️ Scope: qms-kit delivers a documentation scaffold for internal maturity and customer/second-party audits. Accredited certification requires an additional operating phase (~3 months, full internal audit cycle + management review) that no tool can shortcut.
- 📋 ISO 9001 clauses 4–10 as structure — every space, page, and tracker maps to a clause.
- ⚙️ Config-driven, idempotent — declare your QMS in YAML; run deploy as often as needed.
- 🔁 Multi-tenant — one core config, one overlay per client. No copy-paste between engagements.
- 🧩 Adapter model — self-hosted, Atlassian, and M365 are interchangeable modules.
- 📄 Jinja2 templates — quality policy, procedures, management review agenda, internal audit checklist, CAPA form — all with placeholders, ready to hand to your client.
| Layer | What |
|---|---|
| Structure | Space / project, document tree, naming conventions |
| Document templates | Quality policy, procedures, MR agenda, internal audit checklist, CAPA/NC form |
| Record containers | Issue trackers for NC, CAPA, audits, KPIs |
# 1. Clone and install
git clone https://github.com/gerfru/qms-kit.git
cd qms-kit
uv sync
# 2. Start XWiki + Redmine
cp docker/.env.example docker/.env # fill in passwords
docker compose -f docker/docker-compose.yml up -d
# 3. One-time Redmine setup (manual — API limitation)
# See docs/redmine-setup.md
# 4. Create your client overlay
cp config/selfhosted.yaml config/clients/acme.yaml
# edit acme.yaml: org name, URLs, credentials
# 5. Validate (checks config + env vars, no writes)
export XWIKI_PASSWORD=Admin
export REDMINE_API_KEY=<your-key>
qms-kit validate --target selfhosted --config config/clients/acme.yaml
# 6. Deploy
qms-kit deploy --target selfhosted --config config/clients/acme.yamlRedmine custom fields (Root Cause, Effectiveness Check, etc.) must be created once manually — the Redmine API does not support creating field definitions. See docs/redmine-setup.md.
→ Full walkthrough: docs/setup.md
Requirements: an Atlassian Cloud account with admin access to a Confluence space and a Jira project.
# 1. Clone and install (same as above)
git clone https://github.com/gerfru/qms-kit.git
cd qms-kit
uv sync
# 2. Create your client overlay from the Atlassian template
cp config/atlassian.yaml config/clients/acme.yaml
# edit acme.yaml: org name, base_url (https://<org>.atlassian.net), email,
# space_key, project_key
# 3. Generate an API token at id.atlassian.com → Security → API tokens
export ATLASSIAN_API_TOKEN=<your-api-token>
# 4. Validate (checks config + token presence, no writes)
qms-kit validate --target atlassian --config config/clients/acme.yaml
# 5. Deploy
qms-kit deploy --target atlassian --config config/clients/acme.yamlOne token, two services:
ATLASSIAN_API_TOKENis used for both Confluence and Jira. The email in your overlay config must match the token owner's Atlassian account.
No API credentials needed — generates files you can upload to any document library.
# Export as standalone HTML (recommended for SharePoint document libraries)
qms-kit export --format html --config config/clients/acme.yaml --output-dir ./qms-export
# Export as plain Markdown (version control, email, local archive)
qms-kit export --format md --config config/clients/acme.yaml --output-dir ./qms-exportThe --output-dir defaults to ./qms-export/. HTML output includes an index.html
with links to all documents and a "← Back" navigation link on every page.
| Target | Status | Stack |
|---|---|---|
| Self-hosted | ✅ Phase 1 complete | XWiki (docs) + Redmine (records) via Docker |
| Atlassian | ✅ Phase 2 complete | Confluence + Jira via REST API |
| Export (M365 / archive) | ✅ Phase 3 complete | Markdown + standalone HTML via qms-kit export |
Atlassian note: Approval workflows and versioning are not native to Confluence Cloud — a Marketplace app (e.g. Comala) is required; that part is only partially automatable.
| 📋 Project Brief | Full requirements, constraints, and design decisions |
| 🚀 Setup Guide | Installation and first deployment |
| ⚙️ Configuration Reference | All YAML keys explained |
| 🏛️ Architecture | Four-layer design: config → templates → adapters → CLI |
| 🔌 Redmine Setup | Manual custom field setup (API limitation) |
| 📝 Template Reference | Jinja2 placeholders and rendering |
Python · Jinja2 · Pydantic · YAML · Click · Docker Compose · XWiki REST API · Redmine REST API · Confluence REST API v2 · Jira REST API v3
Three layers above the adapters: a config loader with Pydantic schema validation, a Jinja2
template renderer, and a single CLI entry point (qms-kit deploy --target).
AGPL-3.0 © Gerald Fruhmann