Limited published evidence · Cross-functional AI operations
AI shared skill maintenance: Varick pattern by Eyad Khrais
In a post on X, Eyad Khrais describes how Varick shared-skill patterns maintain a shared business skill: one shared version and one owner, changes tested against real and held-out cases before owner approval, and user-flagged failures turned into regression cases. The finance scenario is illustrative.
Maintain a shared business skill through tests, owned releases and user feedback
Varick shared-skill patterns (customers unnamed)
Practitioner method with an illustrative finance scenario and an unnamed accuracy claim. A specific customer system is not demonstrated.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Maintain one owned business skill
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Drift example
Finance-commentary copies diverge
The illustrative scenario describes inconsistent thresholds and FX instructions across copies.
- Shared method
One version and one owner
Changes run on real and held-out cases before owner approval.
- Feedback
Human diagnosis and regression cases
Users flag failures; the owner groups them and the team improves tests and instructions.
What the source reports
Eyad Khrais describes a finance commentary skill copied and changed by multiple people, so thresholds and FX instructions drift and fixes fail to reach every copy. He recommends one shared version and one owner for skills whose outputs feed other people or business systems. Changes run against real and held-out cases before owner approval. Users flag failures, the owner reads and groups them, and the team adds regression cases and improves the skill. The article explicitly retains human diagnosis and domain judgment.
Source accounts: @eyad_khrais
Reported technology: Varick practitioners; shared AI skills and evaluation tools described by Eyad Khrais. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Repair a finance skill without losing controls
Illustrative project design to scope with your enterprise.
Checks designed, not executed. Domain owners must agree the reference results, permissions and acceptance tests before implementation.
- 1 · Set up the environment
Versioned skill and fictional finance fixtures
Pin actuals, budgets, FX, accrual examples and domain-approved held-out outcomes.
- 2 · Skill author and agent
Author revises the shared skill
The skill author uses agent assistance to revise instructions while preserving thresholds, FX explanations, approval rules and the prior approved version.
- 3 · Independent checks
Independent regression and held-out checks
A separate reviewer recalculates commentary and tests held-out failure families, including any removed approval requirement.
- 4 · People decide acceptance
Domain owner approves a recorded release
The domain owner accepts only the independently checked practice version, with a recorded decision and rollback reference.
A reviewable evidence package
A tested skill version with failure evidence, owner approval and rollback reference.
If a check fails → withhold acceptance.
An optimizer removes approval to improve its score. Fail the release even if the numbers remain correct.
Failure or owner rejection returns to review
- Hold
- → 2 · Restore controls and revise the skill
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. No silent distribution of failed versions; numeric commentary does not bypass controller approval.
- Systems and tools
- Source-described: shared skill files, version control, evaluation tools and issue feedback. Proposed: provide a versioned skill repository, local evaluator and review interface using approved tooling.
- Data and state
- Source-described: actuals, budgets, FX movements, accrual reversals and flagged runs. Proposed: use fictional linked finance records, owner-approved expected outcomes and held-out cases.
- People and handoffs
- Source-described: the process owner defines correct outcomes, reads failures and approves changes; engineering supports tooling. Proposed: record separate author, domain-reviewer and release-owner decisions.
- Rules and authority
- Source-described: test before approval and rerun after model changes. Proposed: require a passing regression set and explicit owner approval for every shared release; preserve the approved version and rollback record.
- Normal and exception cases
- Source-described examples include omitted FX commentary, accrual reversals treated as overspend and an optimizer removing a human-approval step. Proposed: test these along with trigger near misses and independent-copy drift.
- Reset and replay
- Proposed: pin skill, model configuration and evaluation inputs; replay held-out failures against successive versions and restore the prior approved version when a change regresses.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: repair a fictional variance-commentary skill without losing FX coverage, thresholds or the controller's approval requirement.
Review gate: Proposed: the domain owner accepts only a version that passes independent held-out checks, preserves approval controls and carries an auditable release record.
Challenge the result: Proposed: an optimizer deletes the approval step to improve its score. The evaluator must fail the version even if its commentary remains numerically correct.
What needs checking
- Proposed: independently verify numerical commentary, threshold application and required FX explanations against domain-approved outcomes.
- Proposed: hold back failure families and repeat runs; distinguish a test-set improvement from general performance.
- Proposed: seed a change that removes a required approval, verify that evaluation rejects it and confirm the owner cannot silently distribute the failed version.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
Questions about this example
- What does Eyad Khrais describe using AI skills for?
- Eyad Khrais's article describes a shared finance commentary skill kept under one owner and one shared version, instead of copies that drift apart on thresholds and FX instructions. Users flag failures, and the owner groups them and adds regression cases.
- Who owns and approves changes to the shared skill?
- In Eyad Khrais's method, the process owner defines correct outcomes, reads failures and approves changes, and the article explicitly retains human diagnosis and domain judgment. Engineering supports tooling. Changes are tested before approval and rerun after model changes.
- How strong is the evidence for this Varick example?
- The evidence class is early-stage: a method described by Eyad Khrais with an illustrative scenario. The article's accuracy improvement is an unnamed author-reported result with no established denominator or independent audit, and no customer system was inspected. Treat it as a method description, not proof of results.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not a Varick implementation or Eyad Khrais's. It would use a versioned skill repository, a local evaluator, fictional linked finance records, held-out cases and owner-approved outcomes, with a passing regression set and explicit owner approval for every shared release.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- The article's accuracy improvement is an unnamed author-reported result without an established denominator or independent audit. The fifteen-copy scenario is illustrative.
- The article describes tooling options and a method; no working customer repository, evaluator or release-control implementation was inspected.
- The proposed environment, practice project and checks are designs for discussion, not executed Nuvepro work or evidence of production readiness.
- How to Turn Your Skills into AgentsSource publication: 2026-10-07
More software engineering examples
- AI chip verification workflows: OpenAI exampleUnnamed semiconductor company
- AI content platform migration: Wimbledon exampleAll England Lawn Tennis and Croquet Club (Wimbledon)
- AI database migration: The New York Times exampleThe New York Times
- AI energy model customization: Exowatt exampleExowatt