Configuring with config.yaml

An optional config.yaml file placed next to your template gives you full control over the interview experience — without modifying the template itself. The Analyzer merges it into the manifest; the Orchestrator reads only the manifest.

templates/
└── meeting_notes/
    ├── meeting_notes.md            ← template
    └── config.yaml                 ← interview configuration

If no config.yaml is present, CoQuill uses sensible defaults: variable names are converted to labels, types are inferred from name suffixes, and questions are presented in the order they appear in the template.

Top-level structure

meta:
  display_name: "Meeting Notes"
  description: "Structured meeting notes with action items and optional sections"

variables:
  # per-variable overrides

groups:
  # interview grouping and ordering

validation:
  # cross-field rules

All sections are optional. You can use just variables: to override question labels without touching groups or validation.

meta

meta:
  display_name: "Meeting Notes"
  description: "Structured meeting notes with action items and optional sections"

display_name is shown to the user when Claude confirms which template it matched. description is used internally and may appear in future template directory features.

variables

Each entry overrides one variable’s defaults:

variables:
  meeting_title:
    label: "Meeting Title"
    question: "What is the title of this meeting?"
    required: true

  meeting_date:
    question: "When was the meeting held?"
    default: "today"
    format_hint: "DD/MM/YYYY"

  meeting_type:
    type: choice
    choices: [standup, workshop, review]
    default: standup
    question: "What type of meeting was this?"

  include_next_meeting:
    type: boolean
    default: false
    question: "Is a follow-up meeting scheduled?"

Variable fields

Field	Type	Description
label	string	Short label shown above the input field
question	string	Full question text Claude asks the user
type	string	Explicit type override (see types below)
default	any	Pre-filled value; use "today" for today’s date
required	boolean	If true, the user cannot skip this field (default: false)
format_hint	string	Helper text shown alongside the question
choices	list	For type: choice — the list of valid options

Variable types

Type	Use when
text	Free text; the default for most variables
date	A calendar date
number	A numeric value (currency, quantity, percentage)
email	An email address
phone	A phone number
boolean	A yes/no gate for a conditional section
choice	One of a fixed set of options

groups

Groups control how the interview is structured. Without groups, Claude presents variables one at a time in template order. With groups, related variables are batched under a heading and presented together.

Basic group

groups:
  - name: "Meeting Details"
    variables: [meeting_title, meeting_date, meeting_type, facilitator_name, meeting_location]

  - name: "Attendees & Agenda"
    variables: [attendees, agenda]

Conditional group

A group that only appears when a gate variable is true. Claude asks the gate question first; if the answer is no, the entire group is skipped.

groups:
  - name: "Next Meeting"
    condition: include_next_meeting
    variables: [next_meeting_date, next_meeting_topic]

The condition value must be a boolean variable already collected earlier in the interview.

Loop group

A group that maps to a {% for %} loop in the template. Claude collects items one at a time, prompting for the sub-fields on each pass.

groups:
  - name: "Action Items"
    loop: action_items
    variables: [description, assignee, due_date]

loop must match the collection name used in the template ({% for item in action_items %}). The variables list names the sub-fields of each item.

validation

Cross-field rules evaluated after all values are collected but before rendering:

validation:
  - rule: "next_meeting_date > meeting_date"
    message: "The next meeting date must be after this meeting's date."

If a rule fails, Claude reports the message and prompts the user to re-enter the offending values. Rules use Python expression syntax and have access to all collected variable values.

Complete example

meta:
  display_name: "Meeting Notes"
  description: "Structured meeting notes with action items, optional sections, and meeting-type-specific content"

variables:
  meeting_title:
    label: "Meeting Title"
    question: "What is the title of this meeting?"
    required: true

  meeting_date:
    question: "When was the meeting held?"
    default: "today"
    format_hint: "DD/MM/YYYY"

  meeting_type:
    type: choice
    choices: [standup, workshop, review]
    default: standup
    question: "What type of meeting was this?"

  decisions_made:
    type: boolean
    question: "Were any decisions made during this meeting?"
    default: false

  include_next_meeting:
    type: boolean
    question: "Is a follow-up meeting scheduled?"
    default: false

groups:
  - name: "Meeting Details"
    variables: [meeting_title, meeting_date, meeting_type, facilitator_name, meeting_location]

  - name: "Attendees & Agenda"
    variables: [attendees, agenda]

  - name: "Workshop Materials"
    condition: "meeting_type == 'workshop'"
    variables: [workshop_materials]

  - name: "Action Items"
    loop: action_items
    variables: [description, assignee, due_date]

  - name: "Decisions"
    condition: decisions_made
    variables: [decisions]

  - name: "Next Meeting"
    condition: include_next_meeting
    variables: [next_meeting_date, next_meeting_topic]

validation:
  - rule: "next_meeting_date > meeting_date"
    message: "The next meeting date must be after this meeting's date."