@tea-agent/loop-agent 0.13.0 → 0.14.0

package/skills/playwright-cli-case-generator/SKILL.md

@@ -1,74 +1,74 @@
----
-name: playwright-cli-case-generator
-description: 根据 FE-test RAG 知识包生成可由 playwright-cli 串行执行的前端功能测试用例、索引和 case manifest。
----
-
-# Playwright Test Generator
-
-仅用于 FE-test DAG 的 `generate-frontend-functional-cases-pi`。本 skill
-生成中文 Markdown 测试用例和 `manifest.json`，不执行浏览器、不生成
-Playwright/Pytest 源码，也不修改被测应用。
-
-## 输入与边界
-
-- 只读取 `testcase/frontend/rag/context.md`、`coverage-map.md` 与已有
-  `testcase/frontend/cases/`。
-- 只写 `testcase/frontend/cases/**`；不得回读 PRD、读取 `.harness/`，或写
-  `testcase/frontend/evidence/**`。
-- 所有 API、字段限制、状态流转、数据来源、SLA、URL 与账号要求必须能在
-  RAG 知识包中追溯。缺失信息标记 `blocked` 或“需人工确认”，不得猜测。
-
-## 输出
-
-- 写 `index.md`、`manifest.json` 与独立 case 文件
-  `FE-<FEATURE>-<NNN>-<dimension>.md`；`dimension` 仅为 `core`、`boundary`、
-  `flow` 或 `backend`。
-- `manifest.json` 使用 `schemaVersion: 1`，每项只含 `caseId`、`casePath`、
-  `dimension`、`acIds`、`evidenceDir`。所有 ID、路径和 evidenceDir 必须唯一，
-  并位于 `testcase/frontend/` 内。
-- `index.md` 按功能点列出 case、维度、AC、数据依赖、API 映射和预期执行状态。
-
-每个 case 必须包含：
-
-1. 元信息：功能、CRUD 分类、维度、关联 AC、RAG 来源、API 映射状态与数据策略。
-2. 前置条件：独立 `-s=<case-id>` session、登录状态、fixture/存量数据、清理责任。
-3. 可独立执行的命令序列：`open --browser=chrome --headed <base-url>`、按需登录/数据准备、
-   `snapshot` 后优先使用元素引用、操作、UI 断言、可选 API 断言、cleanup、`close`。
-4. 明确的 UI/API 预期与数据清理结果；无法满足的环境或数据依赖必须写为 `blocked`。
-
-所有 snapshot、screenshot、trace 和 video 命令必须指向执行节点提供的
-`testcase/frontend/evidence/<case-id>/` 工作目录。命令必须使用现有
-`playwright-cli` skill 已声明的接口；不要生成 `requests --clear`、
-`request-body` 或 `response-body`。
-
-## 覆盖矩阵
-
-| CRUD 类型 | 必选 | 条件 |
-| --- | --- | --- |
-| C-新增 | `core`、`boundary` | 有状态流转时 `flow`；有 API 映射时 `backend` |
-| R-查询 | `core` | 有搜索/筛选输入时 `boundary`；有 API 映射时 `backend` |
-| U-修改 | `core`、`boundary` | 有状态流转时 `flow`；有 API 映射时 `backend` |
-| D-删除 | `core` | 有 API 映射时 `backend` |
-
-- `boundary` 只从已知必填、长度、范围、精度、枚举或字符规则推导；无约束时
-  不伪造边界值。
-- `flow` 是自包含的多步状态旅程；每个关键步骤都有 UI 与已知数据一致性断言，
-  不依赖其他 case 创建的数据。
-- `backend` 只在 API 映射存在时使用 `requests` / `request <id>`，或在精确时序
-  下使用 `run-code`。错误、空态或超时使用 `route`，并在 cleanup 中 `unroute`。
-  响应字段和性能阈值必须来自 RAG。
-
-## 数据策略
-
-- C-新增优先使用需求中给出的测试数据；仅在已授权 API 映射存在时才描述临时构造
-  与清理。
-- R/U/D 优先使用知识包登记的 fixture 或 test-data；不足时只能使用已授权的
-  测试环境 API 注入并清理。
-- 禁止使用生产 URL、真实用户凭据或不可清理的数据写入。无法证明隔离与清理时，
-  case 必须为 `blocked`。
-
-## 交接
-
-生成结束时仅返回紧凑 JSON 摘要：case 总数、各维度数量、manifest 相对路径、
-blocked case ID 与原因。详细内容保留在 case 文件，供后续 manifest/map 子节点
-逐 case 读取，避免把完整用例塞进上游上下文。
+---
+name: playwright-cli-case-generator
+description: 根据 FE-test RAG 知识包生成可由 playwright-cli 串行执行的前端功能测试用例、索引和 case manifest。
+---
+
+# Playwright Test Generator
+
+仅用于 FE-test DAG 的 `generate-frontend-functional-cases-pi`。本 skill
+生成中文 Markdown 测试用例和 `manifest.json`，不执行浏览器、不生成
+Playwright/Pytest 源码，也不修改被测应用。
+
+## 输入与边界
+
+- 只读取 `testcase/frontend/rag/context.md`、`coverage-map.md` 与已有
+  `testcase/frontend/cases/`。
+- 只写 `testcase/frontend/cases/**`；不得回读 PRD、读取 `.harness/`，或写
+  `testcase/frontend/evidence/**`。
+- 所有 API、字段限制、状态流转、数据来源、SLA、URL 与账号要求必须能在
+  RAG 知识包中追溯。缺失信息标记 `blocked` 或“需人工确认”，不得猜测。
+
+## 输出
+
+- 写 `index.md`、`manifest.json` 与独立 case 文件
+  `FE-<FEATURE>-<NNN>-<dimension>.md`；`dimension` 仅为 `core`、`boundary`、
+  `flow` 或 `backend`。
+- `manifest.json` 使用 `schemaVersion: 1`，每项只含 `caseId`、`casePath`、
+  `dimension`、`acIds`、`evidenceDir`。所有 ID、路径和 evidenceDir 必须唯一，
+  并位于 `testcase/frontend/` 内。
+- `index.md` 按功能点列出 case、维度、AC、数据依赖、API 映射和预期执行状态。
+
+每个 case 必须包含：
+
+1. 元信息：功能、CRUD 分类、维度、关联 AC、RAG 来源、API 映射状态与数据策略。
+2. 前置条件：独立 `-s=<case-id>` session、登录状态、fixture/存量数据、清理责任。
+3. 可独立执行的命令序列：`open --browser=chrome --headed <base-url>`、按需登录/数据准备、
+   `snapshot` 后优先使用元素引用、操作、UI 断言、可选 API 断言、cleanup、`close`。
+4. 明确的 UI/API 预期与数据清理结果；无法满足的环境或数据依赖必须写为 `blocked`。
+
+所有 snapshot、screenshot、trace 和 video 命令必须指向执行节点提供的
+`testcase/frontend/evidence/<case-id>/` 工作目录。命令必须使用现有
+`playwright-cli` skill 已声明的接口；不要生成 `requests --clear`、
+`request-body` 或 `response-body`。
+
+## 覆盖矩阵
+
+| CRUD 类型 | 必选 | 条件 |
+| --- | --- | --- |
+| C-新增 | `core`、`boundary` | 有状态流转时 `flow`；有 API 映射时 `backend` |
+| R-查询 | `core` | 有搜索/筛选输入时 `boundary`；有 API 映射时 `backend` |
+| U-修改 | `core`、`boundary` | 有状态流转时 `flow`；有 API 映射时 `backend` |
+| D-删除 | `core` | 有 API 映射时 `backend` |
+
+- `boundary` 只从已知必填、长度、范围、精度、枚举或字符规则推导；无约束时
+  不伪造边界值。
+- `flow` 是自包含的多步状态旅程；每个关键步骤都有 UI 与已知数据一致性断言，
+  不依赖其他 case 创建的数据。
+- `backend` 只在 API 映射存在时使用 `requests` / `request <id>`，或在精确时序
+  下使用 `run-code`。错误、空态或超时使用 `route`，并在 cleanup 中 `unroute`。
+  响应字段和性能阈值必须来自 RAG。
+
+## 数据策略
+
+- C-新增优先使用需求中给出的测试数据；仅在已授权 API 映射存在时才描述临时构造
+  与清理。
+- R/U/D 优先使用知识包登记的 fixture 或 test-data；不足时只能使用已授权的
+  测试环境 API 注入并清理。
+- 禁止使用生产 URL、真实用户凭据或不可清理的数据写入。无法证明隔离与清理时，
+  case 必须为 `blocked`。
+
+## 交接
+
+生成结束时仅返回紧凑 JSON 摘要：case 总数、各维度数量、manifest 相对路径、
+blocked case ID 与原因。详细内容保留在 case 文件，供后续 manifest/map 子节点
+逐 case 读取，避免把完整用例塞进上游上下文。

