This mode prioritizes using repository-specific issue templates over hardcoded ones. If no templates exist in the repository, simple generic templates are created on the fly. .github/ISSUE_TEMPLATE/*.yml .github/ISSUE_TEMPLATE/*.yaml .github/ISSUE_TEMPLATE/*.md .github/issue_template.md .github/ISSUE_TEMPLATE.md Display name of the template Brief description of when to use this template Default issue title (optional) Array of labels to apply Array of default assignees Array of form elements or markdown content Static markdown content The markdown content to display Single-line text input Unique identifier Display label Help text Placeholder text Default value Boolean Multi-line text input Unique identifier Display label Help text Placeholder text Default value Boolean Language for syntax highlighting Dropdown selection Unique identifier Display label Help text Array of options Boolean Multiple checkbox options Unique identifier Display label Help text Array of checkbox items Optional YAML front matter with: - name: Template name - about: Template description - title: Default title - labels: Comma-separated or array - assignees: Comma-separated or array Markdown content with sections and placeholders Common patterns: - Headers with ## - Placeholder text in brackets or as comments - Checklists with - [ ] - Code blocks with ``` When no repository templates exist, create simple templates based on issue type. These should be minimal and focused on gathering essential information. - Description: Clear explanation of the bug - Steps to Reproduce: Numbered list - Expected Behavior: What should happen - Actual Behavior: What actually happens - Additional Context: Version, environment, logs - Code Investigation: Findings from exploration (if any) ["bug"] - Problem Description: What problem this solves - Current Behavior: How it works now - Proposed Solution: What should change - Impact: Who benefits and how - Technical Context: Code findings (if any) ["enhancement", "proposal"] When parsing YAML templates: 1. Use a YAML parser to extract the structure 2. Convert form elements to markdown sections 3. Preserve required field indicators 4. Include descriptions as help text 5. Maintain the intended flow of the template When parsing Markdown templates: 1. Extract front matter if present 2. Identify section headers 3. Look for placeholder patterns 4. Preserve formatting and structure 5. Replace generic placeholders with user's information For template selection: 1. If only one template exists, use it automatically 2. If multiple exist, let user choose based on name/description 3. Match template to issue type when possible (bug vs feature) 4. Respect template metadata (labels, assignees, etc.) Fill templates intelligently using gathered information: - Map user's description to appropriate sections - Include code investigation findings where relevant - Preserve template structure and formatting - Don't leave placeholder text unfilled - Add contributor scoping if user is contributing When no templates exist, create appropriate generic templates on the fly. Keep them simple and focused on essential information. - Don't overwhelm with too many fields - Focus on problem description first - Include technical details only if user is contributing - Use clear, simple section headers - Adapt based on issue type (bug vs feature)