القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/databricks/cli --skill pr-checklistيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | pr-checklist |
| description | Checklist to run before submitting a PR |
Before submitting a PR, run these commands to match what CI checks. CI uses the full variants (not the -q diff-only wrappers), so ./task lint-q alone is insufficient.
# 1. Formatting and checks (CI runs fmt, not fmt-q)
./task fmt
./task checks
# 2. Linting (CI runs full golangci-lint across all modules, not the diff-only wrapper)
./task lint
# 3. Tests (CI runs with both deployment engines)
./task test
# 4. If you changed bundle config structs, schema, or direct-engine resource code:
./task generate-schema
./task generate-direct
# 5. If you changed files in python/:
./task pydabs-codegen pydabs-test pydabs-lint pydabs-docs
# 6. If you changed cmd/aitools/, libs/aitools/, experimental/aitools/, or experimental/ssh/:
./task test-exp-aitools # only if aitools code changed (top-level or experimental)
./task test-exp-ssh # only if ssh code changed
After the commands above pass, scrub the diff before pushing. The quick version: run git diff @{u} and read through what you added. Specifically:
Debug prints: look for newly added fmt.Print, fmt.Printf, fmt.Println, log.Print, log.Printf, log.Println, or bare println(...) calls. A regex that scans only added lines against your upstream branch:
git diff @{u} -- '*.go' | rg '^\+.*\b(fmt|log)\.(Print|Printf|Println)\b|^\+.*\bprintln\('
If you have no upstream yet, substitute the intended base (e.g. origin/main) for @{u}.
Commented-out code: delete it. If it's needed for reference, it lives in git history.
TODOs without a ticket: either add a ticket reference (e.g. // TODO(DECO-1234): ...) or remove the TODO. Un-tracked TODOs rot.
Unintended files: review git status and git diff --stat to confirm only the files you meant to change are staged.
Follow .github/PULL_REQUEST_TEMPLATE.md exactly. Use its section headings (## Changes, ## Why, ## Tests) in the same order, and fill each one in. Do not invent new sections (## Summary, ## Test plan, etc.), do not drop sections, and do not leave the HTML comment placeholders in the final body — replace them with real content. If a section genuinely does not apply (e.g. a docs-only change has no test steps), say so explicitly under that heading rather than removing it.
RULE: Be concise in the PR summary. Overly verbose descriptions tend to be ignored by reviewers. Let the diff speak for itself and only describe at a high level what you have implemented/what components were touched.
When using gh pr create, read .github/PULL_REQUEST_TEMPLATE.md first and base --body on it.
If an agent (you) authored or substantially helped author the PR, disclose it on the last line of the body, e.g. _This PR was written by Claude Code._ or _PR description drafted with Claude Code._. Be honest about the level of involvement — "written by" vs. "drafted with" vs. "reviewed by" — and keep it to a single italicized line so it doesn't crowd the template sections.
Add a changelog fragment under .nextchanges/ when your change is user-visible. Each PR adds its own file, so entries never conflict between PRs. The release renders these fragments into the real CHANGELOG.md, so never hand-edit CHANGELOG.md directly.
When to add an entry:
Dependency updates)When to skip:
experimental/): no entry until the feature graduates out of experimentalHow to add:
.nextchanges/<section>/<name>.md, picking the section folder that fits: cli, bundles, dependency-updates, notable-changes, or api-changes. <name> is arbitrary (a feature name or your PR number) — just keep it unique.* is optional. Match the voice and tense of existing changelog entries.(#NNNN) (with NNNN being the PR number) in the text and it's expanded to a full link automatically..nextchanges/README.md for details.