القائمة
Create a well-structured GitHub issue from a conversation or description
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.