- Asking "What would you like to do?" at start instead of treating the first message as the issue description - Delaying the workflow with unnecessary questions before discovery - Not immediately beginning codebase-aware discovery (semantic search → regex refine → read key files) - Skipping repository detection (git + origin) before discovery or submission - Not validating repository context before gh commands - Submitting without explicit user confirmation ("Submit now") - Targeting the wrong repository by relying on current directory defaults; always pass --repo OWNER/REPO detected in Step 2 - Performing PR prep, complexity estimates, or technical scoping Splitting final review and submission into multiple steps Creates redundant prompts and inconsistent state; leads to janky UX Use a single merged "Review and Submit" step offering only: Submit now, Submit now and assign to me; treat any other response as a change request Not offering "Submit now and assign to me" Forces manual assignment later; reduces efficiency Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit --add-assignee "@me" Using temporary files or --body-file for issue body submission Introduces filesystem dependencies and leaks paths; contradicts single-command policy Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths Omitting --repo or relying on current directory defaults May submit to the wrong repository in multi-repo or worktree contexts Always pass --repo [OWNER_REPO] detected in Step 2 Attempting submission without prior repository detection Commands may target the wrong repo or fail Detect git repo and ensure origin is configured before any gh commands Inventing or inferring “Variations tried” when the user didn’t provide any Misleads triage and wastes time reproducing non-existent attempts Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first Framing only the problem without the value/impact Makes prioritization harder; obscures who benefits and why it matters Pair the problem with a plain-language value statement (who, when, why it matters) Overstating impact without user signal Damages credibility and misguides prioritization Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question - Vague descriptions like "doesn't work" without who/when impact - Missing minimal reproduction for bugs (environment, steps, expected, actual, variations) - Enhancement requests that skip the user goal or desired behavior in plain language - Titles/summaries that don't quickly communicate the issue - Including code paths, line numbers, stack traces, or diffs in the final issue body - Adding labels, metadata, or repository details to the body - Leaving empty section placeholders instead of omitting the section - Using technical jargon instead of plain, user-centric language Skipping semantic search and jumping straight to assumptions Leads to misclassification and inaccurate context - Start with codebase_search on extracted keywords - Refine with search_files for exact strings (errors, component names, flags) - read_file only as needed to verify behavior; keep evidence internal - Early-stop when hits converge or you can name the exact feature/component - Escalate-once if signals conflict (one refined pass), then proceed Accepting user claims that contradict the codebase without verification Produces misleading or incorrect issue framing - Verify claims against the implementation; trace data from creation → usage - Compare with similar working features to ground expectations - If discrepancies arise, present concrete, plain-language examples (no code) and confirm - Asking broad, unfocused questions instead of targeted ones based on findings - Demanding technical details from non-technical users - Failing to provide easy, suggested answer formats (repro scaffold, goal statement) - Mixing internal technical evidence into the final body - Ignoring the issue format or adding extra sections - Using inconsistent tone or switching between technical and non-technical language