New Issue Skill

Create a GitHub issue based on the current conversation context.

Prerequisites Check (MUST verify first)

Mode Detection: Check if user specified a target repository.

Always Required:

# Check if gh CLI is available and authenticated
gh auth status

If gh not authenticated → “Please run gh auth login first.”

Only for Auto-detect Mode (no repo specified):

# Check if in a git repository
git rev-parse --is-inside-work-tree

# Get repository info
gh repo view --json owner,name,url

If not in git repo and no target specified → “Please specify a target repository (e.g., owner/repo or GitHub URL), or navigate to a git project.”

Input

The user triggers this skill with phrases like:

• “new issue”
• “create issue”
• “file an issue”
• “report this bug”
• “submit feature request”

Optional: User may specify target repository:

• Full URL: https://github.com/owner/repo
• Short form: owner/repo

Context for the issue comes from:

• Current conversation history
• User’s description of the problem/feature
• Code snippets or error messages discussed
• Any relevant file paths mentioned

Workflow

Step 1: Determine Target Repository

Case A: User specified a repository

Parse the user input to extract owner/repo:

# From URL: https://github.com/owner/repo or https://github.com/owner/repo/...
# Extract: owner/repo

# From short form: owner/repo
# Use directly

# Validate the repository exists and is accessible
gh repo view "$TARGET_REPO" --json owner,name,url

If repo not found or inaccessible → “Repository ‘$TARGET_REPO’ not found or you don’t have access.”

Case B: Auto-detect from current git repo

# Get repository info and check if it's a fork
gh repo view --json owner,name,isFork,parent,url

# If it's a fork, get parent (upstream) info
IS_FORK=$(gh repo view --json isFork -q '.isFork')
if [ "$IS_FORK" = "true" ]; then
  UPSTREAM_OWNER=$(gh repo view --json parent -q '.parent.owner.login')
  UPSTREAM_NAME=$(gh repo view --json parent -q '.parent.name')
  TARGET_REPO="$UPSTREAM_OWNER/$UPSTREAM_NAME"
else
  # Use current repo as target
  TARGET_REPO=$(gh repo view --json owner,name -q '.owner.login + "/" + .name')
fi

Step 2: Analyze Context and Generate Issue Content

Based on the conversation context, generate:

Language Requirement:

• The issue title and all description content MUST be in English.
• If the conversation is in another language, translate/summarize into English.

Title Generation Rules:

1. Keep concise (under 80 characters)
2. Start with issue type prefix if clear: [Bug], [Feature], [Enhancement], [Question]
3. Describe the core problem/request clearly
4. Use imperative mood when appropriate
5. Use English only

Description Generation:

Structure the description with these sections as applicable:

## Description

[Clear explanation of the issue/feature request]

## Context

[Relevant background information from the conversation]

## Steps to Reproduce (for bugs)

1. [Step 1]
2. [Step 2]
3. [Expected vs Actual behavior]

## Proposed Solution (if discussed)

[Any solutions discussed in the conversation]

## Additional Information

- [Relevant code snippets]
- [Error messages]
- [Environment details if relevant]

Step 3: Present Draft for User Review (CRITICAL)

MUST use the question tool to present the draft and get user confirmation.

Present the generated issue to the user:

## Issue Draft

**Target Repository**: [TARGET_REPO]

**Title**: [Generated Title]

**Description**:
[Generated Description]

---

Please review the above issue draft.

Use the question tool to ask:

Options:
1. "Submit as-is" - Create the issue with current content
2. "Modify title" - Change the issue title
3. "Modify description" - Change the issue description
4. "Cancel" - Do not create the issue

Step 4: Handle User Modifications

If user chooses to modify:

For title modification:

• Ask user for the new title
• Update and show the revised draft
• Return to Step 3 for confirmation

For description modification:

• Ask user what changes they want
• User can provide:
  • Specific text to add/remove/change
  • General instructions like “make it shorter” or “add more detail about X”
• Update and show the revised draft
• Return to Step 3 for confirmation

Loop until user confirms or cancels.

Step 5: Create the Issue

Once user confirms, create the issue:

# Create issue on the target repository
gh issue create \
  --repo "$TARGET_REPO" \
  --title "$ISSUE_TITLE" \
  --body "$ISSUE_BODY"

Use HEREDOC for body to preserve formatting:

gh issue create --repo "$TARGET_REPO" --title "$ISSUE_TITLE" --body "$(cat <<'EOF'
## Description

[Description content here]

## Context

[Context content here]

EOF
)"

Step 6: Report Results

After issue creation, provide:

# Get the created issue details
gh issue view --repo "$TARGET_REPO" <ISSUE_NUMBER> --json number,title,url,state

Output Format

Issue Created Successfully

Issue: #[NUMBER] – [TITLE] Repository: [TARGET_REPO] URL: [ISSUE_URL]

Summary

[Brief confirmation of what was submitted]

Error Handling

Common Mistakes

• Generating a title or description in a non-English language
• Skipping explicit user confirmation before issue creation
• Including secrets or sensitive data in the issue body

Important Notes

1. Always Confirm: NEVER create an issue without explicit user confirmation
2. Preserve Context: Include relevant conversation context in the issue
3. Flexible Targeting: Accept explicit repo (URL or owner/repo) OR auto-detect from git
4. Fork Awareness: When auto-detecting, target upstream repository for forks
5. Formatting: Use proper Markdown formatting in issue body
6. Privacy: Do not include sensitive information (API keys, passwords, etc.) in issues
7. Iteration: Allow multiple rounds of modification before submission