How I Built a 340-Skill AI Toolkit (and the 3-Layer Framework Behind It)

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.

Within a few months, I had 94 of them. Then 200. Then 340.

And that's when things broke.

The problem with 340 skills

A single prompt is useful. A library of 340 prompts is a search problem.

New people couldn't find what they needed. Experienced users couldn't remember what existed. Nobody knew which skills were battle-tested and which were experiments I'd written on a plane. The library had grown past the point where "just browse it" worked as a discovery strategy.

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 340 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. 340+ 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 you have 340 skills and dozens of practice guides, some will be battle-tested and some will be drafts you wrote at 11pm. 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

Three things I learned the hard way:

Build entry points first, not last. I spent months creating content before thinking about how people would find it. The wizard and sequences should have existed when the library hit 50 skills, not 200.

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 CARATS framework saved ten hours of "is this still accurate?" conversations later.

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: 167 public skills across 6 categories
• 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.