Engineer like Corbin Crutchley #

You ask an AI agent to fix a bug. Along the way, it has to decide what to reuse, which tests are worth writing, and where to explain the change so the next person can understand it.

That's a lot of decisions hiding inside “fix this bug.”

These skills help your agent approach those decisions with Corbin's engineering preferences: keep the people using the software in mind, explain the reasoning, and leave the project easier to work on. They cover everything from choosing a web stack to writing a README that helps someone get started. Yes, including this one. 😉

A skill is a reusable set of instructions for a particular kind of work. Pick the ones that help with your task; you don't need to adopt the whole collection.

Give it a try #

Install with the skills CLI:

npx skills add crutchcorn/skills

Choose the skills you want to use and the agent you want to use them with. Then give your agent a concrete task. For example:

Use $test-like-corbin to cover this bug: when saving a profile fails, the form loses everything I typed.

That gives the agent a problem worth protecting against. The testing skill guides it toward exercising the form as a person would: enter some details, try to save, encounter an error, and check that the details are still there for another attempt.

Now we've given it both the problem and an approach to solving it.

Find the skill for your task #

Skill	What it helps you do
Write Like Corbin	Explain an idea with clear examples, visible reasoning, and a little personality.
Docs Like Corbin	Help people use your project and find the context behind its decisions.
Git Like Corbin	Keep changes easy to review, with explicit rules against rewriting history, force pushes, discarding work, and pushing without permission.
Modularize PRs like Corbin	Explicitly split the full body of work into focused local branches, modular commits, and ready-to-use PR titles and descriptions.
Test Like Corbin	Protect against meaningful bugs with tests that exercise real behavior.
Choose Libraries Like Corbin	Decide when built-in tooling, a maintained library, or a little custom code fits best.
Architect Like Corbin	Fit a feature into the project you have and keep reusable code useful to other projects.
Rethink Code Like Corbin	Break repeated review and rewrite cycles with a validated cleanroom implementation, then migrate consumers to its new API.
UI Like Corbin	Build interfaces people can use across keyboards, screen readers, themes, and screen sizes.
Perf Like Corbin	Make the experience faster, measure the difference, and preserve the design.
Maintain Like Corbin	Fix the underlying problem and finish migrations without leaving obsolete pieces behind.
Web Stack Like Corbin	Choose frontend, backend, and deployment tools using Corbin's preferred stack.
Scaffold Like Corbin	Start with the apps you actually need and make development, checks, and releases straightforward.

Put a few together #

Some tasks benefit from more than one perspective. If you're improving a dashboard, you might ask:

Use $ui-like-corbin and $perf-like-corbin to improve this dashboard's loading. Keep its design, and check that it still works on mobile and with a keyboard.

Or, when it's time to explain what you've built:

Use $docs-like-corbin and $write-like-corbin to rewrite this project's README. Help a new user understand what it does and try it for themselves.

These are opinionated defaults, and your project's requirements still matter. An existing Vue app can stay a Vue app. A small fix can stay a small fix. Start with one task you already need to do, choose a skill that fits, and give your agent the context to do it well.

Modularize PRs like Corbin runs only when you explicitly invoke it. Install it alongside Git Like Corbin, Write Like Corbin, and Docs Like Corbin, then ask:

Use $modularize-prs-like-corbin to split all of this work against the default branch into focused PR branches.

It includes changes across commits and the working tree, preserves the original checkout, and creates local branches with PR drafts. Each branch keeps the tests and documentation needed for its change. When separate PRs may conflict later, it explains why the split is still useful and how they depend on each other.