| name | superplane-issue-logger |
| description | When researching, classifying, drafting, or logging general SuperPlane issues (bug, enhancement, feature, papercut). Use for natural-language issue descriptions, tmp/pm_logger drafts, and optional GitHub MCP logging with labels. |
SuperPlane Issue Logger
Use this skill when a user describes an improvement, bug, or request in natural language. You will: (1) research and understand it in SuperPlane context, (2) classify issue type, (3) propose title and body in tmp/pm_logger, and (4) optionally create the issue on GitHub with correct labels.
Reference: docs/contributing/ (issue-tracking, quality, pull-requests, etc.), https://docs.superplane.com/ when relevant.
1. Research and understanding
- Context: Use docs/contributing/ (issue-tracking, quality, pull-requests, integrations, component-design) and, when relevant, https://docs.superplane.com/ (product behavior, UX).
- Clarification: If the description is vague (e.g. "improve the canvas" or "fix the button"), prompt the user for: what exactly is wrong or desired, where in the app it happens, expected vs actual behavior, and (for bugs) steps to reproduce.
- Scope: One issue per draft. If the user describes multiple items, ask which one to capture first or create separate drafts.
2. Issue type classification
Map the user's description to exactly one of:
| Type | Definition |
|---|
| bug | Something isn't working as expected (incorrect behavior, failure, regression). |
| enhancement | Small/medium improvement to an existing feature already in the app. |
| feature | Completely new feature or functionality. |
| papercut | Small issue, bug, or inconsistency; minor improvement that doesn't break flows. |
- Bug vs papercut: If it breaks a flow or blocks usage → bug. If it's annoying or inconsistent but workable → papercut.
- Enhancement vs feature: Improves something that already exists → enhancement. Adds net-new capability → feature.
Align with issue-tracking (Bugs, Papercuts, Enhancements views on the SuperPlane Board).
3. Title and body in tmp/pm_logger
- Location:
tmp/pm_logger/ (create directory if missing). One file per issue draft (e.g. bug-toolbar-copy-button.md, papercut-header-truncation.md).
- Title: Short — max 40 characters. One or two concrete concepts; not a full list of details, not too vague. Good: "Search canvas modal: layout and icons" (34), "Payload modal: drag-to-resize" (30). Too detailed: "Search canvas modal: long names/IDs rendering, icons, responsive width". Too vague: "Search canvas modal: polish". Put in the file as
### Title (or a clear header) so the log step can reuse it.
- Body: Use the short template below for the chosen type. Keep drafts efficient; avoid long sections or empty boilerplate.
- Screenshot: Screenshots are optional. For bug or papercut, if the user didn't provide one, ask in chat if they can share a screenshot (paste or attach). Screenshots pasted in chat cannot be uploaded to the issue via MCP (GitHub API accepts only text in the body). If the user shared a screenshot in chat: note in the body that they can paste it into the issue after creation (GitHub's issue/comment UI supports paste-to-upload), or omit and suggest they add it once the issue is open. Do not add an empty "Screenshot" section; do not put raw image data in the body.
Bug (short)
**Description:**
Brief statement of what's wrong.
**Steps to reproduce:**
1. …
2. …
**Expected / Actual:**
Expected: … Actual: …
(Screenshot only if user provided one in chat.)
Papercut (minimal)
**What:** One sentence — small issue or inconsistency.
**Where:** Screen/component and element.
(Screenshot only if user provided one.)
Enhancement (short)
**Problem:** Existing feature + what to improve (1–2 sentences).
**Current vs proposed:** One line each.
**Use case:** Who benefits and when.
Feature (short)
**Describe the request:**
1–2 sentences: what to add or build.
___
**Describe your use-case:**
Why this is needed (user pain or opportunity; 1–2 sentences).
___
**Describe functionality:**
- Bullet 1
- Bullet 2
- …
Instructions: (1) Choose the template by type. (2) Fill from the user's description and any clarification. (3) Keep text concise; leave placeholders only where the user didn't provide info.
4. Log issue via GitHub MCP (optional)
Do not log the issue to GitHub until the user has confirmed that the draft (title, body, type) looks OK. Show the draft, ask for verification, and only when the user explicitly approves (e.g. "looks good", "log it", "create the issue") proceed to create the issue.
When the user has confirmed and asks to "log" or "create" the issue on GitHub:
- Read draft: From
tmp/pm_logger/<file>.md get title and body. Strip ### Title and the title line from the body when sending to API.
- Create issue:
issue_write (method create) with owner/repo (e.g. superplanehq/superplane), title, body.
- Labels: Set one type label:
bug, enhancement, feature, or papercut (match repo labels; if repo uses different names, e.g. kind: bug, use those).
- Board: Add item to SuperPlane Board (project 2) via
projects_write (add_project_item with item_type: issue, issue_number, item_owner, item_repo).
Do not set Integration Status (that's for integration issues). Create issues sequentially to avoid rate limits. Optionally keep a small progress note in tmp/pm_logger/log-progress.md and, after user confirmation, delete only the progress file (keep draft files unless user asks to remove them).
After creating the issue: Suggest the user attach a video (e.g. screen recording) to the issue once it's created—by adding a comment with a link or uploading—to help with triage and implementation.
Summary checklist
