positron-qa-verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Positron QA Verify

This skill analyzes GitHub issues and their associated PRs to generate comprehensive verification guides for manual QA testing. It extracts the essential information from issues, comments, linked PRs, and code changes to produce clear test scenarios.

此技能会分析GitHub Issue及其关联的PR，为手动QA测试生成全面的验证指南。它从Issue、评论、关联PR和代码变更中提取关键信息，生成清晰的测试场景。

When to Use This Skill

何时使用此技能

Use this skill when:

You're assigned a ticket from the QA verification board (https://github.com/orgs/posit-dev/projects/2/views/8)
You need to understand what to test for a specific bug fix or feature
You want to extract test scenarios from an issue and its related PRs
You need to identify all edge cases and related scenarios mentioned in comments

在以下场景使用此技能：

你从QA验证看板（https://github.com/orgs/posit-dev/projects/2/views/8）领取了工单
你需要了解针对特定Bug修复或功能的测试内容
你希望从Issue及其关联PR中提取测试场景
你需要识别评论中提到的所有边缘情况和相关场景

Prerequisites

前提条件

GitHub CLI (
```
gh
```
) installed and authenticated
Working in the Positron repository
Access to the posit-dev/positron repository

已安装并认证GitHub CLI（
```
gh
```
）
在Positron仓库中工作
有权限访问posit-dev/positron仓库

Execution Mode

执行模式

CRITICAL: This skill MUST run non-interactively without ANY prompts.

NEVER use
AskUserQuestion
- The skill always writes to a safe output directory (
```
.claude/skills/positron-qa-verify/output/
```
)
Version auto-detection is best-effort - If it fails, silently use empty values. The user can fill them in manually.
All operations must complete quickly - Fail fast if data cannot be retrieved within reasonable timeouts
No permission requests - Reading issue data, writing markdown files, and running version detection do not require special permissions

Performance requirements:

Version detection must complete in ≤4 seconds total (enforced by script timeouts)
If version detection times out or fails, continue without error messages
Never attempt interactive detection methods (no manual path prompts, no user input)

Windows compatibility:

The
```
detect_versions.sh
```
script handles Windows paths via Git Bash/MSYS/PowerShell
Falls back gracefully if Positron installation path cannot be found
Uses multiple detection methods to maximize success rate across platforms

重要提示：此技能必须以非交互模式运行，不得出现任何提示。

绝对不要使用
AskUserQuestion
- 技能始终将内容写入安全的输出目录（
```
.claude/skills/positron-qa-verify/output/
```
）
版本自动检测为尽力而为 - 如果检测失败，静默使用空值。用户可手动填写。
所有操作必须快速完成 - 如果无法在合理超时时间内获取数据，立即终止
无需请求权限 - 读取Issue数据、编写Markdown文件和运行版本检测不需要特殊权限

性能要求：

版本检测必须在≤4秒内完成（由脚本超时机制强制执行）
如果版本检测超时或失败，继续执行且不显示错误信息
绝对不要尝试交互式检测方法（无手动路径提示，无用户输入）

Windows兼容性：

```
detect_versions.sh
```
脚本通过Git Bash/MSYS/PowerShell处理Windows路径
如果无法找到Positron安装路径，会优雅降级
使用多种检测方法以提升跨平台成功率

Input

输入

Provide an issue number or URL. Examples:

```
4567
```
```
#4567
```

https://github.com/posit-dev/positron/issues/4567

提供Issue编号或URL。示例：

```
4567
```
```
#4567
```

https://github.com/posit-dev/positron/issues/4567

Workflow

工作流程

I'll analyze the issue and generate a verification guide following these steps:

我会按照以下步骤分析Issue并生成验证指南：

Performance Optimization Strategy

性能优化策略

CRITICAL: Use parallel execution wherever possible to minimize latency.

Step 1 & 2 run in parallel - Issue details and PR search are independent
Step 3 fetches run in parallel - Related PRs/issues are fetched concurrently
Step 4 checks size first - Only fetch diff for small PRs (<500 lines)

