Menu
Create a well-structured GitHub issue from a conversation or description
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.
Basé sur la classification professionnelle SOC
Add an SSH public key to a remote server's authorized_keys file
Save working documents to .context/ with proper frontmatter
Rebase a contributor's PR onto latest main. Fetches the PR, creates a backup branch on origin, sets up a worktree, analyzes divergence, rebases, and force-pushes back to the contributor's fork. Use when a PR needs to be brought up to date with main.
Merge source branch (default main) to production, create a CalVer release, and generate release content (GitHub release notes, Discord announcement, blog post)
Analyze branch commits, identify fixup candidates, rebase with autosquash, and post a PR comment explaining the cleanup.
Link or unlink a local library for testing in a consumer project. Handles build, npm install from path, and cleanup. Default action is "link". Use "unlink" to reverse.
| name | create-issue |
| description | Create a well-structured GitHub issue from a conversation or description |
Help create well-structured GitHub issues from conversations, bug reports, or feature ideas.
Use the current git repo by default:
gh repo view --json nameWithOwner -q .nameWithOwner
If $ARGUMENTS includes a repo reference (e.g., schemalabz/opencouncil-tasks), use that instead.
Before drafting, ALWAYS search GitHub for related existing issues and PRs:
gh search issues "<relevant keywords>" --repo <REPO> --limit 5
gh search prs "<relevant keywords>" --repo <REPO> --limit 5
If related issues exist, present them:
Only proceed with creating a new issue if the user confirms it is distinct.
Always fetch the current labels from GitHub before assigning them:
gh label list --repo <REPO> --limit 50
Use the actual labels returned. Do not hardcode or assume label names.
Every issue gets one type label:
Bad: "Implement this using a Redis cache with a 5-minute TTL on the /api/search endpoint" Good: "Search results for repeated queries could benefit from caching to reduce response times"
If the description is brief or vague, ask 2-3 focused follow-up questions to understand:
Keep it conversational, not bureaucratic.
When someone reports a bug:
Based on what the user said (or $ARGUMENTS):
Show the user a formatted preview:
ISSUE PREVIEW
Title: <concise, action-oriented title>
Body:
### Concept
<1-3 paragraphs: what this is about and why it matters>
### User Story
As a <role>, I want <goal>, so that <benefit>.
### Context
<any relevant context — existing behavior, related features, constraints>
Labels: <label1>, <label2>
Ask: "Reply yes to create, edit to change something, or cancel to abort."
After user confirms:
gh issue create --repo <REPO> --title "<TITLE>" --body "<BODY>" --label "<label1>" --label "<label2>"
Report the issue URL back to the user.