feat: Add lint-pr-title workflow

[gjtorikian]

Summary

• Adds a lint-pr-title workflow using amannn/action-semantic-pull-request to enforce conventional commit format on PR titles
• Uses the SDK bot app token (via actions/create-github-app-token) for authentication, consistent with the release-please workflow
• This ensures PR titles follow the conventional commits spec, which is required for release-please to generate correct changelogs and version bumps

Test plan

• Open a PR with a non-conventional title (e.g., "update something") and verify the check fails
• Open a PR with a valid conventional title (e.g., "feat: add feature") and verify the check passes

🤖 Generated with Claude Code

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a new GitHub Actions workflow (.github/workflows/lint-pr-title.yml) that runs on PR activity and uses amannn/action-semantic-pull-request to enforce Conventional Commits formatting on pull request titles. The workflow currently triggers on pull_request_target and mints a GitHub App token via actions/create-github-app-token, then passes that token to the semantic PR title linter, aligning with the repo’s release automation expectations (release-please relies on conventional metadata).

Confidence Score: 3/5

• Mergeable after adjusting the workflow to avoid exposing elevated tokens on fork-triggered events.
• The workflow is small and conceptually correct, but pull_request_target combined with a minted GitHub App token unnecessarily increases the blast radius for untrusted PRs. Switching to pull_request and/or removing the app token (and setting minimal explicit permissions) would make this low-risk.
• .github/workflows/lint-pr-title.yml

Important Files Changed

Filename	Overview
.github/workflows/lint-pr-title.yml	Adds a PR title lint workflow using pull_request_target and a minted GitHub App token; main concern is unnecessary elevated token exposure for forked PRs.

Sequence Diagram

sequenceDiagram
  participant PR as Pull Request
  participant GH as GitHub Actions
  participant WF as Lint PR Title workflow
  participant Tok as create-github-app-token
  participant Lint as action-semantic-pull-request

  PR->>GH: pull_request_target (opened/edited/synchronize)
  GH->>WF: Start job
  WF->>Tok: Generate GitHub App installation token
  Tok-->>WF: token
  WF->>Lint: Validate PR title (uses GITHUB_TOKEN env)
  Lint-->>WF: Pass/Fail status
  WF-->>GH: Report check result

Loading

[greptile-apps]

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

pull_request_target token risk
Using pull_request_target plus a generated GitHub App token exposes a write-capable token to workflows triggered by PRs from forks. Even though this workflow doesn’t check out or run PR code, the token is still available to the action and could be abused if the action is compromised or misconfigured. Prefer pull_request (read-only token is sufficient to read PR title) or avoid minting an app token here unless a specific API permission is required.

[greptile-apps]

Unnecessary App token use
action-semantic-pull-request can run with the default GITHUB_TOKEN for pull_request events; generating an SDK bot app token here increases blast radius if anything in the job leaks env vars. If you keep pull_request_target, consider removing the app token step and use the default token with minimal permissions: explicitly set (e.g., pull-requests: read).