EngineeringRuns code work from request to ready-to-merge PRs
Engineering lead
Tell it what you want built or fixed and it splits the request into small, independently shippable tasks, puts each on a board, writes the code on a branch in its own copy of your repository and opens the pull request. A regular chase pass fixes failing checks at the root, answers review threads and rebases only when it has to, and a pull request is marked ready only after several clean passes in a row with real proof attached. It stays quiet while work is healthy, sends one short digest instead of a stream of updates, and never merges: that click is always yours.
- Works with
- GitHubNotionSlackClickUp
- Recommended model
- Claude Opus 5.5
- Skills
- 11
What it does
- Splits a request into a few small tasks that can each ship as their own pull request
- Keeps a board with one row per task and a clear stage, from Working to Ready for review
- Writes the code on its own branch, runs the tests and opens the pull request with real proof
- Chases failing checks, review threads and merge conflicts on a weekday cadence and fixes causes, not symptoms
- Only pings you when something is blocked on you, ready to merge or finished, and batches the rest into a digest
The skills it brings
Playbooks the mate follows when the job calls for them. You can read and edit every one after adding it.
/enl-onboardenl-onboardUse when setting up on the first conversation or when the person adds a repository, to learn the repo, stack, tracker, review norms, attribution and digest channel and get a working copy.
/enl-decomposeenl-decomposeUse when the person asks for something to be built, fixed or changed, to split it into a few independently shippable tasks, board them and start the work.
/enl-boardenl-boardUse when adding, moving or reading a task on the engineering board, to keep the row shape and the stage ladder consistent.
/enl-chaseenl-chaseUse when the chase routine runs or the person asks for a status pass, to check every tracked pull request, fix what you can, escalate what needs a human and stay quiet when all is healthy; also for urgent tasks.
/enl-pull-requestsenl-pull-requestsUse when opening or updating a pull request, to get the branch, title, body, proof and commit attribution right.
/enl-digestenl-digestUse when the daily digest routine runs or the person asks for a summary, to write one short status digest instead of a stream of updates.
/eng-repo-setupWorking copy setupGetting a working copy of the person's code on your computer before any engineering task: access (GitHub connector, a token they paste, or a Knowledge folder), cloning, a branch of your own, installing dependencies and a baseline test run.
/eng-writing-plansImplementation plansTurning an agreed design or a clear multi-step request into a written implementation plan before coding: files to touch, small test-first tasks with exact commands, then executing it task by task with progress ticked off in the plan.
/eng-test-driven-developmentTest-driven developmentWriting or changing code in the person's repo (a feature, a bug fix, a refactor, a behaviour change): write the test first, watch it fail for the right reason, write the least code to pass, then clean up, with the whole suite green at the end.
/eng-systematic-debuggingSystematic debuggingFixing a bug, failing test, broken build or unexpected behaviour in the person's code: find the root cause with evidence before changing anything, prove it with a failing test, fix once, verify. Use before proposing any fix.
/eng-verificationVerify before saying doneAbout to say code work is done, fixed, passing or ready (before a commit, a pull request, or a status update to the person): run the command that proves it, read the output, and report what it showed. Evidence before claims.
Things to ask it
Set up on my repo …Here's what I need built: …What's ready for me to merge?Treat this as urgent: …