Refactoring the AI Skill Tree with Commented Code: From Tool Pile to Entity of Needs

AI skill management often falls into the trap of "feature piling"—every new feature is stuffed haphazardly into some category, and the system eventually becomes bloated and hard to maintain. The LivinGrimoire design pattern proposes a counterintuitive solution: just by reorganizing skill categories through commented code, an AI can transform from a passive pile of tools into an entity with an intrinsic direction of evolution.

The Problem: Skills Piled Up Like "Cables in a Drawer"

LivinGrimoire originally divided skills into piles such as defcon, async, hardware, conversational, utility, sound effects, ear, games, and LLM. The author states plainly in the original article: "These categories have nothing to do with each other, no common theme, no common goal—like a drawer full of tangled cables."

The root cause of this classification approach is the "add a cool feature" workflow: when a new skill doesn't fit anywhere, you create a new pile that barely relates to anything. The piles keep accumulating, the system grows more complex, and ultimately "the vision for the AI drowns in an ever-accumulating collection of collectibles." More fatally, there is no mechanism telling a skill which direction it should evolve in.

This is not a problem unique to LivinGrimoire. Most AI assistant frameworks face a similar skill-bloat dilemma; it's just rarely pointed out so bluntly.

Skill Bloat is a common architectural degradation phenomenon in AI assistants and agent frameworks: as features are continually appended, the number of skills grows linearly, but they lack semantic relationships and hierarchical constraints with one another, leading to higher retrieval costs, confused composition logic, and heavier maintenance burdens. Typical symptoms include: exploding category directories, duplicate implementations, and implicit dependencies. In systems driven by large language models, skill bloat also weakens prompt effectiveness—the model has to choose from a longer list of tools, and accuracy declines accordingly. The "drawer full of tangled cables" described by LivinGrimoire is a vivid metaphor for this phenomenon.

Common strategies for mitigating skill bloat include: dividing bounded contexts according to domain-driven design (DDD), introducing skill registries and metadata annotations, and establishing skill lifecycle management (add/merge/deprecate). What makes LivinGrimoire unique is that it does not rely on runtime mechanisms, but instead imposes structural constraints through classification conventions at the annotation layer.

The Solution: Use "Needs" as Top-Level Categories

The author is revising the skill classification system, changing the top level from functional categories to four needs of the AI:

• Power (energy and rest)
• Continuity
• Attention seeking
• Body

Every skill must answer which need it serves. The system does not stop at four levels—each need can extend into subcategories, which are further subdivided into sub-ecosystems, similar to the Dewey Decimal Classification in libraries. Anything that is built has an address, and any blank space also has an address.

This design transforms the AI from "a collection of tools waiting for instructions" into "an entity with needs, where needs generate goals." In the author's words: "An assistant is a pile of tools waiting for commands, while an entity has needs, and needs create goals."

Dewey Decimal Classification is a library book classification system proposed by Melvil Dewey in 1876. It divides all knowledge into 10 main classes (such as 000 Computer Science, 100 Philosophy and Psychology, 500 Science), and each main class is further subdivided level by level into 10 divisions and 10 sections, forming a hierarchical numeric code. Its core idea is: every knowledge item has a unique and extensible address, and new items can be inserted into the existing hierarchy without destroying the overall structure.

LivinGrimoire borrows this metaphor: the four needs (Power, Continuity, Attention seeking, Body) correspond to the top-level main classes, and subcategories and sub-ecosystems correspond to the levels under the decimal system. Unlike the Dewey Classification, LivinGrimoire's classification addresses are not only used for retrieval but also carry evolutionary semantics—the address determines the direction of skill upgrades. This design of "classification as evolutionary coordinates" transforms traditional taxonomy from a static archiving tool into a dynamic evolution framework.

Why Commented Code Has Real Power

Surprisingly, all of this is implemented solely through commented code—no new classes, no new runtime. But the author believes it is still "powerful" for two reasons:

