祝融说。

You've taken on three feature requests at once. One requires refactoring legacy code, one starts from scratch, and one is a migration of a third-party system. You open your AI coding tool, but you don't know where to begin. Worse, you discover that a feature you built earlier now has AI-generated code that's inconsistent with what it wrote before—it seems to have "forgotten" the design conventions it originally agreed to. You have no idea which skill to reach for to solve these problems.

1.1 From "Knowing How to Use" to "Using It Well"

This is the very purpose of the "skill system." It doesn't teach you 14 isolated techniques; it helps you answer a more fundamental question: When a project grows complex, what methods should you apply, at what moments, and in what order?

The first volume taught you the "Six-Step Workflow"—a universal core process that applies to any AI coding task. But real projects are not single-threaded. You may need to manage multiple features simultaneously, adopt different methods at different stages, and know which skill to call on when something goes wrong.

That is what the 14 skills are for: they are not 14 independent methods, but an organic, collaborative system.

1.2 Why 14 Skills and Not 1

You might be wondering: isn't the Six-Step Workflow already enough? Why do we need 14 skills?

The answer: the Six-Step Workflow solves the problem of "how to build one feature," but real projects face the problem of "how to build multiple features together." These are two entirely different problems.

At the outset, you may only need a Coach (the process coach). It guides you through the six-step cycle: "Decompose → Issue Instructions → Code → Inspect → Branch Decision → Update Blueprint." One feature, two features, three features—this workflow holds up.

But when you have five features advancing in parallel, problems surface. You find that the Coach's conversation about one feature can contaminate the context of another. After you finish inspecting Feature A and switch to Feature B, you discover that AI, while writing B, quietly altered a core interface of Feature A—because it remembered A's interface definition in A's conversation, but in B's conversation it had no idea A even existed.

This is like a team growing. A 3-person team needs no elaborate management structure—everyone knows what everyone else is doing. But when the team grows to 30, you need division of labor: someone owns the architecture, someone owns execution, someone owns inspection, someone owns progress. This isn't an added "layer of hierarchy"—it's a natural adjustment made in response to complexity.

The 14 skills work the same way. They are not 14 independent methods, but an organic, collaborative system. Each skill addresses a specific type of problem; when the problem grows complex, you call on a more advanced skill to handle it.

1.3 The Skill Panorama

The entire skill system is organized around three dimensions:

                    ┌─────────────────┐
                    │  Full Build     │
                    │  Automation(Job)│
                    └────────┬────────┘
                             │
              ┌──────────────┴──────────────┐
              │  Project Orchestration      │
              │  (Orchestrator)             │
              └──────────────┬──────────────┘
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
    ┌────┴────┐       ┌─────┴─────┐       ┌─────┴────┐
    │Requirements│    │  Workflow  │       │ Inspector │
    └────┬────┘       └─────┬─────┘       └─────┬────┘
         │                  │                   │
    ┌────┴────┐       ┌─────┴─────┐             │
    │Architect│◄──────│   Coach   │             │
    └────┬────┘       └───────────┘             │
         │                                       │
    ┌────┴────┐                           ┌──────┴──────┐
    │Frontend │                           │     QA      │
    │Architect│                           │             │
    └─────────┘                           └─────────────┘

    Specialized skills:
    ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
    │  Advisor │  │  Cloner  │  │   POC    │  │Legacy    │  │   Next   │
    │          │  │          │  │          │  │Recon     │  │          │
    └──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘

Where the Four Layers Come From

The 14 skills are not laid out on a single flat plane. They have a clear hierarchical relationship. This hierarchy was not designed by someone in a meeting—it grew out of real projects. As project scale expands from small to large, you naturally discover the need for each layer.

At first, you may only need a Coach. It guides you through the six-step cycle. One feature, two features—this workflow holds up.

But when you have five features advancing in parallel, problems surface. You find that the Coach's conversation about one feature can interfere with another feature's context. Now you need an Orchestrator (project orchestration). Its job isn't to write code—it's to manage "which feature comes first, which comes later, and what depends on what." Like a project manager, it weaves multiple parallel workstreams into a single ordered pipeline.

