Paths: File paths (
shared/
,
references/
,
../ln-*
) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

路径： 文件路径（
shared/
、
references/
、
../ln-*
）是相对于技能仓库根目录的路径。如果在当前工作目录下找不到，请找到此SKILL.md所在目录，向上跳转一级即为仓库根目录。

Automated Test Planner

自动化测试规划器

Creates Story test task with comprehensive automated test coverage (E2E/Integration/Unit) based on Risk-Based Testing methodology and REAL manual testing results.

基于基于风险的测试方法和真实的手动测试结果，生成包含全面自动化测试覆盖（E2E/集成/单元测试）的需求测试任务。

Purpose & Scope

用途与适用范围

Create comprehensive test task for Story automation
Calculate risk-based priorities (Impact x Probability)
Generate 11-section test plan from manual test results
Delegate to ln-301-task-creator (CREATE) or ln-302-task-replanner (REPLAN)
NOT for: manual testing (ln-522), research (ln-521), orchestration (ln-520)

生成用于需求自动化测试的全面测试任务
计算基于风险的优先级（影响度 × 发生概率）
根据手动测试结果生成 11个模块的测试计划
委派任务 至ln-301-task-creator（新建模式）或ln-302-task-replanner（重规划模式）
不适用于：手动测试（ln-522）、调研（ln-521）、流程编排（ln-520）

When to Use This Skill

何时使用此技能

This skill should be used when:

Invoked by ln-520-test-planner after ln-521 research and ln-522 manual testing
All implementation tasks in Story are Done
Manual testing results documented in Linear comment (from ln-522)
Research findings available in Linear comment (from ln-521)

Prerequisites:

All implementation Tasks in Story status = Done
ln-521-test-researcher completed (research comment exists)
ln-522-manual-tester completed (manual test results in Linear comment)

Automation: Supports

autoApprove: true

(default when invoked by ln-520) to skip manual confirmation.

满足以下条件时应使用此技能：

由ln-520-test-planner调用，且已完成ln-521调研和ln-522手动测试
需求下所有实现任务均已完成
手动测试结果已记录在Linear评论中（来自ln-522）
调研结果已记录在Linear评论中（来自ln-521）

前置条件：

需求下所有实现任务状态 = 已完成
ln-521-test-researcher已完成（存在调研评论）
ln-522-manual-tester已完成（Linear评论中存在手动测试结果）

自动化： 支持

autoApprove: true

（由ln-520调用时默认开启），可跳过人工确认。

When NOT to Use

何时不应使用

Do NOT use if:

Manual testing NOT completed -> Wait for ln-522
Research NOT completed -> Wait for ln-521
Implementation tasks NOT all Done -> Complete impl tasks first

出现以下情况时请勿使用：

手动测试未完成 -> 等待ln-522执行完成
调研未完成 -> 等待ln-521执行完成
实现任务未全部完成 -> 先完成所有实现任务

Workflow

工作流程

Phase 1: Discovery (Automated)

阶段1：信息发现（自动化）

Auto-discovers Team ID from

docs/tasks/kanban_board.md

(see CLAUDE.md "Configuration Auto-Discovery").

Input: Story ID from orchestrator (ln-520)

自动从

docs/tasks/kanban_board.md

获取团队ID（参考CLAUDE.md「配置自动发现」章节）。

输入： 来自编排器（ln-520）的需求ID

Phase 2: Story + Tasks Analysis (NO Dialog)

阶段2：需求+任务分析（无对话）

Step 0: Study Project Test Files

Scan for test-related files:
- tests/README.md (commands, setup, environment)
- Test configs (jest.config.js, vitest.config.ts, pytest.ini)
- Existing test structure (tests/, tests/ directories)
- Coverage config (.coveragerc, coverage.json)
Extract: test commands, framework, patterns, coverage thresholds
Ensures test planning aligns with project practices

Step 1: Load Research and Manual Test Results

Fetch Story from Linear (must have label "user-story")
Extract Story.id (UUID) - Use UUID, NOT short ID (required for Linear API)
Load research comment (from ln-521): "## Test Research: {Feature}"
Load manual test results comment (from ln-522): "## Manual Testing Results"
- If not found -> ERROR: Run ln-520-test-planner pipeline first
Parse sections: AC results (PASS/FAIL), Edge Cases, Error Handling, Integration flows
Map to test design: PASSED AC -> E2E, Edge cases -> Unit, Errors -> Error handling, Flows -> Integration

