Spec Document Reviewer Prompt Template【免費(fèi)下載鏈接】superpowersAn agentic skills framework software development methodology that works.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/su/superpowersUse this template when dispatching a spec document reviewer subagent.Purpose:Verify the spec is complete, consistent, and ready for implementation planning.Dispatch after:Spec document is written to docs/superpowers/specs/它要解決的是一個(gè)典型的 Agent 工作流缺陷**寫文檔的 Agent 對自己剛寫完的文檔缺乏懷疑**。LLM 在生成 spec 時(shí)傾向于順著自己剛寫的假設(shè)繼續(xù)推進(jìn)占位符TBD/TODO、前后矛盾、含糊到可以有兩種解讀的需求都會(huì)直接帶進(jìn)下游的 implementation plan。Superpowers 的做法是用一個(gè)**上下文全新的子代理**來審查 spec——它不共享作者的會(huì)話歷史只拿到 spec 文件路徑以陌生審查者視角給出裁決。 這與倉庫中其他 reviewer 模板是同構(gòu)的[plan-document-reviewer-prompt.md](https://link.gitcode.com/i/60d5cc71a8a2249bf98b91be5b1f7367) 審查計(jì)劃文檔[code-reviewer.md](https://link.gitcode.com/i/82c27b5457e2f1b53d2ae7559f00745d) 審查代碼 diff。三者共同的模式是精確裁剪的上下文 獨(dú)立子代理 結(jié)構(gòu)化裁決返回只有 Status / Issues / Recommendations 回到主控 Agent 的上下文里避免審查過程燒掉主會(huì)話的上下文窗口。 ## 完整提示詞模板與逐段解析 模板中真正會(huì)被填充并發(fā)給子代理的是下面這段 prompt[SPEC_FILE_PATH] 為占位符派發(fā)時(shí)替換為 spec 文檔的實(shí)際路徑 text Subagent (general-purpose): description: Review spec document prompt: | You are a spec document reviewer. Verify this spec is complete and ready for planning. **Spec to review:** [SPEC_FILE_PATH] ## What to Check | Category | What to Look For | |----------|------------------| | Completeness | TODOs, placeholders, TBD, incomplete sections | | Consistency | Internal contradictions, conflicting requirements | | Clarity | Requirements ambiguous enough to cause someone to build the wrong thing | | Scope | Focused enough for a single plan — not covering multiple independent subsystems | | YAGNI | Unrequested features, over-engineering | ## Calibration **Only flag issues that would cause real problems during implementation planning.** A missing section, a contradiction, or a requirement so ambiguous it could be interpreted two different ways — those are issues. Minor wording improvements, stylistic preferences, and sections less detailed than others are not. Approve unless there are serious gaps that would lead to a flawed plan. ## Output Format ## Spec Review **Status:** Approved | Issues Found **Issues (if any):** - [Section X]: [specific issue] - [why it matters for planning] **Recommendations (advisory, do not block approval):** - [suggestions for improvement]下面逐段展開。子代理類型與派發(fā)參數(shù)Subagent (general-purpose)以通用型子代理派發(fā)。設(shè)計(jì)規(guī)格文檔 2026-01-22-document-review-system-design.md 中寫明了派發(fā)機(jī)制——Use the Task tool withsubagent_type: general-purpose. The reviewer prompt template provides the full prompt. The brainstorming skills controller dispatches the reviewer.即由 brainstorming 技能的主控controller在 spec 寫完后負(fù)責(zé)派發(fā)。description: Review spec document用于在會(huì)話中展示這次派發(fā)在做什么對操作者透明。唯一的輸入是[SPEC_FILE_PATH]審查者只拿到文件路徑不拿會(huì)話歷史、不拿作者意圖說明。這與 requesting-code-review/SKILL.md 中Hand it precisely crafted context, never your sessions history的原則一致——審查者應(yīng)該只盯著工作產(chǎn)物本身。檢查維度五個(gè)類別各抓什么類別檢查內(nèi)容為什么重要Completeness完整性TODO、占位符、TBD、未寫完的章節(jié)帶占位符的 spec 會(huì)讓下游計(jì)劃憑空腦補(bǔ)缺失部分Consistency一致性內(nèi)部矛盾、互相沖突的需求矛盾需求會(huì)導(dǎo)致計(jì)劃里出現(xiàn)兩條互斥的實(shí)現(xiàn)路徑Clarity清晰度含糊到足以讓人做錯(cuò)東西的需求注意門檻只有當(dāng)歧義可能導(dǎo)向兩種不同的實(shí)現(xiàn)時(shí)才算問題Scope范圍是否聚焦到單一 plan 能承接而不是覆蓋多個(gè)相互獨(dú)立的子系統(tǒng)與 brainstorming 技能的分解要求呼應(yīng)見下文工作流一節(jié)YAGNI防過度設(shè)計(jì)用戶沒要求的功能、過度工程防止 spec 膨脹出順便做一下的功能這里的 Scope 維度值得注意它不是籠統(tǒng)的范圍太大而是精確到是否可以由一份plan 實(shí)現(xiàn)。這與 brainstorming/SKILL.md 中的范圍評(píng)估要求形成上下游配合——brainstorming 在提問前就要判斷如果需求描述了多個(gè)獨(dú)立子系統(tǒng)例如一個(gè)帶聊天、文件存儲(chǔ)、計(jì)費(fèi)、分析的平臺(tái)立即標(biāo)記它幫助用戶分解成子項(xiàng)目每個(gè)子項(xiàng)目各走一遍 spec → plan → implementation 循環(huán)。審查者的 Scope 檢查就是這條規(guī)則的下游兜底。校準(zhǔn)準(zhǔn)則Calibration防止審查者變成吹毛求疵的編輯模板中最有設(shè)計(jì)含量的部分是## CalibrationOnly flag issues that would cause real problems during implementation planning.A missing section, a contradiction, or a requirement so ambiguous it could be interpreted two different ways — those are issues. Minor wording improvements, stylistic preferences, and sections less detailed than others are not.Approve unless there are serious gaps that would lead to a flawed plan.它做兩件事劃定問題的下限只有會(huì)導(dǎo)致實(shí)施規(guī)劃出真實(shí)問題的缺陷才算 Issue——缺失章節(jié)、內(nèi)部矛盾、存在兩種解讀的需求。措辭潤色、風(fēng)格偏好、某章節(jié)比其他章節(jié)寫得細(xì)一點(diǎn)都不算。設(shè)定通過的默認(rèn)方向默認(rèn)是通過Approve除非存在會(huì)導(dǎo)致 plan 出錯(cuò)的嚴(yán)重缺口。這明確了對抗性審查與顧問式審查的邊界審查者的輸出里只有 Issues 具有阻斷力。這一點(diǎn)也解釋了模板把輸出拆成Issues可阻斷與Recommendations僅建議不阻斷通過兩層的用意——建議類意見即使寫了也不影響 Status 判定從而避免審查者提了 10 條風(fēng)格建議導(dǎo)致循環(huán)無法收斂的死循環(huán)。輸出契約三個(gè)字段的結(jié)構(gòu)化裁決## Spec Review **Status:** Approved | Issues Found **Issues (if any):** - [Section X]: [specific issue] - [why it matters for planning] **Recommendations (advisory, do not block approval):** - [suggestions for improvement]模板末尾用一行總結(jié)了子代理的返回契約**Reviewer returns:** Status, Issues (if any), Recommendations注意 Issues 條目的格式要求[Section X]: [具體問題] - [為什么它對規(guī)劃重要]。每個(gè) Issue 必須定位到章節(jié)、給出具象描述并說明對規(guī)劃的實(shí)際影響——這既便于作者定點(diǎn)修復(fù)也便于后續(xù)對修復(fù)是否有效做再審查。設(shè)計(jì)規(guī)格文檔 2026-01-22-document-review-system-design.md 還規(guī)定了主控側(cè)的容錯(cuò)控制器應(yīng)校驗(yàn)審查輸出包含必需字段Status 及有 Issue 時(shí)的 Issues若輸出格式畸形malformed帶格式說明重新派發(fā)連續(xù)兩次畸形后上報(bào)給人。模板在 Superpowers 工作流中的位置spec-document-reviewer-prompt.md 聲明的派發(fā)時(shí)機(jī)是 Spec document is written todocs/superpowers/specs/。把這個(gè)時(shí)間點(diǎn)放進(jìn) brainstorming 技能的完整檢查清單見 brainstorming/SKILL.md整條流水線是探索項(xiàng)目上下文按需即時(shí)提供 visual companion逐個(gè)提出澄清問題提出 2–3 個(gè)方案及權(quán)衡分節(jié)呈現(xiàn)設(shè)計(jì)并逐節(jié)獲得用戶批準(zhǔn)將設(shè)計(jì)文檔寫入docs/superpowers/specs/YYYY-MM-DD-topic-design.md并提交 gitSpec 自審——作者自己用新鮮眼睛做占位符掃描、內(nèi)部一致性、范圍、歧義四項(xiàng)檢查問題直接就地修復(fù)用戶審閱 spec 文件進(jìn)入 writing-plans 技能也就是說在 spec 從作者自審過渡到用戶審閱和下游規(guī)劃之前spec reviewer 子代理充當(dāng)獨(dú)立第三方校驗(yàn)層第 7 步的作者自審解決的是作者知道但懶得檢查而 spec reviewer 子代理解決的是作者自己看不出來的盲點(diǎn)——因?yàn)樗粩y帶寫作時(shí)的上下文偏見。brainstorming 技能還設(shè)了一道硬閘門HARD-GATE在呈現(xiàn)設(shè)計(jì)并獲得用戶批準(zhǔn)之前不得調(diào)用任何實(shí)現(xiàn)類技能、不得寫任何代碼。spec reviewer 與這道閘門共同保證了未經(jīng)審查的 spec 不會(huì)進(jìn)入實(shí)施。工作流全景可以概括為設(shè)計(jì)文檔中的公式brainstorming - spec - SPEC REVIEW LOOP - writing-plans - plan - PLAN REVIEW LOOP - implementation【免費(fèi)下載鏈接】superpowersAn agentic skills framework software development methodology that works.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/su/superpowers創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Spec Document Reviewer Prompt Template
Spec Document Reviewer Prompt Template【免費(fèi)下載鏈接】superpowersAn agentic skills framework software development methodology that works.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/su/superpowersUse this template when dispatching a spec document reviewer subagent.Purpose:Verify the spec is complete, consistent, and ready for implementation planning.Dispatch after:Spec document is written to docs/superpowers/specs/它要解決的是一個(gè)典型的 Agent 工作流缺陷**寫文檔的 Agent 對自己剛寫完的文檔缺乏懷疑**。LLM 在生成 spec 時(shí)傾向于順著自己剛寫的假設(shè)繼續(xù)推進(jìn)占位符TBD/TODO、前后矛盾、含糊到可以有兩種解讀的需求都會(huì)直接帶進(jìn)下游的 implementation plan。Superpowers 的做法是用一個(gè)**上下文全新的子代理**來審查 spec——它不共享作者的會(huì)話歷史只拿到 spec 文件路徑以陌生審查者視角給出裁決。 這與倉庫中其他 reviewer 模板是同構(gòu)的[plan-document-reviewer-prompt.md](https://link.gitcode.com/i/60d5cc71a8a2249bf98b91be5b1f7367) 審查計(jì)劃文檔[code-reviewer.md](https://link.gitcode.com/i/82c27b5457e2f1b53d2ae7559f00745d) 審查代碼 diff。三者共同的模式是精確裁剪的上下文 獨(dú)立子代理 結(jié)構(gòu)化裁決返回只有 Status / Issues / Recommendations 回到主控 Agent 的上下文里避免審查過程燒掉主會(huì)話的上下文窗口。 ## 完整提示詞模板與逐段解析 模板中真正會(huì)被填充并發(fā)給子代理的是下面這段 prompt[SPEC_FILE_PATH] 為占位符派發(fā)時(shí)替換為 spec 文檔的實(shí)際路徑 text Subagent (general-purpose): description: Review spec document prompt: | You are a spec document reviewer. Verify this spec is complete and ready for planning. **Spec to review:** [SPEC_FILE_PATH] ## What to Check | Category | What to Look For | |----------|------------------| | Completeness | TODOs, placeholders, TBD, incomplete sections | | Consistency | Internal contradictions, conflicting requirements | | Clarity | Requirements ambiguous enough to cause someone to build the wrong thing | | Scope | Focused enough for a single plan — not covering multiple independent subsystems | | YAGNI | Unrequested features, over-engineering | ## Calibration **Only flag issues that would cause real problems during implementation planning.** A missing section, a contradiction, or a requirement so ambiguous it could be interpreted two different ways — those are issues. Minor wording improvements, stylistic preferences, and sections less detailed than others are not. Approve unless there are serious gaps that would lead to a flawed plan. ## Output Format ## Spec Review **Status:** Approved | Issues Found **Issues (if any):** - [Section X]: [specific issue] - [why it matters for planning] **Recommendations (advisory, do not block approval):** - [suggestions for improvement]下面逐段展開。子代理類型與派發(fā)參數(shù)Subagent (general-purpose)以通用型子代理派發(fā)。設(shè)計(jì)規(guī)格文檔 2026-01-22-document-review-system-design.md 中寫明了派發(fā)機(jī)制——Use the Task tool withsubagent_type: general-purpose. The reviewer prompt template provides the full prompt. The brainstorming skills controller dispatches the reviewer.即由 brainstorming 技能的主控controller在 spec 寫完后負(fù)責(zé)派發(fā)。description: Review spec document用于在會(huì)話中展示這次派發(fā)在做什么對操作者透明。唯一的輸入是[SPEC_FILE_PATH]審查者只拿到文件路徑不拿會(huì)話歷史、不拿作者意圖說明。這與 requesting-code-review/SKILL.md 中Hand it precisely crafted context, never your sessions history的原則一致——審查者應(yīng)該只盯著工作產(chǎn)物本身。檢查維度五個(gè)類別各抓什么類別檢查內(nèi)容為什么重要Completeness完整性TODO、占位符、TBD、未寫完的章節(jié)帶占位符的 spec 會(huì)讓下游計(jì)劃憑空腦補(bǔ)缺失部分Consistency一致性內(nèi)部矛盾、互相沖突的需求矛盾需求會(huì)導(dǎo)致計(jì)劃里出現(xiàn)兩條互斥的實(shí)現(xiàn)路徑Clarity清晰度含糊到足以讓人做錯(cuò)東西的需求注意門檻只有當(dāng)歧義可能導(dǎo)向兩種不同的實(shí)現(xiàn)時(shí)才算問題Scope范圍是否聚焦到單一 plan 能承接而不是覆蓋多個(gè)相互獨(dú)立的子系統(tǒng)與 brainstorming 技能的分解要求呼應(yīng)見下文工作流一節(jié)YAGNI防過度設(shè)計(jì)用戶沒要求的功能、過度工程防止 spec 膨脹出順便做一下的功能這里的 Scope 維度值得注意它不是籠統(tǒng)的范圍太大而是精確到是否可以由一份plan 實(shí)現(xiàn)。這與 brainstorming/SKILL.md 中的范圍評(píng)估要求形成上下游配合——brainstorming 在提問前就要判斷如果需求描述了多個(gè)獨(dú)立子系統(tǒng)例如一個(gè)帶聊天、文件存儲(chǔ)、計(jì)費(fèi)、分析的平臺(tái)立即標(biāo)記它幫助用戶分解成子項(xiàng)目每個(gè)子項(xiàng)目各走一遍 spec → plan → implementation 循環(huán)。審查者的 Scope 檢查就是這條規(guī)則的下游兜底。校準(zhǔn)準(zhǔn)則Calibration防止審查者變成吹毛求疵的編輯模板中最有設(shè)計(jì)含量的部分是## CalibrationOnly flag issues that would cause real problems during implementation planning.A missing section, a contradiction, or a requirement so ambiguous it could be interpreted two different ways — those are issues. Minor wording improvements, stylistic preferences, and sections less detailed than others are not.Approve unless there are serious gaps that would lead to a flawed plan.它做兩件事劃定問題的下限只有會(huì)導(dǎo)致實(shí)施規(guī)劃出真實(shí)問題的缺陷才算 Issue——缺失章節(jié)、內(nèi)部矛盾、存在兩種解讀的需求。措辭潤色、風(fēng)格偏好、某章節(jié)比其他章節(jié)寫得細(xì)一點(diǎn)都不算。設(shè)定通過的默認(rèn)方向默認(rèn)是通過Approve除非存在會(huì)導(dǎo)致 plan 出錯(cuò)的嚴(yán)重缺口。這明確了對抗性審查與顧問式審查的邊界審查者的輸出里只有 Issues 具有阻斷力。這一點(diǎn)也解釋了模板把輸出拆成Issues可阻斷與Recommendations僅建議不阻斷通過兩層的用意——建議類意見即使寫了也不影響 Status 判定從而避免審查者提了 10 條風(fēng)格建議導(dǎo)致循環(huán)無法收斂的死循環(huán)。輸出契約三個(gè)字段的結(jié)構(gòu)化裁決## Spec Review **Status:** Approved | Issues Found **Issues (if any):** - [Section X]: [specific issue] - [why it matters for planning] **Recommendations (advisory, do not block approval):** - [suggestions for improvement]模板末尾用一行總結(jié)了子代理的返回契約**Reviewer returns:** Status, Issues (if any), Recommendations注意 Issues 條目的格式要求[Section X]: [具體問題] - [為什么它對規(guī)劃重要]。每個(gè) Issue 必須定位到章節(jié)、給出具象描述并說明對規(guī)劃的實(shí)際影響——這既便于作者定點(diǎn)修復(fù)也便于后續(xù)對修復(fù)是否有效做再審查。設(shè)計(jì)規(guī)格文檔 2026-01-22-document-review-system-design.md 還規(guī)定了主控側(cè)的容錯(cuò)控制器應(yīng)校驗(yàn)審查輸出包含必需字段Status 及有 Issue 時(shí)的 Issues若輸出格式畸形malformed帶格式說明重新派發(fā)連續(xù)兩次畸形后上報(bào)給人。模板在 Superpowers 工作流中的位置spec-document-reviewer-prompt.md 聲明的派發(fā)時(shí)機(jī)是 Spec document is written todocs/superpowers/specs/。把這個(gè)時(shí)間點(diǎn)放進(jìn) brainstorming 技能的完整檢查清單見 brainstorming/SKILL.md整條流水線是探索項(xiàng)目上下文按需即時(shí)提供 visual companion逐個(gè)提出澄清問題提出 2–3 個(gè)方案及權(quán)衡分節(jié)呈現(xiàn)設(shè)計(jì)并逐節(jié)獲得用戶批準(zhǔn)將設(shè)計(jì)文檔寫入docs/superpowers/specs/YYYY-MM-DD-topic-design.md并提交 gitSpec 自審——作者自己用新鮮眼睛做占位符掃描、內(nèi)部一致性、范圍、歧義四項(xiàng)檢查問題直接就地修復(fù)用戶審閱 spec 文件進(jìn)入 writing-plans 技能也就是說在 spec 從作者自審過渡到用戶審閱和下游規(guī)劃之前spec reviewer 子代理充當(dāng)獨(dú)立第三方校驗(yàn)層第 7 步的作者自審解決的是作者知道但懶得檢查而 spec reviewer 子代理解決的是作者自己看不出來的盲點(diǎn)——因?yàn)樗粩y帶寫作時(shí)的上下文偏見。brainstorming 技能還設(shè)了一道硬閘門HARD-GATE在呈現(xiàn)設(shè)計(jì)并獲得用戶批準(zhǔn)之前不得調(diào)用任何實(shí)現(xiàn)類技能、不得寫任何代碼。spec reviewer 與這道閘門共同保證了未經(jīng)審查的 spec 不會(huì)進(jìn)入實(shí)施。工作流全景可以概括為設(shè)計(jì)文檔中的公式brainstorming - spec - SPEC REVIEW LOOP - writing-plans - plan - PLAN REVIEW LOOP - implementation【免費(fèi)下載鏈接】superpowersAn agentic skills framework software development methodology that works.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/su/superpowers創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考