Total time savings: ~40-50% faster than sequential execution (5-8s vs 10-15s typical)

重要提示：尽可能使用并行执行以减少延迟。

步骤1和步骤2并行运行 - Issue详情和PR搜索相互独立
步骤3的获取操作并行执行 - 关联PR/Issue的获取同时进行
步骤4先检查大小 - 仅对小型PR（<500行）获取差异内容

总时间节省：比顺序执行快约40-50%（通常为5-8秒 vs 10-15秒）

Step 1: Fetch Issue Details (Parallel with Step 2)

步骤1：获取Issue详情（与步骤2并行）

MUST RUN IN PARALLEL with Step 2 using a single message with multiple Bash tool calls.

Using

gh issue view

, I'll retrieve:

Issue title and description
Reporter's repro steps
All comments (which often contain additional test scenarios)
Labels and metadata
Linked issues

必须与步骤2并行运行，在一条消息中调用多个Bash工具：

使用

gh issue view

，我将获取：

Issue标题和描述
报告者的复现步骤
所有评论（通常包含额外测试场景）
标签和元数据
关联的Issue

Step 2: Identify Related PR(s) (Parallel with Step 1)

步骤2：识别关联PR（与步骤1并行）

MUST RUN IN PARALLEL with Step 1 using a single message with multiple Bash tool calls.

I'll automatically detect the PR that fixes this issue by:

Looking for PR references in issue comments (e.g., "Fixed in #1234")
Checking for timeline events linking PRs
Using
```
gh pr list
```
with issue filter if needed

If multiple PRs are found, I'll analyze all of them.

必须与步骤1并行运行，在一条消息中调用多个Bash工具：

我会通过以下方式自动检测修复此Issue的PR：

查找Issue评论中的PR引用（例如："Fixed in #1234"）
检查时间线事件中关联的PR
如有需要，使用
```
gh pr list
```
并结合Issue过滤器

如果找到多个PR，我会全部分析。

Step 3: Analyze PR Context

步骤3：分析PR上下文

OPTIMIZATION: Fetch primary PR details first, then fetch all related PRs/issues in parallel.

For the primary PR, I'll fetch:

PR description and summary
All PR comments (often contain testing notes)
Additions and deletions counts (needed for Step 4 size check)
Related PRs/issues mentioned in the body

Then, for all related PRs/issues referenced, I'll fetch them in parallel using multiple Bash tool calls in a single message.

优化： 先获取主PR详情，再并行获取所有关联PR/Issue。

对于主PR，我将获取：

PR描述和摘要
所有PR评论（通常包含测试说明）
新增和删除代码行数统计（步骤4的大小检查需要此数据）
PR正文中提到的关联PR/Issue

然后，对于所有引用的关联PR/Issue，我会在一条消息中调用多个Bash工具并行获取。

Step 4: Review Code Changes (Conditionally)

步骤4：查看代码变更（有条件执行）

OPTIMIZATION: Check PR size from Step 3 data (additions + deletions) BEFORE fetching diff.

For small PRs (< 500 lines changed):

I'll use
```
gh pr diff
```
to review actual code changes
This helps identify:
- Edge cases to test
- Related functionality that might be affected
- Whether the fix is focused or touches multiple areas

For large PRs (>= 500 lines):

I'll skip detailed code review (don't fetch diff at all)
Focus on PR description and comments instead
Saves 1-5 seconds by avoiding large diff download

优化： 在获取差异内容前，先通过步骤3的数据检查PR大小（新增+删除行数）。

对于小型PR（变更行数<500）：

我会使用
```
gh pr diff
```
查看实际代码变更
这有助于识别：
- 需要测试的边缘情况
- 可能受影响的相关功能
- 修复是集中在特定区域还是涉及多个模块

对于大型PR（变更行数≥500）：

我会跳过详细代码审查（完全不获取差异内容）
重点关注PR描述和评论
通过避免下载大型差异内容，节省1-5秒时间

Step 5: Extract Linked Issues and Scenarios

步骤5：提取关联Issue和场景

I'll search comments for:

