/About /Blog /Reviews /Resources

mathieu@laptop:~/Content/Engineering$ cat create-a-perfect-ai-colleague.txt
> Title: Create a perfect AI colleague
> Date: June 26, 2026
> Tags: Engineering

I do believe that in any team, communication is the single most important skill. And with communication I mean: listening, mutual understanding, and bringing meaningful contributions towards a common goal. Good communication also means being able to speak ideas and concerns freely, without judgement. So, for now, how do we translate the above into a workflow using, for example, Claude? How would we make a 'perfect' AI colleague? My requirements for the colleague would be:

For a long time I've struggled with the right tools, the right 'mcp' servers, the right skills, even what IDE to use with autocomplete or whether to go all in on a complete CLI interface. There are so many models, offline or online, so many providers, and every week I was reminded about a new revolutionary app I really needed to use. Either I was too confused about what all these new features meant, or I'm just too old school. And where are all the success stories? Are we afraid to say it out loud? And what about these "AI skills"? There are hundreds of thousands of skills ready to be injected into your workflow. Why? It just feels like AI slop.
We don't need that.

But here is what I found works well. One to four prompts (who Matt Pocock translated to usable skills). And they all work around the same principle I want AI to do:

The emphasis on goal is deliberate. If your goal is vague or incomplete, the job will be too. This is no different from your human colleagues. These tools work best when you, the user, have a clear picture in mind.

The skills needed

All credit for these go to Matt Pocock (see https://www.aihero.dev/).
/grill-me (or /grill-with-docs for bigger tasks)
"The skill walks down each branch of your design tree, resolving dependencies one by one until you reach a shared understanding." And the docs variant adds Architectural Decision Records for important decisions made during the grilling.

My experience with the /grill-with-docs
80% of your time, energy and focus should be during the grilling session! Do not skip any questions and do not answer everything with the default suggestion. This session is meant as the basic of everything that follows. Mistakes made here will follow down the line. I had sessions of 5 minutes, I had sessions of 1 hour, I had sessions that spawned multiple days because I needed rest in between. It is like working with a client on a new project. You can't all do that on the back of a napkin :-). We need good communication and mutual understanding. And here it happens.

(Optional) /to-prd
"to-prd turns the current conversation context and codebase understanding into a product requirements document.". Super handy with the grill me session!

(Optional) /to-issues (for bigger tasks)
This only works with a (good) 'to-prd' document. It makes GitHub (or Markdown) issues from the plan. These issues, as you will see below, can be assigned to agents.

(Optional) /tdd (test driven development) (for bigger tasks)
This assign agents to the issues and let them build tests first, implementations next. Super good. Especially with industry standard Frameworks (like Laravel).

I've been intensively stress-testing these, especially the /gril-with-docs, for over a two week on a single project. There were zero issues. None. I'm feeling slightly optimistic about LLM.

Install them and test them. It changed my way of working with LLM in a positive manner.

That's it. For now.