The Tool nodes smart-base declares in its tools graph — one instance’s slice of every instance’s tools.

A skill states a capability generically: what an actor needs to know to perform a task. A Tool is one concrete way to exercise it, with an installation, an invocation and typed inputs and outputs. One skill may be satisfied by several tools, and one tool may satisfy several skills.

They are separate graphs and this is the tools one. The relation between them is satisfies, and it runs from a tool to a skill — this tool is one way to do that, never this skill is a tool.

12Tool nodes 9skills satisfied 12invoked as a shell command 0reachable over MCP

How they are invoked, and installed

A tool may declare more than one invocation, so these do not sum to the total.

invocation	tools
shell	12

installation	tools
none	12

Does every satisfies name a skill that exists?

Yes — all 9 skills named across 12 tools resolve to a skill document in this checkout. A satisfies pointing at nothing would be a tool advertising a capability the graph cannot locate.

Every tool

tool	what it does	invoked	satisfies	i/o
bpmn-to-fsh BPMN → FHIR Shorthand	Derive FSH from a DAK’s BPMN business processes — the render direction, of which the extractors are the inverse.	shell	smart-base-tools	1 in / 1 out
dak-api-hub DAK API hub	Generate dak-api.html and the per-artefact .openapi.json / .displays.json sidecars — the hub a reader enters the DAK API through.	shell	dak-postprocessing ig-artifact-ingestion	1 in / 2 out
dak-config-from-sushi sushi-config.yaml → dak.config.json	Derive the DAK configuration from sushi-config.yaml plus repository and branch context.	shell	dak-preprocessing	2 in / 1 out
dmn-to-html DMN → HTML	Render each DMN decision table to HTML for inclusion in a page, via dmn2html.xslt and dmn.css. The only human-readable rendering of a decision table an IG has.	shell	dak-preprocessing	1 in / 1 out
dmn-to-questionnaire DMN → FHIR Questionnaire	Generate FHIR Questionnaire resources from a DAK’s DMN decision tables. Authoring, not rendering: its output is validated and indexed by the IG Publisher like any other resource.	shell	dak-preprocessing	1 in / 2 out
extract-dak DAK spreadsheets → DMN, PlanDefinitions, CQL, requirements, logical models	Run WHO’s extract_dak.py in a DAK or IG repository: it reads the DAK template spreadsheets (input/decision-logic/*.xlsx via dt_extractor, input/system-requirements/*.xlsx via req_extractor, input/dictionary/*.xlsx via dd_extractor) and the BPMN, and writes the DMN decision tables, the CPG recommendation PlanDefinitions with their citations, CQL library skeletons, Requirements and logical-model FSH. The authoring path the WHO IG Starter Kit (l3_decisiontables, l3_cql) prescribes: an adapted decision or scheduling table is an edited copy of the upstream DAK’s spreadsheet, never a parallel format.	shell	smart-base-tools	1 in / 3 out
l1-extraction-pages Write the L1 extraction viewer: a page per instance holding l1-extraction directories, and a hub	For every visualiser an instance declares renderedBy: l1-extraction-pages, write the hub at <locale>/<harness>/<id>/ and, with subgraphs: "instance", one page per instance that declares an l1-extraction directory. Each shows what was extracted, read from the files by what they declare: the L1 statements (graph nodes carrying a statement, and an authored L1 source’s recommendations), the candidate work list’s counts, coverage and decisions, each graph document’s nodes by type and edges by predicate (the L2 scenario candidates among them), the curation, mapping, vocabulary, exclusions and run context counted, and every file linked to its published copy (cat-harness’s library:viz) when the site holds it and to its source at the pinned commit. A declared directory not on disk is reported UNKNOWN, never as zero.	shell	graph-rendering	3 in / 1 out
l1-recommendation-candidates L1 guideline → recommendation candidates (L1 3.0)	Find every normative sentence of an ingested library/ entry (folio-assistant-core’s l1-coverage markers), hint where a reading is uncertain, and propose the publication’s identity. Given an agent’s l1-recommendation-curation/v1, refuse a non-verbatim statement or an unknown location, and write the recommendations and remarks as an L1 3.0 graph, checked with kg/src/validate.ts, with coverage and the proposed (unsigned) exclusions.	shell	recommendation-candidates	2 in / 5 out
l1-recommendation-scenarios L1 recommendations → L2 user-scenario candidates	One smart-kg L2 user-scenario candidate per L1 recommendation, joined to a persona and a business-process by the edges smart-kg L2 already licenses, from an agent’s l1-scenario-mapping/v1. Reuses the guide’s own personas and processes, then smart-base’s generic DAK.Persona.*; otherwise a glossary candidate or could-not-determine, each with a WARNING. Never invents a process.	shell	recommendation-scenarios	4 in / 3 out
l1-transcription-verbatim Authored L1 → verbatim against transcriptions and image narratives	Check authored L1 (*.l1.yaml, the measles pattern) for a source with no usable text layer: each statement must be verbatim in the image narrative (images.json) or the transcription block it names, every transcription word (digits aside) must be corroborated by the entry’s text layer unless listed under inspectionOnly, and keys must be unique.	shell	transcription-verbatim	1 in / 1 out
smart-fhir-cache-seed Seed the FHIR package cache, with WHO’s published site as a source	Run fhir-harness’s fhir-cache-seed-npm with smart-base’s publisher-site rules (SMART_PUBLISHER_SITE_REPOS): smart.who.int.* packages are also read from WHO’s published-site repository, each fetch verified against the tarball’s own package.json. Every other source and check is the seeder’s own.	shell	ig-publisher-fork	2 in / 2 out
smart-liquid-variables IG metadata → Liquid variables	Scan the Publisher’s output/ for {ResourceType}-{id}.json and emit a Liquid include assigning smart__<ResourceType>__<id>__<category>__<key> for each published resource.	shell	dak-postprocessing	2 in / 2 out