Language rule for reports published to issue trackers (GitHub, JIRA, Bugsnag)
php artisan boost:add-skill pekral/arch-app-services
Save this content to: .cursor/rules/reports/general.mdc
## Tracker-Published Reports — Language
Every report a skill publishes to an issue tracker **must be written in the same language as the source assignment**, and **must never mix that language with another natural language inside the same comment**. When the GitHub issue / JIRA ticket / Bugsnag-linked issue description is in Czech, the published report is fully in Czech; when it is in English, the report is fully in English. Pick the assignment language and stay in it for every prose sentence of the comment — no parenthetical bilingual hints, no half-translated headings, no English boilerplate dropped into a Czech body.
The rule applies to every tracker target and every tracker output:
- non-technical PR / issue / JIRA summaries (`pr-summary`, `assignment-compliance-check`, `tester-cookbook`)
- security-review and security-threat-analysis reports surfaced on the linked issue or non-technical channel
- analyze-problem / resolve-issue / test-like-human reports surfaced on the tracker
- process-code-review mirrored issue summaries
- any other comment posted on a tracker by a skill
### Exception — technical CR findings on the GitHub PR
The single, narrowly scoped exception: **the technical code-review comment posted on a GitHub pull request stays in canonical English**, regardless of the assignment language. Specifically:
- `@skills/code-review-github/SKILL.md` PR comments (full CR template — Status, Counts, Findings, Refactoring, Coverage, Summary line)
- `@skills/code-review-jira/SKILL.md` GitHub-side PR comments (the technical findings half of its split publish)
- `@skills/code-review/SKILL.md` review markdown — produced for the wrappers above and never published directly, but the output is shaped for the exception channel and therefore stays English at source
- `@skills/process-code-review/SKILL.md` reply comments on the PR (resolved-items follow-up)
- `@skills/security-review/SKILL.md` audit findings when they are folded into the GitHub PR comment
- `@skills/security-threat-analysis/SKILL.md` remediation reports when posted as a PR comment
- `@skills/resolve-issue/SKILL.md` final technical report posted on the PR (code-review / security-review / test-like-human summary block) — same channel as the CR wrappers above
These comments stay in English because they (a) are machine-parsed by `@skills/process-code-review/SKILL.md` for reproducer extraction; (b) carry severity labels (*Critical / Moderate / Minor* / *High / Low*), structured field labels (*Location*, *Rule*, *Impact*, *Faulty Example*, *Expected Behavior*, *Test Hint*, *Suggested Fix*), and rule references that already exist in English elsewhere in the codebase; (c) live next to code identifiers, error messages, and discussion threads from non-Czech contributors. Translating them creates parsing breakage and cross-language drift without helping the reader.
The exception does **not** extend to:
- the non-technical mirror published on the linked GitHub issue (`closingIssues[]`) — that follows the assignment language
- the JIRA-side comment from `code-review-jira` (delegated to `pr-summary`) — that follows the assignment language
- the assignment-compliance comment from `assignment-compliance-check` — that follows the assignment language
- the `pr-summary` comment, regardless of where it is posted — that follows the assignment language. On a **GitHub** target it carries *TL;DR / Authors / Available behind / Summary of changes / How to test*; on a **JIRA** target it carries **only `TL;DR` and How to test** plus any conditional *Clarifying questions* / *Assignment Compliance* blocks. Either shape follows the assignment language.
### How to detect the assignment language
1. Read the issue description and the most recent author-written comment off the deterministic loader (`skills/code-review-github/scripts/load-issue.sh` for GitHub, `skills/code-review-jira/scripts/load-issue.sh` for JIRA). The wording the reporter used there is the canonical signal.
2. When the issue body is empty or contains only a screenshot, fall back to the language of the linked JIRA ticket, the parent epic, or the PR description written by the same reporter.
3. When no signal is available, default to English and state the assumption in the published report's footer.
### Scope clarifications
- **Code identifiers stay verbatim.** Class names, file paths, function names, error codes, enum cases, configuration keys, route paths, and similar machine-readable tokens keep their original form regardless of the surrounding prose language. Do not translate `App\Actions\ProcessPayment` into the assignment language. Quoting a code identifier inside an assignment-language sentence is not "mixing" — code is not a natural language.
- **PR titles and commit messages stay in English** per `@rules/git/general.mdc`. The language-matching rule applies to report bodies posted as comments / descriptions, not to git metadata.
- **In-conversation status, terminal output, and debug logs may stay in English.** Only tracker-facing reports follow the assignment language.
- **No bilingual parentheses.** Do not write *Kritické (Critical)* or *Závažné (Moderate)*. Either the whole comment is the English exception (so use *Critical / Moderate / Minor* directly), or the whole comment is in the assignment language (so use the assignment-language equivalent without an English gloss).
### Failure modes to avoid
- Posting a bilingual comment with the assignment language for prose and English in inline parentheses for severity labels or structural keywords.
- Translating the technical CR PR comment to Czech — the exception above keeps it English.
- Translating the non-technical issue / JIRA summary to English when the assignment is in Czech — the exception is narrow and does **not** cover those.
- Posting in the language of the agent's chat session instead of the language of the assignment.
- Switching mid-comment between Czech and English when quoting requirements verbatim — quote the requirement verbatim, then continue in the assignment language without a parenthetical translation.
Every report a skill publishes to an issue tracker must be written in the same language as the source assignment, and must never mix that language with another natural language inside the same comment. When the GitHub issue / JIRA ticket / Bugsnag-linked issue description is in Czech, the published report is fully in Czech; when it is in English, the report is fully in English. Pick the assignment language and stay in it for every prose sentence of the comment — no parenthetical bilingual hints, no half-translated headings, no English boilerplate dropped into a Czech body.
The rule applies to every tracker target and every tracker output:
pr-summary, assignment-compliance-check, tester-cookbook)The single, narrowly scoped exception: the technical code-review comment posted on a GitHub pull request stays in canonical English, regardless of the assignment language. Specifically:
@skills/code-review-github/SKILL.md PR comments (full CR template — Status, Counts, Findings, Refactoring, Coverage, Summary line)@skills/code-review-jira/SKILL.md GitHub-side PR comments (the technical findings half of its split publish)@skills/code-review/SKILL.md review markdown — produced for the wrappers above and never published directly, but the output is shaped for the exception channel and therefore stays English at source@skills/process-code-review/SKILL.md reply comments on the PR (resolved-items follow-up)@skills/security-review/SKILL.md audit findings when they are folded into the GitHub PR comment@skills/security-threat-analysis/SKILL.md remediation reports when posted as a PR comment@skills/resolve-issue/SKILL.md final technical report posted on the PR (code-review / security-review / test-like-human summary block) — same channel as the CR wrappers aboveThese comments stay in English because they (a) are machine-parsed by @skills/process-code-review/SKILL.md for reproducer extraction; (b) carry severity labels (Critical / Moderate / Minor / High / Low), structured field labels (Location, Rule, Impact, Faulty Example, Expected Behavior, Test Hint, Suggested Fix), and rule references that already exist in English elsewhere in the codebase; (c) live next to code identifiers, error messages, and discussion threads from non-Czech contributors. Translating them creates parsing breakage and cross-language drift without helping the reader.
The exception does not extend to:
closingIssues[]) — that follows the assignment languagecode-review-jira (delegated to pr-summary) — that follows the assignment languageassignment-compliance-check — that follows the assignment languagepr-summary comment, regardless of where it is posted — that follows the assignment language. On a GitHub target it carries TL;DR / Authors / Available behind / Summary of changes / How to test; on a JIRA target it carries only TL;DR and How to test plus any conditional Clarifying questions / Assignment Compliance blocks. Either shape follows the assignment language.skills/code-review-github/scripts/load-issue.sh for GitHub, skills/code-review-jira/scripts/load-issue.sh for JIRA). The wording the reporter used there is the canonical signal.App\Actions\ProcessPayment into the assignment language. Quoting a code identifier inside an assignment-language sentence is not "mixing" — code is not a natural language.@rules/git/general.mdc. The language-matching rule applies to report bodies posted as comments / descriptions, not to git metadata.How can I help you explore Laravel packages today?