context-development-engineer

name

context_development_engineer

description

Use when the user explicitly asks for 开发工程师, 软件工程师, 研发工程师, 开发专家, 工程专家, 技术专家, 开发方案, 研发方案, 工程方案, 技术方案, 实现, 实现方案, 实施计划, 多开agent, subagent, software engineer, senior engineer, engineering expert, development plan, engineering plan, or technical implementation plan in a Minimal Context Harness project. Do not trigger for routine coding, bug fixes, small refactors, package/release work, or generic mentions of code, development, or engineering.

Context Development Engineer

Package-Managed Boundary

This Skill is generated by ty-context sync and owned by the Harness package. Do not edit the generated context_development_engineer Skill directly.

Project-specific engineering rules belong in a separate project-local Skill under <harnessRoot>/skills/development_engineer/SKILL.md. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in project_context/**. Keep the project-local Skill front matter description trigger keywords aligned with this package-managed Skill and the project AGENTS.md role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and Tiny Context guidance do not drift apart.

目标

帮助 agent 以开发工程师 / 技术专家视角完成实现判断，并把长期工程事实压缩进可恢复的 Minimal Context。

工作方式

1. 先读取 project_context/global.md、project_context/architecture.md 和 project_context/context.toml，按 default area、triggers、read_when 选择相关 context。
2. 先确认用户目标、约束、成功标准、影响产品域、现有验证 / 部署关键路径和风险；能从代码或 Context 发现的事实不要反复询问用户。
3. project_context/** 决定“应该是什么”：模块职责、归属、架构边界、接口方向、契约语义和禁止依赖；代码决定“现在实现到了哪里”。代码不能静默重定义 Context。
4. 第一处代码编辑前，若任务影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff，先给出唯一长期事实判断 Context Delta: none|required，并在 agent 内部保持 Architecture Context Hit 与 Decision Rationale Hit: existing|required|none 清晰。若输入包含产品、架构、技术、实现或验收来源，逐项判断重要约束已被 Context 覆盖、需要先更新 Context、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 plan.md、Task Contract 文件或 Markdown 映射表。
5. 普通 bug fix、局部样式、局部实现漂移修复、小重构、package/release 处理、测试修复或探索性 spike 不强制创建架构 / rationale 流程 artifact，也不更新 Context；一旦形成长期工程结论，继续对齐或交付前必须回写 Context。不要把 Context 机械补成代码改动摘要。
6. 如果代码、搜索结果或相邻实现与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期，不要用当前代码形态反推模块归属。
7. 涉及已有 Context 的实现判断，先做轻量对齐：
   • Context expectation
   • Current code evidence
   • Gap
   • Proposed change
8. 涉及模块原则、模块逻辑、设计原因、API / Schema、状态语义、验证设计或 capability / metric / acceptance claim 时，先做 Module Principle / Design Gate：列出命中的模块设计上下文来源，说明这些原则 / 逻辑控制本次哪些实现或验证选择，再选择实现路径、验证 claim、probe 参数或 fallback。命令、probe、当前实现形态和被触碰文件大小是执行实例或维护风险，不能反推或覆盖模块设计目标。
   • 对外部产品/架构源、技术实现方案或验收清单中的 delivery / acceptance scope，必须显式区分 system_capability_build、representative_sample_validation、full_population_operation、full_population_not_required 和 out-of-scope backlog。不要把若干具体对象运行结果当作可复用系统能力完成，也不要把 framework-only 实现当作全量真实对象已完成；sample provider / interface / page 证据不能替代 all-provider / all-interface / all-platform / full-population 完成，除非 AC 明确批准该边界。若来源要求全量而可交付范围只能支持样本或框架，标记 scope_conflict_requires_decision；用户或权威 AC 收窄范围前不得声称全量完成。
9. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、表单/配置、输入、选择、搜索、筛选、调度/时间、预算/配额/限流或状态反馈的实现方案时，检查当前代码是否只是暴露字段，还是满足了已有 Context、Surface Contract、页面职责和控件任务框架；实现收尾要能给出简短 Surface/Context Conformance 证据。
   • 若存在 Product Surface Contract，内部计划必须保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification 清晰。
   • 若缺失且本任务创建 durable surface responsibility，设置 Context Delta: required，先用 context_surface_contract 或项目 Context 写入具体 surface 职责，再继续实现。
10. 实现时保持精准修改，优先遵循仓库现有框架、接口、测试和代码风格。
11. 当用户明确要求 / 允许“多开agent”或使用 subagent，且当前会话存在可用 subagent 工具时，积极把可并行的探索、审查或实现拆分交给 subagent；使用前先复用已有相关 agent，没有合适 agent 或并行度不足时再新开。wait_agent 只表示取得结果，不释放资源；subagent 完成、空闲或不再需要时必须调用 close_agent，收尾前清理已完成 / 空闲 / 不再需要的 subagent，避免占满后续资源。
12. 当任务涉及新实现、重构、重复逻辑、模块边界或影响面控制时，先做轻量 abstraction / decomposition scan：

• 在内部记录 Modularity Check: none|required|exception；可用 ty-context check-modularity --file <path> --limit 300 审计计划编辑文件，用 make validate-code-modularity 或 ty-context check-modularity --touched --limit 300 --fail-on-warning 做交付前硬审计。若项目本地 Skill 定义不同 limit，使用项目本地值。
• 审计同时检查物理行数、单函数语句数、分支复杂度、导出数、状态转换数和模块职责；压成一行不能规避。发现风险后判断是否加入新职责，并选择产品面、hook、model、adapter、component、service / facade 或 verification helper 等边界。
• 如果本次不拆，Modularity Check 取 exception，必须有 <harnessRoot>/config.yaml 的 lifecycle-complete waiver：path、收窄 category、owner、introduced_at、reason、tracking_issue、expiry_condition。交付说明不是机器豁免；已豁免历史债不得继续塞新职责，除非本次任务就是拆分 / 迁移。
• 查找相似实现、重复逻辑、紧耦合模块或影响面异常扩散点。
• 当一个业务对象、能力或接口的变更需要跨多个 Context、产品域或实现层同步调整时，将该影响范围视为模块边界复核信号；优先评估是否应通过独立模块、服务、facade 或稳定接口收敛依赖，避免通过手工 manifest 长期复制实现暴露面。
• 将候选项分为局部重构与长期边界变化，后者按既有 Context-first 规则处理。
• 对候选点说明当前重复 / 耦合证据、抽象后的边界、收益、风险和是否值得现在做。
• 默认只实施高收益、低风险、语义稳定的候选项。
• 不为一次性代码、不稳定语义或纯粹好看的架构做抽象。

13. 当人工流程呈现重复、确定性、容易漏步骤或顺序影响正确性时，主动评估是否应沉淀为 repo-local tool/script。脚本应放在 owning module 的工具目录并配测试；可恢复的执行入口、参数约束和适用边界写入对应 verification / deployment Context。Skill 只记录这类脚本化机会识别原则，不承载具体模块命令、provider id、artifact 路径或一次性运行结果。
14. 需要沉淀长期事实时，只更新 project_context/**：

• 全局工程取舍、跨产品域索引或当前状态写入 global.md。
• 产品域 API、数据契约、关键约束、入口和风险写入对应 area / subdomain Context。
• 跨域接口语义写入 context_role: contract 或 manifest role 为 contract 的 Context；关键重复验证路径写入 verification；关键部署、运行拓扑或云端初始化路径写入 deployment；代码入口索引用 implementation-index；底层理论源用 foundation；历史归档索引用 archive。
• 新 context unit 可新增 project_context/areas/<unit>.md，并更新 global.md#Context Index；复杂项目同时更新 project_context/context.toml。
• 如果 upgrade 自动把深层 .md 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。

15. 实现收尾时做 Contract Conformance 和 Context drift check：确认 controlling Context 到达正确模块、API、状态、surface 与验证路径，没有 forbidden shortcut、遗漏的重要 source constraint 或未沉淀的长期事实，且 Context 没退化成实现摘要。实现偏差修实现；长期事实缺失返回 Context Delta: required。交付只报告 Context: 已更新 ... 或 Context: 本次无长期事实变化；一次性证据、日志和实现摘要不写入 Context。
16. Context 只能声明验证 / 部署关键路径或验收信号，不能伪造“测试已通过”或“部署已成功”。
17. Verification / Deployment Role Context 只记录长期可复用的重复执行路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload。

UI 实现对齐

• UI 实现方案不只检查字段是否接上，还要检查控件是否支持用户任务、输入语义、反馈状态、错误恢复和已有页面/控件契约。
• 当 current code evidence 显示后端字段、枚举或自由输入直接暴露给用户时，不默认把它当作产品意图；先对照 Context、产品/UIUX Skill 的控件任务框架和项目组件体系判断是否是实现漂移或缺失契约。
• Contract Conformance 证据应短而具体：命中的已有 Context / 页面契约、实现如何满足、未满足或延期项、验证入口或手动检查。它属于交付说明，不属于 project_context/**。

内部执行约束与 Conformance

• Context Delta 只能是 none 或 required。required 先更新 owning Context；none 按现有 Context 工作，不制造 Context 噪音。
• Agent 内部计划应保持 capability、owner、依赖方向、input/output/state/persistence、failure/retry/timeout/degraded/recovery、observability、performance、security、non-goals 和 verification path 清晰。
• 高风险任务在内部保持 Architecture Context Hit、Decision Rationale Hit、Applicable Module Design、首选路径与 fallback/degraded 条件清晰；触及 surface 时也保持 Surface Contract 信息清晰。
• 外部来源的重要约束在内部分类为 Context 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策，并核对 capability / sample / full-population 边界；存在未处理项时不能声称全量完成。
• 默认流程不要求或验证固定 plan.md、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
• Modularity Check: none|required|exception 是内部判断；exception 只能由 lifecycle-complete config waiver 授权。
• Contract Conformance 直接检查 controlling Context 是否到达正确模块、API、状态机、surface 与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 Context Delta: required。
• small code task、普通修改、bug fix、小重构、package/release、测试修复或 spike 不创建额外流程 artifact。

模块设计上下文写法

• 模块设计上下文应是 Minimal Context，不是设计论文；只保留短、准、稳定、会影响后续实现或验证选择的内容。
• Principles 写稳定执行约束；Design Logic 写模块如何判断、选择、降级或组合能力；Design Rationale 只写会改变后续判断的原因、rejected alternative 或 tradeoff。
• Current Standard、Verification Paths、阈值、命令和 probe 参数是当前执行实例，不是永久原则；规则变化时更新对应 Context，而不是让旧命令继续定义目标。
• 不编造 rationale；仅由当前代码形态反推的理由、一次性证据、实现摘要、PR notes、命令输出、截图审查、debug 过程、agent reasoning、完整日志、临时 JSON、raw payload、测试报告和任务契约不进入高频模块原则段。

输出边界

• 不默认创建 .work_products/**、tech plan、ADR、implementation doc、review/test/release 文档。
• 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
• 如果用户明确要求独立开发方案、技术方案或实现说明，可以临时生成；长期事实仍要提炼回 project_context/**。
• 如果用户只是要求普通代码修改、修 bug、小重构、package/release 处理，或只是泛泛提到“代码 / 开发 / engineering”，不需要触发本 Skill；只有明确角色名或强相关产物名指向工程方案、实现方案、实施计划、技术判断或长期工程事实沉淀时才使用。

建议沉淀位置

• global.md#Design Rationale：跨模块工程取舍。
• architecture.md#Design Rationale：架构级选择、rejected alternatives 和 tradeoffs。
• global.md#Current State：影响后续恢复的实现状态。
• areas/*.md#User / System Contract：模块可见行为、API、CLI、UI 或数据契约。
• areas/*.md#Module Design Capsule：模块级 principles、design logic 和会影响后续判断的 rationale。
• areas/*.md#Core Data / API / State：关键数据结构、接口、状态流或规则。
• areas/*.md#Key Constraints：性能、安全、兼容、集成或维护约束。
• role=contract Context：跨域 API / schema / event / interface 语义及其 durable rationale。
• role=decision-rationale Context：更大或跨切面的稳定设计原因。
• areas/*.md#Code Entry Points：未来 agent 需要快速定位的代码入口。
• areas/*/verification.md 或 role=verification Context：关键测试、smoke、CI、probe 或验证重复执行路径。
• areas/*/deployment.md 或 role=deployment Context：关键部署、云端初始化、运行拓扑、健康检查或回滚重复执行路径。
• DESIGN.md：视觉 identity、design token 和视觉 rationale。
• project_context/context.toml：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。