First, every skill gains an evolutionary trajectory. Because a skill knows which need it serves, upgrading or replacing it has a clear direction rather than endless discussion. This directly reduces "thinking time."

Second, it becomes a vector for modular autonomous enhancement. Want to strengthen the AI? Aim at a need, see where it is weak, and evolve, replace, or add functionality there. There is no longer any need to wait for a "cool idea" to arrive.

Annotation-Driven Architecture refers to carrying architectural metadata through structured markers in code comments, rather than relying on separate configuration files or runtime reflection. In the Java ecosystem, annotations such as @Service and @Entity are parsed by frameworks at compile time or runtime; in Python, type annotations and decorators play a similar role. LivinGrimoire's approach is lighterweight: the comments are not enforced by any parser, but serve as a convention followed jointly by humans and AI.

This "weak constraint" is powerful because it lowers the threshold for architectural change—no need to modify class structures or deploy a new runtime; simply adjusting comments can reorganize skill semantics. The risk is that conventions may be violated and cannot be automatically detected, so it is suitable for early evolution stages or small-scale systems. For production environments that require strong consistency, lint rules or CI checks are usually needed to solidify annotation conventions.

Centralization: From Collectibles to a Sculpted Entity

The author emphasizes that this approach is essentially centralization. Once skills are reorganized around needs, what he sees is "no longer a pile, but an entity being sculpted." Each time a group of old skills is replaced with fewer but stronger skills, the entity's outline becomes clearer.

"This is the true power of commented code. Not before the crisis."

The LivinGrimoire project is open source on GitHub, and this design pattern is worth in-depth study by developers interested in AI architecture evolution.

Implications for AI System Design

LivinGrimoire's practice reveals an easily overlooked dimension: the classification structure itself is evolutionary pressure. When classification is based on incidental feature labels, the system can only expand horizontally; when classification is based on intrinsic needs, the system gains coordinates for vertical deepening.

This approach does not require complex infrastructure and can be achieved solely through conventions at the annotation layer. For developers building modular AI applications, it offers a low-cost, high-leverage organizing idea: first define what your AI "needs," then decide what it "can do."

Evolutionary Pressure is borrowed from evolutionary biology and refers to the selective pressure that environmental factors exert on populations, driving the accumulation of advantageous traits. In software architecture, this concept is used to describe how system structure guides the direction of change: good module boundaries and classification systems "reward" cohesive expansion and "punish" arbitrary piling. LivinGrimoire's core insight is that the classification structure itself is a kind of evolutionary pressure—feature-label classification only allows horizontal appending (adding new piles), while need-based classification allows vertical deepening (replacing or strengthening skills under existing needs).

This perspective is in line with the idea that "architecture is constraint": the value of architecture lies not in presetting all features, but in providing a coordinate system for future changes. When developers face the question "where does the next feature go," need-based classification forces them to answer "which intrinsic need does this feature serve," thereby turning a random walk into directed evolution.

One-line Summary

LivinGrimoire replaces feature piling with need-based classification, giving AI skills an evolutionary direction through commented code alone.

Paragraph Summary

To address the "feature piling" dilemma in AI skill management, the LivinGrimoire project proposes a design pattern that restructures the classification system solely through commented code. The original article grouped skills by functional labels such as defcon, async, and hardware, resulting in unrelated categories, a bloated system, and a lack of evolutionary direction. The author changes the top-level classification to four intrinsic needs of the AI—Power, Continuity, Attention seeking, and Body—and draws on the Dewey Decimal Classification to establish extensible hierarchical addresses. This change requires no new classes or runtime; through annotation conventions alone, every skill gains a clear evolutionary trajectory, transforming the AI from "a collection of tools waiting for instructions" into "an entity with needs, where needs generate goals." The article argues that the classification structure itself is evolutionary pressure: feature labels drive horizontal expansion, while need-based classification drives vertical deepening, offering a low-cost, high-leverage organizing idea for modular AI systems.