How do I install the Polyflow QA skill?

Run npx skillmds@latest add evanklem/polyflow-qa in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Polyflow QA safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Polyflow QA?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Polyflow QA free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Polyflow QA?

evanklem (@evanklem) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Polyflow QA by evanklem — Agent Skill

Name: Polyflow QA
Author: evanklem

Polyflow QA

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.

evanklem 6823907 2.8 KB Updated Sep 17, 2026

File contents

PolyFlow: QA

Removed from upstream: automatic gh issue create. Always ask first.

Vocabulary

See polyflow meta-skill.

When to Use

User describes a bug in their own words
QA session walking through a feature
Triaging multiple reports

The Flow

1. Listen Lightly

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. Explore in Background (optional)

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 polyflow-debug.

3. Assess Scope

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)

Show the draft to the user. ASK before running gh issue create.

Single-issue template:

## What happened
<one-paragraph user-facing description, no file paths>

## What I expected
<one-paragraph>

## Steps to reproduce
1. ...
2. ...

## Additional context
<anything that helps an engineer reproduce or scope>

Breakdown template (parent + children):

## Parent issue
References: #<parent-id>

## What's wrong
<scoped to this child>

## What I expected
...

## Steps to reproduce
...

## Blocked by
- #<id> (if any)

## Additional context
...

5. File (with permission)

After user confirms each draft: gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)".

Do NOT batch-file. Confirm each one.

6. Iterate

Process each issue independently. The user signals when the QA session is done.

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.

Hand-offs

Issue filed, want to debug it now → polyflow-debug
Issue reveals a feature gap, not a bug → polyflow-brainstorming (or polyflow-prd if substantial)

---name: polyflow-qadescription: 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.---# PolyFlow: QA**Removed from upstream:** automatic `gh issue create`. Always ask first.## VocabularySee `polyflow` meta-skill.## When to Use- User describes a bug in their own words- QA session walking through a feature- Triaging multiple reports## The Flow### 1. Listen LightlyLet 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. Explore in Background (optional)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 `polyflow-debug`.### 3. Assess ScopeDecide: 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)**Show the draft to the user. ASK before running `gh issue create`.**Single-issue template:```markdown## What happened<one-paragraph user-facing description, no file paths>## What I expected<one-paragraph>## Steps to reproduce1. ...2. ...## Additional context<anything that helps an engineer reproduce or scope>```Breakdown template (parent + children):```markdown## Parent issueReferences: #<parent-id>## What's wrong<scoped to this child>## What I expected...## Steps to reproduce...## Blocked by- #<id> (if any)## Additional context...```### 5. File (with permission)After user confirms each draft: `gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"`.Do NOT batch-file. Confirm each one.### 6. IterateProcess each issue independently. The user signals when the QA session is done.## 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.## Hand-offs- Issue filed, want to debug it now → `polyflow-debug`- Issue reveals a feature gap, not a bug → `polyflow-brainstorming` (or `polyflow-prd` if substantial)

Frequently asked questions