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 development project template initializes software projects: libraries, applications, CLIs, websites, monorepos, and any other codebase where the operational goal is a working developer workflow. Unlike the minimal template, it addresses the full surface of a development project — package manifests, source layout, test commands, build configuration, environment setup, and validation — choosing only what the specific project requires.

​
Template metadata

FieldValue
NameDevelopment Project Init Protocol
TargetSoftware development project, repository, application, library, CLI, website, or monorepo
PurposeInspect a development target, determine the project-specific artifacts and commands required for productive operation, configure what applies, validate the developer workflow, and report readiness
ModesActive, Dry Run, Repair, Reinitialize
CreatesREADME.md when missing or inadequate; AGENTS.md when agent contributors will operate in the project and no valid guidance exists; PRD.md or specification files when product requirements must be established; source, test, task, or configuration files only when required by the project
ConfiguresPackage or dependency manifests; development scripts; linting and formatting; test commands; build and preview commands; environment examples
ValidatesRequired commands run or are documented as unavailable; manifests parse; dependencies resolve where installation is in scope; tests, lint, type checks, or builds pass when applicable
Optional outputsREADME.md; AGENTS.md; PRD.md; .env.example; PLAN.md; task or issue files; source directories; tests; validation report

​
When to use

Use this template when the target is a codebase, repository, application, package, library, website, CLI, tool, or monorepo.
Do not assume every development project needs a PRD, AGENTS.md, tests, a package manager, a src directory, or the same build commands. The target determines which artifacts and commands apply.

​
What it may create

All outputs are conditional on the specific project. Possible artifacts include:
  • README.md — when entry-point documentation is missing or misleading.
  • AGENTS.md — when agent contributors will operate in the project and no valid guidance exists.
  • PRD.md or other specification files — when product requirements must be established.
  • Package or dependency manifests — when the project has a compatible package system.
  • Source directories — when the project lacks an expected implementation location.
  • Test files — when there is a clear test surface and project convention.
  • Lint or formatting configuration — when the project requires it.
  • .env.example — when environment variables are required.
  • Development scripts — when the project needs documented commands.
  • Task or issue files — when actionable work must be tracked.
When an existing file is substantial and mostly correct, the procedure updates it instead of replacing it.

​
What it configures

  • Dependency manifests and package scripts.
  • Development scripts (install, start, dev server).
  • Linting and formatting rules.
  • Test commands.
  • Build and preview commands.
  • Environment examples (.env.example).

​
Validation

The development project template does not declare a project operational without a validation step tied to its real workflow. Relevant checks include:
  • Manifest parsing — confirm the package or dependency file is valid.
  • Dependency installation — when installation is in scope, confirm dependencies resolve.
  • Lint — run the project’s configured linter.
  • Type check — run the project’s type checker if applicable.
  • Tests — run the test suite if one exists.
  • Build — confirm the project builds without errors.
  • Preview — confirm a preview or dev server starts when applicable.
  • CLI smoke tests — confirm the CLI entry point executes when the target is a CLI.
  • Documentation link review — confirm internal links resolve.
  • Agent instruction consistency — confirm AGENTS.md references valid paths and tools.
Status is reported as OPERATIONAL, OPERATIONAL_WITH_WARNINGS, BLOCKED, or DRY_RUN_COMPLETE.

​
The procedure

1

INSPECT

Understand the project as it exists.
  • Inspect repository files, README, license, package or dependency manifests, source layout, tests, scripts, build config, deployment config, environment examples, issue or task files, existing specs, existing agent instructions, and user constraints.
  • Preserve local conventions and avoid unrelated cleanup.
  • Use files in the project, package scripts, framework configuration, docs, and operator instructions as sources.
2

DETERMINE

Decide what the project requires to become operational for development.
  • Identify project type, expected developer workflow, missing documentation, missing manifests, dependency setup, command surface, environment requirements, validation checks, and optional agent guidance.
  • Produce a project-specific initialization plan.
Possible decisions include:
  • Create or update README.md only when entry-point documentation is missing or misleading.
  • Create AGENTS.md only when agent contribution or operation applies.
  • Create PRD.md only when product requirements need to be established.
  • Add .env.example only when environment variables are required.
  • Add or repair package scripts only when the project has a compatible package system.
  • Add tests only when there is a clear test surface and project convention.
  • Add source directories only when the project lacks an expected implementation location.
3

CREATE

Create only applicable artifacts from the list above.
  • Preserve existing work. Update substantial, mostly-correct files rather than replacing them.
4

CONFIGURE

Make the selected development artifacts work together.
  • Configure dependency manifests, package scripts, build commands, test commands, linting, formatting, environment examples, deployment settings, agent instructions, file references, and documentation links.
  • Match the project’s existing framework and style.
5

VALIDATE

Confirm the developer workflow is operational.
  • Use the relevant checks described above, derived from the project’s actual workflow.
  • Do not declare the project operational without a validation step tied to its real workflow.
  • Report status as OPERATIONAL, OPERATIONAL_WITH_WARNINGS, BLOCKED, or DRY_RUN_COMPLETE.
6

REPORT

Report the complete development project initialization result:
  • Project identified.
  • Project type and operational goal.
  • Inspected files and commands.
  • Created or updated artifacts.
  • Configuration changes.
  • Validation commands or reviews.
  • Remaining warnings, blockers, or deferred work.
  • Final status.

​
Project-specific examples

Different project shapes require different initialization work:
A small library may need accurate package metadata, a README with a usage example, and a working test command. It is unlikely to need deployment notes, a PRD, or agent instructions unless those apply to the specific project.
A website may need build and preview commands plus deployment notes. The validation step should confirm both the build succeeds and the preview server starts.
A CLI may need executable configuration, command examples in the README, and smoke tests that confirm the CLI entry point executes and returns expected output for a simple invocation.
A monorepo may need workspace discovery, package-specific commands (install, build, test scoped per package), and agent instructions scoped to the relevant sub-package when agents operate on specific parts of the repo.

​
Using this template

Initialize this repository using the development-project template.
Inspect the project and determine what artifacts and commands apply.
Do not add a PRD, AGENTS.md, or tests unless the project requires them.
Validate the developer workflow before reporting status.

Build docs developers (and LLMs) love

Get started for freeTalk to us