How to write comments in .sdd files
This guide shows you how to write comments in SpecDD .sdd files.
Comments are supported, but they are ignored as spec content. That makes them useful for short non-contract notes and dangerous for hidden requirements.
Short answer
Use whole-line comments whose first non-whitespace character is #. Do not use inline trailing comments as comments.
Comments do not create requirements, constraints, tasks, references, or write authority. If the line affects behavior,
put it in Must, Must not, Tasks, Scenario, Done when, or another real section.
Syntax
Valid comments:
# root comment
# section comment
# deeply indented commentNot an inline comment:
Must:
Validate input. # This is body text, not a comment.Rules:
- A comment line begins with optional whitespace followed by
#. - Comments may appear before, between, and inside sections.
- Comments are ignored as spec content.
- Inline trailing comments are ordinary line content.
Steps
1. Use comments for non-contract notes
Acceptable:
# Temporary note: compare this spec with the storage ADR during review.
Spec: ItineraryBetter for durable context:
References:
/docs/adr/storage-boundary.md2. Put requirements in sections
Do not write:
# Must reject missing place names.
Spec: ItineraryWrite:
Spec: Itinerary
Must:
Reject itinerary items without a place name.3. Put tasks in Tasks
Do not write:
# Note: add missing-place validation later.Write:
Tasks:
[ ] Add missing-place validation.4. Avoid inline comments
This line is a Must body entry with # text inside it:
Must:
Reject empty place names. # required by supportIf the note matters, rewrite the entry or use a separate whole-line comment.
Common mistakes
- Using comments as hidden requirements.
- Writing inline trailing comments and assuming they are ignored.
- Putting work items in comments instead of
Tasks. - Using comments for write authority or constraints.
- Leaving old comments that contradict the spec body.
How to verify the result
Comments are safe when:
- removing comments would not change the contract
- requirements and tasks are in real sections
- inline
#text is not used as a comment - comments do not contradict active spec entries
- comment volume stays low