pr

Constitution Compliance (MANDATORY)

Before generating PR description:

1. Check for Constitution File: Look for .codexspec/memory/constitution.md
2. If Constitution Exists:
   • Load and read relevant principles (especially documentation standards, code review guidelines)
   • Ensure PR description reflects constitutional principles
   • Verify that the changes align with project quality standards
3. If No Constitution Exists: Proceed with standard PR generation

Language Preference

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

PR description language priority:

1. If language.commit is set, use that language for the PR description
2. Otherwise, use language.output as fallback
3. If neither is configured, default to English

Note:

• Technical terms (e.g., API, JWT, OAuth, PR, MR) may remain in English when appropriate
• The PR title and section headers should follow the configured language

Examples:

• output: "zh-CN" + commit: "en" → Chinese interactions, English PR descriptions
• output: "zh-CN" + commit: "zh-CN" → Chinese for both
• output: "zh-CN" + no commit setting → Chinese for both (fallback)

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.