一键在 Manus 中运行任何 Skill

writing-pull-requests

星标0

分支0

更新时间2026年6月25日 23:22

Draft a pull-request title and description that summarize the commits on a branch relative to its base branch. Use when the user is opening a pull request, asks for a PR description or title, or wants a branch summarized for reviewers.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

smithdak

smithdak/objectcore

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Writing Pull Requests

Turn a branch's worth of commits into a reviewer-ready PR title and description. A commit message explains one change; a PR explains the whole change and what a reviewer should look at.

Steps

Establish the range. Find the base (usually main) and diff the branch against it: git log --oneline $(git merge-base HEAD main)..HEAD for the commits and git diff $(git merge-base HEAD main)...HEAD --stat for the shape. Identify the single theme of the branch.
Write the title — one line, like a Conventional Commits subject for the whole branch: type(scope): summary, imperative mood, ≤ ~72 chars, no trailing period. On a squash-merge repo this becomes the commit that lands on main, so make it self-contained.
Write the description with these sections (drop any that are empty):
- What & why — the problem and the chosen approach, in 1–3 sentences. Lead with motivation; reviewers need why before how.
- Changes — a short bulleted list of the meaningful changes, grouped by area. Summarize intent; do not paste the commit log verbatim.
- Testing — how it was verified (commands run, cases covered, manual steps). If untested, say so.
- Notes / risks — migrations, rollout/flag steps, breaking changes, and anything intentionally left out of scope.
Link issues with closing keywords so the PR auto-closes them on merge: Closes #123, Fixes #123, or Refs #123 for a non-closing reference.
Point reviewers at the hotspots — name the files or decisions that need the most scrutiny, and call out anything you're unsure about.

Rules

Summarize the branch's intent; don't narrate each commit.
Keep the title independent of the body — it must stand alone in git log after a squash-merge.
Mark breaking changes explicitly and describe the migration path.
If the branch mixes unrelated work, say so and suggest splitting it into separate PRs.
Match the repo's PR template if one exists (.github/pull_request_template.md); these sections are the fallback.

Example

feat(auth): add refresh-token rotation

## What & why
Long-lived refresh tokens are a replay risk if leaked. Rotate the refresh
token on every use and revoke the prior one, closing the replay window.

## Changes
- Issue a new refresh token on each `/token` exchange; revoke the old one
- Add a `token_family` column to detect and block reuse of a revoked token
- Backfill existing sessions in a migration

## Testing
- `bun test packages/auth` — new rotation + reuse-detection cases
- Manual: logged in, refreshed twice, confirmed the first token 401s

## Notes
- Requires the `2026_06_auth_rotation` migration before deploy.

Closes #214

同仓库更多 Skills

同仓库

choosing-a-seeded-theme

smithdak/objectcore

Pick a READY-MADE seeded design theme instead of authoring one — the curated preset inventory (inkwell = quiet, editorial, warm paper; cathode = loud, technical, emissive) and when a preset beats a custom grill. Use when the user wants a quick-start design system, an off-the-shelf look, or asks which seeded preset/theme to pick — NOT for defining custom brand foundations from scratch (that is defining-design-tokens) and NOT for adding modes to existing tokens (that is theming-with-tokens).

2026-07-020

defining-design-tokens

smithdak/objectcore

The grilling gate for AUTHORING a new design system or token set — turn a vague brand into a decided DTCG design-token spec before any scaffolding. Use at the start of /design, when brand direction (color, type, spacing, motion) is still fuzzy, or when deciding the token foundations and tiers. For a ready-made starting point instead of a custom grill, use choosing-a-seeded-theme.

2026-07-020

curating-knowledge

smithdak/objectcore

Add or curate an entry in ObjectCore's factory knowledge base (a lesson, pattern, gotcha, or decision) stored under knowledge/. Use when a durable, reusable engineering lesson emerges, a design decision is made, or the knowledge base needs pruning.

2026-07-020

building-the-catalog

smithdak/objectcore

Reference for how the ObjectCore marketplace catalog is derived — the deriveCatalog seam, the source/sink ports, and the sync invariant. Use when changing how marketplace.json is produced, when marketplace.json is stale, drifted, or out of sync with the plugin dirs, or when reasoning about the Git/DB source swap. (A plugin failing the manifest rules is validating-plugins' territory.)

2026-07-020

validating-plugins

smithdak/objectcore

The reference for what makes an ObjectCore plugin valid — the hard load-error rules (manifest shape, kebab-case, component placement) and the eval-coverage gate. Use when a plugin fails to load or validate, when reviewing a plugin before it enters the catalog, or when diagnosing which hard rule a plugin manifest breaks. (A stale or drifted marketplace.json is building-the-catalog's territory.)

2026-07-020

design-foundations

smithdak/objectcore

The reference for CONSUMING a token-based design system so UI stays on-brand — pick the semantic token by ROLE, never a raw hex or scale step. Use when building, styling, or reviewing a component, page, or any visual output that must match the design system (choosing colors, spacing, type, radius, or motion).

2026-06-270

name	writing-pull-requests
description	Draft a pull-request title and description that summarize the commits on a branch relative to its base branch. Use when the user is opening a pull request, asks for a PR description or title, or wants a branch summarized for reviewers.

Writing Pull Requests

Turn a branch's worth of commits into a reviewer-ready PR title and description. A commit message explains one change; a PR explains the whole change and what a reviewer should look at.

Steps

Establish the range. Find the base (usually main) and diff the branch against it: git log --oneline $(git merge-base HEAD main)..HEAD for the commits and git diff $(git merge-base HEAD main)...HEAD --stat for the shape. Identify the single theme of the branch.
Write the title — one line, like a Conventional Commits subject for the whole branch: type(scope): summary, imperative mood, ≤ ~72 chars, no trailing period. On a squash-merge repo this becomes the commit that lands on main, so make it self-contained.
Write the description with these sections (drop any that are empty):
- What & why — the problem and the chosen approach, in 1–3 sentences. Lead with motivation; reviewers need why before how.
- Changes — a short bulleted list of the meaningful changes, grouped by area. Summarize intent; do not paste the commit log verbatim.
- Testing — how it was verified (commands run, cases covered, manual steps). If untested, say so.
- Notes / risks — migrations, rollout/flag steps, breaking changes, and anything intentionally left out of scope.
Link issues with closing keywords so the PR auto-closes them on merge: Closes #123, Fixes #123, or Refs #123 for a non-closing reference.
Point reviewers at the hotspots — name the files or decisions that need the most scrutiny, and call out anything you're unsure about.

Rules

Summarize the branch's intent; don't narrate each commit.
Keep the title independent of the body — it must stand alone in git log after a squash-merge.
Mark breaking changes explicitly and describe the migration path.
If the branch mixes unrelated work, say so and suggest splitting it into separate PRs.
Match the repo's PR template if one exists (.github/pull_request_template.md); these sections are the fallback.

Example

feat(auth): add refresh-token rotation

## What & why
Long-lived refresh tokens are a replay risk if leaked. Rotate the refresh
token on every use and revoke the prior one, closing the replay window.

## Changes
- Issue a new refresh token on each `/token` exchange; revoke the old one
- Add a `token_family` column to detect and block reuse of a revoked token
- Backfill existing sessions in a migration

## Testing
- `bun test packages/auth` — new rotation + reuse-detection cases
- Manual: logged in, refreshed twice, confirmed the first token 401s

## Notes
- Requires the `2026_06_auth_rotation` migration before deploy.

Closes #214