![[Work Item] - Plan](http://pic.xiahunao.cn/yaotu/[Work Item] - Plan)
[Work Item] - Plan【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilotGoal[One observable outcome.]- 标题采用 [工作项] - Plan 的命名便于在会话、文件系统与 issue 中快速检索。 - Goal 要求**一个可观察的结果**One observable outcome而不是一串待办。这是整份计划的对齐锚点验收标准Acceptance Criteria本质上就是 Goal 的可验证展开。 ### 2. Context上下文 markdown ## Context - Relevant issue/request: [link or summary] - Repository instructions: [links] - Important constraints: [list]上下文承担跨会话恢复功能链接相关 issue/请求、仓库指令如 AGENTS.md、CONTRIBUTING.md并列出重要约束。这与技能主文档Context Recovery章节的冷启动提示一脉相承——新会话或 Agent只靠计划本身就能接续工作不必重新发掘背景。3. In Scope 与 Out of Scope范围内/范围外## In Scope - [deliverable] ## Out of Scope - [explicit exclusion]明确写出明确排除项explicit exclusion是模板的高明之处它直接对抗范围蔓延scope creep。Producer 的职责描述里就包含Define the outcome, constraints, acceptance criteria, and explicit exclusionsanti-patterns.md 也警告Treating every automated suggestion as a requirement是反模式。Out of Scope 越明确评审阶段越不容易被无关建议带偏。4. Tasks任务清单## Tasks 1. [task] 2. [task] 3. [task]保持简洁的顺序清单。Dev Agentai-team-dev会据此拆解成文件级改动任务粒度建议到可独立验证为止不必过度细化。5. Acceptance Criteria验收标准## Acceptance Criteria - [ ] [observable behavior] - [ ] Relevant repository checks pass (example: npm run lint, npm test) - [ ] Tests covering the change are added or validated - [ ] Documentation/context is updated when behavior or operation changed四类检查项覆盖了功能正确 工程健康 文档同步三个维度且每一项都是可勾选的行为描述首个 checkbox 要求可观察行为对应 Goal仓库检查以可执行命令示例给出npm run lint、npm test强调必须真的能跑通测试要求新增或验证行为或运维变化时更新文档/上下文——这正是本仓库持续维护 docs 与各类模板的实践依据。6. Verification验证## Verification - Automated: [commands or checks] - Example: npm ci npm run test or pytest -q - Example: npm run lint npm run build - Manual: [focused scenarios, if useful] - Independent review: required / optional / not needed - [reason] - QA: required / optional / not needed - [reason]验证是自动化 手动 独立评审 QA的四层组合且每个决策都必须附带理由Automated 给出真实可复制的命令示例npm ci npm run test、npm run lint npm run build需要按目标仓库的实际测试栈替换本仓库自身的验证脚本可参考 eng/validate-plugins.mjs、eng/validate-skills.mjs 等Independent review 与 QA 用 required / optional / not needed 三档配合后面的 QA risk matrix 决定每条决策后要求写 [reason]避免为了仪式而仪式。7. PR ChecklistPR 清单## PR Checklist (add to PR body) - Branch name follows repo policy (e.g., feat/, fix/, or chore/) - Description: short summary, why, and acceptance criteria - Verification steps included (commands manual checks) - Tests added or existing tests updated - Relevant docs/PROJECT_BRIEF updated if behavior changed - Reviewers: team or specific owners - Required checks: list CI jobs that must pass - Release notes / changelog entry: yes/no这段文字明确写着 add to PR body——即由 Dev 在开 PR 时把清单粘贴进 PR 描述。它把计划与提交流程打通分支命名、描述、验证步骤、测试、文档更新、评审人、CI 任务、变更日志一应俱全。分支策略强调遵循仓库策略例如本仓库的 PR 与贡献规范见 CONTRIBUTING.md而不是硬编码一套 Git 命令。8. Risks and Decisions风险与决策## Risks and Decisions - [risk or material decision]用于记录实质风险或需要留痕的决策。结合 anti-patterns.md 的决策日志指引重大决策还应同步进入 DECISIONS.md 或 issue 跟踪器含标题、日期、owner、一行摘要、理由、PR/issue 链接保证决策不只在聊天里。9. QA risk matrix何时需要 QA## QA risk matrix (when to require QA) - High impact × High uncertainty QA required - High impact × Low uncertainty QA recommended - Low impact × High uncertainty QA recommended - Low impact × Low uncertainty QA optional这是模板中最具工程智慧的二维矩阵影响度 × 不确定性 → QA 档位。它把要不要 QA从主观偏好变成可论证的判断影响度不确定性建议高高QA required高低QA recommended低高QA recommended低低QA optional与 ai-team-producer.agent.md 的风险评审原则互相印证安全、隐私、破坏性数据、部署、权限等高影响变更应获得与风险相称的独立评审与 QA低风险文档改动可能只需要聚焦检查。模板还有一条补充规则A valid blocker remains a blocker until fixed or explicitly accepted by the authorized maintainer有效的阻塞项在被修复或维护者明确接受前始终是阻塞项。10. Next Action下一步行动## Next Action [owner and immediate next step]计划以明确的 owner 立即要做的下一步收尾这与 ai-team-producer.agent.md 的工作风格一致always identify the next owner and action。冷启动时新会话直接读取 Next Action 即可继续推进无需重新判断。三、配套文档Progress Note 与 Dev Handoff计划不是一次性产物模板在计划块之外还提供了两个配套块共同构成计划-进度-交接三件套。Progress Note进度记录# [Work Item] - Progress - Completed: [items] - In progress: [item] - Blocked: [issue or none] - Decisions: [material decisions] - Verification so far: [results] - Next action: [specific action]模板注明For long-running work, keep a short progress note——长周期工作必须维护一份简短进度记录。六行结构覆盖了完成项、进行中、阻塞、决策、已验证结果、下一步正是技能主文档Context Recovery要求的两件事的落地工具更新活动计划/进度记录并把决策、阻塞与下一步写入仓库上下文。Dev Handoff交接说明Read the repository instructions, PROJECT_BRIEF.md when present, and this plan. Implement the in-scope work, run the listed verification, update durable context when needed, and prepare a pull request. Do not merge.【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考