Enable Claude PR workflows via tt-pipeline-github-actions

[OG-Stan]

Summary

Adds two GitHub Actions workflows that wire this repo into the shared Claude PR tooling in tt-pipeline-github-actions. Both files are thin callers — ~20 lines each, no logic. The workflow bodies, prompts and coding standards live upstream and are maintained centrally.

pr-review.yaml — automatic code review

When it runs. On pull_request [opened, ready_for_review] — when a PR is first opened (including as a draft) and when a draft is marked ready for review. synchronize and reopened are deliberately excluded, so it does not re-review on every push. On demand any time via a top-level PR comment containing @claude-review.

Context it reads first, in order of authority:

1. CLAUDE.md in the repo root — authoritative project rules, architecture, conventions
2. Bundled coding standards, selected by the languages actually in the diff (java-standards.md, typescript-standards.md, python-standards.md, cpp-standards.md) — standards for untouched languages are skipped
3. README.md as fallback if neither exists

Anything found there is treated as source of truth; the generic review guidance applies only where the project is silent.

What it looks for:

• Project-rule compliance (highest priority) — import patterns, framework conventions, language style, error handling, logging, testing practices, naming, as defined by your CLAUDE.md / standards
• Bugs — logic errors, null/undefined handling, race conditions, resource leaks, security vulnerabilities, performance problems
• Code quality — significant issues only: duplication, missing critical error handling
• Typos — variable names, comments, strings, Javadoc, log messages
• Unused imports
• Modern idioms — outdated patterns where a modern language feature fits better (e.g. Java 21 records, sealed classes, pattern matching, switch expressions, text blocks, var)
• High-value test coverage gaps — new branching logic with non-trivial conditions, error/exception paths, boundary conditions, public API surface changes, bug fixes without a regression test, concurrency/retry/state-transition logic. Explicitly not chasing 100% coverage: trivial getters/setters, pure delegation, generated code, and no-behaviour-change refactors are skipped

Noise control. Every candidate issue is scored 0–100 and filtered aggressively:

Confidence	Meaning	Action
0–25	likely false positive or pre-existing	not reported
26–50	minor nit not in your project rules	not reported
51–75	valid but low impact	not reported
76–89	important, needs attention	reported as [important]
90–100	critical bug or explicit rule violation	reported as [critical]

Only findings ≥76 are posted. If it's uncertain something is an issue, it stays silent.

Output format. Line-specific findings are posted as inline review comments on the exact lines, each starting with its severity and score — [critical] (conf: 95) — followed by the problem and a concrete fix, using GitHub suggestion blocks where the change fits in a few lines. Stylistic issues a formatter or linter would catch are skipped. By default there is no top-level summary comment; only genuine PR-wide design concerns surface at the top level, and inline findings are never recapped there.

Both the standards and the review prompt are overridable per repo, no caller change needed: .github/standards/<language>-standards.md replaces the bundled file of that name, .github/prompt-override.md overrides parts of the prompt itself.

pr-fix.yaml — address review feedback

On demand only. Never runs automatically. Add a comment containing @claude-fix:

• reply inside a review thread → targeted mode: fixes only that one thread
• top-level PR comment → fixes every unresolved thread on the PR

How it reads feedback. Threads come from the GitHub GraphQL API, because REST review comments don't expose resolution state. For each unresolved thread it reads the whole thread rather than just the first comment, and prefers the latest human instruction when comments disagree. Resolved threads are ignored completely, even if they contain useful suggestions. Outdated threads get the current file at HEAD inspected first — if the code already addresses the feedback, no cosmetic change is made just to touch the line. Top-level comments are treated as context only, unless they clearly request a concrete change not covered by a thread.

How it edits. It builds a short worklist from the unresolved threads and fixes each actionable item, keeping edits minimal and consistent with existing patterns — no unrelated refactors, no broad formatting churn, no speculative improvements. If feedback asks for tests, it adds or updates focused tests. If a request is ambiguous, it takes the smallest reasonable interpretation and leaves a comment explaining the assumption.

Validation. Runs the smallest command that exercises the affected module and tests. If validation can't run in the workflow, it says so in its final comment rather than staying quiet about it.

Commit and push. If nothing needed changing, it commits nothing and posts a comment explaining the feedback was already addressed or non-actionable. Otherwise it commits, then fetches and rebases to detect anyone pushing between checkout and push. If that rebase fails it does not force-push — it skips the push entirely and tells you the branch changed under it, asking you to re-trigger. No AI attribution footer in the commit message. Fork PRs are skipped.

Closing the loop. It posts a summary of which threads it addressed and what validation ran, then resolves exactly the threads whose feedback it actually fixed. Threads it skipped or couldn't address stay open for you.

Fix prompt is overridable per repo via .github/fix-override.md.

[svc-ttghsnyk]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.