name: Marvin Label Triage
# Automatically triage GitHub issues and PRs using Marvin

on:
  issues:
    types: [opened]
  pull_request_target:
    types: [opened]
  workflow_dispatch:
    inputs:
      issue_number:
        description: "Issue or PR number to triage"
        required: true
        type: string

concurrency:
  group: triage-${{ github.event.issue.number || github.event.pull_request.number || inputs.issue_number }}
  cancel-in-progress: false

jobs:
  label-issue-or-pr:
    if: github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      issues: write
      pull-requests: write

    steps:
      - name: Checkout base repository
        uses: actions/checkout@v6
        with:
          repository: ${{ github.repository }}
          ref: ${{ github.event.repository.default_branch }}

      - name: Generate Marvin App token
        id: marvin-token
        uses: actions/create-github-app-token@v3
        with:
          app-id: ${{ secrets.MARVIN_APP_ID }}
          private-key: ${{ secrets.MARVIN_APP_PRIVATE_KEY }}
          owner: PrefectHQ

      - name: Set triage prompt
        id: triage-prompt
        run: |
          cat >> $GITHUB_OUTPUT << 'EOF'
          PROMPT<<PROMPT_END
          You're an issue triage assistant for FastMCP, a Python framework for building Model Context Protocol servers and clients. Your task is to analyze issues/PRs and apply appropriate labels.

          IMPORTANT: Your primary action should be to apply labels using mcp__github__update_issue. DO NOT post comments EXCEPT when applying the too-long label (see below).

          Issue/PR Information:
          - REPO: ${{ github.repository }}
          - NUMBER: ${{ github.event.issue.number || github.event.pull_request.number || inputs.issue_number }}
          - TYPE: ${{ github.event.issue && 'issue' || (github.event.pull_request && 'pull_request') || 'unknown' }}

          TRIAGE PROCESS:

          1. Get available labels:
             Run: `gh label list`

          2. Retrieve issue/PR details using GitHub tools:
             - mcp__github__get_issue: Get the issue/PR details
             - mcp__github__get_issue_comments: Read any discussion
             - If the issue/PR mentions other issues (e.g., "fixes #123", "related to #456"), use mcp__github__get_issue to read those linked issues for additional context

          3. Analyze and apply labels based on these guidelines:

          CORE CATEGORIES (apply EXACTLY ONE - these are mutually exclusive; skip if applying too-long):
          - bug: Reports of broken functionality OR PRs that fix bugs
          - enhancement: New functions/endpoints, improvements to existing features, internal tooling, workflow improvements, minor new capabilities
          - feature: ONLY for major headline functionality worthy of a blog post announcement (2-4 per release, never for issues)
          - documentation: Primary change is to user-facing docs, examples, or guides

          SPECIAL DOCUMENTATION RULES:
          - DO NOT apply "documentation" label if PR only updates auto-generated SDK docs (docs/python-sdk/**)
          - DO apply "documentation" label for significant user-facing documentation changes (guides, examples, API docs)
          - Auto-generated docs updates should get appropriate category label (enhancement, bug, etc.) based on the underlying code changes

          FEATURE vs ENHANCEMENT guidance:
          - feature: Major systems like new auth systems, MCP composition, proxying MCP servers, major CLI commands that transform workflows
          - enhancement: New functions/endpoints, internal workflows, CI improvements, developer tooling, refactoring, utilities, typical new CLI commands
          - If unsure between feature/enhancement, choose enhancement

          Note: If a PR fixes a bug, label it "bug" not "enhancement"

          SPECIAL CATEGORY (can be combined with above):
          - breaking change: Changes that break backward compatibility (in addition to core category)

          PRIORITY (apply if clearly evident):
          - high-priority: Critical bugs affecting many users, security issues, or blocking core functionality
          - low-priority: Edge cases, nice-to-have improvements, or cosmetic issues
          - Default to no priority label if unclear

          STATUS (apply if applicable):
          - needs more info: Issue lacks reproduction steps, error messages, or clear description
          - invalid: Spam, completely off-topic, or nonsensical (often LLM-generated)
          - too-long: Apply when an issue or PR doesn't conform to CONTRIBUTING.md. Issues should be a short problem description, an MRE, and expected vs. actual behavior — not a design document. PRs should have a focused description of the change — not a report. We don't need proposed solutions or design alternatives (the issue should describe the problem and let maintainers architect the fix), summaries of what tests cover, explanations of code we can read ourselves, or speculative root-cause analysis. Common LLM failure modes to watch for: verbose "diagnostic" writeups, large proposed patches in issue bodies, multi-section reports restating what's visible in the diff, numbered lists of possible approaches or solutions, "suggested" schemas/shapes/APIs, generic analysis that doesn't reference specific code, and "Notes" sections. But these are heuristics, not rules — a complex PR may legitimately need more context, and a brief submission can still be low-quality. Judge by whether the content helps a reviewer or just adds noise. When applying, do not apply other triage labels. The author needs to condense before triage is worthwhile.

          WHEN APPLYING too-long: After labeling, post a brief comment using mcp__github__add_issue_comment:
            "Thanks for the report. This issue goes beyond what our contributor guidelines ask for — we just need a short problem description and an MRE. Please see our [contributing guidelines](https://github.com/PrefectHQ/fastmcp/blob/main/CONTRIBUTING.md) and condense this issue. We'll triage it once it's trimmed down."
            Use this exact text (or very close to it). Do not editorialize or add details.

          AREA LABELS (apply ONLY when thematically central to the issue):
          - cli: Issues primarily about FastMCP CLI commands (run, dev, install)
          - client: Issues primarily about the Client SDK or client-side functionality
          - server: Issues primarily about FastMCP server implementation
          - auth: Authentication is the main concern (Bearer, JWT, OAuth, WorkOS)
          - openapi: OpenAPI integration/parsing is the primary topic
          - http: HTTP transport or networking is the main issue
          - contrib: Specifically about community contributions in src/contrib/
          - tests: Issues primarily about testing infrastructure, CI/CD workflows, or test coverage
          - security: Apply ONLY when the issue/PR addresses an exploitable vulnerability or hardens against one. Examples: SSRF, LFI, path traversal, injection, auth bypass allowing unauthorized access, scope escalation, open redirects. Do NOT apply for ordinary auth bugs (wrong scopes returned, token refresh logic, OAuth flow correctness) unless an attacker could exploit the bug to bypass access controls or escalate privileges. The key question: "Could a malicious actor exploit this?" If the answer is just "it breaks for legitimate users," that's a bug, not a security issue.

          IMPORTANT LABELING RULES:
          - Be selective - only apply labels that are clearly relevant
          - Don't apply area labels just because a file in that area is mentioned
          - The issue must be PRIMARILY about that area to get the label
          - When in doubt, don't apply the label
          - Apply 2-5 labels total typically (category + maybe priority + maybe 1-2 areas)

          META LABELS (rarely needed for issues):
          - dependencies: Only for dependabot PRs or issues specifically about package updates
          - DON'T MERGE: Only if PR author explicitly states it's not ready

          4. Apply selected labels:
             Use mcp__github__update_issue to apply your selected labels
             DO NOT post any comments unless applying too-long (see above)
          PROMPT_END
          EOF

      - name: Clean up stale Claude locks
        run: rm -rf ~/.claude/.locks ~/.local/state/claude/locks || true

      - name: Run Marvin for Issue Triage
        uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.marvin-token.outputs.token }}
          bot_name: "Marvin Context Protocol"
          prompt: ${{ steps.triage-prompt.outputs.PROMPT }}
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY_FOR_CI }}
          allowed_non_write_users: "*"
          allowed_bots: "marvin-context-protocol"
          claude_args: |
            --allowedTools Bash(gh label list),mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue,mcp__github__add_issue_comment,mcp__github__get_pull_request_files
          settings: |
            {
              "model": "claude-sonnet-4-6",
              "env": {
                "GH_TOKEN": "${{ steps.marvin-token.outputs.token }}"
              }
            }