Step 2: Analyze Story + Tasks

Parse Story: Goal, Test Strategy, Technical Notes
Fetch all child Tasks (parentId = Story.id, status = Done) from Linear
Analyze each Task:
- Components implemented
- Business logic added
- Integration points created
- Conditional branches (if/else/switch)
Identify what needs testing

步骤0：研究项目测试文件

扫描测试相关文件：
- tests/README.md（命令、配置、环境）
- 测试配置文件（jest.config.js, vitest.config.ts, pytest.ini）
- 现有测试结构（tests/, tests/ 目录）
- 覆盖率配置（.coveragerc, coverage.json）
提取：测试命令、框架、规范、覆盖率阈值
确保测试规划符合项目实践规范

步骤1：加载调研和手动测试结果

从Linear获取需求（必须带有「user-story」标签）
提取Story.id（UUID）- 使用UUID，不要使用短ID（Linear API要求）
加载调研评论（来自ln-521）：「## Test Research: {Feature}」
加载手动测试结果评论（来自ln-522）：「## Manual Testing Results」
- 未找到 -> 错误：请先运行ln-520-test-planner流水线
解析模块：验收标准结果（通过/失败）、边界用例、错误处理、集成流程
映射到测试设计：通过的验收标准 -> E2E、边界用例 -> 单元测试、错误场景 -> 错误处理、流程 -> 集成测试

步骤2：分析需求+任务

解析需求：目标、测试策略、技术说明
从Linear获取所有子任务（parentId = Story.id，状态 = 已完成）
分析每个任务：
- 实现的组件
- 新增的业务逻辑
- 创建的集成点
- 条件分支（if/else/switch）
识别需要测试的内容

Phase 3: Parsing Strategy for Manual Test Results

阶段3：手动测试结果解析策略

Process: Locate Linear comment with "Manual Testing Results" header -> Verify Format Version 1.0 -> Extract structured sections (Acceptance Criteria, Test Results by AC, Edge Cases, Error Handling, Integration Testing) using regex -> Validate (at least 1 PASSED AC, AC count matches Story, completeness check) -> Map parsed data to test design structure

Error Handling: Missing comment -> ERROR (run ln-522 first), Missing format version -> WARNING (try legacy parsing), Required section missing -> ERROR (re-run ln-522), No PASSED AC -> ERROR (fix implementation)

流程： 定位带有「Manual Testing Results」标题的Linear评论 -> 验证格式版本1.0 -> 使用正则提取结构化模块（验收标准、按验收标准拆分的测试结果、边界用例、错误处理、集成测试） -> 校验（至少1条验收标准通过、验收标准数量与需求匹配、完整性检查） -> 将解析后的数据映射到测试设计结构

错误处理： 缺失评论 -> 错误（先运行ln-522）、缺失格式版本 -> 警告（尝试兼容旧格式解析）、缺失必填模块 -> 错误（重新运行ln-522）、无通过的验收标准 -> 错误（修复实现代码）

Phase 4: Risk-Based Test Planning (Automated)

阶段4：基于风险的测试规划（自动化）

MANDATORY READ: Load

references/risk_based_testing_guide.md

for complete methodology.

E2E-First Approach: Prioritize by business risk (Priority = Impact x Probability), not coverage metrics.

Workflow:

Step 1: Risk Assessment

Calculate Priority for each scenario from manual testing:

Priority = Business Impact (1-5) x Probability (1-5)

Decision Criteria:

Priority >=15 -> MUST test
Priority 9-14 -> SHOULD test if not covered
Priority <=8 -> SKIP (manual testing sufficient)

Step 2: E2E Test Selection (2-5): Baseline 2 (positive + negative) ALWAYS + 0-3 additional (Priority >=15 only)

Step 3: Unit Test Selection (0-15): DEFAULT 0. Add ONLY for complex business logic (Priority >=15): financial, security, algorithms

Step 4: Integration Test Selection (0-8): DEFAULT 0. Add ONLY if E2E gaps AND Priority >=15: rollback, concurrency, external API errors

Step 5: Validation: Limits 2-28 total (realistic goal: 2-7). Auto-trim if >7 (keep 2 baseline + top 5 by Priority)

必读要求： 加载

references/risk_based_testing_guide.md

查看完整方法论。

E2E优先原则： 按业务风险排序（优先级 = 影响度 × 发生概率），而非覆盖率指标。

工作流程：

步骤1：风险评估

为每个手动测试场景计算优先级：

