GitHub Issue Template Generator

GitHub Issue Template Generator for structured YAML forms

GitHub Issue Template Generator creates a valid issue form file for a repository. Choose a bug report, feature request, or contact link configuration, fill in the fields, and copy the resulting YAML to .github/ISSUE_TEMPLATE/. The tool quotes user data, generates unique identifiers, and enforces the core Issue Forms schema.

Issue Forms versus a classic Markdown template

GitHub supports two different mechanisms that should not be mixed. A classic Markdown template uses a .md extension, optional front matter between --- separators, and ordinary text with comments. Issue Forms are YAML documents with a .yml or .yaml extension. Their name, description, and body keys become an interactive form.

How to build an issue form

1. Select the bug or feature preset to get useful starter names, labels, and questions.
2. Adjust the name, picker description, and title prefix shown when an issue is started.
3. Enter labels and assignee usernames separated by commas. Assignees must already have repository access.
4. Define one control per line: Label | input | placeholder or Label | textarea | placeholder.
5. Copy the result to the path displayed above the output. Do not add front matter separators.
6. Commit the file and test the Issues tab. You can also check the syntax with the YAML validator.

Input and textarea controls

input works well for a short, single-line answer such as an application version, operating system, release number, or demonstration repository URL. Use textarea for a problem description, reproduction steps, expected behavior, or a proposed solution. Every generated control has validations.required: true, so a reporter cannot submit an empty answer.

A placeholder suggests a format but disappears when typing begins, so it does not replace a clear label. To show multiple lines in a textarea placeholder, enter the literal \n sequence. The generator converts it into a safely escaped newline inside a quoted YAML scalar.

Unique IDs and schema validation

Every form element needs an identifier made of letters, digits, hyphens, or underscores. The generator transliterates the label, removes unsupported characters, and limits ID length. If two controls share a label, the next one receives a suffix such as environment-2. The output therefore cannot contain duplicate control IDs.

The tool rejects an empty name or description, a form without controls, an unsupported control type, and lists above their limits. Colons, # characters, quotes, and values that resemble true are emitted as quoted scalars. They cannot become a new YAML key or comment.

Labels and default assignees

Labels route incoming work to an appropriate queue, such as bug, enhancement, or needs-triage. They must already exist in the repository or GitHub will not apply them. A username in assignees must belong to an account with sufficient access. The template neither grants permissions nor creates accounts.

A good form shortens triage but does not replace automation. Configure quality checks with the GitLab CI generator or adapt the same ideas to GitHub Actions. If the issue concerns an image build, create a reproducible example with the Dockerfile generator.

config.yml and contact links

The configuration preset creates the special .github/ISSUE_TEMPLATE/config.yml file. blank_issues_enabled: false prevents reporters from bypassing the available forms. A contact_links entry can direct questions to documentation, discussions, or support. The generator requires a complete HTTPS URL and creates one link that can be copied and expanded manually.

Do not put a token, password, or session data in that URL because the repository file is public to everyone who can read the code. Use a stable documentation page rather than a private dashboard. Projects with a more extensive build process can also use the Jenkinsfile generator to keep pipeline steps reproducible.

Better questions produce better reports

A bug report should ask for observed behavior, minimal reproduction steps, expected behavior, and environment details. A feature request should start with the user problem, then ask for a proposed solution and considered alternatives. Avoid one giant Description field that mixes facts, expectations, and context.

Never request secrets, API keys, private logs, or personal data in a public issue form. If a log is necessary, remind reporters to remove tokens and user addresses. Provide a private reporting channel for security vulnerabilities instead of collecting them in a public issue.

Frequently asked questions