祝融说。

15.1 Why 14 Skills Instead of 1

You are handed three feature requests at once: one requires refactoring legacy code, one starts from scratch, and one is a migration from a third-party system. You open your AI coding tool, but you have no idea where to begin. Worse, you discover that a feature you built earlier has drifted -- the code the AI recently generated no longer matches what it wrote before, as if it had "forgotten" the design conventions it was using.

You might wonder: is a six-step workflow not already enough? Why do we need 14 skills?

The answer is: the six-step workflow solves the problem of "how to build one feature," but an actual project faces the problem of "how to build many features together." These are two completely different problems.

At first, you may only need a Coach (process coach) to guide you through the six-step loop of "breakdown → task dispatch → coding → acceptance → branch decision → blueprint update." Whether it is one feature, two features, or three, this workflow holds up fine.

But when you have five features to advance at the same time, problems appear. You find that Coach's conversation on one feature can contaminate the context of another. After accepting feature A and switching to feature B, you discover that while the AI was writing B, it quietly changed a core interface of feature A -- because it remembered A's interface definitions in A's conversation, yet in B's conversation it had no idea that A even existed.

This is like team growth: a three-person team needs no complex management structure -- everyone knows what everyone else is doing. But when the team grows to thirty people, you need a division of labor -- some own the architecture, some own execution, some own acceptance, and some own schedule management. The 14 skills are not 14 independent methods but an organically collaborative system. Each one is aimed at a specific type of problem; as the problem grows more complex, you invoke a higher-level skill to respond.

15.2 The Four-Layer Structure: Fully Automated Build (Job) → Project Orchestration (Orchestrator) → Core Execution → Basic Support

The 14 skills are not laid out flat on a single plane; they have a clear hierarchical relationship. This hierarchy was not designed out of thin air -- it evolved and settled through project practice. As a project scales from small to large, you naturally discover the need for these layers.

                    ┌───────────────────────┐
                    │ Automated build (Job) │  Layer 1: Fully automated
                    │                       │  The full zero-to-deployment chain
                    └───────────┬───────────┘
                                │
                    ┌───────────┴───────────┐
                    │ Project orchestration │  Layer 2: Orchestration
                    │    (Orchestrator)     │  Sequence multiple features
                    └───────────┬───────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
  ┌─────┴──────┐         ┌──────┴──────┐         ┌──────┴──────┐
  │Requirements│         │ Automated  │         │ Inspection  │ Layer 3: Core execution
  │   (Req.)   │         │ (Workflow) │         │ (Inspector) │ Most used in daily work
  └─────┬──────┘         └──────┬──────┘         └──────┬──────┘
        │                       │                       │
  ┌─────┴──────┐         ┌──────┴──────┐                │
  │Architecture│◄────────│Process coach│                │       Layer 4: Basic support
  │(Architect) │         │   (Coach)   │                │
  └─────┬──────┘         └─────────────┘                │
        │                                               │
  ┌─────┴──────┐         ┌─────────────┐                │
  │  Frontend  │         │   Quality   │                │
  │architecture│         │ assurance   │                │
  │ (Frontend) │         │    (QA)     │                │
  └────────────┘         └─────────────┘                │

Auxiliary skills:
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│  Advisory  │ │Code cloning│ │High-fidelity│ │  Legacy    │ │  Project   │
│  (Advisor) │ │  (Cloner)  │ │prototype   │ │restoration │ │continuation│
│            │ │            │ │   (POC)    │ │  (Legacy)  │ │   (Next)   │
└────────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘

Layer 1: Fully automated build (Job). It sits at the very top of the skill system. When you have a "build a complete project from scratch" requirement, even the preliminary work -- scaffolding, requirements analysis, architecture design -- must be automated. Job packages the entire chain from zero to deployment (scaffolding → requirements analysis → architecture design → frontend design → feature development → integration acceptance → deployment configuration generation) into a single automated pipeline.