But the Orchestrator isn't the end of the road, either. When your need is "build a complete project from scratch," even the preparatory work—scaffolding, requirements analysis, architecture design—must be automated. That is when Job (full build automation) stands at the highest level, stringing the entire process together.

That is the origin of the four-layer structure. It wasn't dreamed up on a whim; it's an organizational structure that grew naturally in response to the variable of "project complexity." Each layer solves problems that the layer above it cannot.

Consider a counterexample: a 10-feature project with no layered management. The developer dumps all features into a single conversation with AI. After AI completes 3 features, the conversation is already long. AI begins to "forget" the conventions of the first 3 features—naming styles drift, data models become inconsistent, API definitions conflict. By the 7th feature, the developer has to stop and spend a week repairing conflicts across the first 6 features.

With layered management—Job overseeing the overall process, Orchestrator sequencing the features, Workflow handling each individual feature, Inspector verifying—those conflicts would be caught and fixed early, rather than accumulating until they erupt all at once.

Layer 3: Core Execution Layer These are the three skills most frequently used in daily development:

• Requirements Analysis—Turns vague requirements into structured feature lists and data models
• Automated Workflow (Workflow)—Automates a feature's coding, inspection, and commit
• Inspector—Checks whether the code conforms to the blueprint

Layer 4: Foundation Layer

• Architecture Design (Architect)—Produces the blueprint before coding begins
• Process Coach (Coach)—Guides the developer through the Six-Step Workflow
• Frontend Architect—Frontend-specific architecture design
• Quality Assurance (QA)—Comprehensive test strategy and quality gates

Specialized Skills Layer

• Advisor—Provides analysis when technical decisions arise
• Code Cloner (Cloner)—Reuses existing code patterns
• High-Fidelity Prototype (POC)—Prototype first, develop later
• Legacy Recon (Legacy Recon)—Rebuilds from a legacy system
• Project Handover (Next)—Takes over a half-finished project

1.4 How the Skills Collaborate

A Typical Collaboration Flow

Project Start
  │
  ▼
Job (Full Build Automation)
  ├── Phase 1: Scaffolding
  ├── Phase 2: Requirements Analysis (Requirements) → REQUIREMENTS.md
  ├── Phase 3: Architecture Design (Architect) → CONTEXT.md
  ├── Phase 4: Frontend Design (Frontend Architect) → FRONTEND-DESIGN.md
  ├── Phase 5: Development
  │   └── Orchestrator (Project Orchestration)
  │       ├── Feature 1 → Workflow (Automated Workflow)
  │       │   ├── Coach (Process Coach) guiding
  │       │   ├── Inspector (Inspector) checking
  │       │   └── Advisor (Advisor) assisting decisions
  │       ├── Feature 2 → Workflow
  │       └── ...
  ├── Phase 6: Integration Inspection
  └── Phase 7: Deployment Configuration

When to Trigger Each Skill (Which One to Use When)

1.5 The Deeper Meaning of the Three Disciplines

The three disciplines look simple, but behind each one lies a complete chain of reasoning. Understanding these reasoning chains matters more than memorizing the three rules themselves.

Discipline One: No Blueprint, No Coding

The underlying logic of this discipline is: AI has no long-term memory.

In every conversation, AI faces a blank page. It doesn't know what you've done before, what tech stack the project uses, or what naming style you prefer. If you don't give it context, it can only "guess"—guess the tech stack, guess the naming style, guess the data structures.

And "guessing" is the most expensive thing in engineering. Because different guessers (including AI in different conversations) guess differently. Today you have AI build user management, and it guesses one naming style (camelCase). Tomorrow you have it build order management, and it guesses another (snake_case). The two modules' data models conflict—because AI "guessed" independently in two separate conversations.

The blueprint's essence is not a document—it's a constraint engine. It compresses AI's possibility space from "infinite" down to "within your project's scope." When the blueprint says "use Prisma ORM, camelCase naming, unified AppException error handling," AI will honor these conventions no matter how many conversations it opens, because every time it sees the blueprint, these "rules" are fixed.

