@anh3d0nic/qwen-code-termux-ice 14.0.0 → 16.0.0

package/.github/workflows/qwen-automated-issue-triage.yml

@@ -1,203 +0,0 @@
-name: 'Qwen Automated Issue Triage'
-
-on:
-  issues:
-    types:
-      - 'opened'
-      - 'reopened'
-  issue_comment:
-    types:
-      - 'created'
-  workflow_dispatch:
-    inputs:
-      issue_number:
-        description: 'issue number to triage'
-        required: true
-        type: 'number'
-
-concurrency:
-  group: '${{ github.workflow }}-${{ github.event.issue.number || github.event.inputs.issue_number }}'
-  cancel-in-progress: true
-
-defaults:
-  run:
-    shell: 'bash'
-
-permissions:
-  contents: 'read'
-  id-token: 'write'
-  issues: 'write'
-  statuses: 'write'
-  packages: 'read'
-  actions: 'write' # Required for cancelling a workflow run
-
-jobs:
-  triage-issue:
-    timeout-minutes: 5
-    if: |-
-      ${{ github.repository == 'QwenLM/qwen-code' }}
-    runs-on: 'ubuntu-latest'
-    steps:
-      - name: 'Run Qwen Issue Analysis'
-        uses: 'QwenLM/qwen-code-action@5fd6818d04d64e87d255ee4d5f77995e32fbf4c2'
-        id: 'qwen_issue_analysis'
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-          ISSUE_TITLE: '${{ github.event.issue.title }}'
-          ISSUE_BODY: '${{ github.event.issue.body }}'
-          ISSUE_NUMBER: '${{ github.event.issue.number }}'
-          REPOSITORY: '${{ github.repository }}'
-        with:
-          OPENAI_API_KEY: '${{ secrets.OPENAI_API_KEY }}'
-          OPENAI_BASE_URL: '${{ secrets.OPENAI_BASE_URL }}'
-          OPENAI_MODEL: '${{ secrets.OPENAI_MODEL }}'
-          settings_json: |-
-            {
-              "maxSessionTurns": 25,
-              "coreTools": [
-                "run_shell_command"
-              ],
-              "sandbox": false
-            }
-          prompt: |-
-            ## Role
-
-            You are an issue triage assistant. Analyze the current GitHub issue
-            and identify the most appropriate existing labels by only using the provided data. Use the available
-            tools to gather information; do not ask for information to be
-            provided. Do not remove the following labels titled maintainer,  help wanted or good first issue.
-
-            ## Steps
-
-            1. Run: `gh label list --repo ${{ github.repository }} --limit 100` to get all available labels.
-            2. Use shell command `echo` to check the issue title and body provided in the environment variables: "${ISSUE_TITLE}" and "${ISSUE_BODY}".
-            3. Ignore any existing priorities or tags on the issue. Just report your findings.
-            4. Select the most relevant labels from the existing labels, focusing on type/*, category/*, scope/*, status/* and priority/*. For category/* and type/* limit yourself to only the single most applicable label in each case.
-            6. Apply the selected labels to this issue using: `gh issue edit ${{ github.event.issue.number }} --repo ${{ github.repository }} --add-label "label1,label2"`.
-            7. For each issue please check if CLI version is present, this is usually in the output of the /about command  and will look like 0.1.5 for anything more than 6 versions older than the most recent should add the status/need-retesting label.
-            8. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label.
-            9. Use Category and Scope definitions mentioned below to help you narrow down issues.
-
-            ## Guidelines
-
-            - Only use labels that already exist in the repository
-            - Do not add comments or modify the issue content
-            - Triage only the current issue
-            - Identify only one category/ label
-            - Identify only one type/ label
-            - Identify all applicable scope/*, status/* and priority/* labels based on the issue content. It's ok to have multiple of these
-            - Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario
-            - Reference all shell variables as "${VAR}" (with quotes and braces)
-            - Output only valid JSON format
-            - Do not include any explanation or additional text, just the JSON
-
-            Categorization Guidelines:
-            P0: Critical / Blocker
-            - A P0 bug is a catastrophic failure that demands immediate attention.
-            - To be a P0 it means almost all users are running into this issue and it is blocking users from being able to use the product.
-            - You would see this in the form of many comments from different developers on the bug.
-            - It represents a complete showstopper for a significant portion of users or for the development process itself.
-            Impact:
-            - Blocks development or testing for the entire team.
-            - Major security vulnerability that could compromise user data or system integrity.
-            - Causes data loss or corruption with no workaround.
-            - Crashes the application or makes a core feature completely unusable for all or most users in a production environment. Will it cause severe quality degration? Is it preventing contributors from contributing to the repository or is it a release blocker?
-            Qualifier: Is the main function of the software broken?
-            Example: The qwen auth login command fails with an unrecoverable error, preventing any user from authenticating and using the rest of the CLI.
-            P1: High
-            - A P1 bug is a serious issue that significantly degrades the user experience or impacts a core feature.
-            - While not a complete blocker, it's a major problem that needs a fast resolution. Feature requests are almost never P1.
-            - Once again this would be affecting many users.
-            - You would see this in the form of comments from different developers on the bug.
-            Impact:
-            - A core feature is broken or behaving incorrectly for a large number of users or large number of use cases.
-            - Review the bug details and comments to try figure out if this issue affects a large set of use cases or if it's a narrow set of use cases.
-            - Severe performance degradation making the application frustratingly slow.
-            - No straightforward workaround exists, or the workaround is difficult and non-obvious.
-            Qualifier: Is a key feature unusable or giving very wrong results?
-            Example: Qwen Code enters a loop when making read-many-files tool call. I am unable to break out of the loop and qwen doesn't follow instructions subsequently.
-            P2: Medium
-            - A P2 bug is a moderately impactful issue. It's a noticeable problem but doesn't prevent the use of the software's main functionality.
-            Impact:
-            - Affects a non-critical feature or a smaller, specific subset of users.
-            - An inconvenient but functional workaround is available and easy to execute.
-            - Noticeable UI/UX problems that don't break functionality but look unprofessional (e.g., elements are misaligned or overlapping).
-            Qualifier: Is it an annoying but non-blocking problem?
-            Example: An error message is unclear or contains a typo, causing user confusion but not halting their workflow.
-            P3: Low
-            - A P3 bug is a minor, low-impact issue that is trivial or cosmetic. It has little to no effect on the overall functionality of the application.
-            Impact:
-            - Minor cosmetic issues like color inconsistencies, typos in documentation, or slight alignment problems on a non-critical page.
-            - An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
-            Qualifier: Is it a "nice-to-fix" issue?
-            Example: Spelling mistakes etc.
-            Things you should know:
-            - If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue
-            - This product is designed to use different models eg.. using pro, downgrading to flash etc. when users report that they dont expect the model to change those would be categorized as feature requests.
-            Definition of Categories and Scopes
-
-            category/cli: Command line interface and interaction
-            - Issues with interactive CLI features, command parsing, keyboard shortcuts
-            - Related scopes: scope/commands, scope/interactive, scope/non-interactive, scope/keybindings
-
-            category/core: Core engine and logic
-            - Issues with fundamental components, content generation, session management
-            - Related scopes: scope/content-generation, scope/token-management, scope/session-management, scope/model-switching
-
-            category/ui: User interface and display
-            - Issues with themes, UI components, rendering, markdown display
-            - Related scopes: scope/themes, scope/components, scope/rendering, scope/markdown
-
-            category/authentication: Authentication and authorization
-            - Issues with login flows, API keys, OAuth, credential storage
-            - Related scopes: scope/oauth, scope/api-keys, scope/token-storage
-
-            category/tools: Tool integration and execution
-            - Issues with MCP, shell execution, file operations, web search, memory, git integration
-            - Related scopes: scope/mcp, scope/shell, scope/file-operations, scope/web-search, scope/memory, scope/git
-
-            category/configuration: Configuration management
-            - Issues with settings, extensions, trusted folders, sandbox configuration
-            - Related scopes: scope/settings, scope/extensions, scope/trusted-folders, scope/sandbox
-
-            category/integration: External integrations
-            - Issues with IDE integration, VSCode extension, Zed integration, GitHub Actions
-            - Related scopes: scope/ide, scope/vscode, scope/zed, scope/github-actions
-
-            category/platform: Platform compatibility
-            - Issues with installation, OS compatibility, packaging
-            - Related scopes: scope/installation, scope/macos, scope/windows, scope/linux, scope/packaging
-
-            category/performance: Performance and optimization
-            - Issues with latency, memory usage, model performance, caching
-            - Related scopes: scope/latency, scope/memory-usage, scope/model-performance, scope/caching
-
-            category/security: Security and privacy
-            - Issues with data privacy, credential security, vulnerabilities
-            - Related scopes: scope/data-privacy, scope/credential-security, scope/vulnerability
-
-            category/telemetry: Telemetry and analytics
-            - Issues with metrics collection, logging, analytics
-            - Related scopes: scope/metrics, scope/logging, scope/analytics
-
-            category/development: Development experience
-            - Issues with build system, testing, CI/CD, documentation
-            - Related scopes: scope/build-system, scope/testing, scope/ci-cd, scope/documentation
-
-      - name: 'Post Issue Analysis Failure Comment'
-        if: |-
-          ${{ failure() && steps.qwen_issue_analysis.outcome == 'failure' }}
-        uses: 'actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea' # ratchet:actions/github-script@v7
-        env:
-          ISSUE_NUMBER: '${{ github.event.issue.number }}'
-          REPOSITORY: '${{ github.repository }}'
-          RUN_URL: '${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}'
-        with:
-          github-token: '${{ secrets.GITHUB_TOKEN }}'
-          script: |-
-            github.rest.issues.createComment({
-              owner: process.env.REPOSITORY.split('/')[0],
-              repo: process.env.REPOSITORY.split('/')[1],
-              issue_number: parseInt(process.env.ISSUE_NUMBER),
-              body: 'There is a problem with the Qwen Code issue analysis. Please check the [action logs](${process.env.RUN_URL}) for details.'
-            })

package/.github/workflows/qwen-code-pr-review.yml

@@ -1,190 +0,0 @@
-name: '🧐 Qwen Pull Request Review'
-
-on:
-  pull_request_target:
-    types: ['opened']
-  pull_request_review_comment:
-    types: ['created']
-  pull_request_review:
-    types: ['submitted']
-  workflow_dispatch:
-    inputs:
-      pr_number:
-        description: 'PR number to review'
-        required: true
-        type: 'number'
-
-jobs:
-  review-pr:
-    if: |-
-      github.event_name == 'workflow_dispatch' ||
-      (github.event_name == 'pull_request_target' &&
-       github.event.action == 'opened' &&
-       (github.event.pull_request.author_association == 'OWNER' ||
-        github.event.pull_request.author_association == 'MEMBER' ||
-        github.event.pull_request.author_association == 'COLLABORATOR')) ||
-      (github.event_name == 'issue_comment' &&
-        github.event.issue.pull_request &&
-        contains(github.event.comment.body, '@qwen /review') &&
-        (github.event.comment.author_association == 'OWNER' ||
-         github.event.comment.author_association == 'MEMBER' ||
-         github.event.comment.author_association == 'COLLABORATOR')) ||
-      (github.event_name == 'pull_request_review_comment' &&
-        contains(github.event.comment.body, '@qwen /review') &&
-        (github.event.comment.author_association == 'OWNER' ||
-         github.event.comment.author_association == 'MEMBER' ||
-         github.event.comment.author_association == 'COLLABORATOR')) ||
-      (github.event_name == 'pull_request_review' &&
-        contains(github.event.review.body, '@qwen /review') &&
-        (github.event.review.author_association == 'OWNER' ||
-         github.event.review.author_association == 'MEMBER' ||
-         github.event.review.author_association == 'COLLABORATOR'))
-    timeout-minutes: 15
-    runs-on: 'ubuntu-latest'
-    permissions:
-      contents: 'read'
-      id-token: 'write'
-      pull-requests: 'write'
-      issues: 'write'
-    steps:
-      - name: 'Checkout PR code'
-        uses: 'actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8' # ratchet:actions/checkout@v5
-        with:
-          token: '${{ secrets.GITHUB_TOKEN }}'
-          fetch-depth: 0
-
-      - name: 'Get PR details (pull_request_target & workflow_dispatch)'
-        id: 'get_pr'
-        if: |-
-          ${{ github.event_name == 'pull_request_target' || github.event_name == 'workflow_dispatch' }}
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-        run: |-
-          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
-            PR_NUMBER=${{ github.event.inputs.pr_number }}
-          else
-            PR_NUMBER=${{ github.event.pull_request.number }}
-          fi
-          echo "pr_number=$PR_NUMBER" >> "$GITHUB_OUTPUT"
-          # Get PR details
-          PR_DATA=$(gh pr view $PR_NUMBER --json title,body,additions,deletions,changedFiles,baseRefName,headRefName)
-          echo "pr_data=$PR_DATA" >> "$GITHUB_OUTPUT"
-          # Get file changes
-          CHANGED_FILES=$(gh pr diff $PR_NUMBER --name-only)
-          echo "changed_files<<EOF" >> "$GITHUB_OUTPUT"
-          echo "$CHANGED_FILES" >> "$GITHUB_OUTPUT"
-          echo "EOF" >> "$GITHUB_OUTPUT"
-
-      - name: 'Get PR details (issue_comment)'
-        id: 'get_pr_comment'
-        if: |-
-          ${{ github.event_name == 'issue_comment' }}
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-          COMMENT_BODY: '${{ github.event.comment.body }}'
-        run: |-
-          PR_NUMBER=${{ github.event.issue.number }}
-          echo "pr_number=$PR_NUMBER" >> "$GITHUB_OUTPUT"
-          # Extract additional instructions from comment
-          ADDITIONAL_INSTRUCTIONS=$(echo "$COMMENT_BODY" | sed 's/.*@qwen \/review//' | xargs)
-          echo "additional_instructions=$ADDITIONAL_INSTRUCTIONS" >> "$GITHUB_OUTPUT"
-          # Get PR details
-          PR_DATA=$(gh pr view $PR_NUMBER --json title,body,additions,deletions,changedFiles,baseRefName,headRefName)
-          echo "pr_data=$PR_DATA" >> "$GITHUB_OUTPUT"
-          # Get file changes
-          CHANGED_FILES=$(gh pr diff $PR_NUMBER --name-only)
-          echo "changed_files<<EOF" >> "$GITHUB_OUTPUT"
-          echo "$CHANGED_FILES" >> "$GITHUB_OUTPUT"
-          echo "EOF" >> "$GITHUB_OUTPUT"
-
-      - name: 'Run Qwen PR Review'
-        uses: 'QwenLM/qwen-code-action@5fd6818d04d64e87d255ee4d5f77995e32fbf4c2'
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-          PR_NUMBER: '${{ steps.get_pr.outputs.pr_number || steps.get_pr_comment.outputs.pr_number }}'
-          PR_DATA: '${{ steps.get_pr.outputs.pr_data || steps.get_pr_comment.outputs.pr_data }}'
-          CHANGED_FILES: '${{ steps.get_pr.outputs.changed_files || steps.get_pr_comment.outputs.changed_files }}'
-          ADDITIONAL_INSTRUCTIONS: '${{ steps.get_pr.outputs.additional_instructions || steps.get_pr_comment.outputs.additional_instructions }}'
-          REPOSITORY: '${{ github.repository }}'
-        with:
-          OPENAI_API_KEY: '${{ secrets.OPENAI_API_KEY }}'
-          OPENAI_BASE_URL: '${{ secrets.OPENAI_BASE_URL }}'
-          OPENAI_MODEL: '${{ secrets.OPENAI_MODEL }}'
-          settings_json: |-
-            {
-              "coreTools": [
-                "run_shell_command",
-                "write_file"
-              ],
-              "sandbox": false
-            }
-          prompt: |-
-            You are an expert code reviewer. You have access to shell commands to gather PR information and perform the review.
-
-            IMPORTANT: Use the available shell commands to gather information. Do not ask for information to be provided.
-
-            Start by running these commands to gather the required data:
-            1. Run: echo "$PR_DATA" to get PR details (JSON format)
-            2. Run: echo "$CHANGED_FILES" to get the list of changed files
-            3. Run: echo "$PR_NUMBER" to get the PR number
-            4. Run: echo "$ADDITIONAL_INSTRUCTIONS" to see any specific review instructions from the user
-            5. Run: gh pr diff $PR_NUMBER to see the full diff
-            6. For any specific files, use: cat filename, head -50 filename, or tail -50 filename
-
-            Additional Review Instructions:
-            If ADDITIONAL_INSTRUCTIONS contains text, prioritize those specific areas or focus points in your review.
-            Common instruction examples: "focus on security", "check performance", "review error handling", "check for breaking changes"
-
-            Once you have the information, provide a comprehensive code review by:
-            1. Writing your review to a file: write_file("review.md", "<your detailed review feedback here>")
-            2. Posting the review: gh pr comment $PR_NUMBER --body-file review.md --repo $REPOSITORY
-
-            Review Areas:
-            - **Security**: Authentication, authorization, input validation, data sanitization
-            - **Performance**: Algorithms, database queries, caching, resource usage
-            - **Reliability**: Error handling, logging, testing coverage, edge cases
-            - **Maintainability**: Code structure, documentation, naming conventions
-            - **Functionality**: Logic correctness, requirements fulfillment
-
-            Output Format:
-            Structure your review using this exact format with markdown:
-
-            ## 📋 Review Summary
-            Provide a brief 2-3 sentence overview of the PR and overall assessment.
-
-            ## 🔍 General Feedback
-            - List general observations about code quality
-            - Mention overall patterns or architectural decisions
-            - Highlight positive aspects of the implementation
-            - Note any recurring themes across files
-
-            ## 🎯 Specific Feedback
-            Only include sections below that have actual issues. If there are no issues in a priority category, omit that entire section.
-
-            ### 🔴 Critical
-            (Only include this section if there are critical issues)
-            Issues that must be addressed before merging (security vulnerabilities, breaking changes, major bugs):
-            - **File: `filename:line`** - Description of critical issue with specific recommendation
-
-            ### 🟡 High
-            (Only include this section if there are high priority issues)
-            Important issues that should be addressed (performance problems, design flaws, significant bugs):
-            - **File: `filename:line`** - Description of high priority issue with suggested fix
-
-            ### 🟢 Medium
-            (Only include this section if there are medium priority issues)
-            Improvements that would enhance code quality (style issues, minor optimizations, better practices):
-            - **File: `filename:line`** - Description of medium priority improvement
-
-            ### 🔵 Low
-            (Only include this section if there are suggestions)
-            Nice-to-have improvements and suggestions (documentation, naming, minor refactoring):
-            - **File: `filename:line`** - Description of suggestion or enhancement
-
-            **Note**: If no specific issues are found in any category, simply state "No specific issues identified in this review."
-
-            ## ✅ Highlights
-            (Only include this section if there are positive aspects to highlight)
-            - Mention specific good practices or implementations
-            - Acknowledge well-written code sections
-            - Note improvements from previous versions

package/.github/workflows/qwen-scheduled-issue-triage.yml

@@ -1,213 +0,0 @@
-name: 'Qwen Scheduled Issue Triage'
-
-on:
-  schedule:
-    - cron: '0 * * * *' # Runs every hour
-  workflow_dispatch:
-
-concurrency:
-  group: '${{ github.workflow }}'
-  cancel-in-progress: true
-
-defaults:
-  run:
-    shell: 'bash'
-
-permissions:
-  id-token: 'write'
-  issues: 'write'
-
-jobs:
-  triage-issues:
-    timeout-minutes: 10
-    if: |-
-      ${{ github.repository == 'QwenLM/qwen-code' }}
-    runs-on: 'ubuntu-latest'
-    permissions:
-      contents: 'read'
-      id-token: 'write'
-      issues: 'write'
-    steps:
-      - name: 'Find untriaged issues'
-        id: 'find_issues'
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-          GITHUB_REPOSITORY: '${{ github.repository }}'
-        run: |-
-          echo "🔍 Finding issues without labels..."
-          NO_LABEL_ISSUES=$(gh issue list --repo ${{ github.repository }} --search "is:open is:issue no:label" --json number,title,body)
-
-          echo '🔍 Finding issues without labels...'
-          NO_LABEL_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \
-            --search 'is:open is:issue no:label' --json number,title,body)"
-
-          echo '🏷️ Finding issues that need triage...'
-          NEED_TRIAGE_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \
-            --search "is:open is:issue label:\"status/need-triage\""  --limit 1000 --json number,title,body)"
-
-          echo '🔄 Merging and deduplicating issues...'
-          ISSUES="$(echo "${NO_LABEL_ISSUES}" "${NEED_TRIAGE_ISSUES}" | jq -c -s 'add | unique_by(.number)')"
-
-          echo '📝 Setting output for GitHub Actions...'
-          echo "issues_to_triage=${ISSUES}" >> "${GITHUB_OUTPUT}"
-
-      - name: 'Run Qwen Issue Triage'
-        if: |-
-          ${{ steps.find_issues.outputs.issues_to_triage != '[]' }}
-        uses: 'QwenLM/qwen-code-action@5fd6818d04d64e87d255ee4d5f77995e32fbf4c2'
-        env:
-          GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
-          ISSUES_TO_TRIAGE: '${{ steps.find_issues.outputs.issues_to_triage }}'
-          REPOSITORY: '${{ github.repository }}'
-        with:
-          OPENAI_API_KEY: '${{ secrets.OPENAI_API_KEY }}'
-          OPENAI_BASE_URL: '${{ secrets.OPENAI_BASE_URL }}'
-          OPENAI_MODEL: '${{ secrets.OPENAI_MODEL }}'
-          settings_json: |-
-            {
-              "maxSessionTurns": 25,
-              "coreTools": [
-                "run_shell_command(echo)"
-              ],
-              "sandbox": false
-            }
-          prompt: |-
-            ## Role
-
-            You are an issue triage assistant. Analyze issues and identify
-            appropriate labels. Use the available tools to gather information;
-            do not ask for information to be provided.
-
-            ## Steps
-
-            1. Run: `gh label list --repo ${{ github.repository }} --limit 100` to get all available labels.
-            2. Use shell command `echo` to check environment variable for issues to triage: $ISSUES_TO_TRIAGE (JSON array of issues)
-            3. Review the issue title, body and any comments provided in the environment variables.
-            4. Ignore any existing priorities or tags on the issue.
-            5. Select the most relevant labels from the existing labels, focusing on type/*, category/*, scope/*, status/* and priority/*.
-            6. Get the list of labels already on the issue using `gh issue view ISSUE_NUMBER --repo ${{ github.repository }} --json labels -t '{{range .labels}}{{.name}}{{"\n"}}{{end}}'
-            7. For category/* and type/* limit yourself to only the single most applicable label in each case.
-            8. Give me a single short paragraph about why you are selecting each label in the process. use the format Issue ID: , Title, Label applied:, Label removed, ovearll explanation
-            9. Parse the JSON array from step 2 and for EACH INDIVIDUAL issue, apply appropriate labels using separate commands:
-              - `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --add-label "label1"`
-              - `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --add-label "label2"`
-              - Continue for each label separately
-              - IMPORTANT: Label each issue individually, one command per issue, one label at a time if needed.
-              - Make sure after you apply labels there is only one category/* and one type/* label per issue.
-              - To do this look for labels found in step 6 that no longer apply remove them one at a time using
-              - `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "label-name1"`
-              - `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "label-name2"`
-              - IMPORTANT: Remove each label one at a time, one command per issue if needed.
-            10. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5
-              - Anything more than 6 versions older than the most recent should add the status/need-retesting label
-            11. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label
-              - After applying appropriate labels to an issue, remove the "status/need-triage" label if present: `gh issue edit ISSUE_NUMBER --repo ${{ github.repository }} --remove-label "status/need-triage"`
-              - Execute one `gh issue edit` command per issue, wait for success before proceeding to the next
-            Process each issue sequentially and confirm each labeling operation before moving to the next issue.
-
-            ## Guidelines
-
-            - Output only valid JSON format
-            - Do not include any explanation or additional text, just the JSON
-            - Only use labels that already exist in the repository.
-              - Do not add comments or modify the issue content.
-              - Do not remove the following labels maintainer, help wanted or good first issue.
-              - Triage only the current issue.
-              - Identify only one category/ label
-              - Identify only one type/ label (Do not apply type/duplicate or type/parent-issue)
-              - Identify all applicable scope/*, status/* and priority/* labels based on the issue content. It's ok to have multiple of these.
-              - Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario.
-            Categorization Guidelines:
-            P0: Critical / Blocker
-              - A P0 bug is a catastrophic failure that demands immediate attention.
-              - To be a P0 it means almost all users are running into this issue and it is blocking users from being able to use the product.
-              - You would see this in the form of many comments from different developers on the bug.
-              - It represents a complete showstopper for a significant portion of users or for the development process itself.
-            Impact:
-              - Blocks development or testing for the entire team.
-              - Major security vulnerability that could compromise user data or system integrity.
-              - Causes data loss or corruption with no workaround.
-              - Crashes the application or makes a core feature completely unusable for all or most users in a production environment. Will it cause severe quality degration?
-              - Is it preventing contributors from contributing to the repository or is it a release blocker?
-              Qualifier: Is the main function of the software broken?
-              Example: The gemini auth login command fails with an unrecoverable error, preventing any user from authenticating and using the rest of the CLI.
-            P1: High
-              - A P1 bug is a serious issue that significantly degrades the user experience or impacts a core feature.
-              - While not a complete blocker, it's a major problem that needs a fast resolution. Feature requests are almost never P1.
-              - Once again this would be affecting many users.
-              - You would see this in the form of comments from different developers on the bug.
-              Impact:
-              - A core feature is broken or behaving incorrectly for a large number of users or large number of use cases.
-              - Review the bug details and comments to try figure out if this issue affects a large set of use cases or if it's a narrow set of use cases.
-              - Severe performance degradation making the application frustratingly slow.
-              - No straightforward workaround exists, or the workaround is difficult and non-obvious.
-              Qualifier: Is a key feature unusable or giving very wrong results?
-              Example: Gemini CLI enters a loop when making read-many-files tool call. I am unable to break out of the loop and gemini doesn't follow instructions subsequently.
-            P2: Medium
-              - A P2 bug is a moderately impactful issue. It's a noticeable problem but doesn't prevent the use of the software's main functionality.
-              Impact:
-              - Affects a non-critical feature or a smaller, specific subset of users.
-              - An inconvenient but functional workaround is available and easy to execute.
-              - Noticeable UI/UX problems that don't break functionality but look unprofessional (e.g., elements are misaligned or overlapping).
-              Qualifier: Is it an annoying but non-blocking problem?
-              Example: An error message is unclear or contains a typo, causing user confusion but not halting their workflow.
-            P3: Low
-              - A P3 bug is a minor, low-impact issue that is trivial or cosmetic. It has little to no effect on the overall functionality of the application.
-              Impact:
-              - Minor cosmetic issues like color inconsistencies, typos in documentation, or slight alignment problems on a non-critical page.
-              - An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
-              Qualifier: Is it a "nice-to-fix" issue?
-              Example: Spelling mistakes etc.
-            Additional Context:
-              - If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue
-              - This product is designed to use different models eg.. using pro, downgrading to flash etc.
-              - When users report that they dont expect the model to change those would be categorized as feature requests.
-            Definition of Categories and Scopes
-
-            category/cli: Command line interface and interaction
-            - Issues with interactive CLI features, command parsing, keyboard shortcuts
-            - Related scopes: scope/commands, scope/interactive, scope/non-interactive, scope/keybindings
-
-            category/core: Core engine and logic
-            - Issues with fundamental components, content generation, session management
-            - Related scopes: scope/content-generation, scope/token-management, scope/session-management, scope/model-switching
-
-            category/ui: User interface and display
-            - Issues with themes, UI components, rendering, markdown display
-            - Related scopes: scope/themes, scope/components, scope/rendering, scope/markdown
-
-            category/authentication: Authentication and authorization
-            - Issues with login flows, API keys, OAuth, credential storage
-            - Related scopes: scope/oauth, scope/api-keys, scope/token-storage
-
-            category/tools: Tool integration and execution
-            - Issues with MCP, shell execution, file operations, web search, memory, git integration
-            - Related scopes: scope/mcp, scope/shell, scope/file-operations, scope/web-search, scope/memory, scope/git
-
-            category/configuration: Configuration management
-            - Issues with settings, extensions, trusted folders, sandbox configuration
-            - Related scopes: scope/settings, scope/extensions, scope/trusted-folders, scope/sandbox
-
-            category/integration: External integrations
-            - Issues with IDE integration, VSCode extension, Zed integration, GitHub Actions
-            - Related scopes: scope/ide, scope/vscode, scope/zed, scope/github-actions
-
-            category/platform: Platform compatibility
-            - Issues with installation, OS compatibility, packaging
-            - Related scopes: scope/installation, scope/macos, scope/windows, scope/linux, scope/packaging
-
-            category/performance: Performance and optimization
-            - Issues with latency, memory usage, model performance, caching
-            - Related scopes: scope/latency, scope/memory-usage, scope/model-performance, scope/caching
-
-            category/security: Security and privacy
-            - Issues with data privacy, credential security, vulnerabilities
-            - Related scopes: scope/data-privacy, scope/credential-security, scope/vulnerability
-
-            category/telemetry: Telemetry and analytics
-            - Issues with metrics collection, logging, analytics
-            - Related scopes: scope/metrics, scope/logging, scope/analytics
-
-            category/development: Development experience
-            - Issues with build system, testing, CI/CD, documentation
-            - Related scopes: scope/build-system, scope/testing, scope/ci-cd, scope/documentation