Back to Details

evanflow-qa

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

EvanFlow: QA

EvanFlow: QA

Removed from upstream: automatic 
gh issue create
. Always ask first.
**已从上游移除：**自动执行
gh issue create
的功能。始终先询问用户。

Vocabulary

术语说明

See 
evanflow
meta-skill.
请查看
evanflow
元技能文档。

When to Use

使用场景

  • User describes a bug in their own words
  • QA session walking through a feature
  • Triaging multiple reports
  • 用户用自己的语言描述bug
  • 针对某个功能开展QA会话
  • 对多份反馈进行分类处理

The Flow

流程步骤

1. Listen Lightly

1. 轻量倾听

Let the user describe in their own words. At most 2-3 short clarifying questions, focused on:
  • What did you expect to happen?
  • What actually happened?
  • What were the steps?
Don't pre-debug. Don't pre-judge.
让用户用自己的语言描述问题。最多提出2-3个简短的澄清问题，聚焦于：
  • 你预期会发生什么？
  • 实际发生了什么？
  • 操作步骤是什么？
不要提前调试，不要预先判断。

2. Explore in Background (optional)

2. 背景探查（可选）

Spin up an Agent (Explore type) to read the relevant codebase area. Goal: understand domain language and feature intent — not to find a fix. Fixes come later via 
evanflow-debug
.
启动一个Explore类型的Agent来读取相关代码库区域。目标：理解领域语言和功能意图——并非寻找修复方案。修复方案后续通过
evanflow-debug
处理。

3. Assess Scope

3. 范围评估

Decide: is this one issue, or does it need breakdown into multiple independent concerns that different contributors could tackle simultaneously?
If multiple: each becomes its own issue. Mark blocking relationships honestly (don't serialize when work could parallelize).
判断：这是一个独立问题，还是需要拆分为多个不同的独立事项，以便不同贡献者同时处理？
如果是多个事项：每个事项单独创建为一个问题。如实标记依赖关系（当工作可以并行处理时，不要串行化）。

4. Draft the Issue(s)

4. 起草问题（草稿）

Show the draft to the user. ASK before running 
gh issue create
.
Single-issue template:
markdown
undefined
向用户展示草稿。在执行
gh issue create
前务必询问用户。
单问题模板：
markdown
undefined

What happened

问题描述

<one-paragraph user-facing description, no file paths>
<一段面向用户的描述，不要包含文件路径>

What I expected

预期结果

<one-paragraph>
<一段描述>

Steps to reproduce

复现步骤

  1. ...
  2. ...
  1. ...
  2. ...

Additional context

额外上下文

<anything that helps an engineer reproduce or scope> ```
Breakdown template (parent + children):
markdown
undefined
<有助于工程师复现或评估范围的信息>

拆分模板（父问题+子问题）：

```markdown

Parent issue

父问题关联

References: #<parent-id>
引用：#<父问题ID>

What's wrong

问题详情

<scoped to this child>
<针对此子问题的范围描述>

What I expected

预期结果

...
...

Steps to reproduce

复现步骤

...
...

Blocked by

依赖事项

  • #<id> (if any)
  • #<问题ID>（如有）

Additional context

额外上下文

...
undefined
...
undefined

5. File (with permission)

5. 提交（需获得许可）

After user confirms each draft: 
gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"
.
Do NOT batch-file. Confirm each one.
用户确认每个草稿后执行：
gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"
。
请勿批量提交。逐个确认后再提交。

6. Iterate

6. 迭代处理

Process each issue independently. The user signals when the QA session is done.
独立处理每个问题。用户会发出QA会话结束的信号。

Hard Rules

硬性规则

  • No file paths or line numbers in issue bodies. They become stale.
  • Use the project's domain language (
    CONTEXT.md
    ).
  • Describe behaviors, not code mechanics.
  • Reproduction steps mandatory.
  • Concise — readable in 30 seconds.
  • Many thin issues > few thick issues.
  • Mark blocking honestly to maximize parallelism.
  • ALWAYS ask before 
    gh issue create
    .     Never auto-file.
  • Never auto-commit. This skill doesn't modify code anyway, but if it ever does — ask first.
  • 问题描述中禁止包含文件路径或行号。这些信息会过时。
  • 使用项目的领域语言（参考
    CONTEXT.md
    ）。
  • 描述行为表现，而非代码机制。
  • 必须提供复现步骤。
  • 简洁明了——30秒内可读完。
  • 拆分多个细粒度问题 > 合并少量粗粒度问题。
  • 如实标记依赖关系，最大化并行处理效率。
  • 执行
    gh issue create
    前务必询问用户    。绝不自动提交。
  • 绝不自动提交代码。本技能本身不会修改代码，但如果未来涉及代码修改——务必先询问。

Hand-offs

流程衔接

  • Issue filed, want to debug it now → 
    evanflow-debug
  • Issue reveals a feature gap, not a bug → 
    evanflow-brainstorming
    (or 
    evanflow-prd
    if substantial)
  • 问题已提交，现在需要调试 → 使用
    evanflow-debug
  • 问题暴露的是功能缺口而非bug → 使用
    evanflow-brainstorming
    （如果涉及内容较多则使用
    evanflow-prd
    ）