principal-engineer-review

Files (4)

• SKILL.md
• README.md · evals/
• evals.json · evals/
• trigger-queries.json · evals/

SKILL.md (first lines)

# Principal Engineer Review

## Mission

Provide a high-signal review of local changes with emphasis on business impact and long-term maintainability.

## Scope

- Review current local diff and adjacent context.
- Focus on material risks, not style trivia.

## Review Workflow

1. Discover review context.
- Read the current branch with `git branch --show-current`.
- Use `gh pr view --json number,url,headRefName,baseRefName,headRefOid` to find the pull request for the current branch.
- Treat a PR as present only when `headRefName` matches the current branch. If `gh` is unavailable, unauthenticated, or no matching PR exists, continue with the local review and markdown output.

2. Understand intent.
- What business problem is being solved now?
- What is explicitly out of scope?

3. Inspect changed behavior.
- correctness and edge cases
- authorization and data handling
- error paths and rollback behavior
- coupling, ownership, and maintenance burden

4. Check for overbuilding.
- speculative abstractions
- premature optimization
- unnecessary dependencies
- duplicate primitives instead of reuse

5. Validate evidence.
- tests for changed behavior
- operational safety (timeouts, retries, idempotency where relevant)
- migration/deploy safety where relevant

6. Produce decision.
- ready for handoff
- needs changes before handoff

## Output Format

If a matching PR exists:
- Do not create or update `reports/principal-engineer-review.md`.
- Add one inline PR review comment for each blocking or non-blocking finding when its location is commentable in the PR diff. Include the risk and concrete fix direction.
- Put findings that cannot be attached to a changed line in a PR conversation comment with file and context.
- Add a final PR conversation comment containing the decision, a concise findings summary, what looks right, and suggested next steps.
- Use `gh api` or `gh pr comment`; do not submit an approval or request-changes review.

If no matching PR exists, write `reports/principal-engineer-review.md` with:
- Decision
- Blocking findings (ordered by severity)
- Non-blocking findings
- What looks right
- Suggested next steps

Each finding should include: file, line/context, risk, and concrete fix direction.

## Guardrails

- Prefer smallest responsible change.
- Require evidence for claims.
- Do not invent requirements not implied by the change.
- Keep feedback concise and actionable.

From veverkap/skills, MIT.

More from veverkap/skills