Skip to main content

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.

The dry-run template rehearses initialization without changing the target. It may inspect and reason about requirements, but it must not create, configure, delete, install, migrate, start, stop, or overwrite anything in the target. The result is a proposed plan — a complete picture of what active initialization would do — which the operator reviews before committing to any changes.

​
Template metadata

FieldValue
NameDry-Run Init Protocol
TargetAny target that needs proposed initialization work without mutation
PurposeInspect the target, determine requirements, produce an initialization plan, and report what would become operational without changing files, services, or state
ModeDry run only
CreatesNo target artifacts
ConfiguresNo target settings
ValidatesProposed checks are identified and checked for feasibility where possible without mutation
Optional outputsDry-run report outside the target when the operator requests one; proposed PLAN.md content when actionable work remains; proposed validation checklist

​
When to use

Use the dry-run template when:
  • The operator wants to understand the impact of initialization before running it in active mode.
  • The target is sensitive, remote, production-like, or shared.
  • Access is read-only and active changes are not permitted.
  • The correct template is unknown and the operator needs to see what would be proposed before choosing.
  • Proposed outputs need review before creation.
This template works for any target type. Server checks appear only when the target is actually a server or infrastructure environment.

​
Non-mutation rule

A dry run makes no target changes. No files are created in the target. No services are started, stopped, or reconfigured. No configuration is written. No dependencies are installed. Proposed outputs — such as README.md, AGENTS.md, SNAPSHOT.md, server reports, task files, or configuration examples — are described in the plan but never written unless the operator explicitly switches to active mode and reruns the procedure.
A dry run makes no target changes. Switch to active mode only after reviewing the proposed plan and confirming the proposed work is appropriate for the target.

​
The procedure

1

INSPECT

Inspect enough to understand the target and its likely operational requirements.
  • Read existing files, configuration, docs, service descriptions, tool definitions, manifests, environment notes, or user-provided constraints that are relevant to the target.
  • Do not mutate. Do not broaden inspection beyond the target without reason.
  • Use only read-only evidence.
2

DETERMINE

Select the closest initialization pattern or combine compatible pattern sections.
  • Identify what would need to be created, configured, preserved, updated, or validated in an active run.
  • Produce a proposed initialization plan with conditions.
The plan should distinguish:
  • Required work.
  • Optional work.
  • Artifacts that should not be changed.
  • Questions or permissions needed before active mode.
  • Validation steps that would prove operation.
3

CREATE

Do not create target artifacts.
  • If a report is explicitly requested by the operator, place it only where the operator explicitly permits.
  • Otherwise keep the dry-run report in the response or calling system.
  • Output: proposed content or artifact names — not actual target files.
4

CONFIGURE

Do not configure the target.
  • Describe configuration that would be required in active mode, including paths, dependencies, services, tools, environment variables, agent instructions, or integrations.
5

VALIDATE

Validate the plan, not the initialized result.
  • Confirm the proposed work is internally consistent, target-relevant, and has a plausible validation method.
  • Where read-only checks are available, use them to reduce uncertainty.
  • Report status as DRY_RUN_COMPLETE when the plan is complete, or BLOCKED when the plan cannot be formed from available evidence.
6

REPORT

Report the complete dry-run result:
  • Target identified.
  • Evidence inspected.
  • Selected template or pattern.
  • Work that would be created.
  • Work that would be configured.
  • Validation that would be run.
  • Artifacts that would remain untouched.
  • Warnings, unknowns, permissions, or blockers.
  • Whether the target would likely become operational after active initialization.

​
Result

A completed dry run produces a DRY_RUN_COMPLETE status and a structured report. The report typically contains:
  • A description of the target as inspected.
  • The initialization template or pattern that would apply.
  • A list of artifacts that would be created, with conditions noted for each.
  • A list of configuration changes that would be made.
  • The validation commands or checks that would be run to prove operation.
  • Any artifacts or settings that would be left untouched.
  • Open questions, missing permissions, or blockers that would need resolution before active mode.
  • A judgment on whether the target would become operational after the proposed work.
The operator reviews this report, resolves blockers or questions, and then reruns with the appropriate active, repair, or reinitialize mode when ready.

​
Using this template

Inspect this target using the dry-run init template.
Do not create or modify any files.
Produce a proposed initialization plan and report DRY_RUN_COMPLETE.

Build docs developers (and LLMs) love

Get started for freeTalk to us