blender-pr-summary
Use when asked to refresh the current pull request summary from its actual changes and validation Applies to blender-plugin.
ソース情報
- リポジトリ
- scenario-labs/blender-plugin
- ソースの最終更新活動
- 2026年9月25日 11:59
- 検出された SKILL.md の言語
- 英語
- スター
- 14
- フォーク
- 5
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
ファイルエクスプローラー
2 ファイルSKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- name
- blender-pr-summary
- description
- Use when asked to refresh the current pull request summary from its actual changes and validation Applies to blender-plugin.
- metadata
- {"claude-command":"pr-summary"}
Update the current PR description and, when necessary, its title from the final diff. Read `AGENTS.md` and `commitlint.config.ts` first. If the user asks for a draft, return the proposed text without publishing it.
1. Identify the PR with `gh pr view --json number,url,title,body,baseRefName,headRefName,headRefOid`. Check that the checkout and pushed head match this PR; exclude uncommitted or unpushed work from claims about the PR. If no PR exists, draft the summary and say so.
2. Fetch the PR's actual base and review the complete diff and commits from its merge base to the PR head. Normal PRs target `main`; for an existing stacked PR, use its recorded base without retargeting it. Read the changed files, not just `git diff --stat`, and distinguish this PR's work from its dependencies.
3. Collect validation appropriate to the changes, following `AGENTS.md`. For Python changes, use the project's selected interpreter with `-m pytest`; Blender checks must identify the version and the build tested. Capture each command's real exit status before truncating its output. Reuse current evidence when it covers the final diff. Documentation-only changes do not require the entire Blender suite. Do not run paid Scenario operations merely to populate a test count.
4. Audit issue coverage. Find candidate issues from the PR, branch, commits and relevant issue search, then read each issue's current body, acceptance criteria and scope-changing discussion. Compare them with the final diff, merged dependencies and verified evidence; a branch number, existing keyword or generated changelog is not proof of completion. Add missing relationships: use one `Closes #123` line per fully completed issue (`Closes owner/repo#123` across repositories), and `Refs #123` for partial work with a short statement of what remains. Preserve valid links and correct unsupported closing claims. Do not invent an issue or close an umbrella issue for one completed subtask. If no issue applies, state that in the handoff.
5. Follow `.github/pull_request_template.md`, starting with `## What does this PR change?`. Explain the concrete problem and resulting behavior for users or maintainers; include a before/after example when helpful, or the maintenance benefit for internal work. State any action needed to use or validate the change and material limitations. Keep the detail proportional to the change; a file inventory alone is insufficient. Rewrite this section around the final diff when scope changes. Include validation with commands/results and the audited issue relationships. Mark tasks checked only when actually verified. Include counts only when measured; use stats only when they help the review. For API changes, confirm the SDK-first rule and link the demonstrated SDK gap for any raw API exception. Do not expose private research or credentials in this public repository.
6. Pick a Conventional Commit title from the final diff and the allowed scopes in `commitlint.config.ts`: test-only work is `test`, documentation and agent command Markdown is `docs`, and product changes use the appropriate product type. Follow the 120-character limit and no-em-dash rule. Lint a changed title with the repository configuration.
7. Write the body to a temporary file with real newlines, then publish with `gh pr edit <number> --body-file <file>` and, if needed, `--title <title>`. Pass title and paths as properly quoted arguments. Updating this summary does not commit, push or merge code.
8. Fetch the edited PR to verify its title/body and `closingIssuesReferences`. Compare the base with the repository's default branch: GitHub ignores description closing keywords on other bases, so record intended closures for stacked PRs and recheck after retargeting to the default branch. Do not retarget or manually close issues as part of this command. Preserve audited issue footers in the eventual squash message and verify issue state after a separately authorized merge. Report the URL, closing versus partial references, and outstanding validation; investigate missing closing links on default-branch PRs rather than claiming automatic closure is configured.
GitHubで見る