Mirrors/tabler
1
0
Fork 0
mirror of https://github.com/tabler/tabler.git synced 2026-08-29 13:21:29 +04:00
Code Issues Projects Releases Wiki Activity

Keep issue links when regenerating MR descriptions (#2733)

Browse Source
This commit is contained in:
Paweł Kuna
2026-07-30 23:11:05 +02:00
committed by GitHub
parent 02499be091
commit bc949c414c
1 changed files with 12 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/mr-description/SKILL.md
+12 -4
View File
@@ -38,7 +38,15 @@ From the repository root:
Use this to infer **intent**, **user-visible behavior**, and **risk**—not only filenames.
**Vercel preview URL:** after the branch is pushed, Vercel deploys a preview. Build the link from the branch name:
**Existing PR content:** Before drafting, check whether a PR already exists for this branch (e.g. `gh pr view --json title,body,number,url` for the current branch, or a PR number/URL the user gave you). If one exists, read its current title and body first:
- Carry over any issue references it already contains — `Closes #N`, `Fixes #N`, `Resolves #N`, or a plain `#N` mention — into the new body. Put them in **Notes / rollout** (or, if the PR uses a dedicated `Issue`/`Closes` line, keep that same convention) so a regenerated description never silently drops the link to a tracked issue.
- Don't assume the diff alone tells you which issue this closes — the existing PR body is often the only place that link is recorded.
- If no PR exists yet, skip this step (there is nothing to carry over).
**Vercel preview URL:** only when the diff has **visual / UI changes** a reviewer can check in the browser (CSS, preview pages, docs examples, components, layout). Skip the preview URL for non-visual work (agent skills, CI, tooling, docs prose-only, lockfile, config with no rendered UI effect).
When a preview URL is needed and the branch is pushed, Vercel deploys a preview. Build the link from the branch name:
1. Take the current branch name from `git branch --show-current`.
2. Replace `/` with `-`, **remove dots entirely** (do not replace them with dashes), and use lowercase (e.g. `feature/pricing-banner` → `feature-pricing-banner`, `update-icons-3.45.0` → `update-icons-3450`).
@@ -67,7 +75,7 @@ Remove `money-back-guarantee` flag; show label on paid plans
## 4. Body (markdown template)
Output the body in a **second** fenced **`markdown`** block after the title block. Use this structure inside that block. Omit **Notes / rollout** if nothing applies. Do **not** add a separate `## Test plan` section unless the user explicitly asks for one—use **Preview** instead.
Output the body in a **second** fenced **`markdown`** block after the title block. Use this structure inside that block. Omit **Notes / rollout** if nothing applies. Omit the **URL** line (or the whole **Preview** section) when there are no visual changes—do not link a Vercel preview in that case. Do **not** add a separate `## Test plan` section unless the user explicitly asks for one—use **Preview** (or a short “how to review” note under Summary) instead.
```markdown
## Summary
@@ -86,9 +94,9 @@ Output the body in a **second** fenced **`markdown`** block after the title bloc
**Summary bullets:** 1–4 bullets tying changes to product/engineering impact.
**Preview:** Always include when the branch is pushed (or note that preview is unavailable until push). Use the Vercel URL format from §2. Link the most relevant path(s)—homepage only if changes are global; otherwise deep-link (e.g. `/pricing`, `/blog/…`). **How to test** should be actionable: which page, which UI element or behavior changed, and what the reviewer should expect to see.
**Preview:** Include a Vercel **URL** only when the change is visual and the branch is pushed (or note that preview is unavailable until push). If there are no visual changes, omit the preview link entirely—do not add a homepage or generic preview URL. When a URL is included, use the Vercel format from §2 and deep-link the most relevant path(s)—homepage only if changes are global. **How to test** should be actionable: which page, which UI element or behavior changed, and what the reviewer should expect to see. For non-visual PRs, say how to review the diff instead (e.g. which files to read).
**Notes:** Feature flags, env vars, backwards compatibility—only when evidenced in the diff or commit messages.
**Notes:** Feature flags, env vars, backwards compatibility—only when evidenced in the diff or commit messages. Also include any issue reference carried over from an existing PR (see §2), e.g. `Closes #123`.
## 5. Language (simple English)