$ loading_
在设计完成后，为缺乏上下文的工程师生成可执行的详细实施计划。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "writing-plans" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/FluidFramework/main/.agency/plugins/nori/skills/writing-plans/SKILL.md 2. 保存为 ~/.claude/skills/writing-plans/SKILL.md 3. 装好后重载技能，告诉我可以用了
我们已经完成“团队成员邀请”功能设计，请基于以下需求为工程师写一份详细实施计划：包含推荐修改的文件路径、前后端任务拆解、关键数据结构、接口定义、完整代码示例、迁移步骤、测试与验证清单。假设执行者对当前代码库和业务背景几乎不了解。需求如下：……
一份面向陌生代码库执行者的完整实施方案，含步骤、文件位置、示例代码与验收方法。
请把这份产品方案转成工程实施文档，输出应包含：实施目标、依赖前提、按模块划分的开发任务、每步涉及的文件路径、伪代码或真实代码示例、异常处理建议、测试用例以及上线前检查项。默认读者是刚加入项目的工程师。产品方案如下：……
结构化的工程落地文档，帮助新人按文档独立完成开发与自测。
我们要重构现有认证模块，请输出详细执行路线：先解释当前目标和边界，再给出分阶段任务、每阶段涉及的文件路径、关键改动示例、风险点、回滚方案、验证步骤和测试策略。假设工程师不了解现有认证实现。背景信息如下：……
一份分阶段、可回滚、可验证的重构计划，降低陌生工程师执行风险。
Create a comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD.
Assume they are a talented developer. However, assume that they know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Do not add code, but include enough detail that the necessary code is obvious.
Do not write a file to disk unless explicitly asked.
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
Every plan MUST have a test section. This should be written first, and should document how you plan to test the .
<required> For each test, follow this checklist: - Ensure that the test does not just test mocks. If it does, remove the test and try again. - Ensure the test does not test implementation detail. If it does, rewrite the test so that it tests boundary behavior. - Ensure the test does not test data structure format or types. If it does, remove the test and try again. - Ensure the test does not test for removed behavior. For example, if some behavior has been deprecated, do not write a test that simply confirms the behavior no longer works. - Evaluate if the test treats the interior of the test boundary as a blackbox. You should not know anything about interior variables, function calls, or control flow. </required>
**Testing Plan**
I will add an integration test that ensures foo behaves like blah. The
integration test will mock A/B/C. The test will then call function/cli/etc.
I will add a unit test that ensures baz behaves like qux...
You should end EVERY testing plan section by writing:
NOTE: I will write *all* tests before I add any implementation behavior.
<system-reminder>Your tests should NOT contain tests for datastructures or types. Your tests should NOT simply test mocks. Always test actual behavior.</system-reminder>
Every plan MUST end with this footer:
**Testing Details** [Brief description of what tests are being added and how they specifically test BEHAVIOR and NOT just implementation]
**Implementation Details** [maximum 10 bullets about key details]
**Question** [any questions or concerns that may be relevant that need answers]
---
帮助你严谨评估代码评审意见，澄清疑点后再决定是否采纳与实现
用持久化 Markdown 规划流程管理复杂任务，持续跟踪目标、进度与决策。