disable Claude GitHub Actions workflows

[danielchalef]

Summary

Removes the three GitHub Actions workflows that invoke Anthropic Claude Code on issues and pull requests.

Type of Change

• Bug fix
• New feature
• Performance improvement
• Documentation/Tests (CI/config only)

Objective

Stop automated and manual Claude-based CI from running in this repository (cost, maintenance, or policy).

Removed workflows:

• claude.yml — @claude on issues, PR comments, and reviews
• claude-code-review.yml — automatic PR code review on trusted authors / needs-review label
• claude-code-review-manual.yml — workflow_dispatch manual PR review

Not changed: pr-triage.yml still uses claude-code-action for PR triage. Say if that should be disabled too.

Testing

• Unit tests added/updated
• Integration tests added/updated
• All existing tests pass (workflow file deletion only; no code changes)

Breaking Changes

• This PR contains breaking changes

Maintainers and collaborators can no longer invoke @claude via GitHub Actions, and automatic Claude PR reviews will not run. Restore from git history or re-add the workflow files to re-enable.

Checklist

• Code follows project style guidelines (make lint passes)
• Self-review completed
• Documentation updated where necessary
• No secrets or sensitive information committed

Related Issues

N/A

  

[zep-cla-assistant]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. For privacy information, see our Privacy Notice. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA behalf on myself, e-mail: example@example.com

or

I have read the CLA Document and I hereby sign the CLA behalf of my company, e-mail: example@example.com

Signature is valid for 6 months.

---

_{This bot will be retriggered when the Contributor License Agreement comment has been provided. Posted by the CLA Assistant Lite bot.}

[github-actions]

Claude finished @danielchalef's task in 37s —— View job

---

PR Review: disable Claude GitHub Actions workflows

• Read the diff and understand the request
• Check for dangling references to the deleted workflows
• Verify no docs/README updates are needed
• Post review

---

This PR deletes three workflow files (claude.yml, claude-code-review.yml, claude-code-review-manual.yml) — 319 lines removed, no code changes. I reviewed it as a config-only change.

Findings

No blocking issues. The deletion is clean:

• ✅ Grepped the repo for references to the deleted workflow filenames — none found. No other workflow, script, or doc invokes or needs: these files, so nothing breaks.
• ✅ Grepped *.md (README, CONTRIBUTING, etc.) for @claude / needs-review — no references to the removed capabilities, so no documentation update is required.
• ✅ No test impact — these are CI workflow definitions, not application code.

Suggestions

• Suggestion (confidence: high): pr-triage.yml still uses anthropics/claude-code-action@... in two jobs (lines 135 and 268). The PR body already flags this as intentionally out of scope — just confirming it: if the objective is to stop all Claude-based CI (cost/policy), pr-triage.yml will keep incurring it. If the goal is only to remove the @claude-invocation and auto-review paths, leaving pr-triage.yml is consistent. Your call — no change needed unless you want triage disabled too.

• Suggestion (confidence: medium): The needs-review label was a trigger for claude-code-review.yml. After this merges, that label becomes a no-op. Consider removing it from the repo's label set (or any label-automation docs) to avoid confusion, though this is purely cosmetic and not required.

• Note: The PR checklist has "No secrets or sensitive information committed" left unchecked. For a pure deletion of workflow files this is fine — no secrets are involved — so it can safely be checked.

Summary

The change does exactly what it describes and leaves the repo in a consistent state. The only open decision is whether pr-triage.yml should also be disabled, which the author has already surfaced for maintainer input.