Roo-Code/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml

<common_mistakes_to_avoid>
  <mode_initialization_mistakes>
    - 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
  </mode_initialization_mistakes>

  <scope_mistakes>
    - 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
  </scope_mistakes>

  <submission_mistakes>
    <mistake_block>
      <mistake>Splitting final review and submission into multiple steps</mistake>
      <impact>Creates redundant prompts and inconsistent state; leads to janky UX</impact>
      <correct_approach>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</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Not offering "Submit now and assign to me"</mistake>
      <impact>Forces manual assignment later; reduces efficiency</impact>
      <correct_approach>Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit <issue-url-or-number> --add-assignee "@me"</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Using temporary files or --body-file for issue body submission</mistake>
      <impact>Introduces filesystem dependencies and leaks paths; contradicts single-command policy</impact>
      <correct_approach>Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Omitting --repo or relying on current directory defaults</mistake>
      <impact>May submit to the wrong repository in multi-repo or worktree contexts</impact>
      <correct_approach>Always pass --repo [OWNER_REPO] detected in Step 2</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Attempting submission without prior repository detection</mistake>
      <impact>Commands may target the wrong repo or fail</impact>
      <correct_approach>Detect git repo and ensure origin is configured before any gh commands</correct_approach>
    </mistake_block>
  </submission_mistakes>

  <sourcing_mistakes>
    <mistake_block>
      <mistake>Inventing or inferring “Variations tried” when the user didn’t provide any</mistake>
      <impact>Misleads triage and wastes time reproducing non-existent attempts</impact>
      <correct_approach>Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Framing only the problem without the value/impact</mistake>
      <impact>Makes prioritization harder; obscures who benefits and why it matters</impact>
      <correct_approach>Pair the problem with a plain-language value statement (who, when, why it matters)</correct_approach>
    </mistake_block>
    <mistake_block>
      <mistake>Overstating impact without user signal</mistake>
      <impact>Damages credibility and misguides prioritization</impact>
      <correct_approach>Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question</correct_approach>
    </mistake_block>
  </sourcing_mistakes>

  <problem_reporting_mistakes>
    - 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
  </problem_reporting_mistakes>

  <output_mistakes>
    - 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
  </output_mistakes>

  <code_exploration_mistakes>
    <mistake>Skipping semantic search and jumping straight to assumptions</mistake>
    <impact>Leads to misclassification and inaccurate context</impact>
    <correct_approach>
      - 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
    </correct_approach>
  </code_exploration_mistakes>

  <discrepancy_handling_mistakes>
    <mistake>Accepting user claims that contradict the codebase without verification</mistake>
    <impact>Produces misleading or incorrect issue framing</impact>
    <correct_approach>
      - 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
    </correct_approach>
  </discrepancy_handling_mistakes>

  <questioning_mistakes>
    - 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)
  </questioning_mistakes>

  <consistency_mistakes>
    - 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
  </consistency_mistakes>
</common_mistakes_to_avoid>