メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | evanflow-qa |
| description | 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. |
Removed from upstream: automatic gh issue create. Always ask first.
See evanflow meta-skill.
Let the user describe in their own words. At most 2-3 short clarifying questions, focused on:
Don't pre-debug. Don't pre-judge.
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.
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).
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
...
After user confirms each draft: gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)".
Do NOT batch-file. Confirm each one.
Process each issue independently. The user signals when the QA session is done.
CONTEXT.md).gh issue create. Never auto-file.evanflow-debugevanflow-brainstorming (or evanflow-prd if substantial)Single entry-point orchestrator for the entire EvanFlow loop. The user says "let's evanflow this", "use evanflow", "evanflow this idea", "run this through evanflow", "implement with evanflow", or any similar phrasing — and you walk the full loop (brainstorm → plan → execute → tdd → iterate → STOP) end-to-end, announcing each step, respecting checkpoints, and stopping where the user retains control. Trigger keywords: "evanflow", "let's evanflow", "use evanflow", "evanflow this".
Meta skill for the EvanFlow system. Loads the shared vocabulary (deep modules, deletion test, vertical slice, grill, mockup quick-mode, no-auto-commit) and describes when to invoke each evanflow-* skill. Use when starting a new task and unsure which evanflow skill applies, or when you need to ground reasoning in the shared vocabulary.
Vertical-slice TDD for any production code. One test → one impl → repeat. Tests verify behavior through public interfaces, not internals. Use when implementing any feature, bugfix, or behavior change.
Clarify intent, propose 2-3 approaches, embedded grill to stress-test the chosen path. Use before any creative work — new features, components, behavior changes, design questions. Mockup-only requests use mockup quick-mode (no spec/plan ceremony).
Orchestrate parallel implementation with coder/overseer pairs. Coders implement decomposed tasks using evanflow-tdd; overseers review each coder's output for bugs, gaps, errors, AND cohesion violations against a shared contract. A final integration overseer checks cross-coder cohesion. Use for plans with 3+ truly independent tasks that share an interface contract.
Manage long-session context to prevent drift and degradation. Strategies for proactive summarization, branch isolation, and /clear decisions. Invoke when context feels heavy, when accuracy starts slipping, or proactively after a major phase boundary. Addresses the