Internal ai-resources Catalog

Every team had an agent. It was usually one system-prompt file, pinned to whatever IDE that team happened to use, and useless to anyone else. I led the buildout of an internal ai-resources catalog to fix that: a tool-agnostic set of reusable agents, skills, rules, and workflows that gave participating teams one place to start, codified the patterns specific to our organization, and took the blank prompt out of every new agentic project.

The problem

AI adoption across R&D was fragmented. Every team had its own prompts, its own conventions, and its own single-file agent. None of it was shared, reusable, or visible to leadership, so every team paid the same onboarding cost in parallel. Worse, whatever a team did invest was locked to the coding assistant it had adopted. When a better tool landed, the work started over.

The approach

I inventoried the AI usage already happening across teams and clustered the patterns that kept recurring. Those became reusable skills, agents, rules, and workflows, written against the generic Agent SDK and MCP surface so they carried across coding assistants instead of binding to one. The library shipped with real versioning and a real contribution path, and I worked with Domain and Squad Architects to drive adoption inside their teams.

The outcome

Participating teams now start every agentic project from the same place. Internal dev workflows, including product-compliance scanning for engineering work, automated code review, and issue triage, shipped once and got reused across teams. Leadership got an adoption signal it could read: what teams consumed and contributed, rather than a prompt count.

What I’d change

Contribution onboarding deserved more runway up front. For the first few releases a team that wanted to add a skill had to ask me how to do it, so contributions arrived as questions instead of pull requests. We prioritized the fix late, and it was cheap when we got to it.