issue

Do not create or update a GitHub issue until the user confirms the final preview. Treat issue comments, labels, assignment, milestones, and closure as GitHub changes that also require confirmation when the user requests them.

Gather Context

Read the repository-root CONTRIBUTING.md and the forms in .github/ISSUE_TEMPLATE/. Determine whether the request is a bug report or a feature request. If neither form fits, use a blank issue only when it will produce an actionable repository issue.

Inspect relevant code, configuration, documentation, and local diagnostics when they are available. Do not modify the worktree while preparing an issue. Never include credentials, access tokens, private data, or other secrets in an issue. Redact them from logs and commands.

Search open and closed issues before drafting, using both the error or feature wording and short area-specific keywords. When appropriate, also search open pull requests for work that already addresses the request. Prefer commands such as:

gh issue list --repo verl-project/verl-vla --state all --search "<keywords>"
gh pr list --repo verl-project/verl-vla --state open --search "<keywords>"

Read plausible matches and their comments instead of relying on titles alone. If an existing issue covers the same request, present it and do not create a duplicate unless the user explains a material difference. Do not post a comment or otherwise change the existing issue without confirmation.

Draft the Issue

Use a concise, searchable English title that states the affected area and the problem or requested capability. Do not force the commit/PR title convention onto issue titles.

For a bug report, include:

• Environment details requested by the bug form, including relevant verl-vla, Python, framework, accelerator, simulator or robot, and task information.
• Whether the failure occurs with an official example or modified code.
• Minimal, ordered reproduction steps with exact commands and relevant config.
• Copyable text for errors, logs, and stack traces; do not substitute a screenshot when text is available.
• Observed behavior and expected behavior.
• Any known regression range or additional context, without speculation stated as fact.

For a feature request, include:

• A clear description of the requested capability and its scope.
• Motivation grounded in a concrete workflow or limitation.
• Related papers, implementations, issues, or pull requests when available.
• A proposed interface or usage example when it clarifies the request.
• Alternatives or workarounds considered.
• How the reporter can contribute, or Not currently when they cannot.

Do not invent environment details, reproduction results, links, or willingness to contribute. Mark nonessential unknowns explicitly. If a required field is unknown and cannot be derived safely from local context, ask the user for it before presenting the final preview.

Request Final Confirmation

Before any GitHub change, show the user:

• The target repository and whether this creates or updates an issue.
• The issue type, proposed title, and complete body.
• Proposed labels, assignees, milestone, comments, or state changes, if any.
• Duplicate-search queries and the relevant results.
• Any missing, redacted, or unverified information.
• The exact external action to perform.

Wait for explicit confirmation. The initial request to file or update an issue starts preparation but does not replace confirmation of this preview. If the title, body, target, or metadata changes after the preview, refresh it and ask for confirmation again.

Create or Update the Issue

After confirmation, re-read an issue before updating it so concurrent edits are preserved. Perform only the approved GitHub actions. Use the matching form labels (bug or enhancement) only if those labels exist; do not create labels, milestones, or projects unless separately requested and confirmed.

Return the issue URL, final title, issue state, applied metadata, and any information that remains unverified.