How do I install the Intake To Issue skill?

Run npx skillmds@latest add ortwinri/intake-to-issue in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Intake To Issue safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Intake To Issue?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Intake To Issue free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Intake To Issue?

ortwinri (@ortwinri) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Intake To Issue by ortwinri — Agent Skill

Name: Intake To Issue
Rating: 4.666666666666667 (3 reviews)
Author: ortwinri

Intake To Issue

Wandelt eine rohe Anfrage, Mail, Chat-Nachricht oder ein Support-Ticket in ein typisiertes, dedupliziertes Issue auf GitHub oder GitLab um, mit Risiko-Vorklassifikation und Labels. Trigger-Phrasen sind Anliegen aufnehmen, Ticket anlegen, Issue erstellen, Bug oder Feature melden, Intake.

ortwinri Updated Sep 22, 2026

File contents

intake-to-issue

Macht aus einem unstrukturierten Anliegen ein sauberes, auffindbares Issue. Erster Schritt der Lieferkette: danach folgt das Refinement.

Voraussetzungen

Das Arbeitsverzeichnis ist ein Git-Repo, oder der Nutzer nennt das Ziel-Repo.
Zugriff auf die Plattform, in dieser Reihenfolge:
1. GitHub- bzw. GitLab-Tools des eigenen KI-Tools (MCP), falls verfügbar
2. gh bzw. glab CLI (angemeldet)
3. REST-API mit GITHUB_TOKEN bzw. GITLAB_TOKEN
Konkrete Befehle: references/befehle.md

Ablauf

Plattform bestimmen: git remote get-url origin auswerten (github.com → GitHub, sonst gitlab im Host → GitLab). Unklar ⇒ nachfragen.
Anliegen erfassen: Quelle zusammenfassen: Problem, erwartetes Verhalten, betroffener Bereich, Dringlichkeit, Quelle (Mail, Ticket, Chat). Fehlt Wesentliches (z. B. Repro-Schritte bei einem Bug), gezielt nachfragen.
Typ bestimmen: bug | feature | task | question.
Deduplizieren: offene und geschlossene Issues nach 2–3 Schlüsselbegriffen durchsuchen. Passender Treffer ⇒ kein neues Issue, stattdessen am bestehenden kommentieren und dessen Link zurückmelden.
Risiko vorklassifizieren: grob nach Tragweite, wird im Refinement bestätigt.
- low: lokal begrenzt, kein Datenmodell, keine Sicherheit
- med: mehrere Stellen oder geteilte Logik betroffen
- high: Datenmodell/Migration, Auth, Zahlungen, Datenschutz, Produktionsdaten
Entwurf zeigen: Titel, Body (Vorlage: assets/issue-body.md), Labels. Anlegen erst nach Bestätigung, außer der Nutzer hat ausdrücklich „direkt anlegen" gesagt.
Issue anlegen: Labels type:<typ> und risk:<stufe>. Existiert ein Label im Repo nicht, anlegen, falls die Rechte reichen; sonst ohne Label anlegen und das dem Nutzer melden.
Rückverknüpfung: stammt das Anliegen aus einem externen Ticket, beide Seiten verlinken (bzw. dem Nutzer den Link für das Ticket geben).

Output

Issue-Nummer, URL, Typ und Risiko. Bei Duplikat: Link zum bestehenden Issue.

Leitplanken

Keine Duplikate anlegen.
Keine Secrets oder personenbezogenen Daten aus der Quelle übernehmen: Tokens, Passwörter, E-Mail-Adressen, Telefonnummern, Namen von Betroffenen neutralisieren (z. B. „ein Nutzer meldet …").
Issues mit Label manual nie automatisch weiterverarbeiten.
Titel kurz und sachlich, im Body nur, was für das Verständnis nötig ist.

Beispiel-Prompts

„Nimm diese Support-Mail auf und leg ein Issue an."
„Mach aus diesem Bug-Report ein Issue mit Repro-Schritten."

---name: intake-to-issuedescription: Wandelt eine rohe Anfrage, Mail, Chat-Nachricht oder ein Support-Ticket in ein typisiertes, dedupliziertes Issue auf GitHub oder GitLab um, mit Risiko-Vorklassifikation und Labels. Trigger-Phrasen sind Anliegen aufnehmen, Ticket anlegen, Issue erstellen, Bug oder Feature melden, Intake.---# intake-to-issueMacht aus einem unstrukturierten Anliegen ein sauberes, auffindbares Issue.Erster Schritt der Lieferkette: danach folgt das Refinement.## Voraussetzungen- Das Arbeitsverzeichnis ist ein Git-Repo, oder der Nutzer nennt das Ziel-Repo.- Zugriff auf die Plattform, in dieser Reihenfolge: 1. GitHub- bzw. GitLab-Tools des eigenen KI-Tools (MCP), falls verfügbar 2. `gh` bzw. `glab` CLI (angemeldet) 3. REST-API mit `GITHUB_TOKEN` bzw. `GITLAB_TOKEN`- Konkrete Befehle: [references/befehle.md](references/befehle.md)## Ablauf1. **Plattform bestimmen:** `git remote get-url origin` auswerten (`github.com` → GitHub, sonst `gitlab` im Host → GitLab). Unklar ⇒ nachfragen.2. **Anliegen erfassen:** Quelle zusammenfassen: Problem, erwartetes Verhalten, betroffener Bereich, Dringlichkeit, Quelle (Mail, Ticket, Chat). Fehlt Wesentliches (z. B. Repro-Schritte bei einem Bug), gezielt nachfragen.3. **Typ bestimmen:** `bug` | `feature` | `task` | `question`.4. **Deduplizieren:** offene **und** geschlossene Issues nach 2–3 Schlüsselbegriffen durchsuchen. Passender Treffer ⇒ **kein** neues Issue, stattdessen am bestehenden kommentieren und dessen Link zurückmelden.5. **Risiko vorklassifizieren:** grob nach Tragweite, wird im Refinement bestätigt. - `low`: lokal begrenzt, kein Datenmodell, keine Sicherheit - `med`: mehrere Stellen oder geteilte Logik betroffen - `high`: Datenmodell/Migration, Auth, Zahlungen, Datenschutz, Produktionsdaten6. **Entwurf zeigen:** Titel, Body (Vorlage: [assets/issue-body.md](assets/issue-body.md)), Labels. Anlegen erst nach Bestätigung, außer der Nutzer hat ausdrücklich „direkt anlegen" gesagt.7. **Issue anlegen:** Labels `type:<typ>` und `risk:<stufe>`. Existiert ein Label im Repo nicht, anlegen, falls die Rechte reichen; sonst ohne Label anlegen und das dem Nutzer melden.8. **Rückverknüpfung:** stammt das Anliegen aus einem externen Ticket, beide Seiten verlinken (bzw. dem Nutzer den Link für das Ticket geben).## OutputIssue-Nummer, URL, Typ und Risiko. Bei Duplikat: Link zum bestehenden Issue.## Leitplanken- Keine Duplikate anlegen.- Keine Secrets oder personenbezogenen Daten aus der Quelle übernehmen: Tokens, Passwörter, E-Mail-Adressen, Telefonnummern, Namen von Betroffenen neutralisieren (z. B. „ein Nutzer meldet …").- Issues mit Label `manual` nie automatisch weiterverarbeiten.- Titel kurz und sachlich, im Body nur, was für das Verständnis nötig ist.## Beispiel-Prompts- „Nimm diese Support-Mail auf und leg ein Issue an."- „Mach aus diesem Bug-Report ein Issue mit Repro-Schritten."

Frequently asked questions