Priority = Business Impact (1-5) x Probability (1-5)

判定标准：

优先级 >=15 -> 必须测试
优先级 9-14 -> 如果未覆盖则应该测试
优先级 <=8 -> 跳过（手动测试已足够）

步骤2：E2E测试选择（2-5个）： 始终保留2个基础用例（正向+反向）+ 0-3个额外用例（仅优先级>=15的场景）

步骤3：单元测试选择（0-15个）： 默认0个。仅为复杂业务逻辑新增（优先级>=15）：金融、安全、算法相关逻辑

步骤4：集成测试选择（0-8个）： 默认0个。仅当E2E存在覆盖缺口且优先级>=15时新增：回滚、并发、外部API错误场景

步骤5：校验： 总用例限制2-28个（合理目标：2-7个）。如果超过7个自动裁剪（保留2个基础用例 + 优先级最高的5个）

Phase 5: Test Task Generation (Automated)

阶段5：测试任务生成（自动化）

Generates complete test task per

test_task_template.md

(11 sections):

Sections 1-7: Context, Risk Matrix, E2E/Integration/Unit Tests (with Priority scores + justifications), Coverage, DoD

Section 8: Existing Tests to Fix (analysis of affected tests from implementation tasks)

Section 9: Infrastructure Changes (packages, Docker, configs - based on test dependencies)

Section 10: Documentation Updates (README, CHANGELOG, tests/README, config docs)

Section 11: Legacy Code Cleanup (deprecated patterns, backward compat, dead code)

Shows preview for review.

按照

test_task_template.md

生成完整的测试任务（11个模块）：

模块1-7： 上下文、风险矩阵、E2E/集成/单元测试（含优先级得分 + 依据）、覆盖率、完成定义

模块8： 需要修复的现有测试（分析实现任务影响的测试）

模块9： 基础设施变更（依赖包、Docker、配置 - 基于测试依赖）

模块10： 文档更新（README、CHANGELOG、tests/README、配置文档）

模块11： 遗留代码清理（废弃规范、向后兼容、死代码）

展示预览供审核。

Phase 6: Confirmation & Delegation

阶段6：确认与委派

Step 1: Preview generated test plan (always displayed for transparency)

Step 2: Confirmation logic:

autoApprove: true (default from ln-520) -> proceed automatically
Manual run -> prompt user to type "confirm"

Step 3: Check for existing test task

Query Linear:

list_issues(parentId=Story.id, labels=["tests"])

Decision:

Count = 0 -> CREATE MODE (Step 4a)
Count >= 1 -> REPLAN MODE (Step 4b)

Step 4a: CREATE MODE (if Count = 0)

Invoke ln-301-task-creator worker with taskType: "test"

Pass to worker:

taskType, teamId, storyData (Story.id, title, AC, Technical Notes, Context)
researchFindings (from ln-521 comment)
manualTestResults (from ln-522 comment)
testPlan (e2eTests, integrationTests, unitTests, riskPriorityMatrix)
infrastructureChanges, documentationUpdates, legacyCleanup

Worker returns: Task URL + summary

Step 4b: REPLAN MODE (if Count >= 1)

Invoke ln-302-task-replanner worker with taskType: "test"

Pass to worker:

Same data as CREATE MODE + existingTaskIds

Worker returns: Operations summary + warnings

Step 5: Return summary to orchestrator (ln-520)

步骤1： 预览生成的测试计划（为保证透明度始终展示）

步骤2： 确认逻辑：

autoApprove: true（ln-520调用时默认开启）-> 自动继续
手动运行 -> 提示用户输入「confirm」确认

步骤3： 检查是否存在现有测试任务

查询Linear：

list_issues(parentId=Story.id, labels=["tests"])

判定：

数量 = 0 -> 新建模式（步骤4a）
数量 >=1 -> 重规划模式（步骤4b）

步骤4a：新建模式（数量=0时）

调用ln-301-task-creator工作模块，taskType设为「test」

传递给工作模块的参数：

taskType、teamId、storyData（Story.id、标题、验收标准、技术说明、上下文）
researchFindings（来自ln-521评论）
manualTestResults（来自ln-522评论）
testPlan（e2eTests、integrationTests、unitTests、riskPriorityMatrix）
infrastructureChanges、documentationUpdates、legacyCleanup

工作模块返回： 任务URL + 摘要

步骤4b：重规划模式（数量>=1时）

调用ln-302-task-replanner工作模块，taskType设为「test」

