The Three Layers of an AI Skill Library That People Actually Use

I didn't set out to build a knowledge system. I set out to stop repeating myself.

Every new engagement started the same way: draft a context packet, set up ceremonies, write the first batch of user stories, facilitate a kickoff retro. I'd done it dozens of times across healthcare, defense, and enterprise. The patterns were in my head, but they weren't in a form anyone else could use.

So I started writing prompts. Slash commands that could draft a context packet from a few inputs, or generate a sprint report from commit history, or prep a stakeholder meeting in 90 seconds. Each one solved a specific problem I'd had that week.

Here is the part that usually gets left out of stories like this one. Writing them was the fast part. Drafting a skill with an agent takes minutes, so the library was several hundred skills deep inside five months, and it kept growing from there. Nobody hand-crafted this over a year. It piled up.

And that's when things broke.

The problem with a library nobody can navigate

A single prompt is useful. Several hundred of them is a search problem.

It is also a trust problem, and that one gets sharper the faster the library grows. New people couldn't find what they needed. I couldn't remember what existed. Nobody could tell which skills had been used on real client work and which were drafts an agent produced at 11pm that I never opened again.

I recognized this pattern. I'd seen it on every product team I'd ever coached: the content isn't the problem. The problem is that people can't find it, can't trust it, and can't figure out where to start.

So I did what I'd tell any PM to do. I stopped building features and started building architecture.

The 3-layer framework

What emerged was a three-layer system. Each layer solves a different problem, and they work because they're independent: you can improve one without touching the others.

Layer 1: Entry points

Entry points answer one question: how do people find what they need?

Most knowledge systems fail here. They organize content by type (docs, templates, guides) or by topic (engineering, design, product). Both assume the user already knows what they're looking for. That's the wrong assumption for 80% of use cases.

Instead, I built five different ways in:

• A getting-started wizard. Four steps: role, context, tools, comfort level. It delivers three specific recommendations. No browsing required.
• An SDLC timeline. Five phases from Discovery through Delivery, with a role filter. Show me what practices, tools, and skills apply at this phase of this project.
• Practice sequences. Eight curated learning paths: New PM, Experienced PM, Designer Adopting AI, Engineer Agentic Coding, and more. Each one is a guided journey, not a list.
• Role guides. Quick starts and daily workflows for PMs, designers, and engineers.
• Engagement setup. Phase-by-phase onboarding for new consulting engagements, with checklists.

Here's what took me a while to see. Entry points aren't about organizing content. They're about matching where the person is right now to what they should do next. A new PM on Day 1 of an engagement and an experienced PM debugging a stuck team need completely different starting points, even though they might end up using the same practices.

Layer 2: Content system

The content system is what the toolkit actually contains. This is where the skills live, alongside everything else.

• Practices. XP-inspired practices adapted for AI-era product teams: story writing, pairing, TDD, facilitation, iteration planning, conflict resolution.
• Agent skills. The bulk of the library: slash commands for PM, engineering, architecture, and engagement workflows. Each one is a reusable prompt with defined inputs, outputs, and quality checks.
• Tool guides. Organized two ways: by the job you're trying to do (coding, research, facilitation) and by the specific tool (Claude, Cursor, NotebookLM).
• Templates. Engagement charters, context packets, working agreements, feedback forms.
• Open source. Five repos that package the toolkit's patterns for public use.

The organizing principle is what makes it work. Content is grouped by workflow intent, not by type. A PM preparing for a planning session finds the iteration planning practice, the relevant agent skill, and the story template in the same flow, not scattered across three different sections.

Layer 3: Governance and quality

This is the layer nobody thinks about until the system starts rotting.

When a library runs to hundreds of skills and dozens of practice guides, some are battle-tested and some are drafts nobody has opened since the day they were written. Without governance, users can't tell the difference. Worse, you can't tell the difference.

Six mechanisms keep the system coherent:

• Two-layer planning. Raw inputs land in an inbox as immutable records. They get processed into compiled canon, the authoritative, versioned content. Human review is required at every transition.
• Content registry. Central metadata for every piece of content: frontmatter, status, section, search index. One place to answer "what do we have?"
• Tier labels. Every content file is marked Required, Optional, or Experimental. Clear maturity signals on every page.
• CARATS evaluation framework. Six dimensions for evaluating AI-assisted content: Correctness, Alignment, Relevance, Actionability, Timeliness, Safety. It is an AI eval applied to content - how I decide whether a skill is ready for production use. (Here's how to design one for your own product.)
• Dual source of truth. GitHub for technical authoring and versioning. Notion for organizational context. One-way sync from repo to Notion, never the reverse.
• JSON export. A static index of all skills that powers external integrations and cross-tool recommendations.

The governance layer isn't bureaucracy. It's the reason I can tell you with confidence that a skill labeled "Stable" has been used in real engagements and produces reliable output. Without it, the toolkit is just a big folder of prompts.

What I'd do differently

Four things I learned the hard way:

Build entry points first, not last. Generating content is cheap now. Finding it is not. The wizard and the sequences should have existed before the library passed 50 skills, not long after it passed 400.

Tier labels from day one. The moment I started labeling content as Required/Optional/Experimental, user confidence went up immediately. People stopped asking "should I use this?" because the label told them.

Governance is a feature, not overhead. Every hour I spent on the content registry and the CARATS framework paid for itself the first time someone asked "is this still accurate?" and I could answer without opening the file.

The count is not the achievement. I led with a skill count for a while, and it was the least interesting thing about the work. A number that large mostly tells you the drafting was cheap. What matters is whether someone finds the right skill on the first try, and trusts the output enough to put it in front of a client.

What's inside

The toolkit is real and most of it is public. You can explore it now:

• Playbook: practice guides for product teams, from facilitation to AI maturity assessment
• Skills catalog: the public slice of the library, browsable by category
• Tools: work tools, fun apps, and downloadable templates
• Blog: writing on product, AI, and consulting

The gated side has engagement playbooks, delivery templates, AI workflows, and internal docs, the operational layer that supports active consulting work.

If you're building your own knowledge system, whether it's a team wiki, a consulting toolkit, or an AI prompt library, the 3-layer framework scales. Start with entry points. Organize content by workflow intent. Add governance before you need it.

And if you want to talk about how this applies to your team, let's talk.