Your AI hasn't read the onboarding doc

A backend engineer at a Series B asks Claude to refactor the authentication service. Claude does clean work — solid code, tests, documentation. The PR goes up.

Two reviewers later, security finds it. Claude used jsonwebtoken instead of the company's internal wrapper that enforces token rotation and audit logging. It skipped the “any auth change requires security sign-off” step because there was no way for Claude to know that step existed. Eleven hours of delay. The CTO sends another reminder to follow the engineering handbook.

The handbook is 47 pages. It lives in Notion. The AI cannot read Notion.

This is the gap that's about to swallow engineering productivity teams. Every company has spent a decade encoding how it works — code review checklists, deployment policies, approval flows, onboarding curricula, framework standards. Almost none of it is accessible to the entity that's now writing the code.

Training engineers is no longer enough

For thirty years, “how we work” was encoded through people. New hires went through onboarding. Senior engineers reinforced standards in code review. The senior job description included a paragraph about mentoring juniors. Slow, but it worked — because the entity producing the work was the entity being trained.

That stopped being true.

The entity producing the work is Claude Code, Cursor, Copilot, an internal copilot, an agentic harness. The human engineer is becoming an interface — a reviewer, a router, a judgment layer on top of an AI that drafts most of what ships.

If you train the human and not the AI, you've trained an interface. The AI underneath still uses StackOverflow defaults and whatever it scraped from public GitHub. Your code review checklist might as well not exist.

Ship your standards to the AI directly

Anthropic's Skills system gives you the mechanism. A skill is a piece of context — instructions, examples, references, conditions — that the AI loads when relevant.

Skills live in two places. A personal folder, where the engineer adds their own. And an Enterprise layer that overrides it.

The Enterprise layer is the part that matters. When the company publishes a skill there, it sits on every engineer's machine, can't be turned off, and updates centrally. The difference is not subtle. “Everyone should follow the code review checklist” is a memo. “The checklist is loaded into the AI of every engineer who touches the codebase, every time” is enforcement.

That's a different category.

A role is a plugin

Anthropic also lets you group related skills into plugins — bundles that travel together. This is where it becomes useful for platform teams.

A plugin is the unit of “how this role works at this company.”

For a backend engineer, the company plugin might contain:

• the preferred web framework, with patterns for adding new routes
• the logging standard and observability conventions
• the database client and the migration approval flow
• the trigger for “any change to auth, billing, or PII requires security review”
• the standard error-handling pattern and how to add new error types
• the code review checklist as an active gate, not a wiki page
• the on-call escalation matrix and the incident response template

For a data engineer, a different plugin:

• the warehouse, the dimensional model, the dbt conventions
• PII handling rules with required tags and lineage
• the “no production table without a staging migration first” rule
• the metric definition standard
• the data review template and stakeholder approval flow

For a platform engineer:

• the infrastructure-as-code patterns
• the deployment promotion ladder
• SLO templates
• runbook structure for new services
• the change management flow

For a business analyst working alongside engineering:

• the metric source-of-truth registry
• the standard query patterns against the warehouse
• the requirements template that produces engineer-scopable work
• the data access tier rules

The pattern is simple. Whatever a senior in the role is supposed to know that a junior is supposed to learn — that becomes a skill. The bundle of skills becomes the role plugin. The plugin gets pushed through the Enterprise layer.

A new hire shows up Monday. IT provisions their machine. The role plugin is already loaded. The engineer opens Claude Code. The AI knows how your company works before the engineer does.

The skill becomes the policy

This is where engineering productivity stops being a wiki and starts being compliance.

When the way you work is encoded in skills, you get properties documentation cannot provide.

Governed — only authorized publishers ship to the Enterprise layer.

Auditable — every skill invocation is logged. You know which skill the AI used to produce which line of code.

Traceable — when an incident happens, you know which version of which skill was active, who authored it, when it last changed.

Verifiable — skills are tested before they ship. The new code review checklist isn't deployed by a wiki edit at 4pm Friday. It goes through a publish-time evaluation.

Portable — works the same across every engineer's machine, every model, every IDE.

Your code review standard was a Confluence doc. Now it's a contract.

When you update the standard — say, you switch logging libraries — you don't send a Slack announcement and hope. You ship a new version of the skill. Tuesday morning, every engineer's AI follows the new standard. By Wednesday, the old pattern stops appearing in PRs. By Friday, an auditor can prove it happened.

This is the shift platform teams have been waiting for. A way to enforce engineering standards that actually scales with AI-generated code.

Where Invoked fits

Building the skills is the easy part. The hard part is the system around them — who can author, how they get approved, how they get reviewed, how they get distributed, how they get measured, how they get retired.

Invoked operates this loop for a company. Three layers.

Authoring — the front door for experts. A senior backend engineer who knows the codebase shouldn't have to learn YAML to publish her judgment. The authoring studio captures her methods, structures them as skills, and enforces the company's publishing standard at the moment of authorship. The standard is enforced at publish, not after.

Governance — three layers of enforcement. Structural: the skill is well-formed. Evaluative: it passes the tests. Organizational: the right people have signed off, the right scope is set, the right audit trail is attached. Nothing reaches the Enterprise layer that hasn't cleared all three.

Consumption — the AI agent's experience. Skills are discovered online with no installation friction. They run offline with auto-sync. No runtime dependency on Invoked being up. The AI on the engineer's machine works whether the network is good or not.

Every skill in the system has an owner, a version, an evaluation result, a scope, and an audit trail. Every invocation is logged. Every change is reviewable. Every retirement is intentional.

The result: “how we work here” becomes something your company ships, versions, audits, and improves — instead of something you train and hope.

What's next

If your platform team is rolling out Claude Code, Cursor, or an internal copilot across engineering, this is the next problem on the list. Probably this quarter.

We built Invoked for it. We're working with a small number of design partners through a 90-day paid pilot.

→ See Invoked for Platform Teams