Project structure

A PlanQ project is rooted at the directory containing plan.manifest.json. The manifest defines the complete, ordered entry set.

release-planning/
├── plan.manifest.json
├── release.plan
├── operations.plan
├── phases/
│   └── rollout.plan
├── resources.plan
├── resources.lock.json
└── .plan/
    └── config.json

Declare entries

{
  "manifestVersion": "1",
  "entries": ["release.plan", "operations.plan"]
}

Paths are relative to the manifest, remain within its directory, and must reference regular files with a lowercase .plan suffix. Order is significant: the first entry is the default.

Validate the complete project:

planq project validate
planq dev

An explicit planq dev release.plan operations.plan invocation replaces the manifest entry set for that session; it is not merged with the manifest.

Include a child plan

{
  :include "phases/rollout.plan"
  :after [@approval]
  :deadline 2026-10-31
}

Includes are explicit and recursively loaded. They do not make the target a top-level entry unless the manifest also lists it. Absolute paths, parent escapes, symlink escapes, repeated targets, and include cycles are rejected.

Shared resources

Every entry and include in the project shares:

• resources.plan, the human-maintained local source;
• resources.lock.json, the generated and reviewed online snapshot.

The effective catalog is their strict union. Duplicate stable keys across the two sources are errors; neither source silently overrides the other.

Git boundary

Commit *.plan, plan.manifest.json, resources.plan, and an accepted resources.lock.json. Ignore the entire .plan/ directory, which contains machine-local connection state. Never commit Account CLI tokens.

See Project Files for the ownership table.