The AI engine with taste and judgment

Product Manager: This is grilling. Before we spend time planning, I want to make sure that the product specs survive the hard questions. Imagine I'm working on an onboarding flow. I'll give our specs to grilling. It reads the brief, the specs, and the research. Then it asks me what we might have missed. Does an invited teammate count as a user? What happens if someone skips the flow halfway through? What do people see when they land on a new project? And who gets to skip the welcome tour? I answer each one, and every answer changes what we build, and it keeps going until nothing is left to guess. The result is that every answer goes back into the product specs, and the open risks are flagged before planning even starts. This is how it works.

Product Manager: This is the Spike skill. In this exercise, before committing a whole team to it, we use Spike to answer one simple question. Can our search run at the edge, making it faster by running it closer to our users? Let's find out. Spike is now opening a throwaway branch and testing just the risky part using production size data, 2 million rows, the same query, and 200 runs at the edge and at the origin servers. In this example, Spike lets us compare both approaches side by side under the same condition. Let's see, and we have a final answer. Yes, keep it. Search runs in under 40 milliseconds at the edge. The memo captures all the numbers, and the test branch never gets merged. This is how it works.

CDO: So this is the prototype skill. Basically here we have a spec and what we want is to build a page to see how it looks and how it feels according to that spec. Here specifically it's a report view and what I do is I call up the skill and essentially what the skill does is builds the page in slices in different areas. So here specifically we have the shell, we have the filters, we have the stats, the activity and it allows me to see how a page will be for an end user. And it allows me to also understand how an end user would interact with the page. So interacting with the tooltips and switching between different views and essentially something real to react to.

Staff Product Designer: This is the plan skill. Once we know what to build, we plan it properly. I give it the ticket which touches the onboarding flow and invite API. It sends three research agents through the code and the specs at the same time, so nothing gets missed. Then it writes the whole plan on one page, four phases, a checkpoint for each one, and two risks we need to watch. It opens as a draft pull request. Nothing gets built until it's approved. This is how it works.

Front-End Engineer: This is /execute, the skill that builds. With the plan approved, it works one phase at a time. Phase 1 is the invite model and the API behind it. It works from the plan, not from memory, and it reads the plan again before every step. It writes the tests alongside the code, 14 of them, for this phase, and then it stops at the checkpoint. Phase 1 is committed and passing and /verify checks it next. This is how it works.

QA Tester: This is the verify skill. Tests passing isn't the same as the feature working, so it checks phase one the way a real person would, against all of our acceptance criteria. It starts the app with a seeded test data, opens the browser and walks through every criterion, inviting a teammate, keeping their workspace settings, opening an empty workspace and a slow API. It takes a screenshot of each one and it never fixes anything itself. Three pass, one fail, and the report goes straight back to the build. That's how it works.

Principal Engineer: This is watch release skill. Shipping isn't the end. After release, we use this skill to answer one question. Did anything change for your users? Let's find out. It's now comparing our errors and the main funnels with week before the release. Errors look to be flat and the average budget is healthy. But in this example, step 3 of the onboarding dropped 11%, exactly the kind of thing we would otherwise miss. And it drafts the next ticket with the chart and the release date attached. This is how it works.

Chief of Staff: This is our retro skill. At the end of every cycle, we stop and look back. And it compares what we planned with what actually shipped, ticket by ticket. Fourteen tickets went in, twelve shipped, and two carried over. And three pull requests came back from /verify for the exact same reason. They were missing empty states, and nobody had caught it in a plan. So one action is to add empty states to the plan checklist with a clear owner, and the next cycle starts better. And that's how it works.

CEO: This is the audit skills skill. In an age in which projects move so fast and code is built so quickly, it's really easy to create skills that no longer fit your project or that become deprecated. It's really important to keep a good hygiene when it comes to skills usage. This skill audits your repository to make sure that skills don't have deprecated information or duplicated references. This is a great way to keep everything in line as things move quickly.