菜单
用中文生成或评审工作场景的 commit message 与 PR 描述。适用于用户请求根据最终 diff、 staged changes、working tree changes 或指定 commit 生成 `M-xxx(type): title` commit， 以及中文合同式 PR 四块结构。只以最终变更集为事实边界，忽略聊天过程、失败尝试、 被否决方案和临时调试。不要用于公开开源英文 PR、普通代码 review、实现任务或泛泛解释 commit 概念。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Explicit-only, provider-agnostic controller for bounded convergence of an existing technical plan, architecture proposal, migration plan, ADR draft, or implementation proposal. Use when the user explicitly asks for 方案收敛, plan convergence, 方案棘轮, or a controlled review-revision loop, or when an already user-authorized parent workflow explicitly delegates that convergence step with artifact, scope, provider bindings, budget, and modification authority. It decides whether to obtain review, revise locally, gather evidence, request a decision, explore alternatives, pivot, finalize, or stop. Do not use for first-draft planning, standalone review, generic brainstorming, code repair, implementation, or open-ended autonomous loops.
Use when the user needs to summarize, classify, deduplicate, and triage business feedback from a bounded Feishu/Lark group chat window using a specified domain knowledge pack. It turns chat messages into evidence-backed feedback cases, separates usage questions, misuse/config issues, suspected bugs, confirmed bugs, feature requests, product gaps, documentation gaps, resolved and unresolved items, and produces a digest plus memory-update candidates. Default to read-only. Do not create Feishu Project items, reply to chats, or update accepted memory unless explicitly approved.
Use when the user needs to read, search, summarize, analyze, or safely write Feishu/Lark IM messages, group chats, direct messages, threads, reactions, message resources, or bounded realtime IM events in a development workflow. Default to read-only evidence collection; require explicit confirmation for sending messages, replying, pinning, urgent notifications, member/chat changes, or cross-system writes. Do not use for Feishu Project/Meegle work-item operations, domain-backed business feedback triage, or Feishu document editing unless this skill is only gathering chat evidence for another Feishu workflow.
High-signal code change review workflow for PRs, patches, staged/index changes, working-tree diffs, commit ranges, and file-scoped review. Use when the user asks to review concrete code changes for functional/user-impact risks, data model correctness, state ownership, compatibility, or maintainability. Handles partial staged hunks and user-selected files/commits by selecting the exact review target before reading the diff. Do not use for implementation-only requests, generic code explanation, release publishing, issue triage, or plan-only Linus-style strict-pragmatic critique; for strict critique of a concrete diff, use this skill only to establish the target before dbx-linus-review.
Strict pragmatic, evidence-driven technical review for code changes, architecture plans, data models, and implementation proposals. Use when the user explicitly requests Linus-style review, harsh/strict review, pragmatic critique, over-engineering judgment, merge/readiness judgment, or asks whether a technical plan or code change is good enough. Shares judgment principles with dbx-diff-review but uses a stricter artifact-agnostic critique loop. Do not use for ordinary code explanation, implementation-only requests, generic encouragement, interpersonal judgment, or normal diff review unless strict/pragmatic critique is explicitly requested.
Use when the user asks to coordinate a development workflow across Feishu Project/Meegle work items, Feishu documents, and optional Feishu/Lark IM evidence, such as reading a ticket, updating a technical plan, syncing implementation progress, writing release notes, or commenting back with validation evidence. This is an orchestration skill; delegate project operations to dbx-feishu-project, document operations to dbx-feishu-doc, and chat evidence to dbx-feishu-im. Do not use for single-domain Feishu operations or generic planning without external Feishu read/write.
| name | dbx-work-commit-pr |
| description | 用中文生成或评审工作场景的 commit message 与 PR 描述。适用于用户请求根据最终 diff、 staged changes、working tree changes 或指定 commit 生成 `M-xxx(type): title` commit， 以及中文合同式 PR 四块结构。只以最终变更集为事实边界，忽略聊天过程、失败尝试、 被否决方案和临时调试。不要用于公开开源英文 PR、普通代码 review、实现任务或泛泛解释 commit 概念。 |
生成中文工作场景的 commit message 与 PR 描述。
核心分工：
不要把聊天记录写成工程事实。最终变更集才是事实边界。
使用本 skill：
M-xxx(type): title 格式；不要使用本 skill：
dbx-open-source-commit-pr；按这个优先级收集事实：
默认排除：
除非用户明确要求，并且这些内容确实属于最终公开记录的一部分。
优先从最终变更获取信息。缺失时只问会影响输出正确性的最少问题：
M-xxx；未知时可保留 M-xxx，不要臆造；feat|fix|inf|chore|test|docs；不确定时基于 diff 推断或询问；不要为了追求模板完整而盘问一长串问题。
scripts/check_commit_pr_output.py 做质量门检查。格式：
M-xxx(type): {title}
{optional body}
规则：
M-xxx。feat|fix|inf|chore|test|docs 中选。Why/Context: 最终变更或用户明确最终事实能支撑的动机；What: 关键实现或行为变化；Proof: 具体证据或明确未验证；Risk: 长期有效风险与缓解；Notes: 兼容性、迁移、行为差异。Proof 要具体：
Proof:
- 自动：pnpm lint && pnpm test
- 手动：创建订单并确认状态流转为 paid
- 未验证：未跑端到端用例
不要写：
Proof: 已测试
Proof: 测试通过
Proof: 本地测过
使用四块结构：
## 做了什么/为什么
- ...
## 证明它可行
- 自动验证：...
- 手动验证：...
- 未验证：...
## 风险与 AI 参与
- 风险：...
- AI 参与：有/无，作用范围：...
## 评审关注点
- ...
规则：
未验证：...。从最终变更中找这些信号：
只写最重要的，不要把清单机械搬进 PR。
多主题改动时先提示：
这个变更集包含多个主题，建议拆成多个 commit，原因是：...
建议拆分：
- M-xxx(type): ...
- M-xxx(type): ...
如果用户明确要求合并，再生成单个 commit，但要让 PR body 说明主要影响面。
commit only：只输出 commit title + optional body。
PR only：只输出四块 PR 描述。
both：先 commit，再 PR。
review existing text：输出问题列表 + 改写版本，不要重讲全部规则。
scripts/check_commit_pr_output.py 可检查保存后的工作 PR 文案：
python3 scripts/check_commit_pr_output.py --artifact both --file /path/to/output.md
它只检查常见文字质量门，不替代最终 diff 阅读。