祝融说。

From scratch to deployment--it sounds like one sentence, but behind it is a complete chain. Seven links, each of which can be automated.

You have a new project idea. You open your AI tool and start describing the requirements. The AI asks you twenty questions, and you answer all twenty. Then the AI starts writing code--but you need to watch the entire time, with it asking you "what's next?" after every step. You feel like a supervisor rather than a developer.

You think: is there a way where I can just say "I want to build XXX" once, then go have a coffee, and when I come back, the project is already scaffolded, the blueprint is designed, and features are already being developed?

This is not laziness--it is the ultimate pursuit of efficiency. When your project model is mature, the tech stack is fixed, and requirements are clear, every step from scratch to deployment is predictable--and predictable means automatable.

7.1 The Positioning of Full Build Automation

In the entire skill system, Full Build Automation (Job) sits at the top level. Its purpose is: to package the chain of seven links from "scratch to deployment" into a single automated workflow.

The complete chain from scratch to deployment is:

Scaffolding → Requirements Analysis → Architecture Design → Frontend Design → Feature Development → Integration Inspection → Deployment Configuration

Without Job, you need to manually start each link. You run the scaffolding command in your terminal, write requirements documents in your editor, manually call the Architect skill in an AI conversation, then manually start the Orchestrator... This process repeats seven times, and each switch requires you to re-enter the right mindset--shifting from "scaffolding thinking" to "requirements analysis thinking" to "architecture design thinking."

Job's idea is simple: package these seven links into an automated workflow. You only need one entry point ("I want to build XXX"), and Job automatically executes each link in order. The output of each link automatically becomes the input of the next.

This idea works because every link's process is fixed and predictable. Scaffolding has templates, requirements analysis has a methodology, architecture design has principles, feature development has Workflow, inspection has Inspector, and deployment has configuration templates. When every link has a standard operating procedure, stringing them together is a natural choice.

7.2 Division of Responsibilities in the Eight-Stage Process

For each stage, what the AI does, what the human does, and where the boundary lies--this is the most important part of Job's design.

Stage 1: Scaffolding -- The AI generates the directory structure, configuration files, and README based on the tech stack template. The human's responsibility is to confirm the template choice (if multiple options exist). The scaffolding is a skeleton and contains no business logic.

Stage 2: Requirements Analysis -- Call the Requirements skill, guide the user to articulate requirements, and produce REQUIREMENTS.md. The human's responsibility is to answer key questions and confirm the requirements document. The human does not write the document, only makes decisions.

Stage 3: Architecture Design -- Call the Architect skill, and produce CONTEXT.md based on the requirements document. The human's responsibility is to confirm technology choices, data models, and API design. The AI proposes, the human decides.

Stage 4: Frontend Design -- If the project has a frontend interface, call the Frontend Architect skill to produce the frontend design document. The human's responsibility is to confirm the UI style and component breakdown. No actual coding is involved.

Stage 5: High-Fidelity Prototype (POC) -- Optional stage. First produce a pure frontend prototype to confirm the look and feel before development.

Stage 6: Feature Development -- Call the Orchestrator skill to implement features one by one according to dependency order. Each feature is automatically completed by Workflow and inspected by Inspector. The human's responsibility is to confirm at key milestones.

Stage 7: Integration Inspection -- Check the correctness of cross-feature integration. The AI provides the data, the human makes the final judgment.

Stage 8: Deployment Configuration -- Generate Dockerfile and CI/CD configuration based on the project structure. The human's responsibility is to confirm the deployment target environment. The configuration is templated, but the human needs to confirm the target platform.

7.3 Job Mode Selection

Job supports three operating modes:

• normal mode: Show the plan and wait for confirmation at each stage; pause for user decision when inspection finds problems. Suitable for new projects, unfamiliar tech stacks, or unclear requirements.
• auto mode: Execute directly after milestone plan confirmation; automatically make branch decisions during inspection. Suitable for mature tech stacks, clear requirements, and experienced developers.
• silent mode: Fully automatic, silent execution, with only logs recorded. Suitable for fully trusted automation pipelines or CI/CD integration scenarios.

