Compound Engineering for Laravel

I've been experimenting with having AI write most of the Laravel code on Site Spell Checker. The part I wanted to improve was what happened after a feature worked.

I could fix a mistake, ship the feature, and then explain the same convention again on the next task. Or I could save the lesson somewhere the agent would read it.

That second approach is what got me interested in Every's compound engineering work. Each piece of work should leave something useful behind for the next one.

Where the knowledge goes

I use a project context file for the conventions that actually matter in that codebase. Model relationships, validation, queue patterns, testing, and whatever would otherwise require another explanation.

In my projects, AGENTS.md is a place to keep those decisions. Other tools also use files such as CLAUDE.md. The important part is that the tool reads the guidance and the guidance reflects how the project works.

A skill handles a repeatable workflow. The context file says what the project expects; the skill says how to do a particular job with those expectations in mind.

I primarily used Opencode for this experiment, alongside Claude-compatible skills. The tools have their own discovery rules, so use the Opencode skill documentation or your agent's documentation when setting up the files.

Starting with review and release

Every has a full compound engineering plugin. I started smaller, with two workflows.

The review workflow checks the changes against the project's conventions, runs the appropriate tests, cleans up leftover debugging, and creates or updates the PR. It also captures useful lessons from the work.

The release workflow checks the PR and CI, then handles merging, tagging, and cleanup when I invoke it to release. Keeping those separate lets me inspect the changes and test a preview before they go live.

I put the setup in a Laravel demo repo. That's a better place to keep the actual skill files than embedding a second copy of them in this post.

Scheduled scans as an example

For Site Spell Checker, a scheduled scan involves more than a button. There is a model to represent the schedule, a queue job to process it, a Livewire interface to manage it, and a notification when it's done.

The agent uses the existing conventions to build those pieces. Review then checks what it produced: validation, model behavior, job handling, and tests. I can try the change in a Laravel Cloud preview before releasing it.

If that work establishes a queue pattern worth reusing, I want it recorded. The next feature can start with that context instead of rediscovering it.

But not every change needs a new rule. A note about one unusual bug may belong beside that code or in a focused reference. Adding a paragraph to AGENTS.md on every review would eventually make the file harder to use.

What I would set up first

Start with the conventions you actually follow. Then package the workflow you repeat often enough to benefit from instructions. A review skill is a useful starting point because it brings together the changes, the checks, and the things you learned.

For a Claude-compatible skill, the folder contains a SKILL.md with a name and description. The body can describe the review outcome, the project checks to consult, and where relevant lessons should be saved. Keep commits, PR creation, and release actions within the authorization for that workflow.

Then use it on real work. When it misses something, find out whether the problem was missing context, ambiguous instructions, or an implementation mistake. Fix that specific issue and try the workflow again.

If the next feature needs less explanation because of what I saved from this one, the workflow is doing its job.

The demo repo has the review and release setup if you want to see the starting point.