Pattern

Text and non-HTML outputs.

Nift's tracking and templating model is useful anywhere a text file is assembled from reusable pieces—not only for HTML pages.

Initialise for another output extension

mkdir generated-text
cd generated-text
nift init .txt

Compose reusable text

Project: $[title]
Generated: $[build-date]

@content

The same ideas—tracked names, templates, @input, metadata and incremental dependencies—can be applied to text-oriented generated assets when that is useful.

Use the right tool boundary.

Nift is not trying to replace specialist compilers or data formats. This pattern is useful when the output really is templated text and Nift's dependency model is valuable.

Generated manifests or simple feeds

If the target format is fundamentally text, Nift can provide shared headers/footers and metadata without introducing a separate generator.

# generated \$[build-date]
\@content

Shared fragments

The same @input mechanism works outside HTML, so repeated text blocks can live in one place and participate in incremental dependency tracking.

Build metadata in generated text

Generated by Nift
Date: \$[build-date]
Platform: \$[build-OS]

\@content

Where this can be useful

Small manifests, human-readable indexes, generated notices, simple feeds, email source files, configuration fragments and documentation exports can all benefit when the task is fundamentally text composition.

Where it is not

Do not use Nift merely because it can write text. Specialist compilers, serializers and schema-aware tools remain better for formats where correctness depends on a richer semantic model. The value here is the same as on the web: simple composition plus tracking.