Workflow

Nift with AI coding assistants.

Nift is useful with coding assistants for the same reason it is useful to humans: the Nift-specific layer is small, while most of the project remains ordinary HTML, CSS, JavaScript, TypeScript and whatever other technologies you choose.

Start an AI-ready project

You can initialise the same barebones structure yourself, or download the ready-made project and hand it straight to an AI coding assistant.

Or create the same starting point from the CLI:

mkdir my-site
cd my-site
nift init
touch ai-context.txt

Put a short description of Nift's project model in ai-context.txt. Then point Copilot, ChatGPT or another coding assistant at the project and ask it to read that file before making changes.

A useful ai-context.txt

This is a Nift v4 project.

Keep the existing project structure and ordinary HTML/CSS/JS conventions. Nift is the
templating/build layer; do not replace the project with another framework unless asked.

Core Nift template syntax:
- @content inserts the current tracked page's content into its template.
- @input('templates/partials/header.html') parses and inserts a reusable file. Use @input
  for shared markup such as headers, navigation, footers, cards and other partials.
- @pathto(...) produces a path relative to the current output page. Use tracked names for
  links between tracked pages, for example:
    <a href="@pathto('docs')">Docs</a>
- Also use @pathto(...) for concrete local CSS, JavaScript and image assets, for example:
    <link rel="stylesheet" href="@pathto('public/assets/css/style.css')">
    <script src="@pathto('public/assets/js/app.js')"></script>
    <img src="@pathto('public/assets/images/logo.svg')" alt="Logo">
  Using @pathto for a concrete local path also lets Nift report an error during the build
  when that path does not exist, instead of silently generating a broken asset reference.
- @getenv('NAME') inserts the value of an environment variable. If NAME is not set, it
  produces an empty string. Use it when build-time environment configuration belongs in
  generated output; do not put secrets into client-visible HTML or JavaScript.
- $[...] resolves values and pure expressions. It can read documented page/build metadata,
  JSON/project-contract values and scoped loop/pagination values, and supports numeric arithmetic,
  comparisons, boolean composition and lazy ternaries. It does not provide assignment or mutation.
- @dep(...) is only for an external file that affects an output but is not already made a
  dependency through @content, @input or another direct Nift relationship.

Prefer @input and @pathto over duplicating markup or hard-coding fragile relative paths.
Keep Nift-specific machinery small. Use the project's existing npm/Bun/Vite/TypeScript/
React/Vue/Svelte/Tailwind/backend tooling normally rather than trying to recreate it in Nift.

Before editing, inspect the existing templates, content files and project conventions.
Prefer the smallest change that preserves the existing architecture.

Then ask for the website you actually want

Once the context file is present, the interesting prompt can stay focused on the result rather than teaching the assistant Nift every time.

Read ai-context.txt and inspect this project.

Turn the barebones Nift project into a polished website for an independent architecture
studio. Create the pages, shared template/partials, CSS and JavaScript you think are
appropriate. Keep the site responsive and accessible, and use Nift's existing project
model rather than replacing it.

The same pattern works for a portfolio, documentation site, product landing page, blog, dashboard shell or frontend for a larger application.

Why the small context works

Human-directed agentic engineering for Nift projects

For a serious production site, an AI assistant can do more than generate a first draft. A useful workflow is human-directed agentic engineering: the human defines the product intent, constraints and acceptance boundary; the agent inspects the project, proposes or implements bounded changes, runs the real build and tests, and returns evidence for human review.

human intent + perception
        ↓
project context + explicit contracts
        ↓
agent implementation
        ↓
nift build / status / project tests
        ↓
evidence + adversarial checks
        ↓
human review / checkpoint / next direction

Nift fits this style unusually well because the project remains inspectable. Templates and content are ordinary files; tracked.json and config.json expose project state; @pathto, dependencies and project contracts can turn assumptions into build-time checks; and fast incremental builds make repeated agent validation cheap.

For longer work, keep a small project handover alongside the source. Record the current goal, architectural boundaries, commands that establish a known-good state, unresolved risks, rejected approaches and the evidence earned at the last checkpoint. Do not rely on the conversation alone to remember the project. Tests should preserve behavioral guarantees, Git should preserve change, and the handover should preserve the context that is not obvious from either.

The same process is used to develop Nift itself. The deeper discussion covers perception, handovers, checkpoints, executable contracts, adversarial testing, project memory and evidence. Read about human-directed agentic engineering in Nift development →