Repository navigation
[Process] Add structured issue forms for bug reports and feature requests #462
Description
Summary
BrowserSkill currently has no repository-specific issue templates on the default branch (d9a78ae). Bug reports and feature requests therefore start from a blank editor, so environment details, reproduction steps, and compatibility information are not collected consistently.
Adding GitHub Issue Forms would make reports easier to reproduce and reduce the initial clarification round for maintainers.
Current state
The repository tree contains no .github/ISSUE_TEMPLATE/ directory, and a search of existing open and closed issues found no prior request for issue templates.
This is a contribution-process improvement; it does not require any runtime or release behavior change.
Proposed forms
Bug report
Required fields:
- BrowserSkill version or commit
- operating system and architecture
- installation method
- browser and browser-extension version, when applicable
- exact command or API call
- minimal reproduction steps
- expected and actual behavior
- relevant logs with secrets removed
- whether the behavior is a regression
Feature request
Required fields:
- problem or use case
- proposed behavior
- alternatives considered
- affected CLI/API surface
- compatibility considerations
Configuration
Add .github/ISSUE_TEMPLATE/config.yml to:
- keep or disable blank issues deliberately;
- link to the official community for usage questions;
- direct vulnerability reports to the repository's private security-reporting path instead of a public issue.
Acceptance criteria
- Bug reports and feature requests appear as separate choices under New issue.
- Bug reports collect enough information for a maintainer to attempt reproduction without a first-round environment question.
- Feature requests describe the user problem rather than only a proposed implementation.
- The forms remind reporters to search for duplicates and redact credentials/tokens.
- Security-reporting guidance does not encourage publishing vulnerability details in a normal issue.
Non-goals
- Automatically labeling or assigning maintainers.
- Changing the existing issue taxonomy.
- Preventing contributors from reporting issues that do not fit the forms.
Activity
legend91019 commentedon Oct 18, 2026
I would like to take this issue.
Proposed Plan
Add GitHub Issue Forms under .github/ISSUE_TEMPLATE/:
XY-code1 commentedon Oct 18, 2026
@legend91019 Thanks for taking this on — the implementation covers the scope of #462 well. One small usability consideration: logs in the bug form and the CLI/API + compatibility fields in the feature form are currently required. Some reporters may not have logs or know which internal surface is affected, so making those optional (or explicitly allowing “N/A”) could reduce friction.
feat(process): make logs and internal surface fields optional
legend91019 commentedon Oct 18, 2026
@XY-code1 Great feedback, thank you! I have updated the forms accordingly in PR #464 (commit
87283aa):bug_report.yml: Made the relevant logs/diagnostics field optional (required: false) with guidance that it can be left blank or filled with "N/A" if unavailable.feature_request.yml: Made both the Affected CLI / API Surface and Compatibility Considerations fields optional (required: false) with explicit "N/A if unknown" hints so reporters unfamiliar with internal components aren't blocked from submitting.XY-code1 commentedon Oct 18, 2026
@legend91019 Thanks for the update! I reviewed the changes and they address my concerns well. Making these fields optional while keeping the N/A guidance strikes a good balance between structured reports and ease of submission.
feat(process): add structured issue forms for bug reports and feature…