メニュー
Draft a high-quality GitHub bug report from a QA observation - dedup, fill the bug_report form fields. DRAFT ONLY: it never files the issue; it hands you a ready `gh issue create` command to run yourself. Use when QA finds a defect to report.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Draft a GitHub proposal (feature / enhancement / task) - dedup, classify the type, fill the proposal form fields. DRAFT ONLY: it never files the issue; it hands you a ready `gh issue create` command to run yourself. Use when proposing new capability, an improvement, or a unit of work (not a defect - that's /report-bug).
Draft a clear, reviewer-ready pull request description for the current branch (or an existing PR) - feature-first summary, motivation, test plan, linked issues - verified against the real diff. DRAFT ONLY: it never creates, edits, or pushes; it hands you a ready `gh pr create`/`gh pr edit` command to run yourself. Use when writing up a PR.
Scaffold a new backend HTTP endpoint / vertical slice in apps/backend (Zod schema + defineAction + service + mounter) following the slice conventions. Use when adding a backend endpoint, action, or resource.
Scaffold a new Tailor content extension - content element (ce), content container (cc), meta input (mi), or plugin (pl) - and wire it into the registry. Use when adding a new ce/cc/mi/pl extension to the platform.
Scaffold a Playwright Page Object plus a functional spec in tests/, following the POM conventions. Use when adding an end-to-end test for a feature or flow.
Turn a bug (GitHub issue number or description) into a failing Playwright spec that reproduces it - POM-based, tagged @bug, linked to the issue, and marked test.fail() so CI stays green until a fix flips it red. Use to capture a known bug as a regression-first test.
SOC 職業分類に基づく
| name | report-bug |
| description | Draft a high-quality GitHub bug report from a QA observation - dedup, fill the bug_report form fields. DRAFT ONLY: it never files the issue; it hands you a ready `gh issue create` command to run yourself. Use when QA finds a defect to report. |
Produces a polished, de-duplicated bug report matching
.github/ISSUE_TEMPLATE/bug_report.yml. Draft only - never run
gh issue create; hand the user the body plus a command to file it
themselves.
Verify it's a defect. Check the code: if nothing is broken (works
as designed, missing affordance, "should allow X") it's a proposal,
not a bug - switch to /report-proposal and draft against
proposal.yml instead. Then collect the facts (ask for anything
missing):
git rev-parse --short HEAD), env (local/staging/prod).trace.zip / screenshot under
tests/test-results/ if one exists.Dedup (read-only). Search first, and stop if it already exists:
gh issue list --search "<key phrase> in:title" --state all --json number,title,state. Show any matches; if it looks like a
duplicate, link it instead of drafting a new one.
Draft the body. Write markdown mirroring the form fields - gh does
NOT render the .yml form in non-interactive mode, so bake the
structure into the body. Title: [Bug]: <area> - <symptom>. Save it to
a scratch file for --body-file. Do NOT hard-wrap lines (the repo's
80-col rule is for code): GitHub renders newlines in issue bodies as
line breaks, so keep each paragraph/bullet on one source line.
Hand off - do not file. Give the user the exact command to run
themselves:
gh issue create --title "[Bug]: ..." --body-file <path> --type Bug
(--type is needed because non-interactive gh bypasses the form's
auto-assigned issue type; the issue type is the canonical
classification - no labels).
Offer to capture it as a failing spec via /repro-spec.