What issue are you seeing?
The CLI issue form defines description twice for the same terminal-emulator input field:
- type: input
id: terminal
attributes:
label: What terminal emulator and version are you using (if applicable)?
description: Also note any multiplexer in use (screen / tmux / zellij)
description: |
E.g, VSCode, Terminal.app, iTerm2, Ghostty, Windows Terminal (WSL / PowerShell)
In YAML, duplicate mapping keys are ambiguous and common parsers keep the latter value. In practice, the multiplexer guidance can be discarded by the second description key.
What steps can reproduce the bug?
- Inspect
.github/ISSUE_TEMPLATE/3-cli.yml.
- Parse the issue templates with duplicate-key detection.
The duplicate is reported at lines 43 and 44 in the current template.
What is the expected behavior?
The terminal-emulator field should have one description key that preserves both pieces of guidance:
- ask for any multiplexer in use;
- provide examples such as VS Code, Terminal.app, iTerm2, Ghostty, and Windows Terminal.
Additional information
This is a small repo-metadata fix, not a runtime behavior change. A minimal patch would combine the two descriptions into one block scalar.
Because external PRs are invitation-only per docs/contributing.md, I am not opening an unsolicited PR, but I have the two-line template cleanup prepared locally if maintainers want it.
What issue are you seeing?
The CLI issue form defines
descriptiontwice for the same terminal-emulator input field:In YAML, duplicate mapping keys are ambiguous and common parsers keep the latter value. In practice, the multiplexer guidance can be discarded by the second
descriptionkey.What steps can reproduce the bug?
.github/ISSUE_TEMPLATE/3-cli.yml.The duplicate is reported at lines 43 and 44 in the current template.
What is the expected behavior?
The terminal-emulator field should have one
descriptionkey that preserves both pieces of guidance:Additional information
This is a small repo-metadata fix, not a runtime behavior change. A minimal patch would combine the two descriptions into one block scalar.
Because external PRs are invitation-only per
docs/contributing.md, I am not opening an unsolicited PR, but I have the two-line template cleanup prepared locally if maintainers want it.