How I organize 44 AI skills across personal, development, consultant, and system layers using a single decision tree.

The Four-Tier Skills Architecture

When you start building skills for AI coding agents, you hit a wall around skill number 15. Not a technical wall — an organizational one.

You have skills that create other skills. Skills that write code. Skills that give marketing advice without touching code. Skills that help you reflect on what you learned this week. They all live in the same folder, invoked the same way, but they operate in fundamentally different modes. Some need access to your codebase. Some must never touch it. Some are about work output. Some are about personal growth.

Without a clear separation model, you end up with a flat list of skills where a security auditor sits next to a journaling tool, and a project scaffolder sits next to a pricing strategy advisor. The cognitive load of "which skill do I need?" grows linearly with the number of skills. Worse, you start making design mistakes — giving advisory skills write access they don't need, or building personal reflection tools with the same patterns as production code generators.

I needed a framework that would scale to dozens of skills while keeping each one in its correct operating context. The answer turned out to be a four-tier architecture based on a single question: what does this skill need access to?

The decision tree

The entire framework reduces to three yes/no questions asked in sequence:

Does it operate on the AI tool's own infrastructure?
├─ YES → System tier
└─ NO ↓

Does it require codebase access?
├─ YES → Developer tier
└─ NO ↓

Is it for personal growth (not work output)?
├─ YES → Personal tier
└─ NO → Consultant tier

Every skill falls cleanly into one of four tiers. No ambiguity. No "it depends." The decision tree is the test — if a skill doesn't pass cleanly, it's either scoped wrong or needs to be split into two skills.

Tier 1: System — Meta-tools that build the workshop

Definition: Skills that operate on the AI agent environment itself — creating other skills, initializing projects, designing architectures.

The test: Does this skill operate on the tool's own infrastructure?

System skills are meta. They don't produce work output directly — they produce the scaffolding that makes future work possible. A skill that creates new skills. A skill that initializes a project with the right folder structure, dependencies, and configuration. A skill that converts a product requirements document into a format an autonomous agent can execute.

These are the tools that build the workshop. You use them infrequently but they have outsized leverage — a well-designed project launcher saves hours across every project it initializes.

What this tier contains (6 skills):

Skill creation and management
Project scaffolding and initialization
Specification and requirements generation
Architecture design tooling

Key characteristic: System skills are self-referential. They operate on the same environment they live in. This makes them powerful but also dangerous if poorly designed — a broken skill-builder can corrupt the skill system itself. They need to be robust and conservative.

Tier 2: Developer — Technical skills that touch code

Definition: Skills that need to read from or write to a codebase to execute.

The test: Does this skill need codebase access to function?

Developer skills are where most people start — and where most people stop. These are the skills that write components, audit security, analyze UX flows, implement tracking, and generate structured data. They are inherently technical because they operate on source code.

The critical design decision here is the read/write split. Some developer skills only need to read code (auditors, analyzers). Others need to write it (generators, implementers). Making this distinction explicit in the skill's metadata means you can enforce least-privilege access — a UI audit skill has no business writing to your codebase.

What this tier contains (9 skills):

Frontend component creation
UI, UX, and security auditing
Technical SEO implementation
Analytics and tracking implementation
A/B test code generation

Key characteristic: Developer skills produce artifacts that go into version control. Their output has consequences — a bad component ships to production, a missed security issue becomes a vulnerability. This is why they're separated from advisory skills that produce recommendations rather than code.

Tier 3: Consultant — Domain expertise without code

Definition: Skills that provide professional expertise working entirely from conversation context, URLs, or documents — with zero codebase access.

The test: Can this skill execute with zero codebase access?

This is the tier that surprised me most. When I separated "skills that need code access" from "skills that don't," I discovered that the majority of valuable AI skills are purely advisory. They analyze, strategize, recommend, and create content — but they never need to see a line of source code.

A pricing strategy skill needs your business context, not your repository. A copywriting skill needs your brand voice and target audience, not your component library. A competitive analysis skill needs URLs and market data, not your codebase. Giving these skills code access would be not just unnecessary but actively wrong — it creates a larger surface area for mistakes and confuses the skill's purpose.

The consultant tier is organized by domain — product, marketing, growth — with each domain having its own coordinator (an agent that routes to the right skill based on the task). This mirrors how consultant teams work in the real world: you don't hire a "marketing person," you hire a team with specialists in copy, SEO, conversion optimization, paid ads, and strategy.

What this tier contains (24 skills across domains):

Product: Requirements documents, feature specifications
Marketing: 22 skills across conversion optimization, content, SEO, paid ads, testing strategy, growth engineering, and strategic psychology

Key characteristic: Consultant skills are the fastest to create and iterate because they're pure methodology — no code integration, no API calls, no tooling dependencies. A domain expert can write one in an afternoon. This is where the "non-engineers can create skills" principle from the broader skills-as-first-class-citizens architecture pays off most directly.

The consultant-developer split

