用途：直接实现小型功能或修复缺陷，仅在需求清晰、风险低时使用以换取速度。
适用条件（编码前必须通过范围门槛）：需求明确、预期行为清晰、无重大产品/架构歧义；改动面小（通常不超过5个文件）、无跨模块大重构；架构风险低、无基础性重设计或迁移类改动；验证路径简单，可用针对性测试快速校验，无需长时间探索调试。任一条件不满足，应升级到 write-plan。
硬性停止条件：出现需求歧义需设计决策、跨子系统意外耦合、数据模型或模式重大变更、安全/合规敏感改动、需基准与设计权衡的性能工作、超出原范围的重构、反复失败且无明确根因、需要分阶段交付/功能开关/迁移策略等。触发后须立即停止编码，并输出固定提示：'This change exceeds rapid-implementation safety limits. Recommend write-plan first to define phased execution and risk controls.'，并用提问工具询问用户是否交接给 write-plan 技能。
工作流：1）分析与上下文：理解请求、定义验收标准，按共享的 Context Loading Protocol 加载项目上下文，仅检查必要代码路径，确认仍符合范围门槛；若有歧义先提问再编码。2）实现：做满足需求的最小正确改动，复用现有模式与约定，避免无关的顺手重构，适用时保持幂等与可重跑。3）验证：用合适的执行工具做与改动相称的验证，包括相关定向测试、受影响区域的 lint/类型检查、必要的构建或运行时验证；若失败且局部可修则做针对性修复，若显示影响面扩大则立即升级到 write-plan。4）完成：总结改动与原因，列出修改文件，报告验证命令与结果；如涉及细微行为或领域规则变化可更新相应文档（如 docs/project-pdr.md 或组件 README），但不得改动架构文档，若架构变化则本应升级。
执行边界：未经用户明确批准不得扩大范围；不得假设未说明的行为，应澄清；风险上升时不要强行完成，应尽早升级；复杂或风险超出限制时升级到 write-plan；若任务主要是调试问题，改用 fix。
输出检查：确认已满足范围门槛、未引入隐藏架构变更、已运行并报告验证、在超出安全限制时已升级。
限制：资料未提供该技能的安装命令、价格、平台支持等具体信息。