hubermjonathan/engineering

Act on a pull request's review feedback: decide what each comment needs, make and verify the changes, push them, and answer every comment. Use when asked to address or fix review feedback, and when a PR gets new review comments or changes requested.

Drive a pull request to mergeable: green checks, every comment answered, required approval in. Use when asked to babysit or watch a PR, get its checks passing, or get it ready to merge.

Read and reply to pull request comments in the right place. Use when replying to a review comment, posting a comment on a PR, or when another skill needs to read or reply to a PR's feedback.

Branch, worktree, commit, and cleanup conventions. Use when making a branch or worktree, committing, pushing, or cleaning up local branches and worktrees.

Delete code comments and "what" docs so the code is the only source of truth for what it does, and docs carry only the why. Use after writing or changing code, before opening or pushing to a PR, or when asked to remove code comments or trim docs down to the why.

Open a pull request with a short title and a body in a fixed format. Use when asked to open a PR or put a change up for review, after finishing a change that needs review, or when another skill needs the PR title and body format.

Plan how to build a ready ticket before any code is written: the approach, what it touches, and the check that proves each acceptance criterion. Use when starting work on a ticket, or when asked how a change should be built.

Code-level engineering principles: smallest change, subtract first, fix root causes, prove it works, low reader load, encode repeated fixes in tooling. Use when writing, refactoring, or debugging code, or when another skill needs them.

Push new commits to an open pull request and keep the PR honest: base up to date, title and body still true. Use when pushing to a branch that has an open PR, or when a PR's title or body needs to catch up with new commits or a base change.

Get a ticket ready to build: settled requirements, checkable acceptance criteria, the technical facts a builder needs, and for a bug, a reproduction. Use when handed a ticket to refine, or when a ticket is too vague to build from.

Review a pull request or diff against the ticket that asked for it, then optionally address the findings. Use when asked to review a PR or a set of changes, or to check a change against its ticket.

Run a test plan against a deployed environment and record evidence for every step. Use when a change needs checking on staging or another environment, when handed a test plan to run, or when another skill needs before and after results.

Prove a change works before anyone reviews it: it builds, passes the checks CI will run, and does what its ticket and PR say, then write the evidence for the PR body. Use before opening or pushing to a PR, after changing code to address feedback, and when asked to verify, test, or prove a change.

Build a page that maps a GitHub PR for a human reviewer: its changes grouped by area of impact, in reading order, with the ticket's asks mapped to the diff. Use when someone wants a map of a PR before reviewing it, or asks for a PR walkthrough, summary, or review prep.

How to implement a change: smallest code that solves the problem, repo conventions first, one simplification pass before handing off. Use when implementing a plan, building a feature, fixing a bug, or making any code change.

Write a test plan an agent can run against a deployed environment, before and after a change, to prove the change works. Use when a change needs a test plan for staging or another environment, or a plan a later session can run.