Some capabilities need both advisory and implementation modes. SEO is the clearest example: you need strategic SEO advice (which pages to create, what topics to target, how to structure content) and you need technical SEO implementation (generating schema markup, building page templates, implementing redirects).

Rather than creating a single bloated skill that does both, the framework splits these into two skills across tiers:

seo-advisor → Consultant tier (recommendations, no code)
seo-audit → Developer tier (implementation, needs codebase)

This split keeps each skill focused and appropriately scoped. The consultant skill can be invoked in a strategy conversation. The developer skill is invoked during implementation. They can reference each other but they don't need to live together.

Tier 4: Personal — Growth, not output

Definition: Skills for personal development, reflection, and self-improvement — not work output.

The test: Is this skill primarily for personal development rather than work output?

This is the tier most people wouldn't think to create, and the one I find most valuable long-term.

Personal skills don't produce deliverables. They produce understanding. A skill that summarizes what you did across multiple coding sessions and extracts patterns. A skill that reviews your last 30 days and surfaces what you learned. A skill that captures insights from a project and feeds them into a knowledge system.

These skills exist because AI agents don't just help you build things — they help you compound knowledge across everything you build. But only if you deliberately create mechanisms for reflection and capture. Without personal-tier skills, all the implicit learning from your work sessions evaporates when the context window closes.

What this tier contains (5 skills):

Session summarization and knowledge capture
Periodic reflection and review
Project knowledge extraction
Session continuation tracking

Key characteristic: Personal skills are inward-facing. Their output is for you, not for a product or a client. They interact with your personal knowledge system (in my case, an Obsidian vault managed by a personal orchestrator). They're the meta-cognitive layer — helping you think about your thinking.

Why four tiers, not three

When I first sketched this framework, I had three tiers: System, Developer, and Consultant. Personal skills were lumped into "System" because they felt like meta-tools. That was wrong.

Personal skills are fundamentally different from system skills. System skills build infrastructure — they create new skills, scaffold projects, design architectures. Personal skills build understanding — they reflect, synthesize, and compound knowledge. A session summarizer has nothing in common with a project launcher except that neither operates on a user codebase.

The four-tier model also creates a useful spectrum from most-privileged to least-privileged access:

| Tier | Environment Access | Codebase Access | External Access | |------|-------------------|-----------------|-----------------| | System | Full (self-modifying) | No | No | | Developer | No | Read and/or Write | Limited | | Consultant | No | No | URLs, documents | | Personal | No | No | Personal knowledge system |

Each tier has a clear trust boundary. System skills can modify the agent environment itself. Developer skills can modify codebases. Consultant skills can't modify anything — they advise. Personal skills interact only with your private knowledge store. This isn't just organizational tidiness — it's a security model.

What I learned building 44 skills

Most skills are consultant-tier

More than half my skills (24 of 44) are consultant-tier. This was unintuitive — I expected developer skills to dominate. But it turns out that the highest-leverage AI capabilities are advisory. Getting expert-level CRO recommendations, pricing analysis, or launch strategy doesn't require any code integration. The insight is worth more than the implementation.

The decision tree eliminates debates

Before the framework, adding a new skill involved a "where should this go?" discussion. After the framework, the three-question decision tree produces an unambiguous answer in seconds. This matters more than it sounds — organizational friction compounds. Every moment spent deciding where something goes is a moment not spent building it.

Skills should be designed for splitting, not combining

When a skill starts feeling bloated, the answer is almost always to split it across tiers, not to add complexity within a tier. The SEO example (advisor + audit) is the pattern. If a skill needs both advisory and implementation modes, it's two skills, not one.

Personal-tier skills compound silently

The five personal skills have the lowest usage frequency but arguably the highest cumulative impact. Each session summary, each 30-day review, each knowledge capture adds a small increment to a growing corpus of extracted patterns and insights. After six months, the personal tier has built a searchable, linked knowledge base of everything I've learned across dozens of projects. No single session felt transformative. The compound effect is.

Framework rot is real

I audited my skills after three months and found significant bloat — context documents that had grown unchecked, overlapping skills that did similar things with slight variations, and a personal-tier skill that had ballooned from 800 tokens to 18,000 tokens of accumulated context. A 96% reduction in one skill's size (from 18,000 to 700 tokens) made it measurably faster and more focused.

The framework needs periodic pruning just like any codebase. The tier structure makes this easier — you can audit one tier at a time, and the tier definition tells you exactly what belongs and what doesn't.

The broader principle

This four-tier model is my implementation of a broader principle: the access boundary is the organizing principle.

Not "what does this skill do?" (functional grouping — too ambiguous). Not "who uses this skill?" (persona grouping — too fluid). The question is: what does this skill need access to? This produces clean, enforceable boundaries that scale.

The same principle applies beyond personal skill organization. In production AI agent architectures, the three-tier access model (public → project → user) applies the same logic at a different scale — organizing skills by the scope of who can access them rather than what they do.

Whether you have 5 skills or 500, the organizing question remains the same: what does this need access to? Answer that, and the architecture follows.