菜单
Branch naming and PR sizing conventions — invoke before creating a branch, opening a PR, or when a diff exceeds 400 lines. Do NOT trigger on read-only questions about current branch/PR state (e.g. "what branch am I on", "link to the PR").
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | branch-strategy |
| description | Branch naming and PR sizing conventions — invoke before creating a branch, opening a PR, or when a diff exceeds 400 lines. Do NOT trigger on read-only questions about current branch/PR state (e.g. "what branch am I on", "link to the PR"). |
Pattern: <type>/<short-description>
| Type | When |
|---|---|
feature/ | New functionality |
fix/ | Bug fix |
chore/ | Maintenance, deps, config |
docs/ | Documentation only |
refactor/ | Restructure, no behavior change |
test/ | Adding or updating tests |
Use kebab-case, keep it short (2-4 words), no nested slashes.
Examples:
feature/add-user-auth
fix/login-redirect
chore/bump-tsup-v8
docs/update-readme
refactor/extract-token-budget
test/artifact-installer-rule
Not:
feature/addUserAuth ← camelCase
fix/fix-the-login-bug ← redundant "fix" in description
feature/auth/oauth/flow ← nested slashes
my-branch ← missing type prefix
Target < 400 lines changed per PR. Small PRs get reviewed faster, catch bugs earlier, and are easier to revert.
When a diff exceeds 400 lines, suggest splitting:
Exceptions that don't need splitting: generated files, migrations, large atomic refactors where partial application would break the build.
main / master — never commit directly, always use a PRRepository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
End-to-end release workflow for repositories using Conventional Commits. Use when preparing a new version, tagging a release, generating changelog/release notes, bumping version, or when the user asks "release", "new version", "bump version", "publish release", "chuẩn bị release", or "tạo tag release".
Repository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
Repository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
Guide for using Brave Search MCP tools (`brave_web_search`, `brave_news_search`, `brave_image_search`, `brave_video_search`, `brave_local_search`, `brave_summarizer`). Invoke when the user asks to search the web, news, images, videos, or local results AND Brave Search MCP is available. Do NOT trigger for generic lookups when other search tools (Tavily, built-in WebSearch) are more appropriate. Requires `BRAVE_API_KEY`.
Terminal-driven browser automation via the Playwright CLI — invoke when the agent needs to open a page, interact with a form, click through a flow, or verify UI state. Use this (not the test framework, not screenshot-only scraping) for live browser work. Triggers on "open the browser", "click through", "fill the form", "reproduce the UI bug", "check what the page shows".