Working together

The Skills are free. Fitting them to your firm is the work.

All 11 published Skills run as they are. But every one assumes a house format somewhere — your control matrix, your workpaper template, your materiality thresholds, the systems your evidence actually lives in. That gap is where we come in.

Three ways in

Most teams start at the assessment, but they stand alone. If you already know what you want built, start at the pilot.

01

Assessment

Find the work in your function that a Skill can actually do — and, just as usefully, the work it should not.

What happens

  • Walk your audit plan, methodology, and templates with the people who use them
  • Separate the tasks with one correct answer from the ones that need judgment
  • Rank candidates by how much time they take now against how cleanly they automate
  • Name what should stay manual, and why

What you end up with

A ranked list of automatable use cases for your function, each specced the same way the library is — input, what it does, what has to hold true, output.

Teams who know AI should be doing more here, but not which work to point it at first.

02

Pilot

Build two or three Skills against your real files and run them on a period you already know the answer to.

What happens

  • Pick the use cases from the assessment with the clearest before-and-after
  • Build against your control matrix, your templates, and your thresholds
  • Run them on a closed period, so the output can be checked against a known result
  • Fix what the comparison exposes — that step is the point, not a formality

What you end up with

Working Skills in your own environment, plus the evidence of how they performed against a period your team already reviewed by hand.

Teams who need proof it works on their data before committing further.

03

Enablement

Hand it over. Your team writes, reviews, and maintains their own Skills without calling us.

What happens

  • Teach the pattern the library is built on — deterministic where an answer exists, AI only where it does not
  • Set up the review standard a Skill has to clear before anyone relies on it
  • Work through building one together, start to finish
  • Document what your firm decided to automate and what it deliberately did not

What you end up with

A team that can build their own, and a written standard for how AI-assisted work gets reviewed in your firm.

Firms who want this as a capability, not a dependency.

How we build it

The same four steps whichever rung you come in on. The third one is where most of the value is, and it is the one that gets skipped everywhere else.

  1. 01

    Codify the methodology

    We sit with the people who actually run the procedure, or start from the workpaper guidelines, risk matrices, and control objectives you already have.

  2. 02

    Build the Skill

    Write out the steps, wire in your reference formats, and build the fixed calculations — the sampling, date handling, and threshold tests that should never vary.

  3. 03

    Test it against hard cases

    Run it on edge cases and on periods where the answer is already known, so you find where it is wrong before it goes anywhere near live work.

  4. 04

    Hand it over

    It lands in the AI workspace your firm has already approved, runs under the permissions your team already has, and it is yours to edit from then on.

Or point us at something that isn't in the library yet

There are 28 further use cases already specced and waiting to be built — segregation of duties, change population completeness, SOX deficiency evaluation, management review control precision testing, and more. Each is written to the same standard as the published Skills; none has been built yet.

If one of them is the work your team dreads, that's the pilot. And if what you need isn't on the list at all, that's a conversation worth having — the list grows from real engagements.

See what's ready to build

Running on ChatGPT or Copilot?

The Skills are built for Claude. If your firm has standardized on something else, we port them into your environment. Worth being straight about what that means: the deterministic parts — sampling, date handling, threshold tests — get rebuilt against what your platform actually supports, rather than translated. It's re-implementation, and it's scoped that way.

What we don't do

Drawing the boundary is part of the work. If you need any of these, we'll say so early rather than late.

  • Training or fine-tuning models on your data
  • Replacing your audit software, GRC platform, or document management
  • Staff augmentation — we build the tooling, your team runs the audit
  • Reaching an audit conclusion, or signing anything

The last one is the important one. These tools produce audit inputs — organized, traceable, and ready to review. The auditor reaches every conclusion and signs everything.

Start with the work your team dreads

Tell us which part of your audit takes the most hours and returns the least judgment. That's usually the right place to begin.