How to choose? Here is a simple decision tree:

• Is this your first time doing this type of project? → normal
• Have you done three or more similar projects? → auto
• Do you have a validated automation pipeline? → silent

7.4 State-Driven Architecture

Job's core design is "state-driven"--all progress information is written to the file system, and the state of each stage determines what to do next.

State Files

.agents/
├── job.state.json      # Current stage, milestone progress
├── job.progress.md     # Append-only progress log (human-readable)
├── REQUIREMENTS.md     # Requirements document (Stage 2 output)
├── CONTEXT.md          # Project blueprint (Stage 3 output)
└── FRONTEND-DESIGN.md  # Frontend design (Stage 4 output)

State Flow

Phase 0: INIT
  │
  ▼
Phase 1: SCAFFOLD → Complete → State update
  │
  ▼
Phase 2: REQUIREMENTS → Complete → Output REQUIREMENTS.md
  │
  ▼
Phase 3: ARCHITECT → Complete → Output CONTEXT.md
  │
  ▼
Phase 4: FRONTEND → Complete → Output FRONTEND-DESIGN.md
  │
  ▼
Phase 5: POC (optional) → Complete or skip
  │
  ▼
Phase 6: DEVELOP → Features completed one by one → Each inspected
  │
  ▼
Phase 7: RUN_GATE → Pass → Proceed to deployment
  │
  ▼
Phase 8: DEPLOY → Complete → Output deployment config

Recovery after conversation interruption: Read job.state.json, find the current stage, and continue from that stage.

7.5 Degradation Strategy

Job's design philosophy is "degrade rather than block." When encountering an unresolvable failure, the default behavior is to degrade and continue, rather than stop and wait.

Degradation Options

Three Degradation Principles

1. Feature degradation: If a feature cannot be completed within a reasonable number of attempts, mark it as "degraded," record the reason, and continue with other features.
2. Quality degradation: If inspection criteria are too strict to pass, lower to the "minimum acceptable standard," but record the degradation decision.
3. Scope degradation: If a feature exceeds the current version's scope, defer it to the next version.

7.6 Use Cases

Scenario One: Personal Project

"Help me build a personal blog system from scratch."

Job will automatically complete all stages and ultimately produce a deployable blog system. You can step in and make adjustments at any stage.

Scenario Two: Enterprise Project Prototype

"Quickly build a prototype of a device management system, with Vue 3 on the frontend and Spring Boot on the backend."

Job will scaffold the project, design the architecture, complete the core features, and generate deployment configuration. After the prototype is approved, you can dive deeper into development based on the generated code.

Scenario Three: Learning Project

"Help me build a simple expense tracking app to understand project structure."

Job will produce a complete project structure, and you can learn how a full project is organized by reviewing the generated code.

7.7 Boundaries: When Not to Use Job

Full build automation is not a silver bullet. The following scenarios are not suitable for Job:

1. Extremely vague requirements: If you do not even know what you want to build, do not ask for "full automation"--start with requirements analysis first.
2. Immature tech stack: If you need to experiment with new technologies or do POC validation, one-click full automation is not suitable.
3. Deep customization needed: Projects with special security, performance, or compliance requirements need more human intervention at many stages.
4. Existing large codebase: Job is designed for "from scratch" projects. Existing projects should use the Orchestrator or Next skill.

In these scenarios, a flexible combination of Orchestrator and Workflow is recommended instead of the fully automated Job.

Chapter Summary

Job sits at the top of the AI coding system, packaging the seven links from "scratch to deployment" into a single automated workflow. Its core value is not "automated coding" but "automated project management"--from scaffolding to requirements analysis, architecture design, feature development, integration inspection, and deployment configuration, the entire flow is seamlessly connected. Three modes (normal, auto, silent) suit different scenarios, and the degradation strategy ensures the flow does not get stuck on local problems. But Job is not a silver bullet--projects with vague requirements, immature tech stacks, or deep customization needs are better served by a flexible combination of Orchestrator and Workflow. In the next chapter, we will dive into advanced usage of the fourteen skills.