Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

create-issue

Étoiles22

Forks3

Mis à jour3 mai 2026 à 00:46

Create a GitHub issue from a short user description, auto-classify it with type + area + priority labels, ensure those labels exist in the repo (creating any that are missing with consistent colors), then create the issue via `gh issue create` and print the URL. Trigger phrases — "create an issue", "open a github issue", "file a bug", "log this as an issue", "/create-issue", "make a ticket for this", "track this in github". Skip for — PRs (use open-pr), commenting on existing issues (use `gh issue comment`), non-GitHub trackers (Linear, Jira).

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

webdevcody

webdevcody/go-mailing-list

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Spécialistes en gestion de projetsProfessions des affaires et des opérations financières·SOC 13-1082

SKILL.md

readonly

name

create-issue

description

User-question protocol: Whenever this skill needs the user to pick between options, confirm an action, or answer a multiple-choice prompt, you MUST call the AskUserQuestion tool to render a proper interactive picker. Do NOT print numbered options as plain text and wait for the user to type a number — that produces a degraded UX. Free-form questions (open-ended typing) may be asked in prose, but any time you would write "1) … 2) … 3) …", use AskUserQuestion instead.

Create Issue

Phased. The auto-label step is the value — do not skip it.

Phase 1 — Gather

In parallel:

gh repo view --json nameWithOwner,defaultBranchRef -q '{repo:.nameWithOwner,base:.defaultBranchRef.name}' — confirm repo. If this fails, stop: no GitHub remote.
gh label list --limit 200 --json name,color,description — current labels.

Stop conditions:

No GitHub remote → stop. Tell the user.
User description is one ambiguous word ("broken", "fix") → ask for one sentence of context before continuing.

Phase 2 — Draft + Classify

Draft a title (≤70 chars, imperative, no trailing period) and a short body:

## Description
<1–3 sentences>

## Acceptance criteria
- [ ] <checkable>
- [ ] <checkable>

Then classify the issue across three label axes. Pick at least one type and at least one area; priority is optional but encouraged.

Type (pick 1–2): bug, feature, enhancement, refactor, docs, test, chore, question

Area (pick 1–3): ui, ux, frontend, backend, infra, performance, security, accessibility, dx, dependencies

Priority (pick 0–1): priority:critical, priority:high, priority:medium, priority:low

