The six protocol stages apply to every target without exception. What varies between targets is the implementation detail inside each stage: what files to inspect, which pattern to determine, what artifacts to create, how to configure them, which validation checks are relevant, and what to report. Those specifics come from the target itself and the selected template, not from the root protocol.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.
INSPECT
INSPECT
The INSPECT stage establishes what already exists before any decisions are made. Nothing should be created, modified, or configured during this stage.Determine:
- what exists at the target location (files, directories, configuration, existing documentation)
- what the target appears to be — its type, purpose, and current state
- what instructions and configuration already exist and whether they are valid
- what is complete and can be reused as-is
- what is missing and will need to be created
- what is contradictory or conflicting and will need to be resolved
- what can be reused, adapted, or built upon
DETERMINE
DETERMINE
The DETERMINE stage converts inspection findings into a concrete initialization plan. No changes are made yet, but every subsequent stage follows from what is decided here.Determine:
- the target’s operational requirements — what it needs in order to function as intended
- which initialization pattern applies — the root protocol alone, a specific template, or a combination of compatible template sections
- which files, directories, dependencies, settings, tools, or services are required
- which existing artifacts should remain unchanged and which need updating
- which outputs would be useful given this target’s actual needs
- what validation is possible and meaningful for this target
CREATE
CREATE
The CREATE stage produces the artifacts determined to be necessary. Only create what applies to this specific target and the selected initialization pattern.Possible outputs include:
- directories and file structure scaffolding
- configuration files (tool config, runtime config, build config)
- documentation (README, runbooks, handoff material)
- dependency manifests (package files, lock files, requirement lists)
- agent instructions (
AGENTS.md,SELF.md,TOOLS.md) - project requirements (
PRD.md) - startup scripts and entrypoints
- environment variable examples (
.env.example) - context files and state records (
STATE.md,SNAPSHOT.md) - tests and readiness checks
- task files and work plans (
PLAN.md) - data structures and schema definitions
- service definitions and deployment descriptors
These are examples, not universal requirements. A minimal local directory target may produce nothing beyond an
INIT.md. A full agent target may produce several of the above. Let the target and selected template determine which outputs apply.CONFIGURE
CONFIGURE
The CONFIGURE stage connects created and existing elements so they work together as an operational system.Possible configuration includes:
- paths and directory references
- runtime settings and environment variables
- dependency versions and resolution configuration
- scripts (build, start, test, deploy)
- services and process managers
- tools and their invocation rules
- agent instructions and behavioral constraints
- file relationships and cross-reference links
- permissions and access controls
- integrations with external systems or APIs
VALIDATE
VALIDATE
The VALIDATE stage confirms that the initialized target actually works as intended. Validation must be derived from the target — do not apply generic checks that are irrelevant to the target type.Possible checks include:
- required files exist at expected paths
- configuration files parse without errors
- commands execute successfully
- services start and become healthy
- dependencies resolve without conflicts
- tests pass
- instructions are internally consistent and non-contradictory
- expected outputs can be produced (e.g., a build succeeds, a script runs)
- required tools are accessible in the current environment
REPORT
REPORT
The REPORT stage produces a clear, structured account of what the initialization procedure did and what state the target is now in.Report must include:
- what target was initialized (identity, type, location)
- what was inspected and what was found
- what was created and where outputs are located
- what was configured and what connections were established
- what was validated and which checks passed
- what remains incomplete or was intentionally deferred
- what warnings or blockers remain unresolved
- where the important outputs are located
- whether the target is operational — one of the four standard result states
Instruction vocabulary
When a step inside a stage needs structure, use this small vocabulary. Not every field is required in every step — use only the fields that are meaningful for the step being described.| Field | Purpose |
|---|---|
description | What the step accomplishes |
condition | When the step applies (omit if the step is unconditional) |
inspect | What must be examined before acting |
action | What should be created or configured |
output | Any resulting artifact produced by the step |
validation | How the result of the step is checked |
source | Evidence or input used to inform the step |
status | The resulting operational state after the step completes |
Do not require every vocabulary field in every step. Do not make shell commands the default representation. Use commands only when commands are the right validation or configuration tool for the situation.