传递给工作模块的参数：

与新建模式相同的参数 + existingTaskIds

工作模块返回： 操作摘要 + 警告

步骤5： 返回摘要给编排器（ln-520）

Definition of Done

完成定义

Reference Files

参考文件

Risk-based testing methodology:

shared/references/risk_based_testing_guide.md

Auto-discovery patterns:

shared/references/auto_discovery_pattern.md

基于风险的测试方法论：

shared/references/risk_based_testing_guide.md

自动发现规范：

shared/references/auto_discovery_pattern.md

risk_based_testing_guide.md

Purpose: Risk-Based Testing methodology (detailed guide)

Location: references/risk_based_testing_guide.md

用途：基于风险的测试方法论（详细指南）

位置： references/risk_based_testing_guide.md

test_task_template.md (CENTRALIZED)

test_task_template.md（统一管理）

Location:

shared/templates/test_task_template.md

Usage: Workers (ln-301, ln-302) load via Template Loading logic

位置：

shared/templates/test_task_template.md

用法： 工作模块（ln-301、ln-302）通过模板加载逻辑读取

Critical Rules

关键规则

Manual results required: Never plan tests without ln-522 manual testing results — guessing coverage is worse than no tests
E2E-first, not unit-first: Baseline is always 2 E2E (positive + negative); unit/integration added only for Priority >= 15
No framework testing: Every test must validate OUR business logic; never test library/framework behavior
Auto-trim enforcement: If total tests exceed 7, auto-trim to baseline 2 + top 5 by Priority score
Delegate, don't create: Task creation goes through ln-301/ln-302 workers; this skill generates the plan only

必须提供手动测试结果： 没有ln-522的手动测试结果绝对不能规划测试 — 猜测覆盖范围比没有测试更差
E2E优先，而非单元测试优先： 基础用例始终为2个E2E测试（正向+反向）；仅为优先级>=15的场景新增单元/集成测试
不测试框架： 每个测试必须验证我方业务逻辑；绝对不要测试库/框架的行为
强制自动裁剪： 如果总测试用例超过7个，自动裁剪为2个基础用例 + 优先级最高的5个
仅委派不创建： 任务创建通过ln-301/ln-302工作模块执行；此技能仅生成测试计划

Best Practices

最佳实践

Minimum Viable Testing: Start with 2 E2E tests (positive + negative). Add more ONLY with critical justification. Realistic goal: 2-7 tests per Story.

Risk-Based Testing: Prioritize by Business Impact x Probability. E2E-first from ACTUAL manual testing results. Priority >=15 scenarios covered by tests.

Expected-Based Testing: For deterministic tests, compare actual vs expected using

diff

. MANDATORY READ: Load

../ln-522-manual-tester/SKILL.md

— section "Test Design Principles".

Version: 1.0.0 Last Updated: 2026-01-15

最小可行测试： 从2个E2E测试（正向+反向）开始。仅在有关键依据时新增更多用例。合理目标：每个需求2-7个测试。

基于风险的测试： 按业务影响度 × 发生概率排序。基于真实手动测试结果优先做E2E测试。优先级>=15的场景必须被测试覆盖。

预期值对比测试： 对于确定性测试，使用

diff

对比实际输出与预期输出。必读： 加载

../ln-522-manual-tester/SKILL.md

— 「测试设计原则」章节。

版本： 1.0.0 最后更新： 2026-01-15

ln-523-auto-test-planner

Original

Translation

Automated Test Planner

自动化测试规划器

Purpose & Scope

用途与适用范围

When to Use This Skill

何时使用此技能

When NOT to Use

何时不应使用

Workflow

工作流程

Phase 1: Discovery (Automated)

阶段1：信息发现（自动化）

Phase 2: Story + Tasks Analysis (NO Dialog)

阶段2：需求+任务分析（无对话）

Phase 3: Parsing Strategy for Manual Test Results

阶段3：手动测试结果解析策略

Phase 4: Risk-Based Test Planning (Automated)

阶段4：基于风险的测试规划（自动化）

Phase 5: Test Task Generation (Automated)

阶段5：测试任务生成（自动化）

Phase 6: Confirmation & Delegation

阶段6：确认与委派

Definition of Done

完成定义

Reference Files

参考文件

risk_based_testing_guide.md

risk_based_testing_guide.md

test_task_template.md (CENTRALIZED)

test_task_template.md（统一管理）

Critical Rules

关键规则

Best Practices

最佳实践