The Template Manifest

Every Markdown help template has a manifest.yaml file at its root; its presence is what identifies the folder as a help template.

The manifest defines the template’s metadata, the page header and footer, the styles, the table of contents, and the map of which layout renders each kind of API entity.

A complete example

name: Default
version: 1.0.0
description: Default help template for IVI.NET drivers
driver-type: IviNet

# Page header and footer (Mustache markdown, rendered on every topic).
# Use {root} for a relative path back to the output root.
header-left: "{{driver.name}} IVI.NET Driver Reference"
header-right: "[Created with Pacific MindWorks Nimbus](https://pacificmindworks.com/what-we-do/nimbus/)"
footer: "[Copyright © {{copyright.year}}, {{company}}]({root}conceptual/copyright.html)"

# Styles
styles:
  base: styles/base.css

# Table of contents (see below)
toc:
  root: layouts/driver.md
  children:
    - resource: conceptual/getting-started/getting-started.md
    # ...

# Which layout renders each entity type (see Layout Templates)
layouts:
  method: layouts/method/method.md
  property: layouts/property/property.md
  # ...

Metadata

Key	Purpose
name	Template name.
version	Template version string.
description	Short description of the template.
driver-type	Which driver flavor this template targets: IviNet, IviCom, or IviC.

Page header and footer

header-left, header-right, and footer are short Mustache markdown snippets rendered on every generated topic. They can use any value from the driver model (see Layout Templates) and the special {root} token, which expands to a relative path back to the output root so links work from any depth in the topic tree.

header-left: "{{driver.name}} IVI.NET Driver Reference"
footer: "[Copyright © {{copyright.year}}, {{company}}]({root}conceptual/copyright.html)"

Styles

styles.base points to a CSS file used by the CHM and Microsoft Help Viewer output. The static-website output is styled by its own theme rather than this CSS.

CHM and Help Viewer render through an older engine that reads neither CSS custom properties (var()) nor rem units, so Nimbus generates a compatible version of this stylesheet for each of them during the build. This happens automatically; base.css is the only stylesheet to edit.

CHM renders on an unscaled surface, where text sized for Help Viewer appears small. chm-styles lists the custom property values CHM uses instead. Values not listed are taken from base.css, so the two differ only where stated:

chm-styles:
  font-size-base: 18px
  font-size-small: 16px

styles:
  base: styles/base.css

Custom images and other static files

Custom images, downloads, and other static files are not declared in the manifest — content references them directly, so the generator only needs to make them present in the output.

Each template ships an empty assets/ folder next to its manifest.yaml. Place files in there — subfolders may be used to organize them — and reference them from topics with a topic-relative link:

![Block diagram](../assets/images/diagram.png)

Everything under assets/ is copied verbatim into the generated help, with its folder layout preserved, for every output format — including the MadCap Flare output, so images reach the PDF that Flare builds. The references are validated when the help builds; a link to a file that is not present is reported as a broken help link.

Table of contents

The toc block defines the structure of the generated help. It has a root (the landing page) and a tree of children. Each node is one of:

Node key	Meaning
resource	Path to a Markdown topic file (conceptual or boilerplate).
title	An explicit node title, used for grouping or for auto-generated content.
content	An auto-generated content type produced from the driver model (e.g. IviNetHierarchy, IviNetFlat, IviNetCommandReference).
condition	Include this node only when a condition is met (e.g. RepCap, NoClass). See Conceptual Topics and the Table of Contents.
output	Override the output file name — useful when two conditional variants must produce the same output path.
children	Nested TOC nodes.

toc:
  root: layouts/driver.md
  children:
    - resource: conceptual/ivinet-accessing-repcaps.md
      condition: RepCap
    - resource: conceptual/getting-started/ivi-compliance.md
      condition: NotNoClass
    - resource: conceptual/getting-started/ivi-compliance-no-class.md
      condition: NoClass
      output: ivi-compliance.html       # both variants emit the same file name
    - resource: conceptual/ivinet-driver-reference.md
      children:
        - title: Driver Hierarchy
          content: IviNetHierarchy
        - title: Driver Interfaces
          content: IviNetFlat
        - title: Instrument Command Reference
          content: IviNetCommandReference

Layout map

The layouts block maps each API entity type to the layout that renders it. Entity types with custom fields use a folder (layouts/method/method.md plus sibling custom-field files); types without custom fields are a single file (layouts/enum/enum.md).

layouts:
  driver: layouts/driver.md
  assembly: layouts/assembly/assembly.md
  interface: layouts/interface/interface.md
  class: layouts/class/class.md
  method: layouts/method/method.md
  property: layouts/property/property.md
  event: layouts/event/event.md
  constructor: layouts/constructor/constructor.md
  delegate: layouts/delegate/delegate.md
  enum: layouts/enum/enum.md

Custom fields are auto-discovered from the sibling files in a layout folder — for example, layouts/method/remarks.md defines a Remarks custom field for methods. See Custom Fields.