Flutter Forge

要解决什么问题

在 Flutter 仓库里，Agent 很容易在需求未收口时就改代码、在状态管理/路由/目录约定上越界，或在「小改文案」和「从 PRD 做新模块」之间选错流程。Flutter Forge 是项目内的 controller skill：统一做命中判断、任务路由、阶段推进与最终收口，而不是把整段流程交给单次即兴对话。

技能如何工作

链路固定为 先路由 → 再分类 → 再展示模式 → 再执行。若任务不明确，会在路由环进入等待态，只追问、不往下跑分类与实现。

• 项目根状态：通过脚本判定 empty_new / flutter_existing / non_flutter，非 Flutter 或非允许状态直接退出。
• 任务分级：从直通（文档、环境、打包等）到轻量（10 秒测试可定位的小改）、中等、UI 优化、架构级、功能开发、页面开发、新项目共创（C0–C3）。
• 铁律与门禁：需求/方案未确认且无 auto_assumption 时禁止写实现；gate_check.py 与 hook 在写操作前强制执行阶段门禁与角色写权限隔离。
• 执行轨道：已有项目默认 S1→S2→(S3 拆分冻结，大任务并行时)→S4→S5（Rubric 评分）→S6 收口；S1 需确认 quality_tier（mvp/polished/production）。
• 策略入口：ff-fast 轻量优先、有风险再升级；ff-a 用推荐方案补缺口，仅在高风险事项上中断确认。

适用边界与注意点

• 触发词须出现在消息首个 token（行首），见 trigger_words.md；仅工作区是 Flutter 项目不会自动进入。
• project_guardrails 缺失时，对触及状态管理、路由、核心目录等的写操作会被硬阻断，需先初始化项目锚点。
• 轻量路径豁免「最强写前确认」，但不豁免需求确认；从需求/设计/0 到 1 起步不得降级为轻量。
• S4 遇 bug 须走系统化调试流程（轻量可简化但仍需根因）；多工作包冻结后应连续执行至 S5，中间不因常规确认停顿。