plan
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseImplementation Planning Skill
实现规划Skill
Overview
概述
Author the section of the one unified artifact — granular, parallelizable tasks tracing to the requirements in the same document's section. There is no second file: traceability resolves within one doc. Ensures complete coverage through explicit, internal traceability. The artifact shape is owned by — author against it.
## Decompositiondocs/specs/DR-N## Design & Rationalereferences/spec-template.mdFor a complete worked example, see .
references/worked-example.md编写统一工件的(分解)章节——细化的、可并行执行的任务,需追溯至同一文档(设计与原理)部分中的DR-N需求。无需第二个文件:可追溯性在单个文档内解决。通过明确的内部可追溯性确保覆盖完整。工件格式由定义——需据此编写。
docs/specs/## Decomposition## Design & Rationalereferences/spec-template.md完整示例请参阅。
references/worked-example.mdTriggers
触发条件
Activate this skill when:
- User runs command
plan - User wants to break a spec into tasks
- A unified artifact's Design & Rationale section needs decomposition
docs/specs/ - User says "plan the implementation" or similar
- Auto-chained from after the Design & Rationale section is written
ideate - Run directly (no prior ): at thin/standard depth, author the whole unified spec — light/standard Design & Rationale section plus Decomposition — in one pass
ideate - Auto-chained from plan-review with flag (gaps found)
--revise
在以下场景激活此技能:
- 用户运行命令
plan - 用户希望将规格分解为任务
- 统一工件的设计与原理章节需要分解
docs/specs/ - 用户说出"plan the implementation"(规划实现)或类似表述
- 在设计与原理章节编写完成后,从自动链式调用
ideate - 直接运行(无需先执行):以精简/标准深度编写完整的统一规格文档——包含精简/标准的设计与原理章节以及分解内容——一步完成
ideate - 从带有标志的plan-review自动链式调用(发现漏洞)
--revise
Revision Mode (--revise flag)
修订模式(--revise标志)
When invoked with , plan-review found gaps. Read from state, re-read the design, add tasks to address each gap, update the plan file, then clear gaps via .
--revise.planReview.gapsexarchos:exarchos_workflowaction: "update"当使用调用时,说明plan-review发现了漏洞。读取状态中的,重新读取设计内容,添加任务以解决每个漏洞,更新规划文件,然后通过的清除漏洞。
--revise.planReview.gapsexarchos:exarchos_workflowaction: "update"Revision Loop Guard
修订循环限制
Max revisions: 3 per plan.
After 3 failed revisions:
- Set
planReview.revisionsExhausted = true - Output: "Plan revision failed after 3 attempts. Design may be incomplete."
- Escalate: Suggest to revisit design
ideate --redesign
MANDATORY: Before accepting any rationalization for skipping tests, planning, or TDD steps, consult. Every common excuse is catalogued with a counter-argument and the correct action.references/rationalization-refutation.md
最大修订次数:每个规划最多3次。
3次修订失败后:
- 设置
planReview.revisionsExhausted = true - 输出:"规划修订已尝试3次仍失败。设计可能不完整。"
- 升级处理:建议执行重新审视设计
ideate --redesign
强制要求: 在接受任何跳过测试、规划或TDD步骤的理由之前,请查阅。所有常见借口均已分类记录,并配有反驳论据和正确操作指引。references/rationalization-refutation.md
The Verification Ladder
验证阶梯
Verification depth matches blast radius. The deeper rungs add tests, an adequacy kill-probe, and integration coverage — judged by outcome, test-after, not by a universal failing-test-first law. Each task gets the cheapest verification that still captures its risk:
| Risk tier | What it adds | Why |
|---|---|---|
| low | Static analysis (typecheck + lint) suffices | A docs/config/rename-only edit has near-zero blast radius; a test ceremony is pure overhead. |
| medium | Scoped tests + the | The kill-probe recaptures test-first's one real guarantee — that a test can actually fail — at lower cost, judged test-after instead of mandating a failing test first on every commit. |
| high | The integration suite (and mutation-adequacy at the boundary) on top of medium | Schema/type/API/shared-contract surfaces span the codebase; here adequacy-judged coverage plus real-collaborator integration across the seam earns its cost. |
The planner stamps each task's (and ); the classifier derives it from blast radius when the planner does not override. The dispatched implementer prompt and the gate sequence both scale off that stamp — so the verification effort is data-driven, not a blanket rule.
riskTierboundaryTouchingFor a high-tier task, the discipline is outcome-based (write the behavior and its tests in whatever order is natural — test-after is fine):
- Cover the new/changed behavior with scoped tests that pin its contract
- Let the kill-probe prove the tests can actually fail (it reverts your source and asserts at least one test goes red)
check_test_adequacy - Add real-collaborator integration coverage across the seam
Verify high-tier test adequacy after implementation — the keeper gate (the test-FIRST ordering gate was retired):
check_tdd_compliancetypescript
exarchos_orchestrate({
action: "check_test_adequacy",
featureId: "<featureId>",
taskId: "<taskId>",
branch: "feature/<name>",
riskTier: "high"
})- — Reverting the task's source makes at least one new/changed test fail: the tests are not vacuous
passed: true - — A test still passes against the reverted source; strengthen it
passed: false
验证深度与影响范围相匹配。更深的层级会增加测试、充分性kill-probe和集成覆盖——基于结果,测试后评估,而非通用的测试优先规则。每个任务采用成本最低但仍能覆盖其风险的验证方式:
| 风险层级 | 新增内容 | 原因 |
|---|---|---|
| 低 | 仅需静态分析(类型检查+代码扫描)即可 | 仅涉及文档/配置/重命名的修改影响范围几乎为零;测试流程纯粹是额外开销。 |
| 中 | 限定范围测试 + | kill-probe以更低成本重现了测试优先的核心保障——即测试确实可以失败——采用测试后评估,而非强制每次提交都先编写失败测试。 |
| 高 | 在中等风险验证基础上增加集成测试套件(以及边界处的变异充分性测试) | Schema/类型/API/共享契约层面的修改会影响整个代码库;此处基于充分性评估的覆盖加上跨边界的真实协作方集成测试是值得投入成本的。 |
规划器会为每个任务标记(风险层级)和(是否涉及边界);若规划器未覆盖,分类器会根据影响范围推导得出。调度的实现者提示和 gate 序列均会根据该标记调整——因此验证工作是数据驱动的,而非统一规则。
riskTierboundaryTouching对于高风险层级任务,遵循基于结果的原则(以自然顺序编写行为及其测试——测试后编写也可):
- 用限定范围测试覆盖新增/修改的行为,固定其契约
- 让kill-probe证明测试确实可以失败(它会还原你的源代码,并断言至少一个测试会失败)
check_test_adequacy - 添加跨边界的真实协作方集成覆盖
在实现后验证高风险层级测试的充分性——原测试优先顺序的gate已被弃用:
check_tdd_compliancetypescript
exarchos_orchestrate({
action: "check_test_adequacy",
featureId: "<featureId>",
taskId: "<taskId>",
branch: "feature/<name>",
riskTier: "high"
})- —— 还原任务源代码后,至少一个新增/修改的测试会失败:测试并非无效
passed: true - —— 还原源代码后测试仍通过;需强化测试
passed: false
Planning Process
规划流程
Step 1: Analyze the Design & Rationale section
步骤1:分析设计与原理章节
Read the unified spec's section thoroughly (if ran, it is already written; otherwise author it at thin/standard depth now, per ). From it, extract:
## Design & Rationaleideatereferences/spec-template.md- Problem Statement — Context (no tasks, but informs scope)
- Chosen Approach — Architectural decisions to implement
- Requirements (DR-N) — the provenance anchors every task must trace to
- Technical Design — Core implementation requirements
- Integration Points — Integration and glue code tasks
- Open Questions — Decisions to resolve or explicitly defer
仔细阅读统一规格文档的章节(若已执行,则该章节已编写完成;否则需根据以精简/标准深度编写)。从中提取:
## Design & Rationaleideatereferences/spec-template.md- 问题陈述 —— 背景信息(不包含任务,但用于明确范围)
- 选定方案 —— 需实现的架构决策
- 需求(DR-N) —— 每个任务必须追溯的来源锚点
- 技术设计 —— 核心实现需求
- 集成点 —— 集成和粘合代码任务
- 待解决问题 —— 需解决或明确推迟的决策
Step 1.5: Spec Tracing (Required)
步骤1.5:规格追溯(必填)
Create a traceability matrix mapping requirements to planned tasks within the unified document.
Consult for the methodology and template.
DR-Nreferences/spec-tracing-guide.mdPre-populate the matrix using the traceability generator — pass the unified artifact as both and (DR-N is parsed from its region, tasks from its region — one file):
docs/specs/designFileplanFile## Design & Rationale## Decompositiontypescript
exarchos_orchestrate({
action: "generate_traceability",
designFile: "docs/specs/<date>-<feature>.md",
planFile: "docs/specs/<date>-<feature>.md",
outputFile: "docs/specs/<date>-<feature>-traceability.md"
})- — Matrix generated; review and fill in "Key Requirements" column
passed: true - — Parse error; the spec may lack expected
passed: false/##headers###
创建可追溯性矩阵,在统一文档内将DR-N需求映射至规划任务。
查阅获取方法和模板。
references/spec-tracing-guide.md预填充矩阵:使用可追溯性生成器——将统一的工件同时作为和传入(DR-N从其区域解析,任务从其区域解析——单个文件):
docs/specs/designFileplanFile## Design & Rationale## Decompositiontypescript
exarchos_orchestrate({
action: "generate_traceability",
designFile: "docs/specs/<date>-<feature>.md",
planFile: "docs/specs/<date>-<feature>.md",
outputFile: "docs/specs/<date>-<feature>-traceability.md"
})- —— 矩阵已生成;审阅并填写"关键需求"列
passed: true - —— 解析错误;规格文档可能缺少预期的
passed: false/##标题###
Step 2: Decompose into Tasks
步骤2:分解为任务
Each task follows the TDD format in .
references/task-template.mdGranularity Guidelines:
- Each task: 2-5 minutes of focused work
- One test = one behavior
- Prefer many small tasks over few large ones
Assign a to each task using to control which verification techniques agents apply. Auto-determine and flags by matching each task's description and file paths against the category tables — do not leave these for the implementer to decide.
testingStrategyreferences/testing-strategy-guide.mdpropertyTestsbenchmarksTask Ordering:
- Foundation first (types, interfaces, data structures)
- Core behaviors second
- Edge cases and error handling third
- Integration and glue code last
每个任务遵循中的TDD格式。
references/task-template.md粒度指南:
- 每个任务:2-5分钟的专注工作
- 一个测试对应一个行为
- 优先拆分为多个小任务,而非少量大任务
使用为每个任务分配,以控制代理应用的验证技术。通过将每个任务的描述和文件路径与类别表匹配,自动确定和标志——勿将这些决策留给实现者。
references/testing-strategy-guide.mdtestingStrategypropertyTestsbenchmarks任务顺序:
- 基础任务优先(类型、接口、数据结构)
- 核心行为次之
- 边缘情况和错误处理第三
- 集成和粘合代码最后
Step 3: Identify Parallelization
步骤3:识别并行化机会
Analyze dependencies to find sequential chains and parallel-safe groups that can run simultaneously in worktrees.
分析依赖关系,找出可在工作树中同时运行的顺序链和可并行分组。
Step 4: Author the Decomposition section
步骤4:编写分解章节
Write the section into the unified spec at , using . Its carries the task breakdown, with traceability resolved within this single document against the DR-N source above it.
## Decompositiondocs/specs/YYYY-MM-DD-<feature>.mdreferences/spec-template.md## Decomposition## Design & RationaleThe legacy two-file split (→references/plan-document-template.md) is retained only for in-flight workflows already on the old path; new features author the onedocs/plans/artifact.docs/specs/
将章节写入统一规格文档,遵循。其部分包含任务拆分,可追溯性在单个文档内与上方中的DR-N来源关联。
## Decompositiondocs/specs/YYYY-MM-DD-<feature>.mdreferences/spec-template.md## Decomposition## Design & Rationale遗留的双文件拆分(→references/plan-document-template.md)仅适用于已采用旧流程的进行中工作流;新功能需编写单个docs/plans/工件。docs/specs/
Step 5: Plan Verification
步骤5:规划验证
Run deterministic verification scripts instead of manual checklist review. Each takes the unified artifact as both and — the handlers parse DR-N from its design region and tasks from its decomposition region.
docs/specs/designPathplanPath5a. Coverage — verify every Design & Rationale requirement maps to a task (the folded design-completeness acceptance-criteria check rides here now):
typescript
exarchos_orchestrate({
action: "check_plan_coverage",
featureId: "<id>",
designPath: "docs/specs/<date>-<feature>.md",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true — All requirements covered; proceed to 5a-ii
- passed: false — Gaps found; add tasks for uncovered requirements or defer with rationale
- error — Usage error or empty spec; check arguments
5a-ii. Provenance chain verification — verify every DR-N requirement maps to a task via field:
Implements:typescript
exarchos_orchestrate({
action: "check_provenance_chain",
featureId: "<id>",
designPath: "docs/specs/<date>-<feature>.md",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true — All DR-N requirements traced; proceed to 5b
- passed: false — Block: gaps or orphan references found. Add to tasks for each uncovered requirement before proceeding. Every DR-N requirement MUST trace to at least one task.
**Implements:** DR-N - error — No DR-N identifiers in design (exit 2); if design doesn't use DR-N identifiers, this check is skipped (exempt)
5a-iii. D5: Task decomposition quality (advisory) — verify each task has clear description, file targets, and test expectations; dependency graph is a valid DAG; parallelizable tasks don't modify the same files:
typescript
exarchos_orchestrate({
action: "check_task_decomposition",
featureId: "<id>",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true — All tasks well-decomposed; proceed to 5b
- passed: false — Findings recorded as D5 gate events for the ConvergenceView. Present findings to the user for awareness but do not block plan approval.
- error — Input error (missing file, no task headers); check arguments
Advisory: This gate verifies task structure quality but does not block plan approval. Findings are recorded for convergence tracking.
5b. Spec coverage check — verify planned test files exist and pass:
typescript
exarchos_orchestrate({
action: "spec_coverage_check",
planFile: "docs/specs/<date>-<feature>.md",
repoRoot: "."
})- — All planned tests found and passing; plan verification complete
passed: true - — Missing test files or test failures; create missing tests or fix failures
passed: false
For reference, consult for the underlying methodology.
references/spec-tracing-guide.md运行确定性验证脚本,而非手动检查清单。每个脚本均将统一工件同时作为和传入——处理器从其设计区域解析DR-N,从分解区域解析任务。
docs/specs/designPathplanPath5a. 覆盖验证 —— 验证每个设计与原理需求均映射至任务(折叠的设计完整性验收标准检查现在在此处执行):
typescript
exarchos_orchestrate({
action: "check_plan_coverage",
featureId: "<id>",
designPath: "docs/specs/<date>-<feature>.md",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true —— 所有需求均已覆盖;进入5a-ii
- passed: false —— 发现漏洞;为未覆盖的需求添加任务,或提供推迟理由
- error —— 使用错误或规格文档为空;检查参数
5a-ii. 来源链验证 —— 验证每个DR-N需求均通过字段映射至任务:
Implements:typescript
exarchos_orchestrate({
action: "check_provenance_chain",
featureId: "<id>",
designPath: "docs/specs/<date>-<feature>.md",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true —— 所有DR-N需求均已追溯;进入5b
- passed: false —— 阻塞:发现漏洞或孤立引用。为每个未覆盖的需求在任务中添加后再继续。每个DR-N需求必须至少追溯至一个任务。
**Implements:** DR-N - error —— 设计中无DR-N标识符(退出码2);若设计未使用DR-N标识符,则跳过此检查(豁免)
5a-iii. D5:任务分解质量(建议性) —— 验证每个任务有清晰的描述、文件目标和测试预期;依赖图为有效的DAG;可并行任务不修改同一文件:
typescript
exarchos_orchestrate({
action: "check_task_decomposition",
featureId: "<id>",
planPath: "docs/specs/<date>-<feature>.md"
})- passed: true —— 所有任务分解良好;进入5b
- passed: false —— 检查结果记录为ConvergenceView的D5 gate事件。向用户展示检查结果以提高认知,但不阻塞规划批准。
- error —— 输入错误(文件缺失、无任务标题);检查参数
建议: 此gate验证任务结构质量,但不阻塞规划批准。检查结果会被记录以用于收敛跟踪。
5b. 规格覆盖检查 —— 验证规划的测试文件存在且通过:
typescript
exarchos_orchestrate({
action: "spec_coverage_check",
planFile: "docs/specs/<date>-<feature>.md",
repoRoot: "."
})- —— 所有规划的测试均已找到且通过;规划验证完成
passed: true - —— 测试文件缺失或测试失败;创建缺失的测试或修复失败的测试
passed: false
如需参考,请查阅获取底层方法。
references/spec-tracing-guide.mdAnti-Patterns
反模式
| Don't | Do Instead |
|---|---|
| Ship medium/high-tier behavior with no tests | Cover it with adequacy-judged tests (test-after is fine) |
| Mandate red-green-refactor on every task | Scale verification to the task's |
| Create large tasks | Break into 2-5 min chunks |
| Skip dependency analysis | Identify parallel opportunities |
| Vague test descriptions | Specific: Method_Scenario_Outcome |
| Assume your tests can fail | Let |
| Add "nice to have" code | Only what the behavior requires |
| 禁止行为 | 正确做法 |
|---|---|
| 发布中/高风险层级的行为却不编写测试 | 用基于充分性评估的测试覆盖(测试后编写也可) |
| 强制每个任务都遵循红-绿-重构流程 | 根据任务的 |
| 创建大型任务 | 拆分为2-5分钟的小任务 |
| 跳过依赖分析 | 识别并行化机会 |
| 模糊的测试描述 | 具体化:方法_场景_结果 |
| 假设测试可以失败 | 让 |
| 添加"锦上添花"的代码 | 仅添加行为所需的代码 |
Rationalization Debunking
理由反驳
The ladder already prices in genuinely low-risk work — so these excuses apply to medium/high-tier tasks, where they are rationalizations rather than reasonable tier choices:
| Excuse | Reality |
|---|---|
| "This is too simple for a test" (on a medium/high-tier task) | If it touches a high-blast surface, its tier is not low. Test it at the tier the ladder assigns. |
| "I'll add tests after" | You won't. Or they'll be weak — and |
| "Tests slow me down" | Debugging an untested medium/high-tier change is slower. |
| "The design is obvious" | Obvious to you now. Not in 3 months. |
验证阶梯已考虑到真正低风险的工作——因此以下借口适用于中/高风险层级任务,它们属于不合理的理由而非合理的层级选择:
| 借口 | 事实 |
|---|---|
| "这太简单了,不需要测试"(针对中/高风险层级任务) | 如果它涉及高影响范围,其风险层级就不是低风险。需按照阶梯分配的层级进行测试。 |
| "我之后再添加测试" | 你不会的。或者测试会很薄弱——而 |
| "测试拖慢我的速度" | 调试未测试的中/高风险变更会更慢。 |
| "设计很明显" | 现在对你来说明显。3个月后就不一定了。 |
State Management
状态管理
On spec save, record the artifact and transition phase based on : feature → , refactor → . Set to the unified path — this is the key the guard reads, and it points at the one unified doc (the same path recorded as ). Artifacts and phase are two separate calls — is non-phase mutation only; phase changes go through the HSM-guarded action:
workflowTypeplan-reviewoverhaul-plan-reviewartifacts.plandocs/specs/planArtifactExistsideateartifacts.specupdatetransitiontext
action: "update", featureId: "<id>", updates: {
"artifacts": { "plan": "docs/specs/<date>-<feature>.md" },
"tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}
action: "transition", featureId: "<id>", target: "<plan-review-phase>"保存规格文档时,记录工件并根据转换阶段:feature(功能)→ ,refactor(重构)→ 。将设置为统一路径——这是 guard读取的键,指向单个统一文档(与记录为的路径相同)。工件和阶段是两个独立的调用——仅用于非阶段变更;阶段变更需通过HSM保护的操作:
workflowTypeplan-reviewoverhaul-plan-reviewartifacts.plandocs/specs/planArtifactExistsideateartifacts.specupdatetransitiontext
action: "update", featureId: "<id>", updates: {
"artifacts": { "plan": "docs/specs/<date>-<feature>.md" },
"tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}
action: "transition", featureId: "<id>", target: "<plan-review-phase>"Phase Transitions and Guards
阶段转换与Guard
For the full transition table, consult .
@skills/checkpoint/references/phase-transitions.mdQuick reference: The → transition requires guard — set to the unified path before the call.
planplan-reviewplan-artifact-existsartifacts.plandocs/specs/transition完整的转换表请查阅。
@skills/checkpoint/references/phase-transitions.md快速参考: → 转换需要 guard——在调用之前,需将设置为统一路径。
planplan-reviewplan-artifact-existstransitionartifacts.plandocs/specs/Schema Discovery
模式发现
Use for
parameter schemas and
(or , ) for phase transitions, guards, and playbook guidance.
Use
for orchestrate action schemas.
exarchos_workflow({ action: "describe", actions: ["update", "init"] })exarchos_workflow({ action: "describe", playbook: "feature" })"debug""refactor"exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })使用获取参数模式,使用(或、)获取阶段转换、guard和工作流指南。使用获取编排操作模式。
exarchos_workflow({ action: "describe", actions: ["update", "init"] })exarchos_workflow({ action: "describe", playbook: "feature" })"debug""refactor"exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })Completion Criteria
完成标准
- Design document read and understood
- Spec traceability table created ()
exarchos_orchestrate({ action: "generate_traceability" }) - Scope declared (full or partial with rationale)
- Tasks decomposed to 2-5 min granularity
- Each task carries a (and
riskTier) stamp; medium/high-tier tasks carry adequacy-judged tests (test-after), high-tier adds the integration suiteboundaryTouching - Dependencies mapped
- Parallel groups identified
- Plan verification passed — returns passed: true
exarchos_orchestrate({ action: "check_plan_coverage" }) - Provenance chain checked — passed (blocking; gaps must be resolved before proceeding)
exarchos_orchestrate({ action: "check_provenance_chain" }) - Task decomposition checked — run (advisory; findings presented but non-blocking)
exarchos_orchestrate({ action: "check_task_decomposition" }) - Spec coverage check passed — passed: true
exarchos_orchestrate({ action: "spec_coverage_check" }) - Coverage thresholds met — passed: true:
exarchos_orchestrate({ action: "check_coverage_thresholds" })
typescript
exarchos_orchestrate({
action: "check_coverage_thresholds",
coverageFile: "coverage/coverage-summary.json",
lineThreshold: 80,
branchThreshold: 70,
functionThreshold: 100
})- Unified spec saved to (Design & Rationale + Decomposition in one doc)
docs/specs/ - State file updated with = unified spec path and tasks
artifacts.plan
- 已阅读并理解设计文档
- 已创建规格可追溯性表(执行)
exarchos_orchestrate({ action: "generate_traceability" }) - 已声明范围(完整范围或带有理由的部分范围)
- 任务已分解为2-5分钟的粒度
- 每个任务都带有(和
riskTier)标记;中/高风险层级任务带有基于充分性评估的测试(测试后编写),高风险层级额外添加集成测试套件boundaryTouching - 已映射依赖关系
- 已识别并行分组
- 规划验证通过——返回passed: true
exarchos_orchestrate({ action: "check_plan_coverage" }) - 来源链已检查——通过(阻塞;漏洞必须解决后才能继续)
exarchos_orchestrate({ action: "check_provenance_chain" }) - 任务分解已检查——已执行(建议性;展示结果但不阻塞)
exarchos_orchestrate({ action: "check_task_decomposition" }) - 规格覆盖检查通过——返回passed: true
exarchos_orchestrate({ action: "spec_coverage_check" }) - 覆盖阈值已满足——返回passed: true:
exarchos_orchestrate({ action: "check_coverage_thresholds" })
typescript
exarchos_orchestrate({
action: "check_coverage_thresholds",
coverageFile: "coverage/coverage-summary.json",
lineThreshold: 80,
branchThreshold: 70,
functionThreshold: 100
})- 统一规格文档已保存至(设计与原理 + 分解内容在单个文档中)
docs/specs/ - 状态文件已更新,= 统一规格文档路径,且包含任务信息
artifacts.plan
Transition
转换
After decomposition completes, auto-continue to plan-review. Transition to the appropriate review phase (feature: , refactor: ). Plan-review is no longer an inline plan-vs-design delta (one artifact now) — it is a dispatched, fresh-context, adversarial read-only pass over the unified artifact (DR-10): a clean reviewer provisioned with only {artifact + spec} (never this authoring transcript), prompted to refute the plan, its adversarial depth scaled by the frozen . Provision it via .
plan-reviewoverhaul-plan-reviewdesignDepthexarchos_orchestrate({ action: "prepare_review", scope: "plan", artifact: "docs/specs/<...>", designDepth: "<frozen>" })- Refuted (gaps): set , auto-loop back to
.planReview.gapsplan --revise - Survives: present to user for approval (the single human checkpoint)
- On approval: set , invoke
.planReview.approved = truedelegate
REQUIRED: Run over the unified artifact. If passed: false → auto-invoke . If passed: true → transition to the plan-review phase and only invoke after plan-review approval.
exarchos_orchestrate({ action: "check_plan_coverage" })plan --revisedelegate分解完成后,自动继续至plan-review。转换至相应的评审阶段(功能:,重构:)。Plan-review不再是内联的规划与设计差异检查(现在是单个工件)——而是对统一工件的调度式、全新上下文、对抗性只读检查(DR-10):为评审者提供仅包含{工件 + 规格}的干净环境(绝不提供此编写记录),提示其反驳规划,对抗性深度由冻结的决定。通过准备环境。
plan-reviewoverhaul-plan-reviewdesignDepthexarchos_orchestrate({ action: "prepare_review", scope: "plan", artifact: "docs/specs/<...>", designDepth: "<frozen>" })- 被反驳(发现漏洞):设置,自动循环回
.planReview.gapsplan --revise - 通过评审:提交给用户批准(唯一的人工检查点)
- 批准后:设置,调用
.planReview.approved = truedelegate
强制要求: 对统一工件运行。若返回passed: false → 自动调用。若返回passed: true → 转换至plan-review阶段,仅在plan-review批准后调用。
exarchos_orchestrate({ action: "check_plan_coverage" })plan --revisedelegateExarchos Integration
Exarchos集成
Phase transitions auto-emit events via . No manual append needed.
workflow.transitionexarchos_workflowsetexarchos_event阶段转换会通过的自动发送事件。无需手动添加。
exarchos_workflowsetworkflow.transitionexarchos_eventTroubleshooting
故障排除
| Issue | Cause | Resolution |
|---|---|---|
| Design sections not mapped to tasks | Add tasks for uncovered sections or add explicit deferral rationale |
| Planned test files missing or failing | Create missing test stubs, verify file paths in plan match actual paths |
| Design doc missing expected | Verify design uses standard Markdown headings |
| Revision loop (3+ attempts) | Persistent gaps between design and plan | Set |
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 设计章节未映射至任务 | 为未覆盖的章节添加任务,或添加明确的推迟理由 |
| 规划的测试文件缺失或失败 | 创建缺失的测试桩,验证规划中的文件路径与实际路径匹配 |
| 设计文档缺少预期的 | 验证设计使用标准Markdown标题 |
| 修订循环(3次以上尝试) | 设计与规划之间存在持续漏洞 | 设置 |
Performance Notes
性能说明
- Complete each step fully before advancing — quality over speed
- Do not skip validation checks even when the change appears trivial
- Trace every design section to at least one task. Do not leave uncovered sections without explicit rationale.
- 完成每个步骤后再推进——质量优先于速度
- 即使变更看似微不足道,也不要跳过验证检查
- 每个设计章节至少追溯至一个任务。未覆盖的章节必须有明确的理由。