Documentation Index
Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/init.md/llms.txt
Use this file to discover all available pages before exploring further.
When no canonical template fits your target, you can write a custom template. Custom templates follow the same structure as the five canonical templates — a frontmatter metadata block followed by a protocol body that implements the six initialization stages. A well-written custom template can be reused across similar targets and shared with others.
When to write a custom template
Write a custom template when:
- The target has a recognizable type not covered by the five canonical templates (minimal, dry run, development project, agent, server)
- You need a specialized initialization procedure for a recurring context — such as a data pipeline, research environment, or documentation site
- You want to make a reusable procedure for a domain-specific operational pattern
Do not write a custom template simply to install a different set of default files. Templates describe likely behavior for a target category, not a fixed output bundle.
Template structure
Every template has two parts:
- Frontmatter metadata block — delimited by
--- at the top of the file; describes the template’s name, target, purpose, modes, and likely outputs
- Protocol body — the actual initialization procedure written in Markdown; implements INSPECT, DETERMINE, CREATE, CONFIGURE, VALIDATE, and REPORT
The canonical Markdown files under templates/ are the source of truth for all template content. The init.md website imports those files directly using Vite’s raw import pattern (?raw) — it does not store template bodies as TypeScript strings. The frontmatter is parsed for display and by scripts/check-templates.mjs for build-time validation. The protocol body is the usable instruction content that practitioners copy and execute.
Required frontmatter fields
Every template must include the following fields in its frontmatter block:
| Field | Type | Description |
|---|
name | string | Human-readable template name displayed in the website |
target | string | Description of what target this template applies to |
purpose | string | What the template accomplishes |
mode | list | Initialization modes supported: active, dry run, repair, reinitialize |
creates | list | Conditional artifacts this template may create |
configures | list | What this template configures |
validates | list | Validation checks this template performs |
optional_outputs | list | Optional output files this template may generate |
creates, configures, validates, and optional_outputs fields describe likely behavior — they do not force the template to create every listed artifact on every run.
---
name: Data Pipeline Init Protocol
target: Data pipeline, ETL job, batch processor, or scheduled transformation workflow
purpose: Inspect a data pipeline target, determine its operational requirements, create or configure applicable artifacts, validate that the pipeline can execute its intended transformation, and report readiness.
mode:
- active
- dry run
- repair
creates:
- Pipeline configuration file when none exists
- Schema definition when input or output structure is undocumented
- AGENTS.md when agent operation applies and no valid instruction file exists
- PLAN.md when unresolved work or missing data sources remain
configures:
- Source and destination connection settings
- Transformation logic references
- Schedule or trigger configuration
- Environment variables for credentials and endpoints
validates:
- Source connectivity is reachable or documented
- Transformation logic references valid input schema
- Output destination is writable or documented
- Schedule or trigger configuration parses correctly
optional_outputs:
- README.md when pipeline documentation is missing
- SNAPSHOT.md when a point-in-time record of pipeline state is useful
- AGENTS.md
- PLAN.md
---
Protocol body structure
The body implements the same six stages used in the canonical templates. Each stage uses the instruction vocabulary defined in the root protocol:
description — what the step accomplishescondition — when the step appliesinspect — what must be examinedaction — what should be created or configuredoutput — any resulting artifactvalidation — how the result is checkedsource — evidence or input usedstatus — resulting operational state
Not every field is required in every step. Use only the fields that are meaningful for the step being described.
# Data Pipeline Init Protocol
Use this template when the target is a data pipeline, ETL job, batch processor,
or scheduled transformation workflow that needs to become operational.
## Target Fit
Use this template when:
- the target reads from one or more sources and writes to a destination;
- transformation logic exists or needs to be defined;
- the pipeline has a schedule, trigger, or manual execution path.
Do not assume a specific pipeline framework, cloud provider, or orchestration tool.
## Procedure
### `INSPECT`
- `description`: Identify the pipeline target and what already exists.
- `inspect`: Existing configuration files, schema definitions, source and
destination connection settings, transformation scripts, schedule definitions,
credentials or secret references, documentation, and operator constraints.
- `condition`: Stay within the pipeline boundary unless external dependencies
are directly referenced.
- `source`: Existing files, environment metadata, and user-provided constraints.
### `DETERMINE`
- `description`: Decide what the pipeline needs to become operational.
- `action`: Identify missing configuration, undocumented schema, inaccessible
connections, or unclear transformation logic.
- `output`: A target-specific pipeline initialization plan.
### `CREATE`
- `description`: Create only the applicable missing artifacts.
- `condition`: Skip creation when a usable equivalent already exists.
- `action`: Preserve existing configuration and avoid generating duplicates.
- `output`: Created or updated pipeline artifacts.
### `CONFIGURE`
- `description`: Connect pipeline components so they work together.
- `action`: Configure source connections, transformation references, destination
settings, schedule or trigger, and environment variable references.
- `condition`: Configure only what the selected target requires.
### `VALIDATE`
- `description`: Confirm the pipeline can execute its intended transformation.
- `validation`: Check source connectivity, schema consistency, destination
writability, and schedule parseability. Run a dry-run execution if supported.
- `status`: Use `OPERATIONAL`, `OPERATIONAL_WITH_WARNINGS`, `BLOCKED`,
or `DRY_RUN_COMPLETE`.
### `REPORT`
Report:
- pipeline target identified;
- sources, destinations, and transformation logic inspected;
- configuration created or updated;
- validation result;
- remaining warnings, missing access, or blockers;
- final status.
Key principles
Keep these principles in mind when writing a custom template:
- Target-specific requirements belong in templates, not the root protocol — do not move domain-specific checks or outputs into
init.md itself
- Generated outputs are conditional — not universal — list possible artifacts in
creates and optional_outputs, but the procedure creates only what applies
- Validation must be derived from the target — define checks that are meaningful for the specific target category, not a generic success declaration
- Existing work should be adapted before creating replacements — inspect what already exists before generating new files
- Different targets should have different template implementations — a custom template for data pipelines should not resemble a server template with renamed headings
Keep metadata descriptions accurate. If using the init.md website, the frontmatter is parsed and displayed directly from the Markdown source.
Contributions should preserve the distinction between the general protocol and target-specific templates. Avoid adding universal requirements to the root protocol when they belong in a template.