References to other issues (
```
#1234
```
)
Additional test scenarios mentioned by team members
Edge cases discovered during PR review
Platform-specific considerations (macOS, Windows, Linux)

我会在评论中搜索：

对其他Issue的引用（
```
#1234
```
）
团队成员提到的额外测试场景
PR审查中发现的边缘情况
平台特定注意事项（macOS、Windows、Linux）

Step 6: Generate Verification Guide

步骤6：生成验证指南

I'll create a markdown file in

.claude/skills/positron-qa-verify/output/

with:

Ticket Type (Bug, Feature, Documentation, Maintenance)
- Helps set testing expectations
- Determines whether Root Cause section is included
Issue Summary
- What changed or what was broken
- User impact (why this matters)
- Uses H4 subsections for readability
Root Cause (Bugs only)
- What was causing the issue
- Only included for bug fixes when clearly stated in PR
- Helps understand what might break again
Test Scenarios
- Scenario titles use checkmarks (✓) for visual organization
- Test steps within scenarios use checkboxes (- [ ]) for tracking progress
- Primary scenario (the main repro steps from the issue)
- Edge cases (from comments, PR review, code analysis) with "Why test:" rationale
- Regression checks (related functionality to verify still works)
- Platform-specific scenarios if mentioned
Testing Context
- Environment requirements (Python/R version, specific packages, etc.)
- Setup steps (if any)
- Expected vs actual behavior
- Related PRs to be aware of
References
- Link to original issue
- Link to PR(s)
- Links to related issues

我会在

.claude/skills/positron-qa-verify/output/

目录下创建一个Markdown文件，包含以下内容：

工单类型（Bug、功能、文档、维护）
- 帮助设定测试预期
- 决定是否包含根本原因部分
Issue摘要
- 变更内容或问题所在
- 用户影响（问题的重要性）
- 使用H4子标题提升可读性
根本原因（仅Bug修复）
- 问题的诱因
- 仅在PR中明确说明时，才会包含在Bug修复的指南中
- 帮助理解哪些部分可能再次出现问题
测试场景
- 场景标题使用对勾（✓）进行视觉区分
- 场景内的测试步骤使用复选框（- [ ]）以跟踪进度
- 主场景（Issue中的核心复现步骤）
- 边缘情况（来自评论、PR审查、代码分析）并附带“测试原因”说明
- 回归检查（验证相关功能仍可正常工作）
- 如提及则包含平台特定场景
测试上下文
- 环境要求（Python/R版本、特定包等）
- 设置步骤（如有）
- 预期行为 vs 实际行为
- 需要注意的关联PR
参考资料
- 原始Issue链接
- PR链接
- 关联Issue链接

Step 7: Offer Verification Comment Template (User-Triggered)

步骤7：提供验证评论模板（用户触发）

After generating the guide, I'll offer to create a verification comment template. Only if you accept will I run the version detection script and generate the template.

Workflow:

Generate verification guide
Offer: "Would you like me to generate a verification comment template?"
If yes → Run
```
detect_versions.sh
```
to auto-detect versions
Generate template and copy to clipboard

For single scenario tests (only 1 test, no edge cases or regressions), I'll use a simple format:

markdown

undefined

生成指南后，我会提供创建验证评论模板的选项。仅当你同意时，我才会运行版本检测脚本并生成模板。

工作流程：

生成验证指南
询问：“是否需要我生成验证评论模板？”
如果是 → 运行
```
detect_versions.sh
```
自动检测版本
生成模板并复制到剪贴板

对于单一场景测试（仅1个测试，无边缘情况或回归检查），我会使用简单格式：

markdown

undefined

Verified Fixed

已验证修复

Positron Version(s): [version] OS Version(s): [OS]

Test scenario(s)

[Single scenario]

[Single scenario]

Link(s) to test cases run or created:

[links or paths to e2e tests, or n/a]


For everything else (2+ scenarios, or any edge cases/regressions), I'll use a grouped format for better readability:

```markdown

[links or paths to e2e tests, or n/a]


对于其他情况（2个及以上场景，或包含任何边缘情况/回归检查），我会使用分组格式以提升可读性：

```markdown

