create-issuelisted

# Create GitHub Issue Create well-structured GitHub issues from user descriptions through interactive clarification. ## Repository Detection Detect the repository from the current git remote using your platform's CLI. Examples: ```bash # GitHub lane (CODE_HOST=github): REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner') # GitLab lane (CODE_HOST=gitlab): REPO=$(glab repo view -F json | jq -r '.path_with_namespace') ``` Both split into `OWNER` and `REPO_NAME` (or `NAMESPACE` and `PROJECT` on GitLab). If detection fails, ask the user for the target repository. ## Process ### Step 1: Understand the Request When the user describes a feature or bug, gather context through clarifying questions. Do NOT create the issue immediately. **For features, clarify:** - What is the user-facing goal? (not implementation details) - What are the acceptance criteria? (how to verify it works) - **For each acceptance criterion, is it _pre-merge verifiable_?** Can its evidence be obtained before the PR merges, from a surface the autonomous dev/review agents can reach — a CI job, a PR-preview URL, a staging command, a local repro? Prefer pre-merge-verifiable ACs and have the author **name the surface + expected evidence**. If a criterion is *not* pre-merge verifiable (needs deploy/prod, real users, a time soak, an external approval, prod telemetry, or credentials the bot lacks), first check whether an existing PR-preview/staging path already covers the same code path