用途：编写和维护 Letsrunit 的 Gherkin 功能测试（.feature 文件）。最终交付物是持久化的 feature，仅成功完成一次浏览器探索不算交付。
主要能力：先理解测试契约，阅读目标行为、相关 UI 或应用代码、邻近 feature、support 文件及 cucumber.js；明确用户可见行为与结果、起始状态与测试数据、成功与失败用例。仅在能带来独立回归信号时新增场景；同一行为已存在时应扩展。覆盖度由行为决定，而非 UI 控件数量。
用法：优先复用现有步骤词汇。有 MCP 会话时先调用 letsrunit_list_steps（带 sessionId），这是内置与项目步骤的准确来源；无活动会话时检查 support 文件与步骤注册表，核对表达式与参数类型。匹配顺序为：复用能表达领域概念的精确项目步骤、组合内置步骤、修正定位器或作用域、最后才为真实行为缺口添加自定义定义。
结构：用被保护的行为命名 feature 与场景，保持 Given 建状态、When 执行操作、Then 检查结果的因果顺序，And/But 延续前一步类型。共享前置仅在所有场景都需要时放 Background；同行为不同数据用 scenario outline。断言应可能因回归而失败，使用稳定测试数据与 fixture，不提交密钥。定位器优先语义化（按钮、链接、字段、可见文本），仅在无可访问名称且选择器稳定时用原始选择器。
限制与收尾：自定义步骤仅用于真实缺口，需先说明已考虑的组合为何不可行。用项目 Cucumber 命令运行保存的 feature，诊断失败原因而非直接改期望。确认每个场景有明确前置、有意义动作与结果；每个步骤表达式已注册；每个定位器指向唯一目标；保存的 feature 在项目中通过。若执行受阻，保留测试目标形态并指出缺失的应用、数据或运行时依赖。当任务主要是实时浏览器调查而非编写持久测试时，应使用 letsrunit 本身。