Verified Fixed

已验证修复

Positron Version(s): [version] OS Version(s): [OS]

Test scenario(s)

Primary scenario:

[Main test scenario]

Edge cases:

[Edge case 1]
[Edge case 2]

Regression checks:

[Regression check 1]
[Regression check 2]

Primary scenario:

[Main test scenario]

Edge cases:

[Edge case 1]
[Edge case 2]

Regression checks:

[Regression check 1]
[Regression check 2]

Link(s) to test cases run or created:

[links or paths to e2e tests, or n/a]


**Note:** The verification comment uses plain bullets. Checkmarks (✓) and checkboxes (- [ ]) are only in the verification guide for visual organization and progress tracking during testing.

The template will be pre-filled with:
- Test scenarios extracted and condensed from the verification guide
- Grouped format used by default for better readability (unless only 1 scenario)
- **Positron Version automatically detected** from installed application (using `scripts/detect_versions.sh`)
- **OS Version automatically detected** from your system (using `scripts/detect_versions.sh`)
- Ready to paste - you can adjust versions if you tested on multiple systems

**Version detection is best-effort and silent:**
- **Only runs when you request the comment template** (not during initial guide generation)
- Uses the `detect_versions.sh` script with 3-second timeouts per detection
- If detection fails, empty values are used (you can fill them in manually)
- Never prompts or shows errors - fails fast and silent

**The template will be automatically copied to your clipboard** (on macOS/Linux using `pbcopy`/`xclip`, on Windows using `clip`) when you accept the offer, making it easy to paste directly into the GitHub issue after you complete testing.

[links or paths to e2e tests, or n/a]


**注意：** 验证评论使用普通项目符号。对勾（✓）和复选框（- [ ]）仅用于验证指南中的视觉区分和测试进度跟踪。

模板将预填充以下内容：
- 从验证指南中提取并精简的测试场景
- 默认使用分组格式以提升可读性（除非只有1个场景）
- **Positron版本**从已安装应用中自动检测（使用`scripts/detect_versions.sh`）
- **OS版本**从你的系统中自动检测（使用`scripts/detect_versions.sh`）
- 可直接粘贴 - 如果你在多个系统上进行了测试，可以调整版本信息

**版本检测为尽力而为且静默执行：**
- **仅在你请求评论模板时运行**（初始指南生成时不运行）
- 使用`detect_versions.sh`脚本，每个检测有3秒超时
- 如果检测失败，使用空值（你可手动填写）
- 从不提示或显示错误 - 快速失败且静默

**当你同意后，模板将自动复制到剪贴板**（在macOS/Linux上使用`pbcopy`/`xclip`，在Windows上使用`clip`），方便你在完成测试后直接粘贴到GitHub Issue中。

Output Format

输出格式

The verification guide is saved as a markdown file:

.claude/skills/positron-qa-verify/output/verify-issue-{number}-{timestamp}.md

Example filename:

verify-issue-4567-20260108-153045.md

验证指南将保存为Markdown文件：

.claude/skills/positron-qa-verify/output/verify-issue-{number}-{timestamp}.md

示例文件名：

verify-issue-4567-20260108-153045.md

Example Usage

示例用法

User: /qa-verify 4567

I'll respond with:

A summary of what I found
Path to the generated verification guide
Key highlights (number of scenarios, any blockers, etc.)

用户: /qa-verify 4567

我会回复：

我所发现内容的摘要
生成的验证指南路径
关键亮点（场景数量、任何障碍等）

Implementation Examples

实现示例

Example 1: Parallel Execution of Steps 1 & 2

示例1：步骤1和步骤2的并行执行

Do this (FAST - ~2 seconds):

Single message with multiple Bash tool calls running in parallel:

```
gh issue view <number>
```
fetches issue details
```
gh pr list --search "<number>"
```
searches for related PRs

Saves ~1-2 seconds compared to sequential execution.

正确做法（快速 - 约2秒）：

在一条消息中调用多个Bash工具并行运行：

