用途：处理单个可评审单元（一个子系统、约一天以内）的标准改动流程，从规格到合并 PR，含评审与验证。若涉及两个以上可独立评审/测试的单元或多个子系统，应改用 epic-dev；若首次接触该代码库，先用 codebase-onboarding；若行为异常且原因未知，先用 debugging 技能。
主要流程：先读规格（gh issue view N），对含糊指令复述理解并注明可纠正；探索并寻找同类已有实现作为模板，不要自创新模式；使用 gh issue develop N --checkout 或按仓库约定新建分支，禁止在默认分支上工作；对声明保持行为的重构，先提交基于原代码的特征测试；实现最小一致 diff，保持周边风格，提交前丢弃无关改动；每个新守卫或错误路径需明确 fail-open 还是 fail-closed 并说明理由；相邻 bug 仅在小型且机制相关时一并修复并在 PR 单独披露，否则另开 issue。
每次提交都需通过门禁：格式化、lint、类型检查、测试，标准是相对实测基线的零新增诊断。Python 用 uv run ruff format && uv run ruff check --fix && uv run ty check && uv run pytest；JS/TS 用 bun run biome check --write && bun test，或按项目配置命令。提交信息主题 50 字符内，无 emoji、无 AI 署名。涉及决策逻辑的改动，除测试外还需运行可重复场景套件并在 PR 引用前后分数。超过约十分钟的长任务按 references/background-jobs.md 分离运行。
推送并开 PR：说明改了什么、为什么（Closes #N）、测试的命令与数量。PR/issue 正文每段保持单行、段落间空行。需先核实用户提供的事实性声明再写入持久文档。随后用 pr-review-toolkit 或仓库评审命令处理所有发现：修复或一句话理由拒绝，不得静默忽略。等待 CI 通过后按仓库合并约定合并。完成后以实质性评论关闭 issue，更新项目状态/记忆文件并清理产物。
限制与边界：完成定义为已合并（或 PR 已开且绿灯），代码写完不算完成，测试失败不算完成；结构性无法验证时，运行最近的只读替代方案并说明覆盖范围，把剩余步骤以可复制命令交给用户。新建不承载流量的基础设施可自行进行；影响线上外部使用者的操作（生产部署、发包、推送线上端点）即使持有凭证也要交给用户执行。用户陈述的风险容忍或紧迫性不构成跳过验证门禁的授权。本资料未提供该技能的定价、安装方式与具体支持平台。