Create or revise an issue
An issue describes a problem or missing capability. A PR describes a proposed change.
Keep their writing rules separate. For PRs, use create-pr.
Title
Use a concise statement of the problem, naming the affected behavior. Do not use an
imperative change request such as "Fix", "Add", "Enable", or "Keep" as the default.
- "Visitor country is unavailable to upstream apps"
- "GeoIP data becomes stale on running installations"
- "Login returns to the wrong page after checkout"
Body
Follow the repository's issue template and the user's requested format. Otherwise use:
## Problem
One or two sentences naming the failure and its effect.
## Reproduction
1. The relevant setup or version.
2. The smallest steps that demonstrate the problem.
## Current behavior
What was observed, with a short error or result when useful.
## Desired behavior
The outcome the reporter needs.
For a missing feature, reproduce the current workflow that exposes the gap. If the
problem was not reproduced, say so instead of inventing steps or results. Add environment
details, evidence, or a proposed approach only when they help a maintainer act. Keep a
possible implementation separate from the desired outcome.
Remove repeated explanations, promotional claims, conversation history, full diagnostic
dumps, and details that do not help reproduce or resolve the issue. A few useful sections
are better than a long narrative or a checklist of every investigation step.
Publish or update
Inspect repository guidance and templates, search for an existing issue, and verify the
claims before publishing. When revising, read the current issue and preserve useful
attachments, links, and user edits. Do not expand an issue's scope without user direction.
Use gh issue create or gh issue edit with --title and --body-file. Read back the
published title and body. Link related PRs, but use a closing reference only when the PR
addresses the issue's complete desired outcome.