The Post-Fable Repo

Thoughts on rebuilding our skills repo to actually work well with Claude 5 models.

Fable 5 and Opus 5 are more similar than they appear, despite Fable being much more capable. They are both:

much better at long-running tasks
perform well even at lower effort levels
more willing to dispatch subagents
overperformers that will self-correct and go beyond scope on their own (see this thread on Opus 5 going beyond scope)
Opus 5 is verbose, which is more annoying than practically impactful

The Field Guide to Fable describes finding your unknowns when prompting Fable. What does this look like outside of a live session?

I’m writing this because we love public repos for all sorts of tasks in the GTM world. At Zevenue, we are dropping our Headless GTM public repo tomorrow for teams to add a judgement layer to their API calls across each GTM step in their coding agent. We needed to know how to get this repo to make the most of Claude 5 models.

Purpose of a repo

If you are disappointed with Opus 5, the most likely reason is that your repo is built for older models.

We have to reshape how we think about repos entirely.

The repo’s job now is to specify and verify, not just instruct.

Screenshot of an old skill file with numbered rules like "NEVER include the signing off in the email" and "Always use a social proof in your emails", with the NEVER and Always instructions underlined

prompting Claude 3 models in 2024 was like talking to a kid

“Instruct” looks very different now. The balance has shifted: less instruction, more proprietary context, calibration, and verification.

There are two jobs to be done: supply what the model can’t know and can’t be allowed to improvise.

The analogy used to be that skill files are like writing an onboarding manual for a junior employee. The analogy I would make now is that your repo is the employment contract, signing authority, and performance review for a senior employee.

With a great employee, you hand them the terms, the limits, the criteria and get out of their way.

Old way versus new way: a thick "Onboarding manual" document on the left, and on the right a repo made of three cards labelled Contract, Signing authority, and Performance review

Three-layer repo

With our own repo, I graded our full outbound chain (discover → qualify → scrape → signals → score → resolve → write) against this.

The Zevenue GTM chain: a router that picks the chain, feeding discover steps for B2B databases and local/SMB, then site research and company signals, then the signal builder for ranking and approach, then email resolution

The pipeline was falling apart even though each run looked good.

The workflow was drifting across stages without any end-to-end invariant catching it. Later, production runs exposed operational facts we didn’t know we should encode (more on this later).

A good 3-layer repo avoids this. Each layer signifies something different - what you know, what good means, and what’s enforced.

Layer 1 - Operational knowledge

These are facts the model can’t know. It’s unique to your business and doesn’t exist in the training data.

I’ll share an example. In our repo, we make use of Firecrawl for scraping. We found that the stealth proxy silently activated on blocked sites at 5x credits (silent retries). Very cheap overall ($0.001 → $0.005), but makes cost prediction at scale harder. This is an unknown unknown in Thariq’s terms.

Examples can be vendor quirks, internal definitions, historical failure modes, and calibration data for different verticals.

In this case, the fix was to read actual credits from metadata.credits_used, not a hard page count. In the past, we may have tried to resolve this with a warning telling the model to “be careful with credits on large batches”. That is not an effective solution, because “be careful” is not executable. This same logic applies to several similar silent failures - valid responses that produce a wrong conclusion (e.g. a company showing up as “not hiring” on CrustData because we keyed on headcount, rather than employee_count).

Layer 2 - Judgement calibration

What does a 5/10 lead look like vs. a 9/10?

That answer is different for every team. The model can make an opinion, but you want to calibrate the model’s judgment to your business. You do this with evidence and worked examples.

For one of the teams we work with, a 9 is “competitor in place + visible friction”, and a 5 is “hiring around the function, not in it”.

This leads to much better results than writing instructions in the skill file to “score honestly”. Or on the other side of the spectrum, creating a strict scoring procedure with no room for judgement (“+2 points for this signal, +1 point for that one”).

Layer 3 - Controls and verification

Everything a downstream step must parse, and every dollar / credit the agent is allowed to spend - record schemas, spend caps, deterministic scripts, runtime checks, evals.

This layer gets more important as models improve. Older workflows stopped or required manual handoffs often enough that someone was likely to notice a broken seam. Fable and Opus 5 can route around the break and still finish the task. That makes drift less visible, not less dangerous.

Explicit rules need to be enforced. We need to enforce two types of terms - mechanical steps and behaviour.

Code for mechanical steps

This looks like deterministic scripts for things like pagination, retries, dedupes, and schema validation.

SKILL.md defines the record shape once - the script rejects anything that doesn’t match. The model can exercise judgement inside the record, but it can’t silently change the shape multiple steps later.

Evals for behaviour

This is the biggest reason lean skill files are viable now.

It can be hard to tell if writing skill files in this new way is still reliable. Evals show you if the behaviour holds so you don’t have to find out in production.

Practical example: Our signal builder skill collects unique sales signals for target accounts. The SKILL.md file says what a finished signal must look like. This is enforced with code (the model never writes the output file). It hands its judgment to a script which checks every field.

Python code for a validate_signals function that returns signals, fallback and errors, with a docstring noting the contract lives in SKILL.md, and a check that rejects any approach not in the allowed PQS, PVP, Pain-led set

Having robust contracts matters more now as skill files run more autonomously on newer models, where a weaker model previously had a human in the loop more often.

This is how we ensure anyone using the repo doesn’t overspend unexpectedly.

Tying things back to the employment analogy:

Employee to agent mapping: employment contract becomes boundaries plus success criteria, signing authority becomes permissions plus hard caps, institutional knowledge becomes proprietary context, performance review becomes evals plus monitoring

What we removed from the repo

Overly dramatic instructions: “NEVER use this filter to do that”
Overly prescriptive instructions
Natural language reminders where evals showed they were redundant

Conclusion

Claude 5 does not make scaffolding disappear. It does change which scaffolding matters.

Remove instructions that merely narrate steps the model already knows how to perform.
Keep the operational facts it can’t know, examples that calibrate judgment, and hard controls around anything you can’t let it improvise.

Reusable expertise goes in skills. Put mechanical guarantees in code. Then use evals to determine whether the behaviour is reliable enough to ship.

New model capability will continue to eat old prompting patterns. Your agent repo is not “set and forget”: every model release is a reason to rerun the evals, remove obsolete scaffolding, and strengthen the parts that fail.