Generated from
fhir-harness/skills/fhir-ig-base/ig-site-theme.md— do not edit here.
ig-site-theme
Skill id:
ig-site-theme· Package:fhir-ig-base· Instance:fhir-harness· Beansk6tw,u3cd,bamf,7h3u
An IG staged as its own just-the-docs site (/<instance>/ig/, bean bamf)
wears the palette of the one webpage theme its instance declares. Nothing
new is authored for the IG: the theme already exists as data, and this is how
it reaches the site.
The path, end to end
- Declared — the instance’s
themes/themes.tsexportsINSTANCE_THEMES, one of which haskind: "webpage"and apaletteof four roles (surface,ink,edge,accent). Declaring a theme istheme-declaration’s subject, not this skill’s. - Resolved —
stage-ig-sites.tswebpagePalette(repoRoot, instance)reads it throughinstanceThemes(cat-harness/schemas/theme-by-ref.ts), keyed on the instance’s declared name. - Rendered —
build-ig-site.tscolourScheme(palette)writes_sass/color_schemes/ig.scssand setscolor_scheme: ig. just-the-docs’ own colour-scheme mechanism does the rest, so the IG keeps the theme’s machinery unchanged and only its colours move. The sidebar takesaccent; its text colour is chosen by contrast, and a pairing under WCAG AA is reported (CONTRAST:in the stage log), never hidden.
What is refused, and what is said
| case | outcome |
|---|---|
| no theme declared | built on just-the-docs’ default light scheme, and the stage log says colour scheme: NONE |
themes declared, none webpage | same, with the reason (declares themes, none of kind webpage) |
two or more webpage themes | refused — nothing says which one dresses the IG |
| a palette pairing below AA | built, and reported under CONTRAST: |
Three theme paths — do not conflate them
| path | surface | data | code |
|---|---|---|---|
IG site palette (this skill, u3cd) | the standalone IG site, /<instance>/ig/ | the webpage theme’s palette | stage-ig-sites.ts → build-ig-site.ts colourScheme |
docs-page theme (7h3u) | the instance’s composed docs pages, /<instance>/… | the same theme, as CSS variables | gen-themes-css.ts → _data/instance-themes.json → head_custom.html |
IG chrome (ajx9) | “fixture” pages that mirror the Publisher’s template | the template chain’s tokens and rules (chrome.json) | ig-chrome.ts, ingest-ig-chrome.ts |
The first two read one declaration, so an IG’s site and its docs pages cannot disagree on colour. The chrome is a different model — the Publisher template’s own CSS, ingested with its conflicts — and is not a palette.
Verify on the built CSS, not on a log line
A staged site’s theme is checked by finding the palette’s hex values in the
built stylesheet, e.g. for the WHO SMART Trust IG’s who-smart-ig (accent #00477d):
git show <gh-pages>:STAGING/<slug>/<ig>/ig/assets/css/just-the-docs-default.css \
| grep -c '#00477d'
Measured 2026-10-01: 15 occurrences of #00477d and 8 of #f6f7f9 on
the WHO SMART Trust IG’s staged IG site.
The trap this section exists for. Calling stageIgSite directly with no
palette option prints colour scheme: NONE — truthfully, for that call. Read
as a fact about the instance, it says the theme is missing when it is not. An
agent did exactly that on 2026-10-01 and opened k6tw on the false premise.
Stage through stage-ig-sites.ts (or pass webpagePalette(...).palette), and
judge the result by the built CSS.
Do not
- Author a second palette for the IG. One declaration, read by both paths above; a copy would be a second answer free to drift.
- Touch the theme’s machinery. just-the-docs’ layout, nav and components stay as they are; only the colour scheme is the instance’s.
- Put the WHO logo on it. Colour carries identity; the wordmark is set in type
(owner, 2026-10-01: “no branding” means no logos — bean
jut3).