So the blueprint must be complete, accurate, and readable. Incomplete means AI still has to "guess"—it will guess at the parts the blueprint doesn't cover. Inaccurate means AI makes decisions on the basis of wrong information. Unreadable means AI can't grasp it quickly, wasting its context window.

Discipline Two: No Inspection, No Commit

The underlying logic of this discipline is: AI has a "self-consistency trap."

Code generated by AI is almost always syntactically correct—because AI is a probabilistic model, and every token it produces is "the one most probable in the current context." This means its code looks "right," yet may have serious problems at the logical and architectural levels.

A typical scenario: you ask AI to implement user registration. It writes the code, you run the tests—registration succeeds, login succeeds. You commit the code. But a month later you discover the passwords are stored in plain text—because the functional test only checked the outcome "registration succeeded," not the implementation detail of "whether the password was encrypted."

The "self-consistency trap" means: AI will make itself look "correct" even when the underlying logic is wrong. It won't volunteer, "I stored passwords in plain text," because it equates "it ran through" with "it's done."

So inspection can't just check "does it run"—it must also check "is it built according to the blueprint." That is why three lines of defense are needed: the functional line checks "does it run," the architectural line checks "is it built according to the blueprint," and the security line checks "are there hidden vulnerabilities."

Discipline Three: When in Chaos, Rebuild

The underlying logic of this discipline is: The cost of fixing can exceed the cost of rebuilding.

In traditional development, when code is wrong, you fix it. But in AI coding, "fixing" can cost more than "rewriting." The reason is simple: AI's cost to write code is near zero, while the human cost to review code is very high.

If AI spent 30 minutes going down the wrong path and generated 200 lines of code, asking it to fix that code might take 3 rounds of conversation (5 minutes each, 15 minutes total)—and the quality of the fixed code is usually lower than a rewrite. If you choose to rebuild—roll back to the last clean commit and issue more precise instructions—AI needs only 1 round of conversation, 5 minutes, and the resulting code is higher quality because the context is clean.

The three rebuild signals are shortcuts for judging "whether a rebuild is needed":

1. Foundation tampering: AI modified core code it shouldn't have (database connections, authentication logic, global configuration)—this is the most dangerous signal. It means AI has lost its grasp of the architecture; a rebuild is mandatory.
2. Over-engineering: AI introduced unnecessary complexity (pointless abstraction layers, design patterns, third-party libraries)—this means AI is designing "just in case" rather than "just enough." Rebuilding is the cleaner solution.
3. Size explosion: A single file is ballooning without restraint—this means AI is "appending code" rather than "refactoring code." Rebuilding is more efficient than fixing.

1.6 The Evolution of the Skill System

The 14 skills weren't designed all at once; they evolved step by step through real projects.

Phase 1: Coach Only In the beginning, there was only a process coach, guiding users through the Six-Step Workflow. But it soon became clear that purely manual guidance was too inefficient.

Phase 2: Workflow + Inspector The Automated Workflow (automating the entire process from coding to inspection) and the Inspector (dedicated to code review) were added. Coach handled guidance, Workflow handled execution, and Inspector handled quality control.

Phase 3: Architect + Orchestrator + Job As project complexity grew, more upfront architecture design (Architect), more macro-level multi-feature management (Orchestrator), and full automation from scratch to deployment (Job) became necessary.

Phase 4: Specialized Skills Code Cloner, Legacy Recon, Project Handover (Next), and other specialized skills were added gradually, completing the full 14-skill system.

Chapter Summary

The 14 skills are not a toolbox—they are a layered decision-making framework for handling project complexity. The core flow is "design first → execute → inspect," and the management hierarchy is "Job governs the whole project, Orchestrator governs multiple features, Workflow governs single features." Behind each of the three disciplines—No Blueprint, No Coding; No Inspection, No Commit; When in Chaos, Rebuild—lies a chain of reasoning that starts from AI's underlying characteristics. The system was not designed all at once; it evolved step by step through real projects. In the next chapter, we dive into requirements analysis—how to turn vague requirements into precise blueprints.