Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

create-issue

Sterne22

Forks3

Aktualisiert3. Mai 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

webdevcody

webdevcody/go-mailing-list

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

ProjektmanagementspezialistenWirtschafts- und Finanzberufe·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.

Mehr aus diesem Repository

gleiches Repository

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.