Spawn Manifest Schema
The manifest file (.lumenflow/templates/manifest.yaml) controls how templates are assembled into spawn prompts. It defines the order, requirements, and conditions for each template.
File Location
Section titled “File Location”Minimal Manifest
Section titled “Minimal Manifest”Complete Manifest
Section titled “Complete Manifest”Schema Reference
Section titled “Schema Reference”Root Fields
Section titled “Root Fields”| Field | Type | Required | Description |
|---|---|---|---|
version | string | Yes | Manifest schema version |
defaults | object | No | Default settings for processing |
templates | array | Yes | List of template entries |
defaults Object
Section titled “defaults Object”| Field | Type | Default | Description |
|---|---|---|---|
tokenFormat | string | {TOKEN} | Token placeholder format |
Template Entry
Section titled “Template Entry”Each entry in the templates array:
| Field | Type | Required | Description |
|---|---|---|---|
id | string | Yes | Unique identifier matching template frontmatter |
path | string | Yes | Relative path from .lumenflow/templates/ |
required | boolean | Yes | Whether template must exist |
order | number | Yes | Sort position (ascending) |
condition | string | No | Inclusion condition expression |
Field Details
Section titled “Field Details”version
Section titled “version”The manifest schema version. Currently only 1.0 is supported.
Future versions may add new fields or change behavior.
A unique identifier for the template. Must match the id field in the template’s YAML frontmatter.
The id is used for:
- Matching templates during loading
- Client override resolution
- Error messages and debugging
Relative path from .lumenflow/templates/ to the template file.
required
Section titled “required”Controls behavior when a template cannot be found or loaded.
When true:
Assembly fails with an error message indicating the expected path.
When false:
Missing template is skipped without error.
Numeric value controlling assembly sequence. Lower values appear first in the output.
Recommended ranges:
| Range | Purpose |
|---|---|
| 10-20 | Type and verification directives |
| 50-70 | Skills, craft, and context |
| 100-140 | Agent guidance and completion format |
| 200-300 | Operational guidance |
| 300-310 | Recovery and worktree |
| 400-500 | Lane-specific guidance |
| 820-850 | Action and completion checks |
| 900+ | Constraints (always last) |
Equal order values:
When multiple templates have the same order, their relative order is undefined. Use conditions to ensure only one is included:
condition
Section titled “condition”Optional JavaScript-like expression controlling template inclusion.
Syntax:
| Operator | Example |
|---|---|
| Equality | type === 'feature' |
| Inequality | type !== 'documentation' |
| Truthy | worktreePath |
| AND | type === 'bug' && laneParent === 'Core' |
| OR | type === 'feature' || type === 'bug' |
Available variables:
| Variable | Description |
|---|---|
type | WU type (feature, bug, documentation) |
lane | Full lane name |
laneParent | Parent lane (Framework, Content, etc.) |
wuId | Work Unit ID |
worktreePath | Worktree path (truthy if claimed) |
title | WU title |
description | WU description |
policy.testing | Resolved testing policy (tdd, test-after, none) |
policy.architecture | Resolved architecture policy |
work.domain | Classified work domain (ui, backend, docs, etc.) |
work.testMethodologyHint | Classifier hint (smoke-test, structured-content) |
hasRequiredVerification | Truthy when any required verification is declared |
tests.hasUnit | Truthy when the WU spec declares unit test paths |
tests.hasE2E | Truthy when the WU spec declares E2E test paths |
tests.hasManual | Truthy when the WU spec declares manual verification items |
Examples:
Validation
Section titled “Validation”The manifest is validated when loaded. Errors include:
Missing version
Section titled “Missing version”Missing templates array
Section titled “Missing templates array”Invalid template entry
Section titled “Invalid template entry”YAML syntax error
Section titled “YAML syntax error”Assembly Algorithm
Section titled “Assembly Algorithm”When wu:brief assembles templates:
- Parse manifest - Validate structure and entries
- Load templates - Read files from
spawn-prompt/ - Resolve client alias - Example:
claude-code->claude,codex-cli->codex - Apply overrides - Replace base templates with client-specific versions
- Sort entries - Order by
orderfield ascending - Evaluate conditions - Skip templates where condition is false
- Check required - Error if required template is missing
- Replace tokens - Substitute
{TOKEN}placeholders - Join sections - Concatenate with double newlines
Client Override Resolution
Section titled “Client Override Resolution”Client-specific manifests are not supported. Overrides work at the template level:
When assembling for --client claude-code:
- Load base template with
id: skills-selection - Resolve alias to
claude - Load override from
templates.claude/spawn-prompt/skills-selection.md - Override replaces base (matched by
id)
Client Alias Mapping
Section titled “Client Alias Mapping”Client Flag (--client) | Alias | Override Directory |
|---|---|---|
claude-code | claude | templates.claude/ |
codex-cli | codex | templates.codex/ |
gemini-cli | gemini | templates.gemini/ |
cursor | cursor | templates.cursor/ |
windsurf | windsurf | templates.windsurf/ |
Default Built-In Sections
Section titled “Default Built-In Sections”These are the built-in sections most consumers override first:
| Template ID | When it is included | Typical reason to override |
|---|---|---|
visual-directive | UI work or work.testMethodologyHint === 'smoke-test' | Add project-specific UI verification commands |
structured-content-directive | work.testMethodologyHint === 'structured-content' | Add content/config evaluators or schema checks |
verification-requirements | hasRequiredVerification | Reformat or extend WU-declared verification output |
design-context-ui | work.domain === 'ui' | Add design system or accessibility review guidance |
code-craft | Always | Tighten implementation standards |
read-before-write | Always | Add repo-specific discovery expectations |
self-review | Always | Add completion checklist items |
Lookup-Based Section Tokens
Section titled “Lookup-Based Section Tokens”These shipped ids are selected directly by the CLI prompt builders and often carry section-specific
tokens in addition to the shared {WU_ID}, {LANE}, and {WORKTREE_PATH} values:
| Template ID | Primary token(s) | Notes |
|---|---|---|
project-specific-co-change-guidance | CO_CHANGE_GUIDANCE_SECTION | Wrapper token containing the fully rendered co-change section |
mandatory-agents | MANDATORY_AGENTS | Injects the rendered bullet list of required agents |
invariants-prior-art | INVARIANTS_PRIOR_ART_SECTION | Wrapper token for the full invariants/prior-art section |
implementation-context | IMPLEMENTATION_CONTEXT_SECTION | Wrapper token for the full implementation-context section |
agent-coordination | AGENT_COORDINATION_SECTION | Wrapper token preserving config-driven progress-signal wording |
action-unclaimed | WORKTREE_PATH_HINT, WU_EVENTS_PATH | Use alongside shared {WU_ID} and {LANE} |
codex-constraints | TDD_CHECKPOINT_BLOCK, numbering tokens, {WU_ID} | Codex-only constraints rendering |
Next Steps
Section titled “Next Steps”- Template Format - Template file structure
- Customizing Spawn Prompts - Create custom templates
- CLI Reference -
wu:briefandwu:delegatecommand options