// feature 流程的超轻量通道——不写 design / checklist 直接动手，但先指引 AI 查 CodeStable 知识库再开工。触发：用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干"，且需求小到不值得走 design 流程。
通过 Chrome 扩展控制真实浏览器。需要访问网页、抽取网页数据、点击按钮、填写表单、执行浏览器自动化、提取渲染后的组件证据，或以程序方式操作页面时使用。通过 DOM diff、简化 HTML 和 component evidence pack 返回节省 token 的结构化结果。适用于 browser control、web automation、page scraping、web data extraction、execute JS in browser、web_scan、web_execute_js、open browser、navigate to URL、get page content、fill form、click button、extract component、rendered DOM、computed styles、component evidence。
想法还模糊时的讨论入口，做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发：用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入，拍板后抽出 checklist。触发：用户说"开始设计方案"、"写 design doc"、"准备实现 XX"，前提是已知道做什么、为谁、怎么算成功。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。
系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离，产出批量发现清单。触发：用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
CodeStable 工作流根入口，介绍体系全貌并把诉求路由到对应 cs-* 子技能。触发：用户只输入 `cs`、说"介绍一下 codestable"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。
| name | cs-feat-ff |
| description | feature 流程的超轻量通道——不写 design / checklist 直接动手，但先指引 AI 查 CodeStable 知识库再开工。触发：用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干"，且需求小到不值得走 design 流程。 |
用户让你做小功能时本来 AI 就会直接动手——这个技能不改变这件事。它只做一件事：动手前把项目里已沉淀的 CodeStable 知识指给你，按需搜一下，写出来的代码就比裸写多一层保护；动手后回写一份最简的 {slug}-ff-note.md 让这次工作可追溯、可被 cs-arch / cs-req backfill 看到、能纳入 scoped-commit 提交。
很轻：没有 design doc / checklist / 验收清单 / 动手前的用户确认。看完指引，该读代码读、该写代码写、写完回写一段话。
Glob codestable/ 发现可用目录和文档，按需取用：
architecture/ — ARCHITECTURE.md 总入口 + 子系统 doc。改跨模块的东西前看一眼避免违反边界compound/ — learning / trick / decision / explore 四类沉淀：
python codestable/tools/search-yaml.py --dir codestable/compound --filter doc_type=learning --query "关键词"
python codestable/tools/search-yaml.py --dir codestable/compound --filter doc_type=decision --query "关键词"
python codestable/tools/search-yaml.py --dir codestable/compound --filter doc_type=trick --query "关键词"
requirements/ — 有相关 req 时读边界features/ — 有同类 feature 时参考其 designreference/ — shared-conventions.md / tools.md动手前问 2 个问题：
compound/ 的 learningcompound/ 的 decision + 看 architecture/ 相关子系统命中就把结论融进实现（按约束来写，不是抄）。没命中按自己判断写很正常。搜不到换几个关键词再试。
design / implement 的硬约束在 fastforward 的精简版。没 design doc 不代表可以不讲——这些是让你"直接动手"时不偏向 AI 默认会踩的坑。
30 秒回答：这次要加的东西在项目结构里属于哪儿？
默认坑：不思考就往眼前最顺手的文件里加——加完就成"什么都装的筐"。
开写前看一眼：文件多长？承担几件事？类有多少方法？新加的是自然扩展还是把它推向"什么都能干"？
健康就直接加；要先收拾（拆长文件 / 抽重函数）就先收拾再加，范围锁死为"只搬不改行为"；结构性问题（职责重划 / 模块拆合）→ 停下来回 design 流程。
只写用户明确要的。不顺手加：
判据：写完觉得"是不是还得加点 X"——X 是不是用户能感知到的？不是就别加。多出来的代码不是中性的，是后人维护的负担。
只改要改的函数。同文件里别的函数丑 / 命名怪——除非和这次冲突，否则别碰。新代码风格匹配当前文件已有写法。看到值得改的别处 → "顺手发现：{文件:行号} {问题}，不在本次范围"让用户决定。
会被其他地方引用 → 新文件；只一处用的小工具函数 → 就近放。
冒出 if (特殊情况) { 特殊处理 } → 停。这种分支基本只因为思路没覆盖到这种情况，硬写下去得到的是"为让代码能跑而加的特殊逻辑"。要么改数据结构让它不需要特殊处理，要么明确承认是边界情况并注释说明为什么特殊。
utils.ts / helpers.ts 万能 util 堆东西完整清单看 codestable/reference/shared-conventions.md 第 7 节。
{slug}-ff-note.md代码写完、验证完、用户确认效果 OK 之后才动这一步——动手前先建空壳会破坏 ff 的轻体感。
不问用户。规则：
最终路径：codestable/features/YYYY-MM-DD-{slug}/{slug}-ff-note.md，日期用今天。
---
doc_type: feature-ff-note
feature: {slug}
date: YYYY-MM-DD
requirement: {req-slug 或留空}
tags: [...]
---
## 做了什么
{1-3 句：解决什么需求 / 加了什么能力，业务视角}
## 改了哪些
- {file:行号区间或函数名} — {一句话说改了什么}
- ...
## 怎么验证的
{1-2 句：跑了哪些验证 / 浏览器走通了哪条路径 / 跑了什么测试}
## 顺手发现（可选，不阻塞）
- {文件:行号} {问题简述} — 不在本次范围
写得真的轻：每节就那么几行，不要把它写成迷你 design / 迷你 acceptance。这份文档的目标是"半年后有人看 git log 能跳进来 30 秒搞清楚做了啥"，不是替代标准流程。
落盘后告诉用户："已写 {slug}-ff-note.md，本次 fastforward 闭环。"
cs-feat-designcodestable/ 里留 {slug}-ff-note.md 之外的新文件——除非发现值得沉淀的坑 / 技巧，另起对话用 cs-learn / cs-trick 写干到一半发现下面任一情况，停下来告诉用户"这比想象的复杂，建议切回完整流程"：
codestable/architecture/ 既定的模块边界切回方式：触发 cs-feat-design。已写的代码在 design 里标"已部分实现"即可。
{slug}-ff-note.md 已落盘且四节填齐（顺手发现可省）按 codestable/reference/shared-conventions.md 第 4 节"scoped-commit"规则执行。本通道：
{slug}-ff-note.md按 shared-conventions.md 第 3 节"feature-ff"收尾推荐顺序逐项一句话提示（用户"不用"立即跳过）：
cs-learn）"cs-decide）"