dwf-coding 用于单独执行 DWF 工作流的「编码执行」阶段。它只负责把已确认的方案和实现清单落到目标代码目录，不负责生成需求文档、设计稿、需求分析、技术方案或实现清单。默认只读取或更新目标代码目录、目标 spec 目录下 05-实现清单/实现清单.md、必要的项目代码文件，以及工作流模式下的 .dwf/state.json；不主动创建或重写 01-需求/、02-设计稿/、03-需求分析/、04-技术方案/ 或 05-实现清单/ 的主体内容，除非用户明确要求先回到对应阶段。
目标代码目录与目标 spec 目录由运行模式决定。工作流模式读取 .dwf/state.json，在 specs 数组中找 status: "active" 且 current_step 为 code 的 spec，目标 spec 目录为 .dwf/specs/{spec.name}/，目标代码目录为工作区根目录（dwf-orchestrator 的约定：代码不放 spec 目录内、统一放根目录）；若 shared_ref 非空，可读取 .dwf/specs/{shared_ref}/01-需求/、/02-设计稿/ 作为只读上下文。独立模式则用 question 询问用户目标 spec 目录（含实现清单与技术方案）与目标代码目录，spec 目录默认提议 .dwf/specs/{今日日期}-{seq}-feat-{描述}，其中 seq 扫描 .dwf/specs/ 现有 spec 目录名中的最大序号 +1（无则 001），代码目录默认提议工作区当前目录，由用户确认或修改。
编码前必须读取依据。执行任何代码修改前，必须先读取目标 spec 目录下 05-实现清单/实现清单.md、04-技术方案/技术方案.md（如果存在）、本技能目录下 references/coding_standards.md、项目级 .dwf/coding-specs/ 下已确认的编程规范（如果存在），并检查目标代码目录的现有结构。若缺少实现清单或技术方案不足以执行，先说明缺口并请求用户补充或回到 dwf-development。
每次触发后都要检测运行模式：检查 .dwf/state.json，找到 status: "active" 且 current_step 为 code 的 spec。找到则按工作流模式执行编码，完成后把该 spec 从 specs 队列移除、追加到 completed_specs、递增 iteration_count（由 dwf-orchestrator 收尾；本技能也可代为更新 state.json 与 _meta.json）。未找到满足条件的 active spec 时按独立模式执行，不创建 .dwf/state.json，不推进完整工作流状态。
编码前必须完成编程范式约定。进入「执行编码」前，必须先就编程范式与用户达成一致，并把结果落到项目级 .dwf/coding-specs/（与所有 spec/迭代共享，不放 spec 目录内）：检查 .dwf/coding-specs/ 下是否已有覆盖当前技术栈的 *.md（如 前端编程规范.md、后端编程规范.md、移动端编程规范.md）；已存在则用 question 确认是否沿用，用户可能修改，修改时按不存在流程协商修订并更新该文件，沿用则跳过生成；不存在则从 04-技术方案/技术方案.md 探测本次涉及的端，用 question 与用户确认要生成哪几份规范，逐份协商第三方库选型、组件/模块拆分、是否使用 TypeScript、状态管理、样式体系、目录结构、命名约定、接口封装、测试方式等，写入 .dwf/coding-specs/{端}编程规范.md，并用 question 逐份确认。项目级规范补充 references/coding_standards.md 的通用基线，冲突时以项目级规范为准，两者都读。未获得用户确认前，不进入「执行编码」，不修改任何项目代码。
不绕过确认边界。如果实现清单仍未确认、spec 的 current_step 不是 code、编程范式约定未完成、或发现需求/方案/清单互相冲突，必须暂停并说明原因，不擅自编码。执行时严格按实现清单顺序逐项执行任务，每完成一项依据该任务的「编码规范检查」和「验证标准」核对结果，再把对应任务从 [ ] 标记为 [x]（写入目标 spec 目录下 05-实现清单/实现清单.md），不一次性把未验证的任务全部标记完成。变更范围受控，只修改完成当前任务所必需的文件；工作流模式下只实施本次确认的受影响范围，不顺手重构无关模块、替换架构或扩大需求。
触发后流程包括：探查上下文（读取 .dwf/state.json 与 specs、读取实现清单、技术方案、references/coding_standards.md、检查 .dwf/coding-specs/、检查目标代码目录已有代码并分析框架、目录结构、命名、样式、测试和构建方式）；判断运行模式（独立模式或工作流模式）；编程范式约定；执行编码（选择第一个未完成且未阻塞的任务，读取涉及文件，按项目现有模式实施最小必要改动，自检并运行 lint、typecheck、test、build 等验证命令，无法运行时说明原因并记录替代检查，标记已验证完成的任务，继续下一项直到清单完成或遇到阻塞）；处理模板和新项目（若目标代码目录为空且技术方案明确选择基于本技能 assets/ 中的 React 模板，PC 端优先使用 assets/react-pc/，移动端优先使用 assets/react-mobile/，通用配置、hooks、utils、请求封装等可参考或合并 assets/shared/，只复制匹配内容，不把 dist/ 当作源代码继续开发，模板/技术方案/需求冲突时暂停说明）；阻塞处理（缺少实现清单、清单无明确任务或验证标准或依赖顺序、技术方案缺失无法判断架构选型、current_step 仍处于 requirements/design/breakdown/plans/todos、编程范式约定未完成、发现需求方案清单失效，均须暂停并说明缺少什么、为何不能继续、建议进入哪个技能或阶段补齐）。
全程使用中文，除非用户明确要求其他语言，所有交互、技能说明、生成文档、测试记录、审计结论和产物说明均使用中文；代码、文件路径、命令、API 名、技术术语、第三方库名和用户提供的原文内容可保留英文。
完成前需确认：已读取实现清单、技术方案、编码规范和现有代码结构；编程范式约定已完成并经用户确认；已按任务顺序执行且只标记已验证完成的任务；已运行可用验证命令或说明无法运行原因；独立模式下没有创建或推进 .dwf/state.json；工作流模式下只在任务全部完成后更新 state.json 与该 spec 的 _meta.json（status=done）；总结中列出完成任务、主要修改文件、验证结果、未完成事项或阻塞点。
关于收费、价格、平台支持范围、运行环境要求、性能指标等信息，资料中暂未提供。