gh-create-issuelisted

# Create issue File an issue a maintainer three years from now can act on without asking you anything. Argument: $ARGUMENTS — a description, a repository, a pasted finding, or nothing. The body follows `references/rendered-markdown.md` and every link in it follows `references/source-links.md`. Read both before drafting. ## Core principle Evidence before prose. An issue is worth filing when it carries something the maintainer cannot reconstruct: the exact command, the exact version, the line that does it, the output that proves it. Everything else is a paragraph asking them to do the investigation again. ## Phase 1 — Resolve the target repository It is often not the one you are standing in. Take it from the argument when given; otherwise resolve it from the checkout's remote: ``` gh repo view "$(git remote get-url origin)" --json nameWithOwner --jq .nameWithOwner ``` With more than one GitHub remote, list them with `git remote -v` and ask which one the issue belongs to. Do not use a bare `gh repo view` or `gh issue` to decide: they sort remotes upstream before origin, so on a fork clone they answer with the upstream project. (`gh repo set-default --view` prints to stderr and exits 0 when no default is configured, so empty output there means "no default", not "no repository".) Pass `--repo OWNER/REPO` on every command from here. ## Phase 2 — Decide it belongs in a public issue A vulnerability does not. Check the resolved repository's policy before anything else: `