メニュー
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 職業分類に基づく
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).
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
Root-cause discipline for bugs, test failures, and unexpected behavior. Embedded grill on the hypothesis before writing fix code. Use when encountering any bug, failing test, or behavior that doesn't match expectation.
Design a module's interface using parallel sub-agents producing radically different designs ("design it twice"). Compare on depth, simplicity, and efficiency. Embedded grill on the synthesized choice. Use when designing a new API, exploring interface options, or deciding the shape of a refactor before writing code.
Execute a written implementation plan task-by-task with inline verification. Stop and ask on blockers. No forced sub-skill chains. Use when a plan exists and you're ready to implement.
Extract canonical domain terms into CONTEXT.md. Flag ambiguities (same word, different meanings) and synonyms (different words, same meaning). Re-invoking updates the file in place. Use when authoring or updating CONTEXT.md, or when a new domain term emerges in conversation.
| name | polyflow-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 polyflow 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 polyflow-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.polyflow-debugpolyflow-brainstorming (or polyflow-prd if substantial)