Why building Claude Skills isn’t enough to transform your TAS practice

We informally polled the last 20 TAS practices we spoke with. Seventeen are using Claude in some capacity. None reported cutting total deal time by 30%, 40%, or 50%.

This informal poll doesn't tell us why those firms haven't seen larger reductions or how much time individual tasks are saving. It does raise a useful question: how much work remains between getting a useful AI output and delivering something a manager can review?

There's plenty I would use Claude for. Draft management questions from reviewed findings. Summarize a meeting and organize follow-ups. Help write commentary around an analysis the team has checked. Those are useful applications. Turning Claude into a repeatable process for preparing and reconciling a databook takes considerably more work.

What you're actually building with a Claude Skill

A Claude Skill packages instructions in a file called SKILL.md, along with any examples, templates, reference documents, and scripts. For a revenue analysis, you might include your firm's workbook, instructions for mapping accounts, and code that calculates monthly trends.

That saves you from explaining the procedure every time. It doesn't retrain Claude or turn your written procedure into a program that must execute every step. Anthropic's explanation of Skills describes how these materials become available to the model.

Claude is a large language model. It learns patterns during training and generates responses one token—a piece of content—at a time, using probabilities shaped by its training and current context. Your instructions influence that process. They don't give you the same execution guarantee as a fixed software rule. Anthropic's glossary explains the underlying mechanics.

There is also a selection step that is easy to overlook. Claude initially sees the available Skills' names and descriptions. When it selects a Skill, it loads its instructions; supporting files are accessed as needed. Claude doesn't begin every assignment with every instruction from every Skill loaded. That keeps the context manageable, but it means the right procedure has to be selected before it can be followed.

Suppose your team has a revenue-analysis Skill, a databook Skill, and a general financial-analysis Skill. Their descriptions may overlap. Adding another Skill to handle an exception can introduce another selection decision.

Anthropic's enterprise guidance warns that too many active Skills can worsen selection. It recommends testing which Skills Claude selects, consolidating conflicts, and retiring Skills that repeatedly fail. It also identifies skipped validation as a failure mode to test.

So the maintenance work includes checking whether a new Skill has affected procedures that previously worked. A growing collection of Skills needs testing as a collection.

“Always reconcile” still leaves decisions to Claude

Consider an instruction in your Skill: “Always reconcile revenue before finishing.”

Here's a hypothetical example. The general ledger shows $12.4 million in revenue; sales detail covering the same entities and period totals $12.1 million. If Claude inserts a $300,000 “other revenue” line to make the workbook balance, the difference becomes zero. Nobody has explained it.

In diligence, that difference may be exactly what you need to investigate. It could relate to a manual journal entry, missing records, or a cutoff issue. A documented reconciling item is legitimate. An unsupported plug could conceal a finding.

You can tell Claude to leave unexplained differences open, prohibit unsupported adjustments, and show the reconciliation. Those are good instructions to include. You still need evidence that the workflow followed them: the source totals, the difference, and support for each reconciling item. Writing “always” in the Skill doesn't enforce that review.

Having Claude write code adds another review responsibility

Claude can write and run code that performs deterministic calculations. Fixed code can repeat the same operations on the same inputs under the same conditions. Anthropic explicitly includes this capability in its Skills architecture.

That can help with arithmetic. But what did the code include? If a script drops transactions with missing account numbers, the totals could be incomplete even though the script finishes successfully. If it treats cumulative year-to-date balances as monthly activity, it can repeat the same error on every run.

Someone needs to understand and test those decisions. An engineer can test the implementation; a diligence professional needs to establish the accounting requirements. If your team can't review the code, it needs another way to establish that the procedure is complete and correct before relying on it.

Anthropic's own advice:

“complex or mission-critical calculations should be verified using specialized mathematical software or manual methods.”

Read Anthropic's calculation guidance.

The time savings have to survive the next deal

This is where I'd focus the business case. Give the Claude workflow a completed deal it wasn't built around, then revised files. Have someone other than the author review the output. Count the total time spent preparing, checking, correcting, and explaining it. Compare that with the time needed to prepare and review the same deal under your current process.

Then account for upkeep. Your firm changes its databook template. A client adds an entity. Someone updates a Skill. Each change can require testing. The senior associate doing that work may already be on payroll, but their time is also needed to deliver deals.

Some work may have a short useful life. Anthropic distinguishes Skills that compensate for Claude's limitations from Skills that capture a team's preferred process. The workarounds may become unnecessary as Claude improves; firm procedures and examples can retain value. Its testing guidance explains the distinction.

Watch: Which Skills still help as Claude improves?

In a July 2026 Y Combinator interview, Anthropic's Boris Cherny recommends that Claude Code users try removing their instructions, Skills, and hooks every six months to see what the model can do without them.

“Delete your skills. Delete your hooks. See what the model does and it might surprise you.”

▶ Watch Boris Cherny — discussion starts at 6:37

He goes on to explain testing the model without those instructions and restoring them where it repeatedly struggles. For a live diligence process, I'd make that comparison against known results in a test environment before changing the workflow. The firm's accounting requirements and review still apply. Read the interview transcript.

For API-based workflows, model retirements can require migration and retesting. I'd also test the economics at a higher Claude price, without assuming one is coming.

Building may still make sense. But compare the full responsibility with buying software, including who maintains it, what your team reviews, and how you leave the vendor if you need to. Ask Audit Sight those questions too.

How we approach this at Audit Sight

We built TAS OS around using the right tool for each part of the job. AI helps interpret documents, match them to requests, extract information, and map accounts. Defined rules and calculations populate your firm's databooks and perform cash proofs. Your professionals investigate differences and reach conclusions.

That work sits within your firm's request lists, assignments, and review process. The team needs both the workbook and a way to see what's missing, who's responsible, and what's ready for review.

You can keep using Claude for questions, summaries, and commentary. We maintain the software for the recurring preparation and coordination, configured around your firm's templates and workflow.

Bring a request list and an example databook to a TAS OS demo. We'll walk through how your firm would prepare and review a deal, what TAS OS handles, and where your team's judgment comes in.

‍