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.
By instance
Each instance that declares a tools graph has its own page.
| instance | tools |
|---|---|
| cat-harness | 175 |
| cat-harness-tools | 1 |
| fhir-harness | 32 |
| folio-assistant-core | 12 |
| folio-assistant-sci | 8 |
| smart-base | 12 |
| who-iris | 1 |
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 | 212 |
| inProcess | 32 |
| mcp | 30 |
| manual | 6 |
| container | 1 |
| installation | tools |
|---|---|
none | 213 |
cli | 26 |
container | 2 |
Does every satisfies name a skill that exists?
Yes — all 105 skills named across 241 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 |
|---|---|---|---|---|
agent-memoryAgent memory assembler | Assemble every declared memory directory’s nodes into each agent’s memory, per vendor: Claude Code’s .claude/agent-memory/<agent>/MEMORY.md (a marked region, injected when the subagent starts) and Antigravity’s workspace skill .agents/skills/<agent>-memory/SKILL.md. Other vendors (Gemini CLI, Copilot, Codex, Cursor) are beaned under 31ni and not generated. | shell | agent-memory | 0 in / 1 out |
archimate-checkCheck an instance’s ArchiMate models against its config | The gate for the archimate graph typology: every model cat-archimate.config.json names is held, parses (Archi’s native XML or its zipped archive), and resolves — every box in every view draws an element the model holds, every relationship’s ends are in the model — and no .archimate file is held that the config does not name. | shell | archimate-models | 1 in / 1 out |
archimate-pagesGive every ArchiMate view, element and relationship a page and an IRI, and draw every view | Write a JSON-LD node and a thin page for each model an instance’s cat-archimate.config.json names and for every view, element and relationship in it — keyed by Archi’s own ids — plus the normalised model the pages’ one loader draws from, and every view drawn as SVG from the model’s own bounds and bendpoints in ArchiMate’s notation, each box a link to its element. --out writes into a site being built — the data at the graph’s path, the pages at the route of the visualiser the instance declares for this Tool, <locale>/<harness>/<id>/; without it the files go into the graph and --check gates them. | shell | archimate-models | 3 in / 1 out |
auto-docs-viewerGenerated index pages | Render index pages for the declared skills, docs and swimlane-glossary directories, one per directory. | shell | graph-rendering | 2 in / 1 out |
avatars-cssAvatar stylesheet | Render the declared avatar nodes — an actor’s glyph and colours, including the overlay states — into the stylesheet the site serves. | shell | site-presentation-assets | 1 in / 1 out |
bean-queryQuery the beans knowledge graph | Query the beans knowledge graph using named graph analytics or arbitrary SPARQL 1.1. | inProcess mcp | bean-coordinationtodo-manager | 3 in / 1 out |
beans-clibeans CLI | Read and write the work plan with the beans binary. The normal mechanism when it is installed. | shell | bean-coordinationcontinual-progressidle-backlogpending-showsession-intenttodo-manager | 3 in / 1 out |
beans-manualbeans, by hand | Read and write the same work plan without the CLI — scripts/beans-fallback.ts, or editing a bean’s front matter directly. Equal standing to the CLI, not a degraded mode. | manual shell | bean-coordinationcontinual-progressidle-backlogpending-showsession-intenttodo-manager | 3 in / 1 out |
bibliography-pageBibliography page | Render every reference in the checkout (each declared references directory’s folio-reference/v1 nodes and each catalogue directory’s Dublin Core records) as the bibliography page and one page per sub-graph, each with its BibTeX, CSL-JSON, RIS and Dublin Core JSON-LD exports and a per-reference export, at the route of the visualiser core declares for it. | shell | graph-rendering | 2 in / 1 out |
block-actionsBlock edit and feedback links | Each labelled block’s links back to where it can be changed: [edit] opens the block’s Markdown source in GitHub’s editor on main, and [feedback] opens a new GitHub issue about the block, from the folio’s .github/ISSUE_TEMPLATE/block-feedback.yml when it has one (prefilling only the fields it declares: block, section, source, page, url) or as a plain issue whose body carries the same facts. The document build draws these on every block; this Tool prints them as JSON for one block or all. Governed by the block-actions skill (bean uphx, REQ-17). | shell | block-actions | 5 in / 1 out |
bpmn-checklistBPMN checklist projection | Generate, per diagram, a checklist that walks the BPMN as a state machine: each task names the workflow_complete call that records it and ends with next: by node id; each decision lists its labelled branches (or the DMN that computes it); parallel forks name every branch and joins wait for all; start/end events are entry and exit lines. A rendering, never an authority: it says it is generated, and --check fails when one is stale. | shell | docs-generation | 2 in / 1 out |
bpmn-engineBPMN workflow engine | Run a declared BPMN process as an instance: workflow_start opens one for a subject, workflow_next reports what is enabled, workflow_complete records a step or answers a decision (a DMN-computed one from facts) and REFUSES a step that is not enabled. State is committed under the work plan, so which edge was taken is a record, not a memory. | inProcess mcp | process-state | 2 in / 1 out |
bpmn-renderBPMN diagram rendering | Render each process diagram to SVG for the documentation site. The .bpmn file is the source of truth; the picture is generated from it, so a diagram and its image cannot disagree. | shell | docs-generation | 1 in / 1 out |
bpmn-to-fshBPMN → 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 |
build-ig-siteStage one IG as its own just-the-docs Jekyll site | Turn an IG source repository into ONE Jekyll source for just-the-docs, as the IG Publisher builds one IG per site: input/pagecontent pages with title, parent and order from sushi-config.yaml pages:, the files the Publisher’s include tags resolve against, images, _data/fhir.json from ig-site-data, and a _config.yml. The pages render unchanged, including their references to the IG’s site data (bean bamf, owner’s choice of one site per IG). With the IG’s menu, the layout is the one every IG site wears (bean mftp): the IG’s own top bar, the IG’s TOC declared as the folio-assistant navbar’s section (added by rail-standalone-pages), no sidebar of its own, an edit link per page, and per heading a source-line link and a pre-filled feedback issue. | shell | ig-build-pipeline | 4 in / 2 out |
build-instance-siteBuild, check and (on request) publish an instance’s own site, or a STAGING/ | From a checkout whose layers arrive by remote mount: mount the pinned closure, install, run the instance’s own gates (--pre), compose the harness chrome for THIS instance, run its source steps, build with Jekyll at the base path read from the git remote (/<repo>, or /<repo>/STAGING/<branch> for a preview), run the post-build steps (mount-instance-docs, pdf-viewer, set-html-lang, publish-id-lookup, rail-standalone-pages), and check that every relative or base-rooted link in every page resolves to a file under the site, reading each page with an HTML parser. Any failing step stops the run; a link that does not resolve means nothing is published. It never decides to publish: only --publish does, and then a root publish keeps STAGING/ and _render-log/ on the branch, and a preview replaces only its own STAGING/<branch>/. | shell | deployment-awarenessremote-mount | 10 in / 2 out |
cat-harness-schemaInstance declaration schema | The zod definition of <name>.json — what an instance may declare about itself — and the published JSON Schema generated from it. | shell | kg-export | 1 in / 1 out |
check-dependenciesDependency probe | Report which of the harness’s optional and required dependencies are present on this machine, and what each unmet one blocks. | inProcess mcp shell | verify-local-substrate | 1 in / 1 out |
check-toolsDo the Tool nodes agree with their skills? | Check every Tool node’s joins: that each satisfies resolves to a real skill and agrees with that skill’s declared contract, that every io port names a declared type, and that no argv input has a type able to express a shell payload. | shell | code-node-review | 0 in / 1 out |
check-wireframe-questionnaireCheck a Questionnaire field for field against the wireframe it was derived from | Compare the data-element fields of a mid-fidelity wireframe (per data-layout, in document order) with the answerable items of a BUILT Questionnaire (depth first, named by definition or code). Reports a field with no item, an item with no field, an item naming no data element, a data element twice in one layout, and the first place the order differs. Fidelity, not design. Moved down from the WHO layer on the owner’s ruling of 2026-10-14: nothing in it is WHO’s. | shell | fhir-questionnaire-wireframe | 2 in / 1 out |
ci-healthIs CI passing on the default branch? | Report each workflow’s state on the default branch, which a checkout cannot see: a red workflow looks exactly like a green one from in here. One API call over the recent run history, not one request per workflow — fanning out would exhaust the unauthenticated 60/hr limit and make it unusable at session start. | shell | ci-health | 3 in / 1 out |
compose-docsCompose the site’s documentation tree from its declared docs layers | Write the Jekyll source the docs site is built from: the base docs layer, the repository overlay on top (an overlay’s _config.yml merged, every override reported), and each composed instance under its own name. --staging keeps staging-only visualisations; --changed-files stubs instances a branch does not reach. --shell writes the CHROME only — the layers’ Jekyll machinery and assets, no page, no instance, and the host’s generated includes empty — which an IG repository composes its IG into so its own site wears the main site’s chrome (#2235). | shell | harness-tiles | 4 in / 1 out |
content-contextContent JSON-LD context | Emit the published JSON-LD @context that both populations share — authored block siblings and ingested library/** nodes reference it by URL — generated from its TypeScript definition rather than hand-kept. | shell | kg-export | 1 in / 1 out |
content-graph-analysisEditorial content-graph analysis | Build the block- and section-level editorial dependency graph of one paper from its .ts manifests and report forward references, cross-chapter coupling, sparse or dense sections and isolated blocks, ranked. Reads uses[]/interprets only — the editorial relation, never the formal one. | shell | content-graph | 6 in / 1 out |
content-graph-buildContent graph | Build the content graph under a path and report its edges, separated into the EDITORIAL relation an author maintains and the FORMAL one derived from Lean. Reading the two as one number is how the editorial signal gets overwritten. | shell | content-validate | 2 in / 1 out |
content-graph-umlA paper’s block graph as UML | Draw a paper’s block graph from buildContentGraph: chapters as packages, editorial edges (uses / interprets) solid and formal Lean edges (type / value) dashed purple, never one derived from the other, and each block filled by its formalization status from proof-objects.json when given. One diagram for the paper and one per chapter, each in portrait and landscape, stamped with its source’s hash. Run from a folio: the platform carries no paper. | shell | content-graphgraph-rendering | 4 in / 1 out |
content-manifest-validateContent manifest validation | Validate the block manifests under a path against their schemas. Exits 2 where no folio is present rather than reporting a clean run — the platform carries no content, and a validator that passes over nothing is how this one validated nothing for a while. | shell | content-validatecontent-validation | 2 in / 1 out |
context-prefixesJSON-LD content-key check | Check every committed JSON-LD document that names the content context, or an instance’s own generated context: every plain key is a declared term (never descending into an @json value), and no file path sits under an @id-coerced term. An empty corpus is a finding, never a clean run. Prefixes are checked by jsonld:contexts --check. | shell | kg-export | 1 in / 1 out |
corpus-searchSearch the corpus and follow the graph | Seed lexically over the authored folio and every declared library, then expand along graph edges, labelling each hit MATCHED or REACHED and by which edge. Counts are split authored vs ingested, and a root that exists but holds no graph nodes is reported rather than read as an empty answer. | inProcess mcp | corpus-grep | 6 in / 1 out |
dak-api-hubDAK 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-postprocessingig-artifact-ingestion | 1 in / 2 out |
dak-config-from-sushisushi-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 |
declaration-resolutionEvery path a declaration names resolves — directories, assets, visualisers, needs | Read every instance declaration in the checkout and resolve what it names: directories (and those declared from within) through check:declared-dirs, assets through check:declared-assets, visualisers[].renderedBy through check:visualiser-routes, needs through the instance-graph resolver, and visualisers[].coversKinds against the graph typologies registered IN THIS CHECKOUT — its own and those a mounted layer contributes, read from the checkout under inspection rather than from where the harness module sits (lesson 6). A declaration that does not parse is a finding. One verdict per instance and field, naming the gate that decided it. Exit 0 every reference resolves, 1 one does not, 2 could not determine; a certain finding is reported before anything undetermined. | shell | kg-separation | 2 in / 1 out |
discussdiscussion | Put a question to a person or a sibling agent and receive an answer, to determine which harness this repository should become and which repositories are read from and written to. The two facts no file holds. | manual | discussion | 2 in / 1 out |
dmn-to-htmlDMN → 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-questionnaireDMN → 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 |
document-kinds-viewerDocument kinds viewer | Render each declared document-kinds directory: every kind’s structure, sections and sources, one page per subject instance. | shell | graph-rendering | 2 in / 1 out |
dublin-core-renderDublin Core renderings | Render every folio-dublin-core/v1 record a catalogue item names as Dublin Core XML (qualified DC, per DCMI’s XML guidelines) and as JSON-LD bound to DCMI Metadata Terms. Both are written into the instance’s published root (<instanceRoot>/dublin-core/<stem>.dc.xml and .dc.jsonld), so the site mount publishes them beside the item pages. Deterministic. --check fails on a missing, stale or orphaned rendering. Governed by the dublin-core-renderings skill (bean 7eak). | shell | dublin-core-renderings | 2 in / 1 out |
external-schemas-viewerExternal schemas viewer | Render the declared external schemas, and which of this instance’s modules conform to each, as one page. | shell | graph-rendering | 2 in / 1 out |
extract-dakDAK 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 |
feature-stagingStage a branch’s preview | Publish a branch’s built site to STAGING/<slug>/ on the publish branch, so a reviewer compares a rendered before and after rather than a description of one. Stamps the commit SHA, and removes the preview when its pull request closes. | shell | feature-staging | 3 in / 1 out |
fhir-cache-seed-npmSeed the FHIR package cache from trusted sources (exact versions) | Fill ~/.fhir/packages (or --cache) for an environment that cannot reach packages.fhir.org, from trust anchors only: npm account grahamegrieve (owner-trusted), publishers’ own published-site repositories (the seeder’s list, each fetch verified against the tarball’s own package.json), template repos found through FHIR/ig-registry’s templates.json read live each run, and an owner --mirror. Exact versions only (a patch wildcard resolves as the Publisher resolves it, recorded); every tarball verified; nothing computed once and kept; provenance recorded; missing versions listed, never substituted. | shell | ig-publisher-fork | 5 in / 2 out |
fhir-package-mirrorMirror FHIR packages from packages.fhir.org into a git repository | On a machine that reaches packages.fhir.org, fetch exactly a missing list (from fhir-cache-seed-npm --missing-out), check each tarball names itself exactly, record SHA512SUMS, and commit and push to a git repository that an environment without packages.fhir.org reads with --mirror. The person running it is the trust anchor for what it adds. | shell | ig-publisher-fork | 2 in / 1 out |
folio-block-qa-summaryFolio block QA summary | Summarise a folio’s committed per-block QA verdicts into one block-qa.json a staging preview publishes: each block is failing (a FRESH verdict failed, with the worst severity), stale (a verdict predates the block’s current files), passing, or unaudited. Freshness is the QA sweep’s own rule, including the uses-graph hash for graph-scoped criteria. Runs no checker and writes no verdict. | shell | review-heatmap | 3 in / 1 out |
folio-block-screenshotsFolio block screenshots | Picture each changed figure, diagram, table, equation or simulator block on the published main site and on a staging build, and compare the two pictures pixel by pixel in Chromium’s canvas. Writes visual-diff.json (folio-visual-diff/v1: per block, the share of pixels changed beyond anti-aliasing, and the before, after and diff pictures) and visual/*.png, which the review page’s visual renderer shows. A side that cannot be pictured (page or anchor missing) is recorded as missing, never drawn blank. Adds no dependency: Playwright is already the platform’s browser driver. | shell | visual-diff | 5 in / 1 out |
folio-changesetFolio ChangeSet | What changed in a folio between two git refs, block by block: each block added, removed, or changed — and for a changed block, every aspect that applies (renamed, prose, manifest, moved). Keyed on the block label, which the id-unique / id-stable QA criteria guard, not on file paths. | shell | diffstaging-review | 5 in / 1 out |
folio-initScaffold a folio | Create a new folio repository that uses this platform — folio/, uploads/, library/, the first manifests, the builder shim, agent files, and the link back to the platform. | inProcess mcp shell | getting-startedrepo-conversion | 9 in / 1 out |
folio-review-comment-moveMove a review comment’s status | A review-process task moves one review-comment/1.0.0 todo’s status (address, send back, resolve, adjudicate, withdraw) through transition(), which refuses any move the named BPMN task may not make. The comment is written to the folio’s todos graph (its declared todo-feedback directory) and, with --commit, committed to the edit-set’s FEATURE branch. Refused on the base branch and on a detached HEAD. | shell | review-comments | 9 in / 1 out |
folio-review-commentsFolio review comments | Ingest a pull request’s tagged conversation comments (block: <label> on the first line) into review-comment/1.0.0 todos, and write them as review-comments.json. Idempotent over its previous output, whose statuses it keeps. Re-anchors every comment against the head’s blocks, following renamedFrom, and orphans a comment whose block is gone rather than dropping it. | shell | review-comments | 10 in / 1 out |
folio-review-coverageFolio review coverage | Compute the two facts content-change-review.bpmn’s coverage gate (GW_Covered) reads: uncoveredBlocks, the changed blocks with no reviewer verdict on their CURRENT hash, and openDefects. Reads a preview’s changeset.json, blocks.json and review-comments.json. With --commit, writes the ingested folio-review-verdict/v1 verdicts into the todos graph’s declared review-verdicts directory and commits them to the edit-set’s FEATURE branch; refused on the base branch and a detached HEAD. Prints the facts as JSON on stdout. | shell | review-comments | 7 in / 1 out |
folio-viewerFolio viewer | Render each declared folio directory as a browsable page over its published index. | shell | graph-rendering | 2 in / 1 out |
fsh-coneFSH dependency cone | Compute the dependency cone over an IG’s FSH graph, and the blast radius of a set of changed files. What makes an incremental IG build possible: without it, any edit rebuilds everything. | shell | fhir-validation | 5 in / 1 out |
gatesThe platform’s quality gates | Run the checks CI runs, derived from the workflow rather than listed here. One Tool for all of them, not one per gate: the list is computed from .github/workflows/code-quality-gates.yml at call time, so it cannot drift from what CI actually enforces. | shell | continual-progressplatform-gatesprepare-merge | 2 in / 1 out |
gates-mergedGates on the merged tree | Build this branch merged with the current base in a throwaway worktree and run the full bun run cat gates there — the state a merge will actually produce, which neither the branch’s CI nor the base’s CI evaluates. Exit 0 passes, 1 conflicts or fails, 2 could not determine (never read as clean). The working copy is never touched. | shell | prepare-merge | 1 in / 1 out |
get-graph-statsContent graph counts | Node and edge counts for the content graph by provenance and kind, and whether each root exists. Tells ‘nothing matched’ from ‘that population has not been built’. | inProcess mcp | corpus-grep | 1 in / 1 out |
get-neighborsWalk the content graph from one node | List the nodes adjacent to one node, out (what it depends on) or in (what depends on it), to a given depth and optionally over named edge terms only. An unknown edge term is reported, never silently dropped. | inProcess mcp | corpus-grep | 4 in / 1 out |
gh-pagesGitHub Pages (gh-pages) | Push a rendered Knowledge Graph to GitHub Pages at a publication root URL — a staging preview (STAGING/<slug>/) or the release root, the same steps either way — and report the push: a status (pushed, not pushed, could not determine) and one message carrying the commit merged onto gh-pages and the QA result. Its steps are bootstrap-tools’ render-kg-to-github-pages process, which first provisions the target: an orphan gh-pages branch, then Pages switched on to serve it. | manual | render-kg-to-cdn | 4 in / 2 out |
github-branchesList branches (GitHub) | List the branch names of the current checkout’s GitHub project, as the forge reports them. | shell | coordinate | 0 in / 1 out |
github-pr-checksRead a pull request’s checks (GitHub) | Read the check runs of one pull request and their state. | shell | prepare-merge-autowatch | 1 in / 1 out |
github-pr-commentComment on a pull request (GitHub) | Add a comment to one pull request. The comment is read from stdin, never from the command line. | shell | coordinateprepare-merge-auto | 2 in / 1 out |
github-pr-filesList a pull request’s changed files (GitHub) | List the paths one pull request changes. | shell | coordinate | 1 in / 1 out |
github-pr-listList pull requests (GitHub) | List the open pull requests of the current checkout’s GitHub project, optionally only those from one branch. | shell | coordinatepickupprepare-merge-auto | 1 in / 1 out |
github-pr-request-reviewRequest review on a pull request (GitHub) | Ask one or more accounts to review a pull request. Adds to the reviewers already requested. | shell | pickupprepare-merge-auto | 2 in / 1 out |
github-pr-resolve-threadResolve a review thread on a pull request (GitHub) | Mark one review thread on a pull request as resolved. A GitHub thread id names its pull request, so no number is needed. | shell | coordinate | 1 in / 0 out |
github-pr-viewRead a pull request (GitHub) | Read one pull request: title, state, body, and its comments and reviews. | shell | coordinatepickupprepare-merge-autowatch | 1 in / 1 out |
gitlab-branchesList branches (GitLab) | List the branch names of the current checkout’s GitLab project, as the forge reports them. | shell | coordinate | 0 in / 1 out |
gitlab-mr-commentComment on a merge request (GitLab) | Add a comment to one merge request. The comment is read from stdin, never from the command line. | shell | coordinateprepare-merge-auto | 2 in / 1 out |
gitlab-mr-listList merge requests (GitLab) | List the open merge requests of the current checkout’s GitLab project, optionally only those from one branch. | shell | coordinatepickupprepare-merge-auto | 1 in / 1 out |
gitlab-mr-resolve-threadResolve a review thread on a merge request (GitLab) | Mark one discussion on a merge request as resolved. | shell | coordinate | 2 in / 0 out |
gitlab-mr-viewRead a merge request (GitLab) | Read one merge request: title, state, body, and its comments and reviews. | shell | coordinatepickupprepare-merge-autowatch | 1 in / 1 out |
glossary-buildGlossary build | Build a paper’s glossary index from its manifests and render the LaTeX. --check reports drift instead of writing, comparing everything except the generated timestamp so a re-run is not mistaken for a change. | shell | document-intake | 2 in / 1 out |
glossary-pageGlossary page | Render every declared glossary — authored SKOS schemes, the swimlane ledger and the terms extracted from knowledge-graph assets — as the glossary page and one page per asset type, at the route of the visualiser core declares for it. | shell | graph-rendering | 2 in / 1 out |
handover-screenScreen a hand-over for injected instructions, field by field | Before a model reads a sub-agent’s report, a delegated prompt, a tool result or a comment from someone who is not the principal, screen it against a declared schema whose top-level fields are control (steers what the receiver does) or data (content it reads). A finding in a control field, or any field the strict schema does not declare, is REFUSED, so a report cannot extend the delegator’s plan. A finding in a data field is QUARANTINED: the original is kept and marked, never stripped. The patterns are a deterministic tripwire (instruction overrides, role and turn spoofs, fence breaks, tool-call syntax, hidden Unicode, exfiltration links, pipe-to-shell), a mitigation and not a guarantee. Exit 0 clean, 1 refused, 3 quarantined, 2 could not determine. | shell | security | 3 in / 1 out |
headless-render-qcHeadless render QC (Playwright) | Drive a folio’s built viewer in headless Chromium and report the blocks whose diagrams, SVGs, LaTeX math or markdown do not render — with --screenshot to save the pictures. This is the mechanised half of looking at it: a green gate set is not a rendering. | shell | rendered-verification | 1 in / 1 out |
ig-artifact-jsonldWrite one JSON-LD node per IG artefact, and check a built site’s nodes | write turns an artefact index into artifact/<Type>-<id>.jsonld (and a .json twin) under a docs root: one folio-ig-artifact-jsonld/v1 node per artefact, in borrowed vocabularies only (the FHIR RDF class, dcterms, schema.org, PROV), naming the artefact’s canonical URL, its representations and, for a compiled copy, what built it. check is the kind’s QA: over a BUILT site, every artefact has its node and no node is an orphan, each node is its own file’s, its twin matches, and every local resource it names is on the site. It also writes and checks the index node, artifact/index.jsonld (folio-ig-artifact-index-jsonld/v1): every artefact once, each entry naming its node. WHO-free; the assets the thin pages render (owner, 2026-10-11, option A; thin by default since 2026-10-12). | shell | ig-build-pipeline | 6 in / 1 out |
ig-ast-diffList and view the delta between two IG ASTs | Diff two ASTs by resource key: added, removed, changed (with a structural element-level differential) and version-changed resources, plus edges added and removed; optionally fold in the incremental plan, and render just-the-docs pages (an index that lists, a page per resource that shows) every one of which carries the provisional mark. list <ast> summarises one AST. | shell | ig-ast-delta | 4 in / 2 out |
ig-ast-exportBuild an IG and write its AST | Run one ordinary IG Publisher build through AstPublisher (a subclass that overrides nothing) and write the AST beside output/: one JSON file per resource keyed canonical\|version, dependencies.json (upstream’s DependencyAnalyser plus the Library/PlanDefinition/ActivityDefinition/Measure edges it leaves empty), SUSHI’s fsh-index.json, and a manifest that declares itself a cache and records the inputs it is valid for. | shell | ig-publisher-fork | 2 in / 2 out |
ig-ast-incremental-buildRebuild only the cone of a change and merge it into the AST | Write the unchanged part of a base AST as a FHIR package into the package cache, build a temporary IG of only the rebuild set with the stock Publisher, merge the result into a mixed-provenance AST (builtAt per resource), and repeat while the merged graph’s cone reaches resources that were not rebuilt. | shell | ig-publisher-fork | 5 in / 1 out |
ig-ast-jsonldExport an IG AST as JSON-LD | Write an AST as linked data against fhir-harness/schemas/ig-ast.context.jsonld: each resource a node identified by its canonical URL (urn:fhir:<Type>/<id> when it has none) and typed by its FHIR resource type, each dependency edge a link to its target, and the manifest’s authority: cache and provisional list carried on the graph. The AST is validated against the Zod declaration the JSON Schemas are generated from before it is exported (bean l0lq). | shell | ig-ast-delta | 1 in / 1 out |
ig-ast-listSummarise one IG AST | Counts per resource type, edges in total and resolved inside the IG, edges by origin (upstream’s DependencyAnalyser or ast-export’s LogicEdges), whether the AST is mixed-provenance and how many resources each revision built, and what the manifest declares provisional. | shell | ig-ast-delta | 1 in / 1 out |
ig-ast-measure-real-igsMeasure the AST export on real IGs | Build the WHO SMART Trust and Immunizations IGs through ig-ast-export and print the W1/W2 measurements: counts, whether FSH sources sit where the plan expects, and logic-layer edge coverage per resource type against 458 of 458. --byte-identical adds a stock build and an output/ diff. | shell | ig-publisher-fork | 1 in / 1 out |
ig-ast-planPlan an incremental IG build from a delta of changed files | Map a delta (a commit range, a PR’s diff, or the staged index) onto a base AST: which resources to rebuild (the forward cone), which to load from cache, which to remove, or a full build and why. Builds nothing. | shell | ig-ast-deltaig-publisher-fork | 4 in / 1 out |
ig-ast-refreshRefresh an IG’s AST cache on a runner | Dispatch an IG repository’s ig-ast-refresh.yml, which calls fhir-harness’s reusable .github/workflows/ig-ast-refresh.yml: mount the layers the IG’s index.lock.json pins, restore and judge the cache for ref, and when it is not valid (or force) run the caller’s optional pre-export overlay command and build the IG with the pinned Publisher AST exporter (the AST is recorded against the clean commit’s inputs, the overlay’s changes put back), check the new AST is valid for its commit, and seed cat/fhir-harness/fhir-ast/<package id> with ig-cache seed --push — only from a commit on the default branch with the tip’s inputs. Builds no site, writes no gh-pages, dispatches nothing. | shell | compiled-artefact-cacheig-build-pipeline | 3 in / 1 out |
ig-ast-renderRender a computed IG AST delta as just-the-docs pages | Write the pages for a delta already computed by ig-ast-diff --json: an index that lists, a page per changed resource that shows, every one opening with the provisional mark and with Liquid in values neutralised. | shell | ig-ast-delta | 2 in / 1 out |
ig-ast-validityIs this IG AST still valid for the IG’s current inputs? | Run folio-assistant-core’s compiledValidity on an AST manifest’s inputs: recompute the input digest (the same algorithm as the Java writer, pinned by a shared golden vector) and the source revision, and answer valid, stale-inputs (naming which input), or cannot-tell. | shell | ig-ast-delta | 3 in / 1 out |
ig-binary-auditMeasure the IG Publisher’s binary outputs on a pages branch | Read a pages branch’s git tree and report the Publisher’s binary outputs (full-ig.zip, package.tgz and variants, package.db, validator packs, the definitions/examples/expansions zips, spreadsheets) by name: copies, bytes, and how much of it sits in branch previews. Reads the tree, never a checkout, so a multi-gigabyte branch costs a depth-1 fetch. | shell | ig-binary-artefacts | 2 in / 1 out |
ig-cacheFHIR AST cache | Restore, verify, seed and diagnose the prebuilt AST artefacts for an IG. Always try restore first: a full AST build via AstExportCli is expensive, a restore is fast. | shell | compiled-artefact-cacheig-ast-delta | 4 in / 1 out |
ig-folio-site-workflowBuild and publish an IG repository’s own site with its folio-site.yml workflow | Dispatch the IG repository’s folio-site.yml (copied from the IG layer’s ig-repo-site template): on a runner it composes the harness chrome for THIS instance (compose-docs --shell --instance, gen-navbar-include), composes the IG at the root of that Jekyll shell (stage-ig-sites --compose-at-root), builds it with Jekyll so every IG page wears the theme’s side bar, search box and icon row, publishes the instance’s served directories, rails any page Jekyll did not lay out (rail-standalone-pages --foreign-site --instance), stamps the platform that built it (folio-build.json), and on the default branch deploys the whole site to the gh-pages root. It reports platform drift against sibling sites and re-dispatches the IGs this one depends on when a token allows. | shell | feature-stagingharness-tiles | 2 in / 1 out |
ig-pagesGenerate an IG instance’s reader-facing pages from its artefact index | Write <instance>/docs/ — an index page, one page per artefact, a page per over-large category and per menu group — from fhir-artifact-index/index.json (and menu.json when ingested), styled by the template chrome an owning instance ingested. Moved down to this layer because nothing in it was one IG’s own (#1767); with --summary it writes an instance’s landing page, opening with that instance’s harness section. For an instance whose docs declare igSite (bean mftp) it writes no index, menu or category pages — the IG site’s own replace them — and only a front-matter artifacts.md naming the Tool that drew it. Where an instance declares a visualiser renderedBy: ig-pages, it also writes that visualiser’s route page, <base>/<instance>/<id>/, which opens the artefact index; with --site <dir> it writes only those route pages, under that site. For an IG whose SOURCE is at hand, build-ig-site renders the IG’s own pages instead; this is for an IG known only by what it published. | shell | ig-build-pipeline | 9 in / 1 out |
ig-repo-siteBuild an IG repository’s own site from its cached AST, with no instance declaration | The three checkout scripts the platform’s site build runs for a repository that holds an IG and only mounts layers (index.config.json): ig-site:ast restores the AST from the IG’s cache branch (ig-cache.sh restore) and judges it, refusing a stale, cannot-tell or absent one (a stale one is accepted for a preview with SITE_ACCEPT_STALE_AST=1); ig-site:compose derives the artefact index from the AST (binding any IG API sidecars a layer above left in $SITE_WORK/ig-api/), writes the thin artefact pages, stages the IG’s input/ and sushi-config.yaml (menu read at build time, palette from the webpage theme of the top layer the repository mounts, edit links from its origin) and composes it at the ROOT of the host site source; ig-site:publisher-pages serves the AST’s resources (ast-data/ and <Type>-<id>.json), the artefact index and the sidecars, refuses a page wearing the IG Publisher’s chrome, repairs repeated element ids and stamps folio-build.json. Never runs the Publisher and never reads its output. Compose lists the pages it puts in the site in FOLIO_SITE_UPSTREAM_PAGES, so the site build reports the IG’s own dead links rather than refusing the publish over them. | shell | ig-build-pipeline | 4 in / 1 out |
ig-site-dataPopulate site.data.fhir for a just-the-docs IG render | Write the IG Publisher’s Jekyll variables (site.data.fhir.ig.*, packageId, canonical) for ONE implementation guide, from sushi-config.yaml or a published IG’s fhir-artifact-index, so pages written for the Publisher render on just-the-docs unchanged. fhir-harness declares site.data as a pass-through Liquid prefix; this is what Jekyll then reads (bean bamf). | shell | ig-build-pipeline | 3 in / 2 out |
index-config-migrateConvert a checkout to a root index.config.json | Write the root index.config.json (folio-index-config/v1) that says which instances the checkout instantiates, where each comes from (source.local or source.remote) and which owns / (site.landing), from the root *.config.json files and the declaration’s remoteMounts. With --write it moves remoteMounts off the declaration into source.remote entries, writes the generated .gitignore block, and renames a legacy <name>.mount-lock.json to index.lock.json. Without a flag it prints the index it would write. Idempotent: a re-run merges what the declaration gained, and refuses an entry the index already holds differently. A root config naming no instance is reported as unmatched-config and not imported, because what to do with it is a person’s decision. | shell | index-configremote-mount | 3 in / 1 out |
ingest-extendedIngest, with PDF and image extensions | Ingest a PDF into library/ — embedded outline, page text, OCR for scans, and image extraction — using PyMuPDF, tesseract and pypdf with Pillow. | shell | library-ingestion | 3 in / 1 out |
ingest-ig-menuIngest an IG’s navigation from its sushi-config | Read menu: (and the page tree) out of an IG source repository’s sushi-config.yaml into fhir-artifact-index/menu.json, recording the repository and commit it was read at — the declared source stage-ig-sites clones. --check re-derives it against a checkout; with no --source it reports COULD NOT DETERMINE and exits 2, never 0. | shell | ig-build-pipeline | 3 in / 1 out |
ingest-ig-releasesRecord an IG’s GitHub releases as pointers to their binary assets | Read an IG repository’s GitHub releases and write fhir-artifact-index/releases.json (ig-releases/v1): each asset’s name, size, SHA-256 digest and download URL, never its bytes. The IG site’s generated releases page lists them (bean b8ip). | shell | ig-binary-artefacts | 2 in / 1 out |
ingest-stdlibIngest, standard library only | Ingest an upload into library/ using only the Python standard library — archive listings, CSV and spreadsheet records, technical file metadata, and the content sniff that routes a file to its rung. | shell | library-ingestion | 3 in / 1 out |
iris-pagesIRIS replica and catalogue pages | Render who-iris’s replica of the IRIS site, its docs pages, and the catalogue visualiser who-iris declares — what the catalogue knows and what it records that it does not know — at that visualiser’s declared route. | shell | graph-rendering | 1 in / 1 out |
jsonld-vocabulariesValueSet expansions → JSON-LD | JSON-LD vocabularies built from the ValueSet expansions in the published output. | shell | ig-build-pipeline | 1 in / 1 out |
judge-treeJudge a tree and record the verdict by digest | Run the layer PR-check gates and tests on a composed tree (head) and on its base, or reuse a stored verdict whose digest is the base tree’s, compare them with the layer-pr-checks compare scripts, and write a verdict record: {treeDigest, runner {kind agent|github-actions|local, id}, startedAt, finishedAt, gates [{name, exit, seconds, skipped?}], tests {total, failed, new}, verdict green|red|unknown}. With a token it publishes the verdict as the commit status judge-tree; check answers whether any runner judged a digest green; sample re-runs a seeded few gates of a record. | shell | platform-gatesprepare-merge | 10 in / 1 out |
kg-auditKnowledge-graph audit | Audit every join in the actor→role→skill→task sentence and write a committed QA sidecar per node. A printed verdict is gone; a sidecar is what makes “unbound since it was drawn” distinguishable from “broken in the commit under review”. | shell | code-node-review | 2 in / 2 out |
kg-graph-exportKnowledge-graph export | Dump this instance’s knowledge graph — skills, BPMN activities and their lanes, roles, actors, directories — to one JSON-LD document for publication. The export is data; something else draws it. | shell | bootstrap-graph-emissionbootstrap-graph-publicationkg-export | 2 in / 2 out |
kg-retrieve-npmRetrieve a remote Knowledge Graph via npm package or tarball | Retrieve and inspect a remote Knowledge Graph packaged as an npm package or tarball (.tgz), supporting both unhydrated source graph views (authored declarations, skills, schemas) and hydrated materialized graph views (subgraph JSON-LD, metadata indexes, dereferenced graph projections). | shell | npm-kg-distributionremote-mount | 4 in / 2 out |
kg-validateValidate a node in the graph | Check one file against the schema for its graph typology. ONE tool rather than one per schema: the declaration already says which directory holds which kind, so the kind is the parameter and the lookup does the rest. | shell | kg-navigation | 2 in / 1 out |
kg-viewerKnowledge graph viewer | Render the instance’s published knowledge graph as one page: facets by kind and sub-graph, search, a node’s properties, its edges and back-links, and the graph’s own gaps — reading the JSON-LD document at the site root rather than carrying a copy. | shell | graph-rendering | 2 in / 1 out |
l1-complete-checkL1 source completeness | Is a library/<bib-slug>/ entry complete as L1 source content? Each requirement is met, unmet, or NOT-DERIVABLE, so a document that cannot yield an artefact is distinguished from one that simply has not. | shell | library-ingestion | 1 in / 1 out |
l1-coverageL1 extraction coverage | Of the normative sentences in a publication (the closed marker list of smart-kg’s docs/COVERAGE.md §1), count how many an L1 extraction CAPTURED, how many are EXCLUDED for a fixed-list reason a person signed off, and how many are UNACCOUNTED — per page and in total. Writes the contract’s §4 report and exits non-zero below 100% accounted-for. Issue #2405 FR-009. | shell | l1-coverage | 4 in / 1 out |
l1-extraction-pagesWrite 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-candidatesL1 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-scenariosL1 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-verbatimAuthored 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 |
latex-imageCompile LaTeX in a container | Compile a rendered paper’s main.tex with latexmk inside a TeX Live (full) image, for a host with Docker but no TeX engine. The image carries TeX Live, latexmk, Pandoc, latexdiff, graphviz and poppler-utils; it does not run the content pipeline, which renders the chapters on the host first. | container | latex-build-cache | 1 in / 1 out |
latex-overfullLaTeX overfull-box report | Turn a pdflatex log’s Overfull \hbox warnings into a located, actionable report, with a threshold so a long tail of trivial overruns does not bury the real ones. | shell | latex-validation | 4 in / 1 out |
latex-preflightLaTeX preflight | Lint TeX source for the pdflatex-compile failure classes a permissive AST parser accepts — the ones that pass validation and then break the build. | shell | latex-validation | 2 in / 1 out |
latexmk-compileLaTeX compilation (latexmk) | Compile LaTeX source documents into PDF using latexmk with safe shell-escape isolation across CI events. | shell | latex-compilation | 2 in / 1 out |
lean-auditLean vacuity audit | Inspect Lean declarations chapter by chapter for proofs that type-check, are sorry-free and axiom-clean, and still carry no mathematical content — assuming what they claim, concluding something trivially true, or resting on a false premise. | shell | lean-proof-vacuity-audit | 4 in / 1 out |
lean-buildLean build | Build every Lean project in the workspace from the root Lake manifest, so cross-package dependencies resolve against it rather than a possibly-stale per-paper manifest. Writes a committable build-status sidecar every run. | shell | lean-build-fix | 4 in / 1 out |
lean-cacheLake olean cache | Restore, verify, seed and diagnose the prebuilt .lake/ artefacts for a Lean package. Always try restore first: a from-source Mathlib build is 30–60 minutes, a restore about two. | shell | lean-cache-restore | 3 in / 1 out |
lean-coverageLean coverage | Count how many provable blocks — theorem, lemma, proposition, corollary — carry a full Lean proof rather than a sorry, per paper. The completeness half of the Lean audit: what is formalised, and what is still a gap. | shell | lean-completeness-audit | 4 in / 1 out |
lean-formal-edgesFormal edges from the Lean build | Extract ELABORATED formal dependencies between a folio’s lean.ref declarations (LeanArchitect’s rule over the folio’s own lean.ref set). Needs a Lean toolchain and a built Lake project. Tagged declarations missing from the build are reported, never recorded as dependency-free; with ingest the result is recorded in the formal cache as source “elaborated”. | inProcess mcp | lean-formal-edges | 3 in / 1 out |
lean-html-docsBuild a Lean package’s HTML docs (doc-gen4) | Build the doc-gen4 HTML render of a folio’s Lake package — the visualiser of a declared lean directory — with lake -R -Kenv=dev build <Lib>:docs, cache-aware: refuses while another lake/lean process holds .lake/, refuses on a restored tree that carries no traces (a Lake build there EVICTS the cache), checks or restores the warm cache first, and enables a sentinel-commented doc-gen4 [[require]] for this build only, restoring the lakefile on exit. Never runs lake update. Output: <lake-root>/.lake/build/doc. | shell | lean-html-docs | 6 in / 1 out |
lean-kg-publishPublish the dynamic Lean viewer: doc-gen4 declaration data as knowledge-graph shards | Ingest doc-gen4’s per-module declaration data (.lake/build/doc-data/declaration-data-<Module>.bmp) into JSON-LD shards — one per module, with declaration nodes, imports edges and formalizes edges to the content blocks whose lean.ref names each declaration — and publish them under the folio’s site with a single viewer page that loads modules, signature chunks and the search list on demand. Signatures are chunked 500 declarations per file so a 12,804-declaration module stays usable. With --base it writes a STAGING overlay: only modules whose content hash differs from the published base, plus overlay.json; the viewer loads the rest from the base. Rails the viewer page with the same pass as lean-render-publish. | shell | lean-html-docs | 14 in / 1 out |
lean-render-publishPublish a Lean render under a folio site, with the harness rail | Stage a doc-gen4 render under a folio’s built site (<site>/<route>/, default lean/) and give every page the harness navbar and rail by running cat-harness/scripts/rail-standalone-pages.ts --foreign-site over the site — the same rail stage-folio-local.ts applies to the folio’s own pages. Leaves out Lake’s .hash/.trace bookkeeping, marks doc-gen4’s iframe navbar and find/ redirect folio-navbar: none so no rail is drawn inside the sidebar, adds a layout shim so the rail does not cover doc-gen4’s fixed sidebar, and with --modules prunes to the folio’s own modules, repointing links into dropped ones to the community docs. Then asserts every staged page is railed or declined. | shell | lean-html-docs | 9 in / 1 out |
lean-toolchain-setupLean toolchain install | Install the toolchain pinned in lean-toolchain, fetching it from the GitHub release rather than through elan’s downloader. Idempotent, and it detects partial state rather than re-downloading. | shell | lean-environment-setup | 0 in / 1 out |
library-viewerLibrary viewer | Render each declared library directory — its entries, intakes and avatars — as a page per subject instance, and give every entry its own path IRI ( | shell | graph-rendering | 2 in / 1 out |
log-messageLog a message to the discussion | Write a log line where the human actor will read it: the discussion you are already in. Takes the five required fields and the optional body, and renders them as one entry. | manual | log-message | 6 in / 1 out |
logical-model-schemasLogical models → JSON Schema | A JSON Schema per logical model, from the published FHIR resources. | shell | ig-build-pipeline | 1 in / 1 out |
lsi-indexBuild the Latent Semantic Indexing index of a prose graph | Build the per-graph LSI index sidecar for every declared prose graph (or the one named): input fingerprint, parameters, dimension summaries, nearest neighbours and near-duplicate findings, never the vectors. Records each run’s outcome and input fingerprint, success or failure, as a folio-tool-run/v1 record. | shell | lsi-indexing | 2 in / 1 out |
lsi-queryLatent Semantic Indexing over a prose graph | Find units of a declared prose graph (a library, the skills, the beans, docs) that discuss a query in OTHER words — the vocabulary gap lexical search cannot reach. Each hit is labelled lexical+latent or latent only, and the score is a cosine in the latent space, never merged with a lexical result. | inProcess mcp shell | lsi-indexing | 3 in / 1 out |
lsi-viewerLatent semantic index viewer | Render every committed LSI index — dimensions as two poles, narrow-dimension and near-duplicate findings — and which declared prose graphs still need one. | shell | graph-rendering | 2 in / 1 out |
mcp-captureWhat this instance’s MCP server serves | Read the real tool surface from the registrars by mounting each against a capture object — the same objects the server asks, so the Zod shapes and their optionality are the served ones rather than a reading of the source. | shell | mcp-contract | 1 in / 1 out |
mcp-server-imagefolio MCP server, as a container | Build and run the folio MCP server as one image carrying Bun, TeX Live, Lean, lean-lsp-mcp and the generated Python set — the image deploy/ serves behind the auth gateway. Run it with docker run -i --rm paper-assistant --stdio, or --http on port 8080. | manual | deployment-auth | 0 in / 0 out |
merge-leftoverMerge leftover (has a PR’s intent landed?) | After a train merged, compare a PR’s head with the base path by path and say whether what it still changes is ONLY generated files, generated README regions, or changes the base already carries (its patch applies in reverse to the base): landed, not-landed with the authored paths still different, or could-not-determine, which is never shown as clean. Only reports; closing the PR stays a steward action. | shell | merge-conflict-patterns | 2 in / 1 out |
merge-overlapMerge overlap (conflict prediction) | For the open PRs (via gh, or a list of branches), report which pairs would conflict: pairwise overlap on AUTHORED paths, with generated paths excluded using the merge-conflict-patterns declaration; which PRs touch a shared declaration (an instance’s <instance>.json, roles.json, package.json, bun.lock, schemas, BPMN/DMN); and which touch the harness layer’s directory or its tools layer’s. A PR that could not be measured makes no pair independent. JSON (merge-overlap/v1), the conflict-prediction input for composing trains. | shell | coordinatemerge-conflict-patterns | 2 in / 1 out |
merge-trainMerge train | Build a train branch from a base SHA: merge each member (a PR number or branch) with merge-base.ts --no-regen, refusing — never hand-resolving — a member whose conflicts no declared pattern covers; then one bun run cat regen, check:l1-complete --write, every check an instance declares afterMerge (its declared writer run when red), and kg:audit:all:check; then merge origin/main, taking main’s side of generated conflicts and regenerating once more. Emits a merge-train-report/v1 JSON report. Never pushes, opens or merges a PR. | shell | merge-conflict-patternsprepare-merge | 5 in / 1 out |
methodologies-viewerMethodologies viewer | Render the declared methodology graph as one page. | shell | graph-rendering | 2 in / 1 out |
mount-from-lockReplay a committed mount lock with nothing but Node | Lay down every remote mount index.lock.json records — each instance fetched at the lock’s full SHA (sparse, blob-filtered), each directory verified against its treeDigest, a mismatch undone and reported — importing only node:*, so it runs on a fresh clone before any layer is present. It never decides what to mount: remote-mount writes the lock (and checks trust); this only replays it. Refuses to write over a path with tracked files or bytes that no longer hash to the lock. Exit 0 mounted/current, 1 missing, 2 could-not-determine. | shell | kg-separationremote-mount | 2 in / 1 out |
narrative-queueWhat narratives are waiting on a person | List the agent-drafted narratives awaiting human confirmation, numbered, with the numbered rejection reasons beside them. The queue is the only place a draft’s state is visible before someone accepts it. | shell | library-ingestion | 0 in / 1 out |
navbar-includeWrite the site sidebar’s harness navbar include | Render _includes/generated/navbar-footer.html from docs/_data/harness.json with the same renderer every railed page uses. With --instance, render the navbar of an IG repository’s OWN site instead — that instance first, then what it needs; its own pages at this site’s root, every other link to the main site at --link-root — into the shell that site is built from (#2235). | shell | harness-tiles | 5 in / 1 out |
node-kind-pagesNode kind pages | Render a page for every node kind, every harness holding nodes of it, and every node, under / | shell | graph-rendering | 2 in / 1 out |
npmPackage manager and registry client for npm and GitHub Packages | Package, publish, inspect, and retrieve npm packages and Knowledge Graphs distributed as tarballs or packages from npm registry or GitHub Packages. | shell | npm-kg-distributionpackage-releaseremote-mount | 1 in / 1 out |
ns-vocabularyNamespace vocabulary | Emit the folio namespace as a document that dereferences — one node per class and property, each with an @id, a type, a label and a definition, so a consumer holding only the JSON-LD can resolve any term it meets. | shell | kg-export | 2 in / 1 out |
openapi-ingest-renderedOpenAPI ingest from a published spec | Ingest the OpenAPI documents an instance’s cat-openapi.config.json lists under rendered by fetching each published spec URL (https), verbatim, with a provenance recording the URL, when it was fetched and the document’s sha256 — a URL has no commit, so the digest pins the bytes. A failed fetch or bytes that are not OpenAPI 3 write nothing and never replace a held copy. | shell | library-ingestion | 2 in / 1 out |
openapi-ingest-sourceOpenAPI ingest from source | Ingest the OpenAPI documents an instance’s cat-openapi.config.json lists under documents from a local checkout of their repository, read AT a branch, tag or commit (git show), verbatim, with a provenance recording the resolved commit and the document’s sha256. --check verifies the committed copies offline. | shell | library-ingestion | 3 in / 1 out |
openapi-pagesOpenAPI viewer | Render every OpenAPI document an instance’s openapi graph holds at the visualiser’s route: a hub, a page per instance listing its documents, and a page per document and per operation, drawn from the document copied beside them. | shell | graph-rendering | 2 in / 1 out |
pack-tarballPackage instance into an npm tarball and record binary release | Build an npm tarball (.tgz) of an instance using bun pm pack, compute its size and SHA-256 digest, and record it as a folio-binary-release/v1 state node. | shell | npm-kg-distributionpackage-release | 6 in / 2 out |
package-exportsA package’s exports are its declared, shipped code directories | Derive a package’s package.json exports from the instance declaration beside it: a directory declared with graph typology code (top level or from within) AND named in files is exported as ./<dir>/*.js → ./<dir>/*.ts and ./<dir>/* → ./<dir>/*; a declared code directory that is not shipped (test/) stays private. Keys without * are named entry points, kept as written and checked to point into an exported directory. Without --write it reports each difference; with it, it rewrites exports. Exit 0 in agreement, 1 drift, 2 cannot tell (no declaration, no package.json, or no shipped code directory). | shell | kg-separation | 2 in / 1 out |
package-release-manualPackage release by hand | A person follows the package-release skill: computes the bump, writes the CHANGELOG entry, tags <package>-v<version>, and creates the release on the host. The same four steps with nothing to configure. | manual | package-release | 2 in / 1 out |
package-release-workflowRelease package via GitHub Actions release workflow | Build, tag, and publish an npm package tarball to GitHub Releases and GitHub Packages registry via workflow_dispatch across any repository. | shell | npm-kg-distributionpackage-release | 4 in / 2 out |
pages-indexPublished-paper index page | Write the gh-pages index.html for a built paper: a Paper tab embedding the PDF and, when given, a Visualizer tab, with download links and the build’s branch and commit. | shell | docs-generation | 8 in / 1 out |
pages-publishGitHub Pages publish | Push a built directory to the gh-pages branch, where it is served. How the knowledge graph and its schema reach a URL. | shell | docs-generationkg-export | 2 in / 1 out |
paper-feature-buildPaper feature build (changed chapters + latexdiff) | Quick preview of a paper folio’s branch: render the paper with the sci print template (plus the folio’s notation fragment when it has one), then compile ONLY the chapters changed against a base ref, and a colored and a plain latexdiff of each. Margin notes are off by default (FAST_PREVIEW=1, about 2x). Cross-references to chapters outside the build print as ‘??’. A preview, never a publish build. Run from the folio. Without a TeX engine the render still runs and the compile steps are skipped with a message. | shell | latex-build-cache | 6 in / 1 out |
paper-latex-buildPaper build to LaTeX chapters | Render a paper’s content objects to LaTeX chapters: load the paper manifest, resolve its chapters and blocks, render, validate the LaTeX AST, and write the chapter files. With no manifest it builds the folio’s only paper, and refuses — naming them — when there are several or none. | shell | content-validation | 2 in / 1 out |
paper-preferencesRendering preferences | Read, write or clear the stored rendering preferences — engine, format, scope, math renderer, print mode. | inProcess mcp | build-docsbuild-pdf | 10 in / 1 out |
paper-previewOpen a render | Open a rendered PDF, HTML page or image in the system browser, or list the renders available to open. | inProcess mcp | rendering-auditorstaging-review | 3 in / 1 out |
pdf-coverPDF page raster | Render one page of a PDF to a PNG — the thumbnail a repository listing shows — and print the provenance a catalogue needs to record it as DERIVED: source, digest, page, geometry, renderer. | shell | asset-extraction | 5 in / 1 out |
pdf-viewer-embedEmbed a PDF inline in a page | Print the HTML fragment that shows a PDF in the installed viewer: a lazily loaded frame whose address is derived from the page’s own location (so one page works at the site root, under a project base and under a staging preview), plus plain open and download links that work without it. | shell | pdf-inline-viewer | 1 in / 1 out |
pdf-viewer-installInstall the inline PDF viewer into a built site | Download the pinned pdf.js release (legacy build), verify its SHA-256, copy the parts a site needs into <site>/assets/vendor/pdfjs/, and add the shim that opens ?src= only for the allowlisted URL prefixes or the site’s own origin. Nothing is committed: the viewer exists only in the built site. | shell | pdf-inline-viewer | 3 in / 1 out |
pin-actionsPin third-party GitHub Actions to full commit SHAs | Rewrite every third-party uses: owner/repo@ref outside the declared staging-only workflows to @<full commit SHA> # <ref>, so Dependabot keeps the pair current. A tag resolves to its PEELED commit (an annotated tag’s object is never pinned), else a branch head, by git ls-remote with argv. A ref that resolves to nothing, or to more than one commit, is refused and reported, never guessed. This repository’s own reusable workflows are first-party and left alone. Idempotent. | shell | security | 1 in / 1 out |
pin-ig-terminologySnapshot a published IG’s terminology at its pinned version | Read every CodeSystem concept out of a FHIR IG clone checked out at its pinned tag and write a folio-pinned-terminology/v1 snapshot: the offline, version-fixed answer check:term-mapping resolves its fhir target against. Which IG, which pin record and which snapshot path are the caller’s (--pin, --out, --source); this layer names none (#1767, stage B′). | shell | vocabulary-authority | 1 in / 1 out |
pin-spdx-license-listSnapshot the SPDX License List at its pinned version | Read json/licenses.json and json/exceptions.json from a copy of github.com/spdx/license-list-data at the pinned tag and write cat-harness/external-schemas/spdx-license-list.terminology.json (folio-pinned-terminology/v1): every licence and exception id with its name and deprecated flag — the offline, version-fixed list check:source-licence validates a licence.json id against. | shell | vocabulary-authority | 1 in / 1 out |
processes-viewerProcesses viewer | Render the declared BPMN processes as an index page and one page per diagram. | shell | graph-rendering | 2 in / 1 out |
proof-dependency-graphProof dependency graph | Render the dependency graph of a paper’s proof objects from proof-objects.json as SVG (or DOT), each node linking to its anchor in the published PDF. | shell | docs-generationproof-status-tracking | 4 in / 1 out |
proof-objects-extractProof-object extraction | Extract the theorem, lemma and definition environments of a paper’s LaTeX chapters into proof-objects.json — the manifest the dependency graph and the proof-status update read. | shell | proof-status-tracking | 1 in / 1 out |
proof-status-updateProof status from a Lean build | Update each proof object’s status in proof-objects.json from a Lean build log — which objects built, which carry sorry, which failed. Exits 1 on a manifest with no objects rather than writing an empty status. | shell | proof-status-tracking | 2 in / 1 out |
qa-sweepQA sweep | Run every registered criterion over the blocks under a path and write a per-block QA sidecar. A sidecar rather than a console report, because a printed verdict cannot distinguish “never checked” from “checked and clean”. | shell | content-test | 4 in / 1 out |
rail-standalone-pagesGive every page Jekyll did not lay out the folio-assistant navbar | A LAST pass over the finished site: inject the shared navbar (lib/navbar.ts, the same component the site sidebar draws) into every page that carries none — standalone viewers, generated instance pages, and each IG site built by stage-ig-sites. A page under an igSite instance’s route is railed as THAT instance’s page (its name, mark and graphs); a page may declare its own section (data-fa-visualiser-nav) and its label (fa-visualiser-label). Mount routes are left to the mount pass, and a page that declines (folio-navbar: none) is left bare. | shell | harness-tiles | 4 in / 1 out |
readme-auditAudit README links | Verify every Markdown link in a folio’s README still resolves — relative paths against the tree, repo refs against a real ls-tree, Pages URLs against the publish ref. Writes nothing. | inProcess mcp shell | docs-generation | 3 in / 1 out |
readme-syncSync generated README sections | Rewrite each generated README region, and only where the README already carries that section’s marker pair. Nothing outside a marked region is touched. | inProcess mcp shell | docs-generation | 5 in / 1 out |
release-pleaserelease-please (declared, not configured here) | Propose the next version of each package from conventional-commit messages, open a release PR with the CHANGELOG and version bump, and — when that PR is merged — create the tag and GitHub release. Does not publish to a registry. Declared here, not configured: no config file and no tag exist in this repository (bean frq2). | shell | package-release | 2 in / 1 out |
remote-mountMount remote harnesses at a pinned commit, only when trusted | Lay down each declared remote mount — a source.remote instance in the root index.config.json, or, in a folio with no index, a remoteMounts entry on its declaration (both at once is refused) — and its dependency closure, from another repository at a full commit SHA. Write the lock, index.lock.json (a legacy <name>.mount-lock.json is read, and renamed onto it when rewritten), and, with an index, regenerate the root .gitignore block that ignores each mount path. It READS the declared mounts and never writes them: a tool that changes a mount writes through writeDeclaredMounts into index.config.json. Before anything is checked out, each mount must pass the trust gate (schemas/mount-trust.ts, rule H8): a person’s consent recorded for THIS pin, or a signature in a declared trust network. No signature verifier exists yet, so a signature alone is could-not-determine and does not mount. Unsigned and unconsented is refused. --staging mounts for a preview and needs neither, by the owner’s ruling. --check compares the disk against the lock and never fetches. When a run CHANGES the lock, it then re-renders the agent surface (skill:commands → .claude/commands/, agent-memory → .claude/agent-memory/ and .agents/) from the checkout root, so a re-pin commit carries the skills and memory the new layers define; a generator that fails fails the run, and --no-agent-surface opts out. | shell | agent-memorysecurity | 8 in / 1 out |
render-logRecord what the publish branch served | Append one entry to the render log on the publish branch: what was published or taken down, when, from which commit, and — for a removal or a retention — WHY. The log is the only place a preview that vanished leaves a trace. | shell | render-logging | 9 in / 1 out |
render-orderThe render pipeline, in dependency order | Flatten the repository’s renders into the order their needs imply, and optionally run them. Two stages: the current declared state as json/jsonld and the README derived from it are FATAL; the dynamic renderers (viewers, visualisers, doc pages, diagrams) skip and log; the dynamic-state export closes it. A cycle or a missing dependency yields NO order rather than a partial one. | inProcess mcp shell | docs-generation | 1 in / 1 out |
rewrite-moved-pathsRewrite paths that still name a moved file’s old layer — never in a record | After a move between two layers lands, find every mention <from>/<prefix>/<rest> in the scanned tree’s tracked files and rewrite it to <to>/<prefix>/<rest> only when the file exists under the destination root and not under the source root. Records are never read: beans, todos, memory, proposals, wireframes, QA results, upstream pins, vocab mappings, provenance figures and terminologies, and test fixtures (DEFAULT_RECORD_GLOBS; the CLI’s --keep <glob> adds more, generated trees among them, which their generators rewrite — a glob is not a shell-safe argument type, so it is not a declared input). Reports by default with file and line; --write applies; --check exits 1 while a rewrite is owed. | shell | kg-separation | 8 in / 1 out |
schema-docsSkill contract reference | Render each skill’s input/output JSON Schema as a browsable Markdown reference page, with an index. The generated pages are committed so they are readable on the forge as well as on the site. | shell | docs-generation | 1 in / 1 out |
schemas-viewerSchemas viewer | Render each declared schema directory as a page per subject instance, over one shared data index. | shell | graph-rendering | 2 in / 1 out |
sdc-checksCheck an IG’s built Questionnaires with CSIRO’s SDC libraries | Build-time Structured Data Capture checks, one result per Questionnaire (sdcChecks[] of fhir-questionnaire-wireframe): assemble (@aehrc/sdc-assemble 2.0.3: an assemble-root’s sub-forms resolve in this IG, and --out writes the assembled Questionnaire), template-extract (@aehrc/sdc-template-extract 1.0.16: extraction from the IG’s fixture response yields the expected resources), populate (@aehrc/sdc-populate 4.7.2: FHIRPath pre-population from a fixture context gives the expected answers) and behaviour (@aehrc/questionnaire-test-toolkit 0.1.0: the IG’s own behavioural test, warn-only). Owner, 2026-10-14: checks, not UI. | shell | fhir-questionnaire-wireframe | 4 in / 1 out |
search-graphLexical search over the content graph | Find graph nodes, authored or ingested, whose label, title, kind or tags contain a string, with no graph expansion. corpus-search composes this with a neighbour walk. | inProcess mcp | corpus-grep | 4 in / 1 out |
secrets-checkCheck declared credential needs against workflow use and expiry, by name | Compare each repository’s declared credential needs (credentials/needs.json, profile and registry) with the secrets.NAME expressions its workflows reference (GitHub Actions’ dollar-and-double-brace form, said in words because this text is rendered on a Jekyll page), with the secret names GitHub lists when a token allows it, and with any recorded expiry. NAMES ONLY — no value is ever read. Findings per §6.2: used-not-declared, declared-not-used, declared-not-present, present-not-declared (reported, never deleted), naming advisories, and expiry (≤30 days minor, ≤7 major, expired critical). Exits 2 when anything could not be determined, which outranks clean; else 1 on a major or critical finding; else 0. | shell | security | 2 in / 1 out |
security-gateRun every existing security check as one named release step | Run the repository’s security checks — workflow injection, secret leaks, lockfile pinning, the toolchain pin, QA reviewer permission, materialised-asset fixity — plus two advisories (dependency advisories, third-party action SHA pinning), each by name as argv. Every check is reported as pass, fail or unknown; a blocking check that fails OR could not be run refuses the release, because could-not-check is never clean. Advisories are reported and never block. Called by prepare-merge before a push that will merge, and by any publish process before it publishes. | shell | security | 1 in / 1 out |
separation-cutover-checkIs this repository’s cutover from the monorepo complete? Measured, condition by condition | Run in a separated repository. Six conditions, each decided by an existing gate: mounts (every declared layer on disk at its pin — remote-mount --check), declarations (every path a declaration names resolves — declaration-resolution), monorepo-paths (no wiring still names the monorepo: livesAt on it, a submodule of it, a reusable workflow called from it, a path into its old checkout — the one condition implemented here), import-direction and reference-direction (no layer reaches a layer above it), and site (the site builds from the mounts alone, every link resolving — build-instance-site --no-mount, only with --site). Findings inside a MOUNTED layer are listed and not counted: a defect in a layer pinned from upstream is fixed upstream and re-pinned. Exit 0 complete, 1 a condition failed, 2 a condition could not be determined or was not run — without --site the answer is never 0. | shell | kg-separation | 5 in / 1 out |
serve-renderingLocal rendering server | Serve an instance’s renderings over local HTTP with their declared media types. The publication host wherever GitHub Pages is absent, and the only host that can enforce application/ld+json at all. | shell | serving-renderings | 2 in / 1 out |
serve-rendering-pyLocal rendering server (Python) | Serve an instance’s renderings over local HTTP with their declared media types using Python 3 standard library. The publication host wherever GitHub Pages is absent, and the only host that can enforce application/ld+json at all. | shell | serving-renderings | 2 in / 1 out |
sibling-sessionsSibling sessions in a window | List the Claude Code sessions that have committed to this repository in a time window, from the Claude-Session: trailer on commits across ALL branches — with each one’s commit count, first and last commit, latest subject, and the branches containing its tip. The session API cannot see a sibling session, so the trailer is the only durable session identity here and a session’s state is INFERRED from its branch; whether a session is still running is not knowable from a checkout and is deliberately not reported. | inProcess shell | bean-coordination | 2 in / 1 out |
site-build-localBuild the docs site locally | Build the published site on this machine, so a page can be looked at rather than described: the same Jekyll build pages-publish runs in CI, into a directory of your choosing, and never pushed. The local half of the two site builds (owner, 2026-10-05: local and GitHub builds are two Tools for one skill). | shell | docs-generation | 1 in / 1 out |
site-search-indexSite search index | The just-the-docs search index, assets/js/search-data.json, which the theme writes as part of the Jekyll site build: one entry per page section, searched by every page’s search box. Built implicitly by the build rather than by a command of its own. | shell | docs-generation | 0 in / 1 out |
site-search-scopesSite search scopes | The site search index cut into one index per scope — each declared instance, each target locale, and the platform — plus assets/js/search/manifest.json naming them, so a reader’s search loads its own scope rather than the whole site (issue #1972, bean m7mn). Run on the assembled site after the index is written or borrowed. | shell | docs-generation | 1 in / 1 out |
site-viewerPublished site viewer | List the published site’s top-level routes and staging previews, with the pages and files under each, as read from the branch that keeps the site — saying so when the branch is empty or could not be read, never drawing zeros in its place. | shell | graph-rendering | 2 in / 1 out |
skill-docsSkill instruction reference | Render the skill instruction bodies — the prose an agent actually loads — as browsable pages with an index, so a reader can see what an agent is told without cloning the repository. | shell | docs-generation | 1 in / 1 out |
skill-fetchFetch a skill | Load one skill’s instruction body for the agent to follow, from the local packages or an external bundle. | inProcess mcp | skills-and-tools | 2 in / 1 out |
skill-listList skills | Every skill this instance can resolve, with its one-line summary. The entry point AGENTS.md sends an agent to first. | inProcess mcp | skills-and-tools | 0 in / 1 out |
slice-sqlitePer-slice SQLite builder | Build a named slice of a graph (beans, todos, library, or the whole-repo kg) as one SQLite file a browser mounts without parsing it, beside a manifest carrying its sha256, a row-content digest, its row counts and the search block the one search page reads. Heavy text is indexed by a contentless FTS5 and not stored; each row points at a content-addressed payload. --check builds every slice twice, requires one sha256, and requires the row digest read back from the file to equal the one computed from the source. | shell | kg-export | 4 in / 2 out |
smart-fhir-cache-seedSeed 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-variablesIG 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 |
stage-ig-sitesStage every IG whose instance records its source, one Jekyll site each | For every instance holding fhir-artifact-index/menu.json with a sushi-config source, clone the IG at the recorded commit and stage it with build-ig-site: the instance’s webpage theme (inherited along needs when it declares none), its artefact pages and artifacts page, its post-processing fills, and an edit link to the IG’s default branch. An instance whose docs directory declares igSite is staged to be served AT /<instance>/ with its artefact pages copied in (a collision is refused); otherwise beside it at /<instance>/ig/. Prints one <instance> <jekyll source> <at> line per IG for the caller’s jekyll build (beans bamf, mftp). | shell | ig-build-pipeline | 9 in / 1 out |
stage-localPublish a folio’s or an IG’s site from the agent’s own checkout — the one agent publish path | Build a repository’s site in the agent’s checkout and push it to the publish branch, as a preview or as the main site, without an Actions runner. Which build is read from the repository: a declared site.build recipe (built by build-instance-site), else the reusable workflow its own workflow files call — folio-staging.yml for a folio, the WHO SMART Base IG’s ghbuild.yml for a FHIR IG, whose build job is planned step by step and run as written. For an IG it then applies the harness chrome over the built output (sync-docs-harness, then rail-standalone-pages --foreign-site --instance <the IG>): every page gains the rail and the icon row #fa-navbar-row, and the IG’s own content is left byte for byte. A root publish is REFUSED when the chrome cannot be applied, and a clean root deploy is refused over any root whose index.html wears the icon row unless the new output does too, so a chromed root is never replaced by bare IG Publisher pages. Every run prints its plan first, and the plan lists the chrome step; --plan stops there, --dry-run composes the commit in a temporary worktree and pushes nothing, --artifact writes a claude.ai Artifact bundle instead. | shell | feature-stagingharness-tiles | 10 in / 1 out |
staging-graph-viewerStaging-only graph viewer | Render a kept-but-unpublished workspace graph as one page, for a local build or a staging preview only; a canonical deploy withholds it. | shell | graph-rendering | 2 in / 1 out |
stakeholder-mapStakeholder map | Given the paths a proposed change touches, report which skills change, which roles declare them, and who therefore has a stake in the review. | inProcess mcp shell | coordinaterole-model | 1 in / 1 out |
state-viewerState graph viewer | Render each declared state graph with a projection as a dashboard page: what the work plan holds, and what state it is in. | shell | graph-rendering | 2 in / 1 out |
strip-library-binariesStrip binary payloads from Library resources | Remove base64 content.data from published Library resources, so an IG embedding compiled CQL does not ship the bytes twice. | shell | ig-build-pipeline | 1 in / 1 out |
strip-library-contentReplace inline Library content with URL references | Replace inline CQL/ELM in Library resources with a URL reference to the published copy. | shell | ig-build-pipeline | 1 in / 2 out |
sub-kg-verify-cloneVerify a separated repository from a fresh clone | Clone a separated sub-KG’s repository (with submodules, and any sibling checkouts it needs) into an empty scratch directory, install, and run its gates: its gates script, else its test script (a person may pass --gate on the command line instead; it is not part of this contract because it is a shell command). Reports green, red or unknown; an empty tree, a failed clone or a repository with no gate is unknown, never green. Catches what a rehearsal inside this checkout cannot, because a rehearsal shares this checkout’s node_modules and environment (#2082). Writes only inside the scratch directory. | shell | sub-kg-lifecycle | 5 in / 1 out |
subgraph-readmesDirectory READMEs from the Knowledge Graph | Write a README for every directory an instance declares, from the declaration and the files themselves: the declared title and description, the Graph Typologies, and one row per file described from the file, with ‘used by’ only where a diagram records it. Renders the Liquid templates in tools/templates/readme/, part of the tools graph, which may include one another with Jekyll-style include tags. Writes only between <!-- kg:subgraph:begin --> and :end; a README without the markers is left alone and reported. Records every missing title, missing or over-long description, absent directory and unmarked README in test/results/subgraph-readmes.qa-results.json. | shell | docs-generationupload-routes | 1 in / 1 out |
subgraph-resolveResolve a declared subgraph’s content source | Say where a declared subgraph gets its content — the checkout’s own directory, a declared repository branch (with its keying), or a branch family (with its prefix, key and repository) — after the instance config’s subgraphSources override by id, and which layer answered. The same declaredSubgraph resolver the KG export, the publishers and the mount tool use, so a shell sees the answer they act on. | shell | directory-conventions | 3 in / 1 out |
tabular-csvCSV tabular metadata | Read a delimited text file into a folio-tabular-csvw/v1 record: one table, its columns and their CSVW datatypes, each measured or explicitly undetermined. Routing is by content, never by extension: the first rows must agree on one field count of two or more, under exactly one of , ; TAB \|. A CSV’s fac:anchor sheet and cell are a determined null. Governed by the tabular-metadata skill (bean eief). | shell | tabular-metadata | 3 in / 1 out |
tabular-xlsxSpreadsheet tabular metadata | Read a workbook into a folio-tabular-csvw/v1 record, one CSVW table per rectangular block of cells. Blocks are split on empty rows, then on empty columns, so several tables on one sheet are found, each anchored at its real top-left cell (fac:anchor: sheet, A1 cell, row, column). Dates are read through the number formats in styles.xml, not misread as integer serials. A malformed part is refused rather than half-read. No new dependency: ZIP via node:zlib, SpreadsheetML via fast-xml-parser. Governed by the tabular-metadata skill (bean eief). | shell | tabular-metadata | 3 in / 1 out |
terminology-indexWrite an IG site’s static terminology index from the IG’s own cache | Read the IG Publisher’s expansions.json and txcache/, as ig-cache.sh restore leaves them, and write index.json (gzipped as index.json.gz over 1 MB): every code with its system and display, and each value set’s codes. The IG site’s service worker answers the self-hosted Form Builder’s LOINC search from it, and its UCUM search from the vendored full UCUM list, so the site makes no cross-site call (owner, 2026-10-14: “cache + ucum. this is gh-pages so no XSS”). build-ig-site runs it for every IG with a Questionnaire. | shell | ig-build-pipeline | 3 in / 1 out |
tex-installInstall TeX Live in a sandbox | Install TeX Live (full) and latexmk where no TeX engine is present, disabling the firewalled launchpad PPAs that otherwise abort apt-get update. Idempotent: does nothing when pdflatex and memoize.sty are already present. About 5 GB and 10-20 minutes, so run it in the background. pdflatex unpacks early but is not usable until the post-install format build ends (kpsewhich memoize.sty returning a path is the ready signal). | shell | latex-build-cache | 0 in / 1 out |
tex-snippet-validateTeX snippet validation (AST) | Parse every tex snippet in a folio’s blocks and report what will not compile — structural, not textual: it reads an AST rather than matching patterns. Complementary to latex-preflight, which gates a main.tex before a compile, and to latex-overfull, which reads a log after one. | shell | latex-validation | 5 in / 1 out |
tex-source-auditTeX-source hazard audit | Catch the source patterns that crash pdflatex but read as ordinary prose — a bare _ or ^ in a bibliography field, \| inside a markdown table cell where it is also the column separator, a $…$ span across two lines, markdown link syntax inside a fenced tex block, a double subscript. Born from named build failures rather than from a style opinion. | shell | latex-validation | 1 in / 1 out |
themes-cssTheme stylesheet | Render the declared theme nodes into the stylesheet the site serves. The nodes are the source: a colour has one home, and light and dark are two valuations of one token set rather than two hand-kept blocks. | shell | site-presentation-assets | 1 in / 1 out |
tool-coverageWhich uncovered skills warrant a Tool? | Triage the skills that have no Tool by EVIDENCE rather than by grep: a serviceTask naming it or an I/O contract puts it in tier A, a userTask only in B, a shell block or a declared script in C, and nothing in D. The answer to “which of these still have their mechanism inlined in their prose”. | shell | code-node-review | 0 in / 1 out |
tool-schemaTool node schema | The zod definition of a Tool node — what defineTool accepts — and the published JSON Schema generated from it. | shell | kg-export | 1 in / 1 out |
tool-types-schemaTool I/O type vocabulary | The zod definitions of the shared types a Tool’s inputs and outputs reference by IRI, and the published JSON Schemas those IRIs name: one document per type, tool-types/<Name>.schema.json, plus the combined tool-types.schema.json. | shell | kg-export | 1 in / 1 out |
tools-viewerTools viewer | Render this instance’s Tool nodes, and the skills each satisfies, as one page. | shell | graph-rendering | 2 in / 1 out |
transcribe-faster-whisperTranscribe audio — faster-whisper (option, not installed) | Transcribe an audio file with faster-whisper (the Whisper models on CTranslate2), from Python. A declared OPTION: not installed in this repository. | shell | library-ingestion | 2 in / 1 out |
transcribe-voskTranscribe audio — vosk (option, not installed) | Transcribe an audio file with vosk (Kaldi-based), offline, from Python, with small per-language models. A declared OPTION: not installed in this repository. | shell | library-ingestion | 2 in / 1 out |
transcribe-whisper-cppTranscribe audio — whisper.cpp (option, not installed) | Transcribe an audio file to a timed transcript with whisper.cpp, offline, on CPU. A declared OPTION: not installed in this repository until the first audio upload (bean 1r0p). | shell | library-ingestion | 2 in / 1 out |
translation-extractExtract translatable strings | Segment a folio’s prose into a GNU gettext .pot template, leaving code, math and identifiers untranslated. | inProcess mcp | translation-manager | 3 in / 1 out |
translation-injectInject translations | Produce a translated copy of a source markdown file from a .po, using the same segmentation the extractor used. | inProcess mcp | translation-manager | 3 in / 1 out |
translation-roundtrip-recordRecord a round-trip translation verdict | Write a back-translation verdict, produced by a pair of translation agents, into a block’s existing translation-QA sidecar. It records a judgement rather than making one, and refuses where no sidecar exists — a round trip cannot be what decides a block is translated. | shell | translation-manager | 1 in / 1 out |
translation-signoffSign off a translation | Record a translation as official — who signed off, when, and the hash of the source it was signed against, so a later source edit is detectable. | inProcess mcp | decision-audittranslation-manager | 4 in / 1 out |
translation-statusTranslation coverage | Per-locale translation coverage, computed from the .po files under the translations directory. | inProcess mcp | translation-manager | 1 in / 1 out |
translation-status-viewerTranslation status viewer | Render the translation status of every declared translation-sources directory, per locale, as one page. | shell | graph-rendering | 2 in / 1 out |
translation-validateValidate a translation | Check a .po against its .pot — every msgid present, none obsolete, placeholders preserved. | inProcess mcp | translation-manager | 3 in / 1 out |
uml-object-modelHarness object model as PlantUML | Draw the harness object model (Actor, Role, Skill, Process, Task, Todo, Bean, tests, schemas) with every attribute read from the schema behind it. Each relationship names the field that carries it, and the generator refuses to write if that field is gone. | shell | uml-overview | 1 in / 1 out |
uml-overviewUML overview per named sub-graph | Draw one UML class diagram per harness and one per named sub-graph it declares, as PlantUML, Mermaid and Graphviz DOT from one model, with every class read from the graph typology’s node schema, and render the PlantUML to the SVG each page shows (needs Java; the check does not). The DOT is the page’s Interactive view, laid out in the reader’s browser by the site’s vendored Graphviz WASM with draggable nodes. A kind with none is drawn as could-not-determine, never as an empty box. | shell | kg-subgraph-layoutuml-overview | 1 in / 1 out |
upload-step-docsThe upload step, from its Tools | Render document ingestion’s FIRST step as a reference page, generated from the Tool nodes that implement it: the step, its lane and role, its skill and every Tool whose satisfies names that skill, with each Tool’s description, installation, invocation, typed ports and selection triple. Everything but the process file’s own path is derived — the start event, the activity its single outgoing flow reaches, and that activity’s skill — so a step inserted, renamed or re-pointed moves the page rather than staling a literal. Refuses rather than emitting a partial page when the start event flows nowhere or to more than one place, when the first step is not an activity, when it names no skill or several, or when NO Tool satisfies that skill — the last because an empty page reads as a documented absence of mechanism, which is a finding rather than a document. | shell | docs-generation | 1 in / 1 out |
upload-urlWhere to drop a file — the queue’s upload URL | Compose the forge URL a person can drop a file at, from the instance’s own declaration: the uploads graph’s directory, resolved against the ROOT its scope names, expressed relative to the repository, and appended to the origin remote as GitHub’s /upload/<branch>/<path>. Every failure is NAMED and no URL is guessed — no declaration, no declared uploads graph, a declared queue absent from disk, no origin remote, and a non-github.com remote each return a reason and a remedy instead. It exists because the obvious composition mints a live 404: the declared path uploads/ is relative to the INSTANCE and a forge URL needs it relative to the REPOSITORY, so pasting the declared path drops the cat-harness/ segment. Owner, 2026-09-20, on the hand-written form: “were it to exist, but it doesmt on main!!!!!” | shell | content-acquisitionupload-routes | 1 in / 1 out |
uploads-viewerUploads viewer | Render each declared uploads directory’s intakes as a page per subject instance. | shell | graph-rendering | 2 in / 1 out |
user-authWho is asking, and what may they do | User authentication and authorization (issue #1207). Asks GitHub for the caller’s login and repository role, maps the role to a gateway actor, and answers from the ODRL policies — for an action, or for a BPMN step. Always states that GitHub’s role covers the whole repository, not a sub-graph, node or query path. | inProcess mcp | deployment-authtask-authorization | 6 in / 1 out |
valueset-schemasValueSets → JSON Schema | A JSON Schema per ValueSet, plus the enumeration-response schemas published at the IG root. | shell | ig-build-pipeline | 1 in / 1 out |
vocab-mapApply a vocabulary mapping table | Carry one source record into a target vocabulary by a declared folio-vocab-mapping/v1 table: each source field becomes the predicate its row names, in the table’s order, with a DERIVED target (such as dcterms:title rendering skos:prefLabel) copied from its authoritative one so the two cannot drift. A table is shaped like a FHIR ConceptMap: an existing ConceptMap, R4 or R5, is representable as one without loss (fromConceptMap), and a table can be produced as a ConceptMap (toConceptMap), which returns every loss rather than dropping anything silently. First consumer: glossary-export. | inProcess | vocabulary-authority | 2 in / 1 out |
voices-viewerVoices viewer | Render each declared voices directory as a page per subject instance. | shell | graph-rendering | 2 in / 1 out |
wireframe-checkWireframe check at web and mobile viewports | Render each mid-fidelity wireframe candidate of one topic at a web viewport (1280x800) and a mobile viewport (390x844). For each viewport it records script entries for renders, no-overflow and no-placeholder, each pass or fail with a note. It writes a screenshot per viewport and a report.json carrying the use, topic and surface, and exits 1 on any fail and 2 when the candidate set is not one the use admits. | shell | wireframe-viewport-check | 5 in / 1 out |
witness-conformanceWitness conformance report | Check every *.witness.json in the folio’s declared computation-witness directories against the two schemas in schemas/computation-witness.ts: the envelope every witness should meet (a failure is a malformed file) and the producer contract (a failure is a finding against the producer, grouped by the fields at fault). Also lists files that are not strict JSON, which Python’s reader accepts and every other consumer rejects. Report-only: it never edits a witness, which is generator output. | shell | directory-conventions | 3 in / 1 out |
witness-parityWitness reproduction check | Re-run a computation witness’s producer and say whether it reproduces the committed witness. Reads the command from invocation.reproduce (else python3 <scriptFile>) and the recorded package versions from environment; on a version mismatch it stops at unknown, since a different environment is not a reproduction test. Otherwise it runs the COMMITTED producer in a scratch git worktree, so the folio’s own checkout is never written, and compares the result with the committed witness with run-specific fields (commit, timing, environment) masked at every depth. pass, fail (with the differing JSON paths), or unknown (mismatch, non-zero exit, timeout, no witness written). | shell | directory-conventions | 4 in / 1 out |
work-plan-primePrime the work plan | Load the current work plan for this session — the same committed beans store the CLI reads, so a fresh container starts from the plan rather than from nothing. | inProcess mcp shell | bean-coordinationpending-showsession-intenttodo-manager | 0 in / 1 out |
workflow-completeComplete a step | Record an enabled step as done — or supply the facts a decision gateway is computed from — and advance the instance. Refuses a step that is not enabled. | inProcess mcp | bean-coordinationprocess-state | 7 in / 1 out |
workflow-gateMay this step be performed? | Ask before doing work a strict process governs. The content-agnostic processes refuse a step that is not enabled; the per-content-type ones advise. | inProcess mcp | process-state | 4 in / 1 out |
workflow-listList processes | The BPMN processes this instance defines, and the instances currently open against them. | inProcess mcp | process-state | 0 in / 1 out |
workflow-nextWhat is enabled now | The activities an instance may work right now, each with the lane that owns it and the skill that implements it. | inProcess mcp | process-state | 1 in / 1 out |
workflow-startStart a process instance | Open an instance of a process for a subject. Idempotent: an existing instance for the same subject is returned rather than duplicated. | inProcess mcp | bean-coordinationprocess-state | 3 in / 1 out |