```
gh issue view <number>
```
获取Issue详情
```
gh pr list --search "<number>"
```
搜索关联PR

比顺序执行节省约1-2秒。

Example 2: Parallel Fetch of Related PRs/Issues

示例2：关联PR/Issue的并行获取

Do this (FAST - ~2 seconds):

After identifying related PRs/issues from PR body (e.g., #10625, #10753), fetch them all in parallel with a single message containing multiple Bash tool calls.

Don't do this (SLOW - ~6 seconds):

Sequential fetches of each related PR/issue one at a time.

Saves ~2-4 seconds depending on number of related items.

正确做法（快速 - 约2秒）：

从PR正文中识别关联PR/Issue后（例如#10625、#10753），在一条消息中调用多个Bash工具并行获取所有内容。

错误做法（缓慢 - 约6秒）：

逐个顺序获取每个关联PR/Issue。

根据关联项数量，节省约2-4秒。

Example 3: Check PR Size Before Fetching Diff

示例3：获取差异内容前检查PR大小

Do this (FAST):

Get PR with
```
--json additions,deletions
```
in Step 3
Calculate total:
```
additions + deletions
```
Only fetch diff if
```
< 500 lines
```

Example:

bash

undefined

正确做法（快速）：

在步骤3中使用
```
--json additions,deletions
```
获取PR数据
计算总行数：
```
additions + deletions
```
仅当
```
< 500行
```
时获取差异内容

示例：

bash

undefined

Already have from Step 3:

步骤3已获取：

"additions": 9, "deletions": 3

Total: 12 lines (< 500, so fetch diff)

总行数：12行（<500，因此获取差异内容）

gh pr diff 11251


**Don't do this (SLOW):**

Always fetch diff, then check size after.

**Saves ~1-5 seconds** on large PRs by avoiding unnecessary diff downloads.

gh pr diff 11251


**错误做法（缓慢）：**

始终获取差异内容，之后再检查大小。

**通过避免不必要的差异内容下载，在大型PR上节省约1-5秒**。

Helper Scripts

辅助脚本

scripts/analyze_issue.sh

scripts/analyze_issue.sh

This script orchestrates the data gathering:

bash

undefined

此脚本协调数据收集工作：

bash

undefined

Usage:

用法:

./scripts/analyze_issue.sh <issue-number>


The script:
- Fetches issue and PR data using `gh` CLI
- Extracts linked issues from comments
- Calculates PR size to determine if code review is needed
- Outputs structured JSON for parsing

./scripts/analyze_issue.sh <issue-number>


该脚本：
- 使用`gh` CLI获取Issue和PR数据
- 从评论中提取关联Issue
- 计算PR大小以决定是否需要代码审查
- 输出结构化JSON以供解析

scripts/detect_versions.sh

scripts/detect_versions.sh

This script performs fast, silent version detection:

bash

undefined

此脚本执行快速、静默的版本检测：

bash

undefined

Usage:

用法:

./scripts/detect_versions.sh

With debug output:

带调试输出:

DEBUG=1 ./scripts/detect_versions.sh


The script:
- Detects Positron version and build number from `product.json`
- Detects OS version using platform-specific commands
- Has 3-second timeout per detection (max 4 seconds total)
- **Never prompts or shows errors** - always outputs valid JSON
- Fails gracefully with empty values if detection fails

Output format:
```json
{
  "positronVersion": "2026.02.0",
  "positronBuild": "10",
  "osVersion": "macOS 26.2",
  "detectionStatus": "success"
}

Detection status values:

```
"success"
```
- Both Positron and OS versions detected
```
"partial"
```
- Only one version detected
```
"failed"
```
- No versions detected

DEBUG=1 ./scripts/detect_versions.sh


该脚本：
- 从`product.json`中检测Positron版本和构建编号
- 使用平台特定命令检测OS版本
- 每个检测有3秒超时（总超时4秒）
- **从不提示或显示错误** - 始终输出有效的JSON
- 如果检测失败，优雅降级为使用空值

输出格式：
```json
{
  "positronVersion": "2026.02.0",
  "positronBuild": "10",
  "osVersion": "macOS 26.2",
  "detectionStatus": "success"
}

检测状态值：

```
"success"
```
- 成功检测到Positron和OS版本
```
"partial"
```
- 仅检测到一个版本
```
"failed"
```
- 未检测到任何版本

Verification Guide Template

验证指南模板

The generated guides follow this structure:

markdown

undefined

生成的指南遵循以下结构：

markdown

undefined

Verification Guide

[Issue Title]

Issue: #number Type: Bug | Feature | Documentation | Maintenance Primary PR: #number Component: [area label] Generated: [timestamp]

Issue Summary

[2-3 sentences explaining the problem and user impact]

Root Cause

[1-2 sentences if identifiable, otherwise "See PR for technical details"]

Test Scenarios

Primary Scenario

✓ [Scenario title]

Setup: (if needed)

Setup step one
Setup step two

Test Steps:

Step one
Step two

Expected: [What should happen] Previously: [What was broken]

✓ [Scenario title]

Setup: (if needed)

Setup step one
Setup step two

Test Steps:

Step one
Step two

Expected: [What should happen] Previously: [What was broken]

Edge Cases

✓ [Edge case scenario title]

Why test: [Brief explanation]

Step one
Step two

✓ [Edge case scenario title]

Why test: [Brief explanation]

Step one
Step two

Regression Checks

[What to verify]
[Another thing to verify]

[What to verify]
[Another thing to verify]

Testing Context

Environment:

Positron version: [if specified]
OS: [if relevant]
Language: Python/R [version if specified]

Setup: [Any required setup steps]

Related PRs:

[Links to related PRs with brief description]

Environment:

Positron version: [if specified]
OS: [if relevant]
Language: Python/R [version if specified]

Setup: [Any required setup steps]

Related PRs:

[Links to related PRs with brief description]

References

Issue: [link]
PR: [link]
Related: [links to other issues]

Generated by positron-qa-verify skill

undefined

Issue: [link]
PR: [link]
Related: [links to other issues]

Generated by positron-qa-verify skill

undefined

Tips for Effective Verification

有效验证技巧

Start with the primary scenario - Always test the exact repro steps from the issue first
Check edge cases - Comments often reveal additional scenarios discovered during development
Test on relevant platforms - If issue mentions "macOS only", prioritize that platform
Verify related functionality - Small fixes sometimes have unintended side effects
Look for performance notes - PRs sometimes mention performance implications

从主场景开始 - 始终首先测试Issue中提供的精确复现步骤
检查边缘情况 - 评论中常包含开发过程中发现的额外场景
在相关平台上测试 - 如果Issue提到“仅macOS”，优先测试该平台
验证相关功能 - 小修复有时会产生意外副作用
查找性能说明 - PR有时会提到性能影响

Advanced Features

高级功能

Multiple PRs

多个PR

If an issue has multiple related PRs (e.g., backend + frontend changes):

I'll analyze all of them
The guide will note which scenarios relate to which PR
Testing order may be suggested if one depends on another

如果一个Issue有多个关联PR（例如后端+前端变更）：

我会分析所有PR
指南会注明哪些场景与哪个PR相关
如果存在依赖关系，会建议测试顺序

Linked Issues

关联Issue

When comments reference other issues:

I'll fetch those issue titles
Include relevant context in the verification guide
Help you understand if they should be tested together

当评论引用其他Issue时：

我会获取这些Issue的标题
在验证指南中包含相关上下文
帮助你了解是否需要一起测试

Code Analysis Insights

代码分析洞察

For small PRs where I review the code:

I'll note if changes are isolated or touch multiple areas
Highlight any test files modified (what the developers tested)
Identify configuration changes that might affect behavior

对于我会审查代码的小型PR：

我会注明变更是独立的还是涉及多个模块
突出显示修改的测试文件（开发人员已测试的内容）
识别可能影响行为的配置变更

Limitations

局限性

Cannot automatically execute tests (manual verification only)
Code analysis is limited to small PRs to save time
Relies on quality of issue description and PR comments
May miss verbal discussions not captured in GitHub

无法自动执行测试（仅支持手动验证）
为节省时间，代码分析仅限于小型PR
依赖Issue描述和PR评论的质量
可能会遗漏未在GitHub中记录的口头讨论

Integration with QA Workflow

与QA工作流的集成

This skill integrates with the typical QA verification workflow:

Sign up for ticket on the QA board
Run
/qa-verify [issue-number]
to generate guide
Review the generated markdown to understand what to test
Perform manual verification following the scenarios
Update ticket status based on results

The generated guides serve as:

A checklist during testing
Documentation of what was verified
Reference for future related issues

此技能与典型的QA验证工作流集成：

在QA看板上领取工单
**运行
```
/qa-verify [issue-number]
```
**生成指南
查看生成的Markdown文件了解测试内容
按照场景执行手动验证
根据结果更新工单状态

生成的指南可作为：

测试期间的检查清单
已验证内容的文档
未来相关Issue的参考资料

Success Criteria

成功标准

A successful verification guide should:

Clearly explain the issue and its impact
Provide specific, actionable test scenarios
Include relevant edge cases from comments/analysis
List required environment/setup details
Reference all related issues and PRs
Be concise but complete (no fluff, all substance)

Remember: This skill generates the testing plan. You still need to execute the manual verification yourself!

一份成功的验证指南应：

清晰说明问题及其影响
提供具体、可执行的测试场景
包含来自评论/分析的相关边缘情况
列出所需的环境/设置细节
引用所有相关Issue和PR
简洁但完整（无冗余内容，全为关键信息）

请注意：此技能生成测试计划。你仍需自行执行手动验证！

positron-qa-verify

Original

Translation

Positron QA Verify

Positron QA Verify

When to Use This Skill

何时使用此技能

Prerequisites

前提条件

Execution Mode

执行模式

Input

输入

Workflow

工作流程

Performance Optimization Strategy

性能优化策略

Step 1: Fetch Issue Details (Parallel with Step 2)

步骤1：获取Issue详情（与步骤2并行）

Step 2: Identify Related PR(s) (Parallel with Step 1)

步骤2：识别关联PR（与步骤1并行）

Step 3: Analyze PR Context

步骤3：分析PR上下文

Step 4: Review Code Changes (Conditionally)

步骤4：查看代码变更（有条件执行）

Step 5: Extract Linked Issues and Scenarios

步骤5：提取关联Issue和场景

Step 6: Generate Verification Guide

步骤6：生成验证指南

Step 7: Offer Verification Comment Template (User-Triggered)

步骤7：提供验证评论模板（用户触发）

Verified Fixed

已验证修复

Test scenario(s)

Test scenario(s)

Link(s) to test cases run or created:

Link(s) to test cases run or created:

Verified Fixed

已验证修复

Test scenario(s)

Test scenario(s)

Link(s) to test cases run or created:

Link(s) to test cases run or created:

Output Format

输出格式

Example Usage

示例用法

Implementation Examples

实现示例

Example 1: Parallel Execution of Steps 1 & 2

示例1：步骤1和步骤2的并行执行

Example 2: Parallel Fetch of Related PRs/Issues

示例2：关联PR/Issue的并行获取

Example 3: Check PR Size Before Fetching Diff

示例3：获取差异内容前检查PR大小

Already have from Step 3:

步骤3已获取：

"additions": 9, "deletions": 3

"additions": 9, "deletions": 3

Total: 12 lines (< 500, so fetch diff)

总行数：12行（<500，因此获取差异内容）

Helper Scripts

辅助脚本

scripts/analyze_issue.sh

scripts/analyze_issue.sh

Usage:

用法:

scripts/detect_versions.sh

scripts/detect_versions.sh

Usage:

用法:

With debug output:

带调试输出:

Verification Guide Template

验证指南模板

Verification Guide

Verification Guide

[Issue Title]<br>

[Issue Title]<br>

Issue Summary

`scripts/analyze_issue.sh`

`scripts/analyze_issue.sh`

`scripts/detect_versions.sh`

`scripts/detect_versions.sh`