Classification heuristics (apply to the user's words):

"broken", "crash", "error", "regression", "doesn't work" → bug
"add", "build", "ship", "support for", "we should be able to" → feature
"make X better/faster/cleaner" on existing behavior → enhancement
"looks", "color", "spacing", "layout", "alignment" → ui
"confusing", "hard to find", "user can't", "flow" → ux
"slow", "lag", "memory", "p95", "timeout" → performance + priority:high if user mentions production
"deploy", "CI", "docker", "env var", "build pipeline" → infra
"API", "server", "DB", "endpoint", "query", "migration" → backend
"screen reader", "keyboard nav", "ARIA", "contrast" → accessibility
"prod down", "data loss", "security incident" → priority:critical

If a single description spans multiple areas (e.g., "the login button looks wrong AND the auth endpoint returns 500"), suggest splitting into two issues before creating.

Phase 3 — Ensure Labels Exist

Diff the chosen labels against the gh label list output. For each missing label, queue a gh label create call with this color map:

Label	Color (hex, no #)
`bug`	`d73a4a`
`feature`	`0e8a16`
`enhancement`	`a2eeef`
`refactor`	`c5def5`
`docs`	`0075ca`
`test`	`bfd4f2`
`chore`	`cfd3d7`
`question`	`d876e3`
`ui`	`fbca04`
`ux`	`f9d0c4`
`frontend`	`bfdadc`
`backend`	`5319e7`
`infra`	`1d76db`
`performance`	`ff9f1c`
`security`	`b60205`
`accessibility`	`006b75`
`dx`	`7057ff`
`dependencies`	`0366d6`
`priority:critical`	`b60205`
`priority:high`	`d93f0b`
`priority:medium`	`fbca04`
`priority:low`	`c2e0c6`

Create with: gh label create "<name>" --color <hex> --description "<short>". Run missing-label creates in parallel.

Phase 4 — Confirm (mandatory gate)

Show the user:

Repo: <owner/name>
Title: <title>
Labels: <comma-separated>
New labels to create: <list or "none">

Body:
<body>

Create issue? (y / edit / cancel)

y → Phase 5
edit → ask which slot (title/body/labels), redraft, show again
cancel → stop, do NOT create the labels either

Phase 5 — Create

After any missing labels are created, run:

gh issue create \
  --title "<title>" \
  --label "<l1>" --label "<l2>" ... \
  --body "$(cat <<'EOF'
<body>
EOF
)"

Always use HEREDOC for --body. Print the issue URL from stdout.

NEVER

NEVER skip the confirmation gate. Why: Issues notify watchers and clutter the tracker; the title/labels are your synthesis, not the user's words verbatim.
NEVER create labels before the user confirms. Instead: Queue the creates, list them in the confirmation, only run them after y. Why: A cancelled issue leaves orphan labels polluting the repo's label set.
NEVER apply more than 2 type labels or more than 1 priority label. Why: Filters break when an issue is simultaneously bug + feature + enhancement — pick the dominant frame.
NEVER assume the repo's label color scheme. Instead: Use the color map above so labels stay consistent across repos. Why: Random colors per-repo make the label list visually noisy and hard to scan.

Plus depuis ce dépôt

même dépôt

add-e2e-test

webdevcody/go-mailing-list

Add a Playwright end-to-end test for a user-facing flow — sign-in, form submit, multi-step wizard, payment, navigation, etc. Detects existing Playwright setup and inherits its config (baseURL, projects, fixtures, auth state); installs Playwright via the official `npm init playwright@latest` flow only with explicit user approval. Wires one smoke test that hits the real running dev server before generating the full flow. Prefers role-based selectors (`getByRole`, `getByLabel`) over CSS/test-ids; uses `expect`-with-auto-retry assertions; adds an auth-state fixture for tests that need a logged-in user. Trigger phrases — "add an e2e test", "playwright test", "browser test for X", "test the signup flow", "/add-e2e-test", "end-to-end test". Skip for — pure unit-testable logic (use code-write-tests), API-only flows (use code-write-tests with supertest/fetch), and projects where the user explicitly does not want a browser harness.

2026-05-0322

add-empty-error-states

webdevcody/go-mailing-list

Sibling to add-skeleton-loaders. After data fetching is wired in a route or component, verify and auto-fix the two non-loading states most often forgotten — empty (the request succeeded but returned zero items / null) and error (the request failed). Empty states get a clear message + primary call-to-action. Error states get a human-readable message + retry affordance + (in dev) a way to surface the actual error. Uses the project's existing UI primitives — shadcn `<EmptyState />` if present, project conventions otherwise. Does NOT cover loading skeletons. Trigger phrases — "add empty state", "what if this list is empty", "add error state", "handle the error case", "/add-empty-error-states", "error UI", "no results UI", any time a route was just wired with `useQuery` / `useSuspenseQuery` / loader. Skip for — pure static pages, mutations (useMutation has different patterns), modals/dialogs whose empty state is the parent's responsibility.

2026-05-0322

add-feature

webdevcody/go-mailing-list

End-to-end workflow for planning and shipping a new feature in an existing codebase. Phases — clarify → explore → design → mandatory plan-approval gate → implement (subagent fan-out where useful) → verify → gated reviews (code + duplication always; security if backend logic changed; performance if DB/queries changed) → automated tests. Also enforces UI-convention parity: any new instance of a recurring UI surface (modal, dialog, drawer, form) must match sibling conventions for hotkeys, kbd hints, focus, and loading states. Accepts `mode=fast|balanced|production` to control depth (default: production); also accepts `include=<phases>` / `skip=<phases>` overrides. Use when the user asks to add, build, ship, or implement a new feature: "add a feature", "build this", "implement X", "new feature", "plan and build", "ship this". Skip for bug fixes (use fix-bug), pure refactors, enum/state renames (use code-realign), or one-line tweaks.

2026-05-0322

add-form

webdevcody/go-mailing-list

Scaffold a form in this TanStack Start app following the project's conventions — a single zod schema reused on the client (react-hook-form resolver) AND on the server function (input validation), shadcn `<Form>`/`<FormField>` primitives for the UI, a server function in `src/fn/` that calls a use case or data-access function, a `useMutation` wired to that server fn with optimistic / pending UI, and proper success / error handling that integrates with the route's invalidations. Detects whether the project uses react-hook-form (default in shadcn setups) or TanStack Form, and follows whichever is already in use. Trigger phrases — "add a form", "create form for X", "/add-form", "new form", "form to create/edit X", "form for the new entity", "scaffold a form". Skip for — pure read-only views, search inputs that are not form submissions (use a controlled input directly), and forms whose validation is so trivial the schema-on-both-sides pattern is overkill (single field with no rules).

2026-05-0322

add-regression-test

webdevcody/go-mailing-list

After a bug fix lands (or is staged), generate a regression test that fails on the pre-fix code and passes on the post-fix code — pinning the bug so it can't silently return. Walks the agent through reproducing the failure first (against the pre-fix state via `git stash` or temporary revert), writing the assertion that captures it, then verifying the test goes red without the fix and green with it. Trigger phrases — "add a regression test", "pin this bug", "write a test for the fix", "/add-regression-test", "lock in this bug fix", "make sure this doesn't come back", or invoke automatically after a /fix-bug session that produced a code fix. Skip for — fixes whose behavior change is already covered by existing passing tests, pure refactors with no behavior delta, fixes to test code itself, and unreproducible heisenbugs.

2026-05-0322

add-seed-data

webdevcody/go-mailing-list

Generate a developer seed-data script for a feature — creates representative rows through the data-access layer (not raw SQL) so the seed respects schema, foreign keys, and any business invariants encoded in DA functions. Detects an existing `scripts/seed.ts` (or the project's convention) and extends it; if none exists, creates one and wires a `seed` script in `package.json`. Defaults to idempotent inserts (upsert by natural key, or wipe-then-insert behind a flag) so re-running doesn't double-create. Trigger phrases — "seed data for X", "add fixtures", "/add-seed-data", "demo data", "create some sample posts", "fill the dev DB", "seed the database with users". Skip for — production data, test fixtures (those live in test files, not the seed), and one-off scripts the user runs manually (use a dedicated migration or admin script).

2026-05-0322

name

create-issue

description

User-question protocol: Whenever this skill needs the user to pick between options, confirm an action, or answer a multiple-choice prompt, you MUST call the AskUserQuestion tool to render a proper interactive picker. Do NOT print numbered options as plain text and wait for the user to type a number — that produces a degraded UX. Free-form questions (open-ended typing) may be asked in prose, but any time you would write "1) … 2) … 3) …", use AskUserQuestion instead.

Create Issue

Phased. The auto-label step is the value — do not skip it.

Phase 1 — Gather

In parallel:

gh repo view --json nameWithOwner,defaultBranchRef -q '{repo:.nameWithOwner,base:.defaultBranchRef.name}' — confirm repo. If this fails, stop: no GitHub remote.
gh label list --limit 200 --json name,color,description — current labels.

Stop conditions:

No GitHub remote → stop. Tell the user.
User description is one ambiguous word ("broken", "fix") → ask for one sentence of context before continuing.

Phase 2 — Draft + Classify

Draft a title (≤70 chars, imperative, no trailing period) and a short body:

## Description
<1–3 sentences>

## Acceptance criteria
- [ ] <checkable>
- [ ] <checkable>

Then classify the issue across three label axes. Pick at least one type and at least one area; priority is optional but encouraged.

Type (pick 1–2): bug, feature, enhancement, refactor, docs, test, chore, question

Area (pick 1–3): ui, ux, frontend, backend, infra, performance, security, accessibility, dx, dependencies

Priority (pick 0–1): priority:critical, priority:high, priority:medium, priority:low

Classification heuristics (apply to the user's words):

"broken", "crash", "error", "regression", "doesn't work" → bug
"add", "build", "ship", "support for", "we should be able to" → feature
"make X better/faster/cleaner" on existing behavior → enhancement
"looks", "color", "spacing", "layout", "alignment" → ui
"confusing", "hard to find", "user can't", "flow" → ux
"slow", "lag", "memory", "p95", "timeout" → performance + priority:high if user mentions production
"deploy", "CI", "docker", "env var", "build pipeline" → infra
"API", "server", "DB", "endpoint", "query", "migration" → backend
"screen reader", "keyboard nav", "ARIA", "contrast" → accessibility
"prod down", "data loss", "security incident" → priority:critical

If a single description spans multiple areas (e.g., "the login button looks wrong AND the auth endpoint returns 500"), suggest splitting into two issues before creating.

Phase 3 — Ensure Labels Exist

Diff the chosen labels against the gh label list output. For each missing label, queue a gh label create call with this color map:

Label	Color (hex, no #)
`bug`	`d73a4a`
`feature`	`0e8a16`
`enhancement`	`a2eeef`
`refactor`	`c5def5`
`docs`	`0075ca`
`test`	`bfd4f2`
`chore`	`cfd3d7`
`question`	`d876e3`
`ui`	`fbca04`
`ux`	`f9d0c4`
`frontend`	`bfdadc`
`backend`	`5319e7`
`infra`	`1d76db`
`performance`	`ff9f1c`
`security`	`b60205`
`accessibility`	`006b75`
`dx`	`7057ff`
`dependencies`	`0366d6`
`priority:critical`	`b60205`
`priority:high`	`d93f0b`
`priority:medium`	`fbca04`
`priority:low`	`c2e0c6`

Create with: gh label create "<name>" --color <hex> --description "<short>". Run missing-label creates in parallel.

Phase 4 — Confirm (mandatory gate)

Show the user:

Repo: <owner/name>
Title: <title>
Labels: <comma-separated>
New labels to create: <list or "none">

Body:
<body>

Create issue? (y / edit / cancel)

y → Phase 5
edit → ask which slot (title/body/labels), redraft, show again
cancel → stop, do NOT create the labels either

Phase 5 — Create

After any missing labels are created, run:

gh issue create \
  --title "<title>" \
  --label "<l1>" --label "<l2>" ... \
  --body "$(cat <<'EOF'
<body>
EOF
)"

Always use HEREDOC for --body. Print the issue URL from stdout.

NEVER

NEVER skip the confirmation gate. Why: Issues notify watchers and clutter the tracker; the title/labels are your synthesis, not the user's words verbatim.
NEVER create labels before the user confirms. Instead: Queue the creates, list them in the confirmation, only run them after y. Why: A cancelled issue leaves orphan labels polluting the repo's label set.
NEVER apply more than 2 type labels or more than 1 priority label. Why: Filters break when an issue is simultaneously bug + feature + enhancement — pick the dominant frame.
NEVER assume the repo's label color scheme. Instead: Use the color map above so labels stay consistent across repos. Why: Random colors per-repo make the label list visually noisy and hard to scan.