Layer 2: Project orchestration (Orchestrator). When you have 3, 5, or 10 features to implement, the question is no longer "how do I build one feature" but "how do I sequence these features." Orchestrator's job is not to write code but to manage "which feature goes first, which goes later, and what dependencies exist between features." Like a project manager, it threads multiple parallel workflows into one orderly pipeline.

Layer 3: Core execution. These are the three skills you use most often in day-to-day development: Requirements -- turning vague requirements into a structured feature list and data model; Workflow -- automatically completing a feature's coding, acceptance, and finalization; Inspector -- checking whether the code conforms to the blueprint.

Layer 4: Basic support. Architect -- producing the blueprint before coding begins; Coach -- guiding developers through the six-step workflow; Frontend Architect -- architecture design dedicated to the frontend; QA -- a comprehensive testing strategy and quality gates.

Auxiliary layer: special-scenario skills. Advisor -- providing analysis when you face technical decisions; Cloner -- reusing existing code patterns; POC -- producing a prototype before development; Legacy Recon -- rebuilding from a legacy system; Next -- taking over a half-finished project.

15.3 Skill Trigger Conditions and the Selection Decision Tree

Quick reference table of trigger conditions:

Skill selection decision tree:

Starting a new project?
├─ Yes → Need the whole chain from zero to deployment?
│   ├─ Yes → Fully automated build (Job)
│   └─ No → Architecture design (Architect) → Project orchestration (Orchestrator)
│
├─ Implementing a new feature?
│   ├─ Clear requirements; want full automation → Automated workflow (Workflow)
│   ├─ Need guidance and want to learn by doing → Process coach (Coach)
│   └─ Multiple features to schedule → Project orchestration (Orchestrator)
│
├─ Checking code quality?
│   ├─ Routine acceptance → Inspection (Inspector)
│   └─ Comprehensive testing → Quality assurance (QA)
│
├─ Having difficulty making a decision?
│   └─ Advisory consultation (Advisor)
│
├─ A special scenario?
│   ├─ Want to see the result first → High-fidelity prototype (POC)
│   ├─ Referring to existing code → Code cloning (Cloner)
│   ├─ Migrating a legacy system → Legacy restoration (Legacy Recon)
│   └─ Taking over a half-finished project → Project continuation (Next)
│
└─ Vague requirements?
    └─ Requirements analysis (Requirements)

15.4 Skill Maturity Model (L0–L4) and Investment Priority

Why do we need a maturity model? Because there is a wide gap between "knowing" and "doing." You may have drafted blueprint standards, but is the team actually following them? Without quantified assessment, you can only rely on intuition -- and intuition is often unreliable.

The maturity model divides "level of mastery" into five grades:

Investment priority (order of investment when resources are limited):

• First priority (must be established): Architect -- without a blueprint, AI coding has no direction; Inspector -- without acceptance, the quality of AI-generated code cannot be controlled. Before promoting AI coding across the team, establish the blueprint and acceptance standards first.
• Second priority (establish soon): Workflow -- drastically reduces manual involvement when requirements are clear; Advisor -- helps the team resolve technical decision difficulties and reduce decision blockage.
• Third priority (establish gradually): Orchestrator -- suited to multi-feature projects; QA -- established once the acceptance system matures; Requirements -- introduced when project complexity is high.
• Fourth priority (establish on demand): Cloner, POC, Legacy Recon, Next, Job, Coach, Frontend Architect -- used in specific scenarios, introduced as needed.

Two different maps must be kept separate here, so that “important” is not mistaken for “core execution.”

Accordingly, Advisor remains in the auxiliary layer of the panorama. The priority list describes adoption order, not a skill's layer or centrality in daily execution.

Core logic: governance skills are the "foundation," and execution skills are the "superstructure." If you build the superstructure before the foundation is solid, the building collapses. (For a detailed breakdown from the manager's perspective, see Chapter 34.)

For a unified mapping of the four process models -- the six-step workflow, the three-step flow, the eight-stage automated build, and the customer-project three phases -- see Chapter 27.