写好编码任务
编码不要求固定模板，但一条可执行的请求应让 Ghast 明确四件事：要得到什么结果、可以改哪里、不能做什么、怎样判断完成。
通用结构
目标：修复保存设置后页面仍显示旧值的问题。
范围：只修改设置页面及其数据请求代码。
限制：不要修改数据库结构，不要添加依赖，不要覆盖已有未提交修改。
完成标准：复现问题，完成修复，运行相关检查，并说明改动文件与未验证项。
目录、命令或文件名已知时直接写出。未知时，要求先调查并汇报，不要猜测路径。
常见任务写法
修复问题
说明复现步骤、预期结果、实际结果和允许修改的范围。若问题只在特定系统、账户或数据下出现，也要写清环境条件。
新增功能
列出用户入口、主要状态、错误状态、不可改变的现有行为和完成标准。设计稿或截图应作为附件加入，并说明哪些细节必须一致。
重构
明确哪些外部行为必须保持不变，以及用哪些命令或场景确认没有回归。只说“优化一下”通常不足以限定范围。
只读审查
只调查并报告，不要修改文件、运行会改变状态的命令、安装依赖或提交 Git。
按严重程度列出问题，并给出文件位置。
同时把命令授权切到 询问，并关闭不需要的 Tools。文字限制不会代替能力开关。
为风险动作单独授权
不要把“完成任务”理解成对所有后续动作的授权。以下动作应逐项写清是否允许：
- 安装或升级依赖、改锁文件；
- 运行迁移、写数据库或访问生产环境；
- 登录外部服务、发送消息或创建远端对象；
- 暂存、提交、推送、创建或合并 Pull Request；
- 删除文件、丢弃修改或清理 Worktree。
在已有修改上工作
项目已经有未提交修改时，告诉 Ghast 哪些文件属于现有工作，并要求先展示当前 Git 状态。若允许修改同一文件，说明必须保留的部分；如果无法安全区分，应先暂停该文件的改动。
让结果便于检查
要求最终回答包含：原因或实现思路、改动文件、运行过的命令、结果、未完成项。对界面问题补充目标交互路径；对服务问题补充请求、响应或日志的可观察结果。完成后仍要使用审查文件修改和 Git 面板自行核对。