This is an automated email from the ASF dual-hosted git repository.
terrymanu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 68be9fb3064 Refactor pr-review and analyze issue skills (#38718)
68be9fb3064 is described below
commit 68be9fb3064f1bf8beabb2d4896627ba6f6e2637
Author: Liang Zhang <[email protected]>
AuthorDate: Mon May 25 19:28:45 2026 +0800
Refactor pr-review and analyze issue skills (#38718)
* Refactor agents.md
* Refactor pr-review and analyze issue skills
---
.codex/skills/analyze-issue/SKILL.md | 102 +++++++++++++++++++++++++++++
.codex/skills/review-pr/SKILL.md | 120 ++++++++++++++++++++++++++---------
2 files changed, 192 insertions(+), 30 deletions(-)
diff --git a/.codex/skills/analyze-issue/SKILL.md
b/.codex/skills/analyze-issue/SKILL.md
index 2da33936b64..e5f58c94379 100644
--- a/.codex/skills/analyze-issue/SKILL.md
+++ b/.codex/skills/analyze-issue/SKILL.md
@@ -187,6 +187,108 @@ Type-specific rules:
## Mandatory Output Structure
+### GitHub Issue Markdown Requirements
+
+- Format every issue analysis as GitHub-flavored Markdown that can be pasted
directly into a GitHub issue comment.
+- The GitHub-facing issue analysis body must not be wrapped in a code fence,
blockquote, XML/HTML container, or plain-text transcript.
+- Use the same natural language as the user request for explanatory prose
unless the user explicitly asks for another language.
+- Keep the mandatory Markdown structure unchanged regardless of output
language.
+- Keep mandatory section titles and stable fields in English, such as `Problem
Understanding`, `Root Cause`, `Problem Analysis`,
+ `Problem Conclusion`, `Evidence Confidence`, `Issue Type`, `Recommended
Labels`, and `Next Action`.
+- Use Markdown headings (`### Problem Understanding`, `### Root Cause`, etc.)
with a blank line before and after each heading.
+- Use short unordered bullets under each heading; use bold inline labels such
as `Observation:`, `Inference:`, `Confidence:`, and `Action:`.
+- Use repo-relative paths with line numbers, for example
`infra/.../Foo.java:123`; do not use local absolute file paths in GitHub-facing
analysis text.
+- Keep evidence IDs, labels, severity values, topology values, commands, class
names, method names, SQL, YAML, and Java snippets in their original
English/code form.
+- Prefer bullets over tables. Use tables only for compact status summaries
that remain readable in GitHub's issue comment pane.
+- Keep command evidence in inline code or short fenced blocks; avoid long raw
JSON, full logs, or unrendered terminal transcripts.
+- Before final output, perform a formatting self-check on the inner
GitHub-facing issue analysis body:
+ - The inner GitHub-facing issue analysis body is not wrapped in a code
fence, blockquote, XML/HTML container, or transcript.
+ - The inner GitHub-facing issue analysis body contains the required `###`
headings for the selected issue-type template.
+ - The inner GitHub-facing issue analysis body contains `Problem Conclusion`
with the required conclusion fields.
+ - File references are repo-relative paths with line numbers, not local
absolute paths.
+ - Stable section titles, evidence IDs, labels, severity values, and
conclusion field labels remain in English/code form.
+
+### Codex Chat Delivery
+
+- When returning the issue analysis in Codex chat for the user to copy, wrap
the GitHub-facing issue analysis body in a fenced `markdown` code block.
+- The fenced code block is only a chat delivery wrapper; it is not part of the
GitHub-facing issue analysis body.
+- Tell the user to copy only the content inside the fenced block.
+- Keep any copy instruction outside the fenced block.
+- When posting directly to GitHub through an API or tool, submit only the
inner GitHub-facing issue analysis body and do not include the outer fence.
+- Apply the formatting self-check to the inner GitHub-facing issue analysis
body, not to the chat delivery wrapper.
+
+Use this GitHub Markdown skeleton for Question and Misunderstanding / Invalid
Usage:
+
+```markdown
+### Problem Understanding
+
+- **Issue:** ...
+- **Topology:** ...
+- **Observed Evidence:** `OBS-1`, `OBS-2`
+
+### Root Cause
+
+- **Observation:** ...
+- **Inference:** ...
+- **Confidence:** High/Medium/Low
+
+### Problem Analysis
+
+- **Issue Type:** Question / Misunderstanding / Invalid Usage
+- **Evidence:** ...
+- **Label Recommendation:** ...
+
+### Problem Conclusion
+
+- **Evidence Confidence:** High/Medium/Low
+- **Impact Scope:** ...
+- **Topology:** JDBC/Proxy + Standalone/Cluster
+- **Issue Type:** ...
+- **Recommended Labels:** ...
+- **Next Action:** ...
+```
+
+Use this GitHub Markdown skeleton for Bug and Enhancement:
+
+```markdown
+### Problem Understanding
+
+- **Issue:** ...
+- **Topology:** ...
+- **Observed Evidence:** `OBS-1`, `OBS-2`
+
+### Root Cause
+
+- **Observation:** ...
+- **Inference:** ...
+- **Confidence:** High/Medium/Low
+
+### Problem Analysis
+
+- **Issue Type:** Bug / Enhancement
+- **Evidence:** ...
+- **Compatibility Checklist:** Behavior / Config / API-SPI / SQL
+
+### Code-Level Design Suggestions
+
+- **Affected Modules:** ...
+- **Key Classes:** ...
+- **Required Test Scope:** ...
+- **Rollback Hint:** ...
+
+### Problem Conclusion
+
+- **Evidence Confidence:** High/Medium/Low
+- **Severity:** S0/S1/S2/S3
+- **Impact Scope:** ...
+- **Topology:** JDBC/Proxy + Standalone/Cluster
+- **Issue Type:** ...
+- **Recommended Labels:** ...
+- **Next Action:** ...
+- **Compatibility:** Behavior/Config/API-SPI/SQL
+- **Regression Scope:** ...
+```
+
Four-section structure (Question, Misunderstanding / Invalid Usage):
1. Problem Understanding
2. Root Cause
diff --git a/.codex/skills/review-pr/SKILL.md b/.codex/skills/review-pr/SKILL.md
index c28f62c3aa3..a305d16acdb 100644
--- a/.codex/skills/review-pr/SKILL.md
+++ b/.codex/skills/review-pr/SKILL.md
@@ -233,41 +233,101 @@ When the user provides previous-round feedback or PR
adds new commits, perform i
## Output Structure
+### GitHub Review Markdown Requirements
+
+- Format every review as GitHub-flavored Markdown that can be pasted directly
into a PR comment or review body.
+- The GitHub-facing review body must not be wrapped in a code fence,
blockquote, XML/HTML container, or plain-text transcript.
+- Use the same natural language as the user request unless the user explicitly
asks for another language.
+- Use Markdown headings (`### Decision`, `### Major Issues`, etc.) with a
blank line before and after each heading.
+- Keep the GitHub Markdown structure unchanged regardless of output language.
+- Keep `Merge Verdict: ...` as a bold bullet near the top, and output exactly
one verdict line.
+- Keep stable review labels in English, such as `Merge Verdict`, `Reviewed
Scope`, `Not Reviewed Scope`, and `Need Expert Review`,
+ so they remain searchable and consistent.
+- Use short unordered bullets under each heading; use bold inline labels such
as `Symptom:`, `Risk:`, and `Action:` for issue details.
+- Use repo-relative paths with line numbers, for example
`infra/.../Foo.java:123`; do not use local absolute file paths in GitHub-facing
review text.
+- Prefer bullets over tables. Use tables only for compact status summaries
that remain readable in GitHub's narrow review pane.
+- Keep command evidence in inline code or short fenced blocks; avoid long raw
JSON, full logs, or unrendered terminal transcripts.
+- Before final output, perform a formatting self-check on the inner
GitHub-facing review body:
+ - The inner GitHub-facing review body is not wrapped in a code fence,
blockquote, XML/HTML container, or transcript.
+ - The inner GitHub-facing review body contains the required `###` headings
for the selected verdict template.
+ - The inner GitHub-facing review body contains exactly one bold `Merge
Verdict: ...` line.
+ - File references are repo-relative paths with line numbers, not local
absolute paths.
+ - Stable labels remain in English.
+
+### Codex Chat Delivery
+
+- When returning the review in Codex chat for the user to copy, wrap the
GitHub-facing review body in a fenced `markdown` code block.
+- The fenced code block is only a chat delivery wrapper; it is not part of the
GitHub-facing review body.
+- Tell the user to copy only the content inside the fenced block.
+- Keep any copy instruction outside the fenced block.
+- When posting directly to GitHub through an API or tool, submit only the
inner GitHub-facing review body and do not include the outer fence.
+- Apply the formatting self-check to the inner GitHub-facing review body, not
to the chat delivery wrapper.
+
### A. Not Mergeable (Change Request)
-Use committer tone, gentle wording, no emojis; structure:
-
-1. Decision block
- - `Merge Verdict: Not Mergeable`
- - `Reviewed Scope / Not Reviewed Scope / Need Expert Review`
-2. Positive feedback (optional)
- - Include only when there are genuinely correct direction-aligned changes.
- - Omit if none.
-3. Major issues
- - List unreasonable/incorrect points by severity.
- - Each issue includes: label, symptom, risk, recommended action (fix or
rollback).
-4. Newly introduced issues
- - Point out defects/regression risks introduced by this PR.
- - Clearly require fix or rollback.
-5. Unrelated changes (output only when present)
- - List changes unrelated to this PR goal and request rollback.
-6. Next-step suggestions
- - Provide executable fix checklist and encourage next revision.
-7. Multi-round comparison (only when history exists)
- - Versus previous round: closed, unresolved, and new items.
-8. Evidence supplement (only when information is insufficient)
- - Explicitly list minimum additional information and review entry points.
+Use committer tone, gentle wording, no emojis; use this GitHub Markdown
skeleton:
+
+```markdown
+### Decision
+
+- **Merge Verdict: Not Mergeable**
+- **Reviewed Scope:** ...
+- **Not Reviewed Scope:** ...
+- **Need Expert Review:** ...
+
+### Positive Feedback
+
+- Optional; omit this section when there is no genuinely correct
direction-aligned change.
+
+### Major Issues
+
+- **[Severity] Short issue title** (`path/to/File.java:123`)
+ - **Symptom:** ...
+ - **Risk:** ...
+ - **Action:** Please ...
+
+### Newly Introduced Issues
+
+- Include only when the latest PR revision introduces new defects or
regression risks.
+
+### Unrelated Changes
+
+- Include only when unrelated changes exist, and explicitly ask for rollback.
+
+### Next Steps
+
+- Provide an executable fix checklist.
+
+### Multi-Round Comparison
+
+- Include only when previous-round feedback exists; summarize closed,
unresolved, and new items.
+
+### Evidence Supplement
+
+- Include only when information gaps block mergeability; list the minimum
additional information required.
+```
### B. Mergeable
-1. Decision block
- - `Merge Verdict: Mergeable`
- - `Reviewed Scope / Not Reviewed Scope / Need Expert Review`
-2. Basis
- - Root-cause fix evidence.
- - Risk assessment results (proving no unresolved risk).
-3. Pre-merge checks
- - CI, tests, compatibility confirmations.
+Use this GitHub Markdown skeleton:
+
+```markdown
+### Decision
+
+- **Merge Verdict: Mergeable**
+- **Reviewed Scope:** ...
+- **Not Reviewed Scope:** ...
+- **Need Expert Review:** ...
+
+### Basis
+
+- Root-cause fix evidence.
+- Risk assessment results proving no unresolved risk.
+
+### Pre-Merge Checks
+
+- CI, tests, and compatibility confirmations.
+```
## Change Request Tone Guidelines