package/skills/requesting-code-review/SKILL.md

@@ -1,101 +1,101 @@
----
-name: requesting-code-review
-description: 在完成任务、实现 major features，或 merge 前验证 work 是否满足 requirements 时使用
----
-
-# Requesting Code Review
-
-Dispatch code reviewer subagent，在问题级联前捕获 issue。Reviewer 获得精确 crafted 的 evaluation context — 绝不是你的 session history。这使 reviewer 聚焦 work product，而非你的 thought process，并保留你自己的 context 以继续工作。
-
-**Core principle：** Review early, review often.
-
-## When to Request Review
-
-**Mandatory：**
-- subagent-driven development 中每个 task 之后
-- 完成 major feature 之后
-- merge 到 main 之前
-
-**Optional but valuable：**
-- 卡住时（fresh perspective）
-- refactoring 前（baseline check）
-- 修复 complex bug 之后
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Use the code reviewer template**（本 skill 目录下的 `code-reviewer.md`）：
-
-**Placeholders:**
-- `{DESCRIPTION}` — 简要 summary of what you built
-- `{PLAN_OR_REQUIREMENTS}` — 它应做什么（contract、exec plan 或 requirements）
-- `{BASE_SHA}` — Starting commit
-- `{HEAD_SHA}` — Ending commit
-
-**3. Act on feedback:**
-- Critical issues 立即修复
-- Important issues 在继续前修复
-- Minor issues 稍后处理
-- Reviewer 有误时 push back（附 reasoning）
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-You: Let me request code review before proceeding.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Dispatch code reviewer subagent]
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-  PLAN_OR_REQUIREMENTS: Task 2 from ai_workspace/loop-agent/exec-plans/active/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with Harness Workflow
-
-**每个 work chunk 之后（Plan → Contract → Implement → Verify → Handoff）：**
-- Implement 之后、Verify 之前 review
-- 在问题 compound 前捕获
-- 进入 next task 前修复
-
-**Before merge / Handoff：**
-- 宣称 complete 前 review
-- 对照 contract acceptance criteria 验证
-
-**Ad-Hoc Development：**
-- merge 前 review
-- 卡住时 review
-
-## Red Flags
-
-**Never：**
-- 因 "it's simple" 跳过 review
-- 忽略 Critical issues
-- 带着未修复的 Important issues 继续
-- 与 valid technical feedback 争辩
-
-**If reviewer wrong：**
-- 用 technical reasoning push back
-- 展示证明其有效的 code/tests
-- 请求 clarification
-
-Template 见：requesting-code-review/code-reviewer.md
+---
+name: requesting-code-review
+description: 在完成任务、实现 major features，或 merge 前验证 work 是否满足 requirements 时使用
+---
+
+# Requesting Code Review
+
+Dispatch code reviewer subagent，在问题级联前捕获 issue。Reviewer 获得精确 crafted 的 evaluation context — 绝不是你的 session history。这使 reviewer 聚焦 work product，而非你的 thought process，并保留你自己的 context 以继续工作。
+
+**Core principle：** Review early, review often.
+
+## When to Request Review
+
+**Mandatory：**
+- subagent-driven development 中每个 task 之后
+- 完成 major feature 之后
+- merge 到 main 之前
+
+**Optional but valuable：**
+- 卡住时（fresh perspective）
+- refactoring 前（baseline check）
+- 修复 complex bug 之后
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Use the code reviewer template**（本 skill 目录下的 `code-reviewer.md`）：
+
+**Placeholders:**
+- `{DESCRIPTION}` — 简要 summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` — 它应做什么（contract、exec plan 或 requirements）
+- `{BASE_SHA}` — Starting commit
+- `{HEAD_SHA}` — Ending commit
+
+**3. Act on feedback:**
+- Critical issues 立即修复
+- Important issues 在继续前修复
+- Minor issues 稍后处理
+- Reviewer 有误时 push back（附 reasoning）
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code reviewer subagent]
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  PLAN_OR_REQUIREMENTS: Task 2 from ai_workspace/loop-agent/exec-plans/active/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Harness Workflow
+
+**每个 work chunk 之后（Plan → Contract → Implement → Verify → Handoff）：**
+- Implement 之后、Verify 之前 review
+- 在问题 compound 前捕获
+- 进入 next task 前修复
+
+**Before merge / Handoff：**
+- 宣称 complete 前 review
+- 对照 contract acceptance criteria 验证
+
+**Ad-Hoc Development：**
+- merge 前 review
+- 卡住时 review
+
+## Red Flags
+
+**Never：**
+- 因 "it's simple" 跳过 review
+- 忽略 Critical issues
+- 带着未修复的 Important issues 继续
+- 与 valid technical feedback 争辩
+
+**If reviewer wrong：**
+- 用 technical reasoning push back
+- 展示证明其有效的 code/tests
+- 请求 clarification
+
+Template 见：requesting-code-review/code-reviewer.md