PR Description Writer

PR description writer

Analyze the git diff of the current branch and write a PR.md file at the repository root, containing the PR title and a description with a French section and an English section.

Language rules

• The PR title is always in English and follows the Conventional Commits format.
• PR.md contains two language sections: French inside <details>, English after the --- separator. Both sections are complete and say the same thing.
• French orthography is mandatory: use every diacritical mark (é, è, ê, ë, à, â, î, ï, ô, û, ù, ü, ç, œ, æ). Never write ASCII substitutes: "généré" not "genere", "désormais" not "desormais", "nécessaire" not "necessaire".

Workflow

1. Determine the base branch.

   • Default: develop, unless the user names another branch.
   • If a PR already exists, read its real base first: gh pr view --json baseRefName,title,body,headRefName.

2. Get the current branch: git rev-parse --abbrev-ref HEAD. Use its name to understand the intent (fix/..., feat/...).

3. Get the diff.

   • Refresh the base first: git fetch origin <base>.
   • Committed work: git diff origin/<base>...HEAD (add --stat when the diff is large).
   • Run git status too. Work is sometimes staged or uncommitted, or a commit is being reverted in the index. If the user says the changes are not committed yet, or if the index changes what the PR will contain, diff the working tree against the merge base instead: git diff $(git merge-base origin/<base> HEAD), and say so in your answer.
   • git diff never shows untracked files. List them with git ls-files --others --exclude-standard, read the ones that belong to the change, and ignore local notes or build artifacts.
   • If the branch is not pushed yet (origin/<branch> missing), fall back to HEAD and warn the user.

4. Read the real content. Never infer the content of the PR from commit titles: several commits can share the same message while containing unrelated changes. Read the full diff, and the per-file diff of the substantial files.

5. Use the context given by the user. Motivation, related issue, logs, analysis documents: integrate them. When the user points to a local analysis or crash report, read it in full and use it for the "why" (root cause, call sequence, why each part of the fix is needed, rejected alternatives). If that file is untracked, never cite or link it as a repository file: fold its content into Technical Details, Testing or Notes.

6. Analyze and synthesize:

   • what changed (features, fixes, refactoring);
   • why it changed (problem solved, motivation);
   • how it changed (key technical decisions);
   • breaking changes, new dependencies, migration steps.

7. Write PR.md with the format below, then confirm to the user that the file was written, with the title and a short summary of the content.

Accuracy rules

• Only state verified facts. Clearly separate what was observed (in logs, tests, reproduction) from what is only possible (a risk, a potential consequence).
• Do not describe an issue as systematic if it is intermittent, and do not claim a fix was validated if no build or test was run. Say explicitly what was not tested.
• Do not invent an explanation for a mechanism that was not identified: say it was not pinpointed.