Creating your own Quattr skill (and passing the gates)

Scroll back through your assistant's history. Find the last three times anyone asked for the same analysis. The wording moved. One version pinned the date range, one left it open, one remembered the segment late and tacked it on. Three answers came back, all defensible, and nothing on the page tells you which one to act on.

That is not three questions. It is one routine, run from memory, and routines run from memory drift. The create-quattr-skill path turns that routine into a skill of your own: a packaged, repeatable analysis you run by name in your assistant, with its triggers written down and its guardrails attached.

The difference is the one between a colleague who remembers how you like things done and a written procedure that outlives that colleague's vacation, promotion, or departure.

Start from a session that already worked

It drafts from what actually ran, rather than from what you meant to run.

The path can interview you about the routine. Or it can replay the session you just finished: which analyses ran, in what order, with which scopes. The draft inherits real steps and parameters that parse, because it came out of a working session rather than a wish list.

That grounding matters more than it sounds. A skill naming analyses that exist works on day one. A skill written from memory usually does not, and it fails halfway through, in front of somebody who trusted it.

Interview mode earns its place when the routine lives in somebody's head instead of a transcript. It asks what starts the work, what it looks at, in what order, and what would make the output wrong.

Replay is the faster road when the session already exists. Your skill inherits the exact steps, scopes and order that just worked. Nobody retypes anything, so nobody mistypes anything.

What your skill has to declare

The same things the built-in library declares. Writing it yourself buys no exemptions.

It states its triggers, so routing stays sane beside the other 39. It declares its guardrails, including the questions it refuses.

And it follows the house language rules. Share language stays qualified. Conversions always mean the named goals your team defined in your analytics tool. No causal claim ships without a significance test, which is a statistical check on whether a change is bigger than the normal week-to-week wobble.

None of that is paperwork. It is the reason somebody who did not write the skill can trust what it hands back.

The stated refusals matter more in a shared library than in a private note. A skill that never says what it will not answer eventually meets the wrong question, and answers it.

Versioning rides along. A skill is a file your team can read, diff and improve, so the routine's evolution lives in a history rather than in one person's memory.

Agencies hit the payback first

Because the same analysis already runs across many properties.

An agency's monthly client readout. A portfolio team's category watch. A marketplace's per-vertical pulse. Write it once, run it everywhere, and every account gets the senior analyst's version.

The economics are plain. Senior judgment written down once becomes safe execution everywhere, and review shifts from redoing the analysis to reading what it produced.

The worked example below is the shape that graduates into a custom skill most often: a recurring watch over one query family, replayed on a schedule.

In-house teams cross the same line at their own scale. Any analysis that runs monthly, for more than one audience, in more than one scope, pays back the authoring hour inside the quarter.

The workflow that does this: Watch a query family →

What belongs in a skill, and what doesn't

Sequences belong. Preferences do not.

If what keeps recurring is your segment, your date defaults, your competitor set, that is context, and it belongs in your setup rather than a new skill. The skill path is for repeated sequences of analysis with decisions inside them.

The test is a hiring test. Would you write it as a checklist for a new hire? Then it is a skill. Would you write it as a preferences file? Then it is context.

Both are cheap to try and both are reversible. The expensive option is the third one, where the routine stays in one head and your team keeps re-deriving it.

The payoff arrives at handover. A new teammate inherits working skills instead of folklore, and the ramp conversation becomes here is our library rather than shadow me for a month.

See also: how a finished skill behaves once it joins your library →