evanflow-qa

Name: evanflow-qa
Author: evanklem

419stars18forks

How to install evanflow-qa?

evanklem/evanflow/evanflow-qa

$npx -y skills add evanklem/evanflow --skill evanflow-qa

Installs into the current project.

Summary

Conversational bug discovery → issue draft. Light listening, background exploration, scope assessment. Asks before gh issue create — never auto-files. Use when conducting a QA session, triaging user-reported issues, or filing bugs.

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: QA
2
3
4	Removed from upstream: automatic `gh issue create`. Always ask first.
5
6	## Vocabulary
7
8	See `evanflow` meta-skill.
9
10	## When to Use
11
12	- User describes a bug in their own words
13	- QA session walking through a feature
14	- Triaging multiple reports
15
16	## The Flow
17
18	### 1. Listen Lightly
19
20	Let the user describe in their own words. At most 2-3 short clarifying questions, focused on:
21
22	- What did you expect to happen?
23	- What actually happened?
24	- What were the steps?
25
26	Don't pre-debug. Don't pre-judge.
27
28	### 2. Explore in Background (optional)
29
30	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`.
31
32	### 3. Assess Scope
33
34	Decide: is this one issue, or does it need breakdown into multiple independent concerns that different contributors could tackle simultaneously?
35
36	If multiple: each becomes its own issue. Mark blocking relationships honestly (don't serialize when work could parallelize).
37
38	### 4. Draft the Issue(s)
39
40	Show the draft to the user. ASK before running `gh issue create`.
41
42	Single-issue template:
43
44	```markdown
45	## What happened
46	<one-paragraph user-facing description, no file paths>
47
48	## What I expected
49	<one-paragraph>
50
51	## Steps to reproduce
52	1. ...
53	2. ...
54
55	## Additional context
56	<anything that helps an engineer reproduce or scope>
57	```
58
59	Breakdown template (parent + children):
60
61	```markdown
62	## Parent issue
63	References: #<parent-id>
64
65	## What's wrong
66	<scoped to this child>
67
68	## What I expected
69	...
70
71	## Steps to reproduce
72	...
73
74	## Blocked by
75	- #<id> (if any)
76
77	## Additional context
78	...
79	```
80
81	### 5. File (with permission)
82
83	After user confirms each draft: `gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"`.
84
85	Do NOT batch-file. Confirm each one.
86
87	### 6. Iterate
88
89	Process each issue independently. The user signals when the QA session is done.
90
91	## Hard Rules
92
93	- No file paths or line numbers in issue bodies. They become stale.
94	- Use the project's domain language (`CONTEXT.md`).
95	- Describe behaviors, not code mechanics.
96	- Reproduction steps mandatory.
97	- Concise — readable in 30 seconds.
98	- Many thin issues > few thick issues.
99	- Mark blocking honestly to maximize parallelism.
100	- ALWAYS ask before `gh issue create`. Never auto-file.
101	- Never auto-commit. This skill doesn't modify code anyway, but if it ever does — ask first.
102
103	## Hand-offs
104
105	- Issue filed, want to debug it now → `evanflow-debug`
106	- Issue reveals a feature gap, not a bug → `evanflow-brainstorming` (or `evanflow-prd` if substantial)

People who liked this also viewed

6 picks

Type

evanflow-qa

419stars18forks

View on GitHub

How to install evanflow-qa?

evanklem/evanflow/evanflow-qa

$npx -y skills add evanklem/evanflow --skill evanflow-qa

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: QA
2
3
4	Removed from upstream: automatic `gh issue create`. Always ask first.
5
6	## Vocabulary
7
8	See `evanflow` meta-skill.
9
10	## When to Use
11
12	- User describes a bug in their own words
13	- QA session walking through a feature
14	- Triaging multiple reports
15
16	## The Flow
17
18	### 1. Listen Lightly
19
20	Let the user describe in their own words. At most 2-3 short clarifying questions, focused on:
21
22	- What did you expect to happen?
23	- What actually happened?
24	- What were the steps?
25
26	Don't pre-debug. Don't pre-judge.
27
28	### 2. Explore in Background (optional)
29
30	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`.
31
32	### 3. Assess Scope
33
34	Decide: is this one issue, or does it need breakdown into multiple independent concerns that different contributors could tackle simultaneously?
35
36	If multiple: each becomes its own issue. Mark blocking relationships honestly (don't serialize when work could parallelize).
37
38	### 4. Draft the Issue(s)
39
40	Show the draft to the user. ASK before running `gh issue create`.
41
42	Single-issue template:
43
44	```markdown
45	## What happened
46	<one-paragraph user-facing description, no file paths>
47
48	## What I expected
49	<one-paragraph>
50
51	## Steps to reproduce
52	1. ...
53	2. ...
54
55	## Additional context
56	<anything that helps an engineer reproduce or scope>
57	```
58
59	Breakdown template (parent + children):
60
61	```markdown
62	## Parent issue
63	References: #<parent-id>
64
65	## What's wrong
66	<scoped to this child>
67
68	## What I expected
69	...
70
71	## Steps to reproduce
72	...
73
74	## Blocked by
75	- #<id> (if any)
76
77	## Additional context
78	...
79	```
80
81	### 5. File (with permission)
82
83	After user confirms each draft: `gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"`.
84
85	Do NOT batch-file. Confirm each one.
86
87	### 6. Iterate
88
89	Process each issue independently. The user signals when the QA session is done.
90
91	## Hard Rules
92
93	- No file paths or line numbers in issue bodies. They become stale.
94	- Use the project's domain language (`CONTEXT.md`).
95	- Describe behaviors, not code mechanics.
96	- Reproduction steps mandatory.
97	- Concise — readable in 30 seconds.
98	- Many thin issues > few thick issues.
99	- Mark blocking honestly to maximize parallelism.
100	- ALWAYS ask before `gh issue create`. Never auto-file.
101	- Never auto-commit. This skill doesn't modify code anyway, but if it ever does — ask first.
102
103	## Hand-offs
104
105	- Issue filed, want to debug it now → `evanflow-debug`
106	- Issue reveals a feature gap, not a bug → `evanflow-brainstorming` (or `evanflow-prd` if substantial)

People who liked this also viewed

6 picks

Type