菜单
How to open a narrow, honest draft PR when the branch context is wider than the landed slice
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve knowledge gaps: fetch unresolved gaps, assess sensitivity, generate research queries, ingest findings, and close gaps with a resolution slug.
Interrupt-driven alerts: detect and surface new contradictions, stale pages, resolved gaps, and embedding drift. Priority-classified with deduplication.
Ingest meeting notes, articles, documents, and conversations into Quaid. Handles idempotent ingestion for exact-byte duplicates and vault-backed sync.
Keep the brain healthy: detect and resolve contradictions via the correction / supersede workflow, validate referential integrity, triage knowledge gaps, find orphaned pages, and compact the database.
Answer questions from the brain using FTS5 + semantic search + structured queries. Synthesize across multiple pages. Cite sources.
Agent-guided binary upgrades: version check, channel detection, download via install.sh (or manual asset fetch + SHA-256 verify), and post-upgrade validation.
| name | truthful-draft-pr-scope |
| description | How to open a narrow, honest draft PR when the branch context is wider than the landed slice |
| domain | devrel, pull-requests, scope-truth |
| confidence | high |
| source | earned |
Use this when a branch needs an early draft PR, but the branch ancestry or compare view is broader than the implementation slice that is actually finished and pushed. Typical cases: stacked work on top of a docs/spec branch, inherited planning artifacts, or a large change where only the first foundation slice is landed.
Do not open the draft PR off local-only work and do not describe scope you have not pushed yet.
Read the actual changed code/tests plus the current proposal/tasks. Separate:
If the proposal is broader than the landed slice, the PR body must follow the landed slice.
If the compare view includes inherited roadmap/spec/docs churn from earlier branch ancestry, say so directly in the PR notes. This prevents reviewers from assuming every file in the compare is part of the current shipped claim.
List the unfinished capabilities that this draft does not land yet. Use the concrete user-facing names reviewers would otherwise assume, such as MCP tool names, worker behavior, retrieval flags, or release readiness.
Only promote the PR out of draft after the wider implementation is actually landed, pushed, and the body can be rewritten without caveats.
