The GitHub CLI (gh) provides comprehensive tools for interacting with GitHub. Here's when and how to use each command in the issue creation workflow. Note: This mode prioritizes using repository-specific issue templates over hardcoded ones. Templates are detected and used dynamically from the repository. ALWAYS use this FIRST before creating any issue to check for duplicates. Search for keywords from the user's problem description. gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20 --search: Search query for issue titles and bodies --state: all, open, or closed --label: Filter by specific labels --limit: Number of results to show --json: Get structured JSON output Use for more advanced searches across issues and pull requests. Supports GitHub's advanced search syntax. gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10 Use when you find a potentially related issue and need full details. Check if the user's issue is already reported or related. gh issue view 123 --repo $REPO_FULL_NAME --comments --comments: Include issue comments --json: Get structured data --web: Open in browser Use to check for issue templates in the repository before creating issues. This is not a gh command but necessary for template detection. Check for templates in standard location: .github/ISSUE_TEMPLATE true Check for single template file: .github false Read template files to parse their structure and content. Used after detecting template files. Read YAML template: .github/ISSUE_TEMPLATE/bug_report.yml Read Markdown template: .github/ISSUE_TEMPLATE/feature_request.md These commands should ONLY be used if the user has indicated they want to contribute the implementation. Skip these for problem reporters. Get repository information and recent activity. gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt Check recent PRs that might be related to the issue. Look for PRs that modified relevant code. gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all For bug reports from contributors, check recent commits that might have introduced the issue. Use after cloning the repository locally. git log --oneline --grep="theme" -n 20 Only use after: 1. Confirming no duplicates exist 2. Checking for and using repository templates 3. Gathering all required information 4. Determining if user is contributing or just reporting 5. Getting user confirmation gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug" gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" --title: Issue title (required) --body: Issue body text --body-file: Read body from file --label: Add labels (can use multiple times) --assignee: Assign to user --project: Add to project --web: Open in browser to create ONLY use if user wants to add additional information after creation. gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments." Use if user realizes they need to update the issue after creation. Can update title, body, or labels. gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]" After user selects issue type, immediately search for related issues: 1. Use `gh issue list --search` with keywords from their description 2. Show any similar issues found 3. Ask if they want to continue or comment on existing issue Template detection (NEW): 1. Use list_files to check .github/ISSUE_TEMPLATE/ directory 2. Read any template files found (YAML or Markdown) 3. Parse template structure and metadata 4. If multiple templates, let user choose 5. If no templates, prepare to create generic one Decision point for contribution: 1. Ask user if they want to contribute implementation 2. If yes: Use contributor commands for codebase investigation 3. If no: Skip directly to creating a problem-focused issue 4. This saves time for problem reporters During codebase exploration (CONTRIBUTORS ONLY): 1. Clone repo locally if needed: `gh repo clone $REPO_FULL_NAME` 2. Use `git log` to find recent changes to affected files 3. Use `gh search prs` for related pull requests 4. Include findings in the technical context section When creating the issue: 1. Use repository template if found, or generic template if not 2. Fill template with gathered information 3. Format differently based on contributor vs problem reporter 4. Save formatted body to temporary file 5. Use `gh issue create` with appropriate labels from template 6. Capture the returned issue URL 7. Show user the created issue URL When creating issues with long bodies: 1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'` 2. Use --body-file flag with gh issue create 3. Clean up after: `rm /tmp/issue_body.md` Use specific search terms: - Include error messages in quotes - Use label filters when appropriate - Limit results to avoid overwhelming output Use --json flag for structured data when needed: - Easier to parse programmatically - Consistent format across commands - Example: `gh issue list --json number,title,state` If search finds exact duplicate: - Show the existing issue to user using `gh issue view` - Ask if they want to add a comment instead - Use `gh issue comment` if they agree If `gh issue create` fails: - Check error message (auth, permissions, network) - Ensure gh is authenticated: `gh auth status` - Save the drafted issue content for user - Suggest using --web flag to create in browser Ensure GitHub CLI is authenticated: - Check status: `gh auth status` - Login if needed: `gh auth login` - Select appropriate scopes for issue creation gh issue create - Create new issue gh issue list - List and search issues gh issue view - View issue details gh issue comment - Add comment to issue gh issue edit - Edit existing issue gh issue close - Close an issue gh issue reopen - Reopen closed issue gh search issues - Search issues and PRs gh search prs - Search pull requests gh search repos - Search repositories gh repo view - View repository info gh repo clone - Clone repository When parsing YAML templates: - Extract 'name' for template identification - Get 'labels' array for automatic labeling - Parse 'body' array for form elements - Convert form elements to markdown sections - Preserve 'required' field indicators When parsing Markdown templates: - Check for YAML front matter - Extract metadata (labels, assignees) - Identify section headers - Replace placeholder text - Maintain formatting structure 1. Detect templates with list_files 2. Read templates with read_file 3. Parse structure and metadata 4. Let user choose if multiple exist 5. Fill template with information 6. Create issue with template content