release-notes

Constitution Compliance (MANDATORY)

Before generating release notes:

1. Check for Constitution File: Look for .codexspec/memory/constitution.md
2. If Constitution Exists:
   • Load and read relevant principles (especially documentation and versioning standards)
   • Ensure the generated notes align with constitutional guidelines
3. If No Constitution Exists: Proceed with the defaults below

Language Preference

IMPORTANT: Before generating output, read the project's language configuration from .codexspec/config.yml.

Generated-content language priority:

1. If language.commit is set, use that language for the CHANGELOG entry and release body
2. Otherwise, use language.output as fallback
3. If neither is configured, default to English

Note:

• Section headings that are format keywords (Added, Changed, Fixed, etc.) and technical terms (API, JWT, OAuth) may remain in English when appropriate.
• The ## [Unreleased] / ## [X.Y.Z] version markers and ISO dates are format, not prose — keep them as-is.

Expression Standard

IMPORTANT: Everything this command produces — documents, reviews, reports, commit messages, diagnostics, and replies — is written for a reader who cannot see your working context. Apply the rules below to every artifact and message you output:

• Write for the reader at hand-off. Every reference must resolve without access to this session: no session-only identifiers or section numbers, no narration of what changed during the conversation, no arguments with absent reviewers. State current reality and cite committed, reachable sources.
• Preserve every proposition. Before summarizing or trimming, list the facts a passage carries: actors, conditions, ordering, modalities (must, never), negative guarantees, and consequences. Remove only reasoning transcripts, repetition, and decoration. Shorter is not clearer if any fact is lost.
• State what the surface requires. Diagnostics name what failed, which rule was violated, and the correction. Problem reports carry the defect, its location, its impact, and the evidence. Decisions record the alternatives they beat. Rejections give the reason in one line. Shipped work is described in the present tense; plans and open questions are labeled as such.
• Define terms before relying on them. Prefer the concrete rule, field, or behavior over a coined label; give a project-specific term a plain-language definition at first use, then use it consistently.
• Be honest, not agreeable. Verify claims before accepting them; fix or rebut on technical grounds. One substantiated blocker is worth more than a list of nitpicks. When a decision is needed, present only viable options, recommend one, and state the real difference between them.
• Declare what is binding. Say explicitly which instructions are hard requirements and where judgment is required. Keep one explanation in one place and link to it, but keep at the point of use the contract a reader needs there.