Why I’m Adding Engineering Skills to My AI Workflow

“Fix this bug” sounds like a complete instruction.

But there are several expectations hiding inside it. Reproduce the failure. Understand what caused it. Keep the change focused. Check that the fix works. Check that something else hasn’t broken.

You can spell those out every time. You can also turn them into a reusable workflow.

That’s what interested me about Addy Osmani’s agent skills. The collection covers engineering tasks such as debugging, frontend development, code review and performance investigation, with instructions for how to approach the work and what to verify.

I’ve added a small selection to this site’s repository. This is an account of that setup and why I’m trying it, rather than a claim that I’ve already measured a productivity improvement.

What a skill actually adds

A skill typically has a SKILL.md file describing when it applies and how to carry out the task. It can also refer to supporting resources, such as checklists and examples.

The debugging skill in this collection is a useful example. It asks the agent to reproduce the problem, localise the failure, reduce it to a minimal case, fix the cause and guard against recurrence. Verification includes checking the original scenario again.

Those are familiar engineering practices. Packaging them makes the process available without having to reconstruct it in each conversation.

It also gives me something to inspect. I can read the workflow, decide whether it suits the project and notice when its recommendations need qualification.

Installing instructions doesn’t guarantee that an agent follows them correctly. The resulting work still needs to hold up to review.

Why I chose these workflows

For this site, I’ve installed six skills:

The site already has an established stack, design and development workflow. I’ve left out the broader lifecycle router and planning and shipping suite because I don’t currently need them here.

The installed files are based on a specific upstream revision, with a few local adaptations. Review and simplification remain unchanged. Their shared reference files are included, and the repository records where they came from. That makes a future update something I can review deliberately.

This setup adds no runtime dependencies to the website. These particular additions are instructions and reference material for the agent working on the code.

Project rules still matter

My repository’s AGENTS.md describes the project: use the existing component library, preserve the visual design, keep client boundaries small and run the appropriate validation commands.

The skills describe approaches to particular tasks within those constraints.

A generic frontend workflow needs to fit this site’s existing components. A debugging example needs to use this repository’s actual test commands. A performance checklist cannot justify a redesign just because it mentions a different architecture.

I’ve made that relationship explicit in the project instructions. The existing conventions take precedence over generic examples, and checks should be proportionate to the change.

I’ve also adapted the skills themselves. The frontend skill’s fixed 200-line component rule is now a judgement call about cohesion and readability, and I’ve removed database-specific performance guidance because this site has no database. After adopting Vitest, React Testing Library and Playwright, I updated the debugging examples again to match those tools. Skills need to evolve with the project; preserving their upstream attribution doesn’t mean keeping every instruction unchanged.

The Git workflow is another example. I’ve preserved its upstream guidance, with small edits to use this project’s validation commands and Biome, and to clarify that commits and pushes happen when requested. The commit-format instructions live in that skill, with a short pointer in AGENTS.md, so there’s one place to maintain them.

That integration is part of adopting a skill. Copying the files is only the beginning.

Three examples I’d use

These are illustrative prompts for this project, not reports of completed investigations or measured results. They name the skills directly; invocation and automatic discovery depend on the agent and its setup.

Investigating a bug

Use debugging-and-error-recovery to investigate why filtering the blog sometimes returns no posts. Reproduce the issue, identify the cause, make a focused fix and add a regression test. Use the repository’s existing test commands.

I’d look for a clear explanation of what failed and evidence that the test catches the original problem. If the issue cannot be reproduced, that uncertainty should remain visible.

Investigating performance

Use performance-optimization to investigate slow loading on an article page. Establish a baseline, identify the bottleneck and compare the same measurement after any change. State anything you couldn’t measure.

The performance workflow emphasises measurement before optimisation. That matters because a plausible suggestion, such as adding memoisation or changing image loading, still needs evidence that it addresses the actual bottleneck.

The useful result would include what was measured, under which conditions, and what changed. An unavailable measurement should be reported as unavailable.

Reviewing a change

Use code-review-and-quality to review this diff. Prioritise actionable issues, explain how each could affect users and identify gaps in verification. Follow the project’s existing conventions.

The review skill provides a structured review process. I’d assess its output by whether the findings are specific, supported by the code and worth acting on.

A long list of speculative concerns would still be a poor review.

What you miss without skills

You can get good results without installing a skill collection. A clear prompt, strong project instructions and careful review can express the same expectations.

The opportunity is reuse.

If you keep typing the same debugging steps or asking for the same verification evidence, you already have the beginnings of a workflow worth saving. A skill gives that workflow a name and a place to live.

Keeping it in the repository also makes it reviewable alongside the project. You can see which instructions changed and decide whether those changes are useful.

Reading the workflows can help you sharpen your own requests, too. Even when you disagree with a recommendation, it gives you a concrete decision to make about how you want the work done.

Where I’d keep expectations realistic

More instructions can add overhead. A detailed workflow might be worthwhile for an intermittent bug and excessive for a small copy edit.

Skills also depend on the tools available to the agent. A workflow asking for browser inspection or profiling cannot supply that access by itself. And instructions to verify something are not the same as a check enforced by CI.

I’d read any skill before adopting it, particularly its assumptions about commands, dependencies, commits and deployment. Its recommendations need to fit the authority and tools you actually intend to give the agent.

There are installation details to check as well. The upstream README currently notes that individual skill installs can omit shared reference files. That’s why preserving the referenced checklists mattered in this repository.

Start with one recurring problem

My suggestion is to choose one task where you repeatedly have to correct the process. Inspect the relevant skill, make sure its resources are available, and try it on a bounded change.

Then assess the work: were requirements missed? Was the verification meaningful? Did it reduce follow-up instructions? Did the extra process justify the time spent?

I’m starting with a handful of workflows that fit the work this site needs. Their value will come from whether they help produce changes I can understand and verify.