跪拜 Guibai
← Back to the summary

A 13-Step Blueprint for Turning AI Coding Agents into a Disciplined Dev Team

AI Programming Engineering: Hands-On — Building an AI Programming Workflow from 0 to 1

In this series on AI programming engineering, we've been talking about one thing:

How to turn AI from a "tool" into an "employee."

We set rules for it (Rule), encapsulate processes (Command), supplement capabilities (Skill), add checks (Hook), divide labor (Subagent), connect to external systems (MCP), and then package and solidify capabilities (Plugin).

It seems quite complete.

But if you haven't actually run through the whole process from start to finish, you might easily think:

"I understand all these concepts, but I still don't know how to implement them in a project."

Honestly, I've been through this stage myself.

Each mechanism makes sense individually. But when it comes to a real project, you don't know which to configure first, which later, and even less how they work together.

This is also the real state of many people using AI programming now.

A bunch of tools installed, a few commands configured, MCP connected, but when it comes to a real project, you still just do whatever comes to mind.

This article is the last in this series, and we won't talk about concepts.

I'll guide you step-by-step, from 0 to 1, to build a complete AI programming workflow, truly putting everything we've learned into practice.

Hands-On Project Setup

To give the entire process a foothold, let's set up a real project scenario: developing an "AI Prompt Asset Management Tool (PromptHub)" from 0 to 1.

The requirements aren't complex, but they are complete enough:

The process covers: Requirements Analysis → UI Design → Frontend Development → Backend Development → Testing & Acceptance → Deployment & Launch.

In the past, you'd basically have to manually push all these tasks forward: write requirements, draw prototypes, design UI, code pages, write interfaces, integrate, test, deploy...

From start to finish, it would take at least a few weeks, maybe even longer.

This time, we'll do it differently.

Let AI participate throughout the entire process, operating in an "engineered" way.

Not just letting AI write a few snippets of code for you.

But letting it work like a real development team, following processes, standards, and division of labor.

engineering-system.png

The hands-on project PromptHub in this article is open-sourced at github.com/XPoet/prompt-hub. If you want to see the final implementation, you can read the article while referencing the directories, configurations, and code in the repository.

Overall Process

A special note here: all scenarios using AI in this article are based on Codex or Claude Code. If you use other AI tools, the ideas can be copied, but the specific configuration methods will differ.

Before we start, let's first sort out and break down the overall process.

Step 1: Create Project Directory Create a directory locally and open it with an AI tool. All subsequent steps and actions will be performed within this directory.

Step 2: Generate Product Requirements Document Don't start writing code right away, and don't start drawing UI. Instead, send your requirements to the AI and have it generate a professional Product Requirements Document (PRD). This is the source for all subsequent work.

Step 3: Generate UI Design Prompts Have the AI generate a prompt specifically for AI design tools (e.g., Pencil, Figma Make, Stitch, Open Design) based on the product requirements document.

Step 4: Generate UI Design Mockups Have the AI design tool generate complete high-fidelity UI design mockups based on the UI design prompts.

Step 5: Build Project Skeleton Have the AI set up the frontend, backend, documentation, and other directory structures based on the product requirements document, UI design mockups, and tech stack plan.

Step 6: Configure Project Rules to Manage the AI Before starting, set the project rules. Tech stack, code standards, output format, prohibitions — write everything into the Rules.

Step 7: Configure Commands to Define Standard Development Processes Encapsulate the process of "analyze requirements → make a plan → generate code → self-check → commit code" into commands.

Step 8: Configure Subagents to Split Roles, Each Doing Their Own Job Product, frontend, backend, review — don't let one AI do everything. Split into multiple Subagents, each with its own independent context, not interfering with each other.

Step 9: Configure Skills to Supplement AI's Specialized Capabilities Not all capabilities need to be written from scratch. You can directly install Skills already solidified by the community, allowing the AI tool to use them right after installation.

Step 10: Configure MCP to Connect AI's External Capabilities Read design mockups, connect to databases, control browsers, and read official documentation in real-time. At this step, AI is no longer just "writing code" but starting to operate in a real environment.

Step 11: Configure Hooks to Add Checks at Key Nodes Automatically trigger check mechanisms at key operational nodes, ensuring every output passes quality verification. AI can be fast, but it cannot be chaotic.

Step 12: Create a Plugin to Solidify Capabilities Package the above Rules, Skills, Hooks, and MCPs into a Plugin. For the next new project, install it with one command, no need to reconfigure.

Step 13: Let AI Plan Autonomously and Continuously Advance According to the Development Plan Let Codex or Claude Code cross-reference the product requirements document, UI design mockups, tech stack plan, project rules, and existing code, autonomously break down the overall development roadmap and phased tasks, then implement, run, test, review, and commit item by item according to the plan.

workflow-13-steps.png

Step 1: Create the Project Root Directory

This step only does two small things:

  1. Create a prompt-hub directory locally
  2. Open this directory with Codex or Claude Code

All subsequent outputs will reside in the prompt-hub directory:

Step 2: Have AI Generate the Product Requirements Document

Many people start an AI project by saying: "Help me develop an AI prompt asset management tool."

This sentence isn't unusable. But it's too rough.

AI doesn't know what your "prompt management" specifically includes, whether login verification is needed, what form the prompts should be displayed in, whether there should be favorites and categories, etc.

So my first step isn't to have AI write code.

It's to first turn a simple functional description into a developable product requirements document.

I would directly say this in Codex or Claude Code:

I need to develop an AI Prompt Asset Management Tool (PromptHub) for personal use from 0 to 1.

Please help me organize the following page and function descriptions into a complete product requirements document and save it as docs/PRD.md.

Page and Function Descriptions:
- Login Page: Supports login using account (email) and password
- Registration Page: Register a new account via email and password
- Prompt Display Page: Supports paginated display of prompt card lists (prompt cards include interactive functions like delete, modify, copy, favorite, AI optimization), supports searching and filtering (by favorite and category) prompts, supports exporting (batch export) prompts
- Prompt Creation Page: Supports manual creation of prompts and AI automatic generation of prompts
- Prompt Editing Page: Supports modifying prompt title, description, content, category, and other information
- Prompt Category Management Page: Supports adding, deleting, modifying, and querying prompt categories
- Prompt AI Optimization Page: Supports before-and-after AI optimization comparison, saving optimization history
- AI Large Model Configuration Page: Supports configuring large model provider, model name, BaseURL, API Key, enable status, test connection
- Personal Settings Page: View personal profile (email, registration time), change password

Requirements:
1. Clearly define project background, user roles, core functions, page list, business processes, field definitions, and acceptance criteria, supplementing complete product logic.
2. Save the output file as docs/PRD.md, serving as the common basis for subsequent UI design, frontend development, backend development, and testing & acceptance.

This step might seem like "taking a detour."

But in actual development, it's very critical.

Because all subsequent steps will proceed based on this product requirements document.

If you're not satisfied with the AI's initial draft, directly send feedback to the AI, continue the conversation, until the final product requirements document is produced and saved to docs/PRD.md.

Step 3: Use the PRD to Generate Prompts for AI Design Tools

Now we have the requirements document, but we can't just throw it directly at an AI design tool.

Because the requirements document is for humans and development agents to read.

AI design tools need a different kind of input: UI design prompts that are more page-, layout-, state-, and visual-style-oriented.

So in this step, we have the AI generate a prompt specifically for AI design tools based on the docs/PRD.md product requirements document.

Save the prompt to: docs/design/ui-prompt.md

I would say this:

Based on the @docs/PRD.md product requirements document, generate a UI design prompt for use by AI design tools (e.g., Pencil, Figma Make, Stitch, Open Design).

Requirements:
1. The prompt must include product background, page list, design system, canvas requirements, component requirements, and output requirements
2. The primary color scheme should be blue
3. All text should be in Chinese
4. Save the output file as docs/design/ui-prompt.md

The key to this step is not "having AI write an extra prompt."

It's translating the product requirements document into a design language that AI design tools can understand.

For example, the PRD might state: "Supports prompt favoriting."

In the AI design tool prompt, this needs to become:

This is the conversion from "functional description" to "interface expression."

If this step is skipped, the AI design tool can easily generate a page that looks okay but lacks sufficient development detail.

Step 4: Generate High-Fidelity UI with AI Design Tools

Once we have the specialized UI design prompt, we can use AI design tools for design, such as: Pencil, Figma Make, Stitch, Open Design, etc. These AI design tools are suitable for developers who aren't very skilled in design.

Here, I use Pencil:

The goal of this step is not to generate a perfect design mockup in one go, but to first make the interface "visible."

After the first version is generated, I'll focus on 4 things:

If there's anything unsatisfactory, directly select that canvas or module. You can adjust it manually, or let the AI modify it based on your feedback.

After this step, the project should have at least these three files:

docs/PRD.md
docs/design/ui-prompt.md
docs/design/UI.pen

Product requirements document, UI design prompt, and UI design mockup are all ready.

Only then is it stable to proceed to the project skeleton and engineering configuration.

Step 5: Have AI Build the Project Skeleton

Before writing Rules, first have AI build the overall skeleton of the project.

Especially for full-stack projects, the frontend and backend are inherently two different systems. If the directory structure is messy from the start, the Rules, Commands, Hooks, Skills, and Subagents will all follow suit and become messy.

So I'll first have AI do a very specific thing:

According to the agreed structure, first generate the project directories and README documentation.

Prompt for AI

The prompt doesn't need to explain every directory, but the tech stack, minimum boundaries, and acceptance criteria must be clearly stated.

Please create a runnable, business-logic-free pnpm workspace full-stack project skeleton for the AI Prompt Asset Management Tool (PromptHub).

Tech Stack:
- Frontend: TypeScript, Vite, Vue 3, SCSS, Element Plus, Axios, Pinia, deployed to Cloudflare Pages
- Backend: TypeScript, Hono, Cloudflare Workers, D1, Drizzle ORM, Wrangler, deployed to Cloudflare Workers

Requirements:
1. The root directory contains README.md, CLAUDE.md, AGENTS.md, docs/, .claude/, .codex/, .agents/, frontend/, and backend/.
2. Use official templates to initialize the frontend and backend. The frontend only keeps the basic entry point and common directories; the backend only keeps environment types, D1 bindings, Drizzle basic configuration, and GET /api/health, without creating business pages, interfaces, or data tables.
3. Reserve a D1 binding named DB in wrangler.jsonc, without writing real Tokens, database IDs, or other sensitive information.
4. docs/ contains design/, api.md, database.md, and deployment.md, explaining design files, interfaces, databases, and Cloudflare deployment conventions.
5. The root directory, frontend/, and backend/ must each have corresponding README.md, CLAUDE.md, and AGENTS.md; all documentation, comments, and descriptions should be in Chinese.
6. Install dependencies and actually verify: frontend type check and production build, backend type check and local startup, D1 local initialization and migration, GET /api/health. Finally, list the executed commands and results.

Based on the above requirements, the AI will roughly plan the directory structure like this:

prompt-hub/
├── .agents/                 # AI agent configuration directory
├── .claude/                 # Claude configuration directory
├── .codex/                  # Codex configuration directory
├── backend/                 # Hono and Cloudflare Workers backend
│   ├── migrations/          # Drizzle SQL migrations
│   ├── src/
│   │   ├── config/          # Configuration
│   │   ├── db/              # D1 and Drizzle
│   │   ├── middleware/      # Hono middleware
│   │   ├── routes/          # API routes
│   │   ├── schemas/         # Input/Output Schemas
│   │   ├── services/        # Application services
│   │   ├── types/           # Environment and common types
│   │   └── utils/           # Utility functions
│   ├── AGENTS.md            # Codex backend rules
│   ├── CLAUDE.md            # Claude Code backend rules
│   ├── README.md            # Backend startup and deployment instructions
│   ├── drizzle.config.ts    # Drizzle Kit configuration
│   └── wrangler.jsonc       # Workers and D1 configuration
├── docs/
│   ├── design/              # UI design mockups and design instructions
│   │   ├── UI.pen           # Pencil design file
│   │   └── ui-prompt.md     # UI design prompt
│   ├── api.md               # API specification
│   ├── database.md          # Database specification
│   ├── deployment.md        # Deployment instructions
│   └── PRD.md               # Product requirements document
├── frontend/                # Vue 3 and Vite frontend
│   ├── public/              # Pages static assets and rewrite rules
│   ├── src/
│   │   ├── api/             # API client
│   │   ├── assets/          # Static assets
│   │   ├── components/      # Reusable components
│   │   ├── composables/     # Composable functions
│   │   ├── router/          # Router configuration
│   │   ├── stores/          # Shared state
│   │   ├── styles/          # SCSS global styles
│   │   ├── types/           # Common types
│   │   ├── utils/           # Utility functions
│   │   └── views/           # Route pages
│   ├── AGENTS.md            # Codex frontend rules
│   ├── CLAUDE.md            # Claude Code frontend rules
│   └── README.md            # Frontend startup and build instructions
├── AGENTS.md                # AI agent project constraints
├── CLAUDE.md                # Claude project constraints
└── README.md                # Project entry description

Three points to note here.

First, frontend/ is not just a few randomly created directories, but a frontend project skeleton initialized based on Vite.

Second, backend/ is not a purely hand-written directory tree, but a TypeScript project initialized based on the Hono Cloudflare Workers template.

Third, D1 is connected via the binding named DB in wrangler.jsonc, with Schema and migrations managed by Drizzle ORM. The skeleton phase only verifies the health check, without creating business tables in advance.

Finally, don't just check if the directories are complete. Have the AI list out the actual executed installation, type check, production build, backend startup commands, and health check results item by item. If the commands haven't run successfully, the skeleton cannot be considered complete.

The benefit of this is that later, the AI doesn't just "know what the directories look like," but also knows which framework initialization results these directories come from.

At this point, the project skeleton is clear.

Once the directories are clear, where the subsequent Rule files should be placed and what they respectively govern becomes naturally clear.

Why Choose This Tech Stack?

The core reason is very practical: it suits individual developers.

The biggest advantage is: one Cloudflare account can host the frontend, backend, and database.

Pages, Workers, and D1 all offer free plans or free quotas. For personal projects, learning projects, and early validation, you can usually go live at a lower cost first, then decide whether to upgrade based on actual traffic.

Step 6: Configure Rules — First, Get the AI Under Control

The core of this step is just one thing: let the AI know "your project rules."

But for a full-stack project, writing just one Rule file is not enough.

The frontend has its own standards, the backend has its own, and there are some global collaboration principles. If everything is crammed into one file, when the AI enters the frontend directory, it will also read a bunch of backend standards, and when it enters the backend directory, it will also read some frontend rules. With too much information, it's easy for it to get confused.

So my approach is: write Rules in layers.

Place a set of Rules in the project root directory, frontend/, and backend/. Claude Code uses CLAUDE.md, Codex uses AGENTS.md, and the two files at the same level maintain the same constraints.

Root Rule: Global Collaboration Principles

Place it in the project root prompt-hub/CLAUDE.md, and sync it to prompt-hub/AGENTS.md.

This file governs "project-level rules" — directory routing, frontend-backend collaboration methods, documentation sync rules, and global prohibitions.

Note, do not write specific tech stack details here.

Because how the frontend writes and how the backend writes should be constrained by the frontend Rule and backend Rule respectively. The root Rule only governs things everyone must follow.

# Project Rules

## Project Overview
This is a full-stack project for an AI Prompt Asset Management Tool, supporting user login, prompt CRUD, favorites, categories, as well as AI prompt generation and AI prompt optimization.

## Project Structure
- frontend/ → Frontend project, follow the CLAUDE.md or AGENTS.md in this directory
- backend/ → Backend project, follow the CLAUDE.md or AGENTS.md in this directory
- docs/ → Project documentation

## Frontend-Backend Collaboration Standards
- The unified API response structure is: { code: number, data: T, message: string }
- All APIs follow RESTful conventions
- Unified API path prefix: /api/v1/
- Frontend and backend synchronize API definitions via docs/api.md. Modifying an API requires updating the documentation first.
- Database design is uniformly recorded in docs/database.md

## Working Method
- Before writing code, first confirm requirements and technical approach, then formulate a development plan.
- When API changes are involved, update the API documentation first, then change the code.
- When page development is involved, first read the UI design mockups and product requirements document under docs/design/.
- Prioritize reusing existing directories and modules; do not arbitrarily add similar structures.

## Global Prohibitions
- Do not delete any files unless explicitly confirmed.
- Do not start writing code directly without confirming the technical approach.
- Do not read or modify dependency or build artifact directories like node_modules, dist.

Frontend Rule: Frontend Project Standards

Place it in prompt-hub/frontend/CLAUDE.md, and sync it to prompt-hub/frontend/AGENTS.md.

When the AI enters the frontend/ directory to work, it will read the corresponding tool's frontend Rule. Everything written here is frontend-related standards, not a word about backend matters.

# Frontend Project Rules

## Tech Stack

- Node.js
- pnpm
- TypeScript
- Vue 3
- Vite
- Vue Router
- Pinia
- Axios
- SCSS + CSS Variables
- Element Plus
- Cloudflare Pages

## Framework Standards

- Uniformly use Composition API + `<script setup>` syntax
- Business code must not use Options API
- Page-level components go in `views/`, reusable components go in `components/`
- Simple component internal state should prioritize `ref` / `reactive`, avoid overusing global stores

## Common Commands

- `pnpm dev`: Start Vite dev server
- `pnpm type-check`: Execute frontend type checking
- `pnpm build`: Execute production build, output used for Cloudflare Pages deployment

## Directory Standards

- `src/api/`: API call encapsulation
- `src/assets/`: Static assets
- `src/components/`: Common components
- `src/composables/`: Composable functions
- `src/layouts/`: Layout components
- `src/views/`: Page-level components
- `src/router/`: Router configuration
- `src/stores/`: State management
- `src/styles/`: Global styles and design variables
- `src/types/`: Common type definitions
- `src/utils/`: Utility functions

## API Standards

- API calls are uniformly placed in `src/api/`
- Page components do not directly call `axios` / `fetch`
- Request parameters and response results must define TypeScript types
- Request/response structures should be consistent with the backend's `ApiResponse<T>`

## Style Standards

- Page development should prioritize referencing UI design files under `docs/design/`
- Use `scoped` styles to avoid global pollution
- Colors, spacing, fonts, etc., use CSS variables, do not hardcode
- SCSS is mainly used for nesting, module splitting, mixins, and functions

## Naming Conventions

- File names: kebab-case
- Variables/functions: camelCase
- Constants: UPPER_SNAKE_CASE
- Types/Interfaces: PascalCase

## Prohibitions

- In principle, the use of `any` is prohibited; if necessary, the reason must be stated
- Do not actively read or modify generated directories like `node_modules`, `dist`, `build`

Backend Rule: Backend Project Standards

Place it in prompt-hub/backend/CLAUDE.md, and sync it to prompt-hub/backend/AGENTS.md.

Similarly, when the AI enters the backend/ directory to work, it will read the corresponding tool's backend Rule.

# Backend Project Rules

## Tech Stack

- Node.js
- pnpm
- TypeScript
- Hono
- Cloudflare Workers
- Cloudflare D1
- Drizzle ORM
- Wrangler

## Architecture Standards

- Split responsibilities by `routes → services → db`
- `routes/` is responsible for routing, parameter parsing, and responses, not piling up business logic
- `services/` is responsible for business rules and process orchestration
- `db/` is responsible for D1 connection, Drizzle Schema, and data access
- `schemas/` is responsible for input/output validation structures
- `middleware/` is responsible for cross-cutting logic like authentication, logging, error handling
- Hono's binding types must be explicitly declared, access D1 and environment variables via `c.env`
- TypeScript code uniformly uses 2-space indentation, necessary comments use JSDoc style

## Common Commands

- `pnpm dev`: Start local Workers dev service via Wrangler
- `pnpm type-check`: Execute backend type checking
- `pnpm exec drizzle-kit generate`: Generate migrations using Drizzle Kit
- `pnpm exec wrangler d1 migrations apply DB --local`: Apply migrations to local D1
- `pnpm exec wrangler deploy`: Deploy to Cloudflare Workers

## API Standards

- API path: /api/v1/{resource name}
- GET query, POST create, PUT update, DELETE delete
- Request parameters must be validated by Schema
- Responses uniformly use the `ApiResponse<T>` structure

## Database Standards

- Table names use snake_case (e.g., `prompts`)
- Field names use snake_case
- Every table must have id, created_at, updated_at fields
- Drizzle Schemas are uniformly placed in `src/db/`
- Migration files are generated by Drizzle Kit and applied to D1 via Wrangler
- Business code should prioritize using Drizzle ORM, not directly concatenating SQL

## Exception Handling

- Use Hono's `app.onError` to uniformly handle uncaught exceptions
- Use `app.notFound` to uniformly handle non-existent routes
- Error responses must comply with the error code standards in `docs/api.md`

## Prohibitions

- Do not hardcode sensitive information like Tokens, database IDs, API Keys in code or `wrangler.jsonc`
- Do not directly read Workers bindings from `process.env`, uniformly use typed `c.env`
- Do not manually modify Drizzle's generated migration records or Wrangler's local persistent data

The Relationship Between the Three Layers of Rules

You might ask: How does the AI know which of these three layers of Rules to read?

It's actually very simple.

Both Claude Code and Codex read the corresponding project rules based on the current working directory:

You don't need to manually specify.

This means:

This is the value of layered Rules.

Write global things once, write specific things separately.

Many people initially want to study how to write more advanced Prompts or choose stronger models.

I later realized that these are not the first problems to solve.

First, clearly define the boundaries, then talk about efficiency.

Step 7: Commands — Define Standard Development Processes

Rules solve "what can be done, what cannot be done."

Commands solve "how to do it each time."

In actual development, there's a very annoying problem:

Every time I assign a task to AI, I have to repeat a bunch of requirements.

"First analyze the requirements, then produce a design, then write the code, check it yourself after writing, and finally generate a commit message..."

This is very draining on patience.

Because you think you're developing, but in reality, a portion of your energy is constantly spent on "correcting the AI's default actions."

So I encapsulated the most frequently repeated operations in development into three Commands:

/dev: Standard Development Process

This is the most used one.

Every time a development task is received, input /dev, and the AI follows a fixed process.

Create .claude/commands/dev.md:

You are a full-stack development expert. After receiving a development task, strictly follow the process below:

## Step 1: Requirements Analysis
- Understand the task goal and business background
- List the involved functional modules
- Sort out the involved files and directories

## Step 2: Component Design (if frontend is involved)
- If docs/design/UI.pen or exported preview images already exist, first reference the UI design mockup, do not design pages out of thin air
- Plan the page structure and component splitting method
- Clarify which are page-level components and which are reusable components
- List the utils, composables, and stores needed

## Step 3: API Design (if backend is involved)
- Output RESTful API definitions
- Include: path, method, request parameters, response structure
- Clarify which APIs need to be added and which need to be modified

## Step 4: Formulate a Modification Plan
- List the files to be added and modified
- For each file, explain the content and reason for the change
- Mark the order of changes (which to change first, which later)

## Step 5: Code Implementation
- Strictly follow the plan, do not exceed the scope
- Write code according to the project Rules
- Frontend components must initiate requests through the API layer in `src/api/`
- Backend APIs must have parameter validation
- After completing each file, briefly explain what was changed

Notice this process.

It's not just two steps of "analyze → write code."

There are three extra steps in between: component design, API design, and plan formulation.

These three steps are the most critical in my experience.

If you skip design and write code directly, the AI easily "writes whatever comes to mind," and ends up producing a bunch of things you don't want.

If you skip the plan, the AI might change 10 files in one go, and you have no idea what it changed or why.

Having a plan before starting, versus starting without a plan, yields very different results.

/commit: Generate Standardized Commit Messages

Code is written, time to commit.

Manually writing commit messages every time is annoying, and letting AI write casually easily leads to inconsistent formats.

So I separately encapsulated a /commit.

Create .claude/commands/commit.md:

Based on the current code changes, generate a commit message conforming to the Conventional Commits specification.

!`git diff --cached`

Requirements:
- Type: feat / fix / refactor / docs / chore / style / test / ci
- Description in Chinese, no more than 50 characters
- If necessary, supplement the reason for the change in the body (optional)
- Do not add extra explanations, directly give the result

Conventional Commits format: <type>(<scope>): <subject>

In the future, after writing code, input /commit, and the AI will automatically read the current code changes and generate a uniformly formatted commit message.

/review: Code Review

Before committing code, it's best to go through a review.

But reviewing your own code makes it easy to "not see the problems."

Having AI do this actually works quite well.

Create .claude/commands/review.md:

Review the current code changes, checking the following dimensions:

1. **Security Issues**: SQL injection, XSS, exposed sensitive information
2. **Error Handling**: Uncaught exceptions, swallowed errors
3. **Type Safety**: Abuse of any, missing return types
4. **Performance Issues**: Unnecessary re-renders, missing caching
5. **Logic Errors**: Boundary conditions, null handling

Classify by severity: Critical / Warning / Suggestion.
For each issue, note the file path and line number, and provide modification suggestions.
If there are no issues, directly say "No issues found."

I generally use this Command before /commit.

Write code → /review first pass → fix issues → /commit to submit.

Forms a small closed loop.

How These Three Commands Are Triggered in the AI Prompt Asset Management Tool

Just talking about definitions is still a bit abstract.

Let me use a real task from the AI Prompt Asset Management Tool as an example: developing the "Prompt Display Page."

Developing this page requires implementing three things:

At this point, I won't directly say "write the page for me."

I'll first input:

/dev @docs/PRD.md Develop the prompt display page

After receiving this, the AI won't immediately start writing.

It will first follow the process in dev.md:

Step 1, Requirements Analysis. It will first break down the task: the frontend needs to add components, pages, routes; the backend needs to add query APIs, pagination parameters, filter conditions.

Step 2, Component Design. For example: The AI will tell you roughly how to split the frontend:

Step 3, API Design. The AI will first list the backend APIs, for example:

GET /api/v1/prompts?page=1&pageSize=20&category=writing

Response structure:

{
  "code": 0,
  "data": {
    "list": [],
    "total": 100,
    "page": 1,
    "pageSize": 20
  },
  "message": "success"
}

Step 4, Formulate a Development Plan. It will list the files to be changed one by one, telling you which are new, which are modifications, and why.

At this point, you already have a good grasp of the situation.

Because the AI isn't "blindly writing code," but presenting you with a plan first.

Once you confirm it's okay, it will proceed to Step 5 to start implementation.

After writing, I won't commit directly.

I'll then input:

/review

At this point, review.md will check according to the preset dimensions.

For example, it might give results like this:

Some of these issues, you might not see at first glance when reviewing the code yourself.

Especially boundary conditions and type issues, which are easy to miss.

After fixing these issues, I finally input:

/commit

The AI will provide a commit message based on the current changes. For example:

feat(prompt): Add prompt display page and pagination query API

If this change also incidentally fixed a boundary issue with a filter parameter, it might also generate:

feat(prompt): Add prompt display page and improve filter query logic

At this point, a complete small closed loop has been run:

/dev is responsible for breaking down the task clearly, designing it well, then starting to write.

/review is responsible for finding problems before committing.

/commit is responsible for standardizing the final commit action.

This is what I mean:

The real usefulness of Commands is not saving a few keystrokes, but making the entire set of development actions stable.

The Coordination of the Three Commands

Here, you can see the relationship between these three Commands:

A complete development cycle is:

/dev → write code → /review → fix issues → /commit → commit

Every step has a standard action.

No need to repeat yourself every time. No worry about it skipping steps.

Commands aren't for saving a few words.

They're for turning "getting it right occasionally" into "getting it right by default every time."

Step 8: Subagents — Start Dividing Labor

At this point, Rules and Commands have already set the "rules" and "processes."

But there's still one problem: one AI doing everything will forget things.

An AI's context window, no matter how large, is not infinite.

You ask it to analyze requirements, design table structures, write backend APIs, write frontend pages, and finally do a Review — stuffing a bunch of things in, it easily loses key information from earlier on towards the end.

The solution is straightforward: split.

For the AI Prompt Asset Management Tool, I split the Subagents like this:

Each Subagent is placed in the .claude/agents/ directory, one .md file per role.

The file contains front-matter (defining metadata) and system prompts (defining behavior).

Claude Code will automatically determine when to call which Agent based on the description field. Of course, you can also directly specify which Agent to use for handling a requirement in the conversation.

The benefit of doing this isn't "more advanced," but more stable.

Because once the context is clean, the output quality will noticeably improve.

1. Product Agent: Clarifying Requirements

The Product Agent isn't here to write code.

Its core value is just one thing: first clearly define what needs to be done.

For example, there's a requirement in the AI Prompt Asset Management Tool: add a "batch export prompts" feature.

If you directly throw this sentence to a development Agent, there will be many problems.

How is the export scope determined? What is the export format? Which fields does the export content include? How to handle when no prompts are selected? How does the page provide feedback if the export fails?

So the Product Agent's definition should look like this (.claude/agents/product-manager.md):

name: product-manager
description: Product requirements analysis expert. Triggered when the user proposes a new feature, the requirements are still vague, or when functional descriptions, processes, field definitions, and acceptance criteria need to be output.
tools: Read, Grep, Glob
model: opus
color: purple

You are a product analysis expert, responsible for organizing vague requirements into executable task descriptions for development.

## Your Responsibilities
- Understand user needs, identify goals, roles, boundary conditions, and exception flows
- Output functional descriptions, page flows, field definitions, and acceptance criteria
- Break down vague descriptions into deliverable development tasks

## Your Input
- User's original requirements
- Existing system functional descriptions
- Existing page or API constraints

## Your Output
- Functional goals
- User operation flow
- Field and state definitions
- Boundary cases
- Acceptance criteria
- List of questions to be confirmed

## Constraints
- Do not directly write implementation code
- Do not arbitrarily decide on technical solutions
- When encountering requirement ambiguities, must explicitly list questions to be confirmed

The content it outputs will be similar to this:

See, only now are the requirements truly in a "developable" state.

2. Frontend Agent: Only Manages Pages and Interactions

The Frontend Agent's goal is very clear: turn requirement descriptions, UI design mockups, and API documentation into usable components and pages.

It only needs to care about four things:

The Frontend Agent's definition can be written like this (.claude/agents/frontend-developer.md):

name: frontend-developer
description: Frontend development expert. Triggered when the user requires developing components, pages, interaction logic, or needs to implement Vue 3 + TypeScript frontend features.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
color: green

You are a frontend development expert, responsible for implementing Vue 3 + TypeScript pages, components, and interaction logic.

## Your Responsibilities
- Implement pages and components based on requirement descriptions and API documentation
- Keep component responsibilities clear, avoid single files becoming overly bloated

## Your Input
- Requirement descriptions or product requirements document output by the Product Agent
- API definitions provided by the Backend Agent
- Existing frontend project structure and component standards

## Your Output
- Page code
- Component code
- API call layer code
- Necessary type definitions

## Constraints
- Do not modify backend code or databases
- Do not arbitrarily change API fields
- Do not skip handling interaction states and exception states

If it were to handle the "batch export prompts" requirement, it should focus on:

These matters are very suitable for the Frontend Agent.

Because its context won't be stuffed with irrelevant information like database table structures, index designs, or transaction processing.

3. Backend Agent: Only Manages APIs, Data, and Business Rules

The Backend Agent is the same.

It doesn't need to care what the buttons look like, nor participate in page layout.

The Backend Agent's definition can be written like this (.claude/agents/backend.md):

name: backend-developer
description: Backend development expert. Triggered when the user requires designing API interfaces, D1 data structures, business logic implementation, or needs Hono + Cloudflare Workers development.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
color: orange

You are a backend development expert, responsible for designing and implementing TypeScript + Hono + Cloudflare Workers + D1 interfaces, data models, and business logic.

## Your Responsibilities
- Design RESTful APIs based on requirement descriptions
- Use Drizzle ORM to design Schemas, indexes, and data constraints
- Implement Hono routes, Services, database access, and middleware
- Handle parameter validation, data consistency, exceptions, and batch operation logic

## Your Input
- Functional descriptions and field definitions output by the Product Agent
- Existing database design and project code structure
- API contracts needed by the frontend

## Your Output
- API definitions (URL, method, parameters, response structure)
- Drizzle Schema and migration plan
- Core business code
- Error codes and exception handling descriptions

## Constraints
- Do not modify frontend page code
- Do not output implementations inconsistent with the project's tech stack
- Must clearly explain data constraints and exception handling strategies

Still the same requirement.

What it needs to be responsible for is:

The Frontend Agent and Backend Agent are working on the same feature, but their focus is completely different.

After splitting, both Agents will be more focused.

4. Review Agent: Only Responsible for Finding Faults, Not Writing Code

Many people make a mistake when using AI for Review:

Letting it review while also letting it fix things along the way.

What's the result?

It sometimes stands from the developer's perspective, sometimes from the reviewer's perspective, roles mixed together, and judgment becomes distorted.

A more stable approach is: let the Review Agent only be responsible for finding problems.

It doesn't participate in requirement discussions, isn't responsible for implementation, and doesn't casually fix code.

It only does reviews.

The definition can be written like this (.claude/agents/code-reviewer.md):

name: code-reviewer
description: Code review expert. Triggered when the user says "help me review the code", "check if there are any issues with this change", or when code changes need a quality review.
tools: Read, Grep, Glob
model: sonnet
color: blue

You are a code review expert, responsible for identifying issues and assessing risks in existing changes.

## Your Responsibilities
- Check if the functionality meets the requirements
- Check code standards, consistency, and maintainability
- Identify potential bugs, boundary issues, and security risks
- Provide clear modification suggestions and priorities

## Your Input
- Changed code
- Original requirement description
- Project standards and existing implementation patterns

## Your Output
- List of issues
- Risk levels
- Modification suggestions
- Optional optimizations

## Constraints
- Do not directly modify code
- Do not rewrite requirements
- Conclusions must be based on specific code and specific scenarios
- Must output grouped by "High-risk issues / General issues / Optimizable items"

For example, when reviewing "batch export prompts," it might raise these issues:

You'll find that once Review is independent, the quality is much higher.

Because it's no longer thinking about "how to finish writing quickly," but specifically thinking about "what could go wrong here."

How to Call These Four Subagents in the AI Prompt Asset Management Tool?

What was discussed earlier were definitions.

What's truly critical is: how to call them in the project.

I'll use the "batch export prompts" requirement from the AI Prompt Asset Management Tool as a complete example.

Step 1: First Call the Product Agent to Solidify the Requirements

For example, I would send a task like this:

Please use the product-manager agent to first organize the "batch export prompts" requirement into a developable description.

The purpose of this step isn't to make the documentation look nice.

It's to first eliminate ambiguities.

Step 2: Hand the Product Output to the Frontend Agent and Backend Agent Separately

After the Product Agent has organized the requirement description, I won't re-explain the entire context again.

Instead, I'll use its result as input, handing it to the frontend and backend separately.

The way to call the Frontend Agent would be like this:

Please use the frontend-developer agent to complete the frontend development for "batch export prompts" based on the following requirement description.

Requirement Description: [Paste product-manager's output]
Design File: docs/design/UI.pen
Requirement: First, split the page and components against the UI design mockup, do not arbitrarily change the overall visual style.

The Backend Agent would be called like this:

Please use the backend-developer agent to complete the backend implementation for "batch export prompts" based on the following requirement description.

Requirement Description: [Paste product-manager's output]

This is the real usage of Subagents.

Distribute the same requirement to different roles for processing based on their responsibilities.

Step 3: After Frontend and Backend Output, Hand to the Review Agent for Review

Once both frontend and backend are complete, hand the results to the Review Agent:

Please use the code-reviewer agent to review this "batch export prompts" change.

Requirement Description:
[Paste product-manager's output]

Change Scope:
[Paste the main changes from frontend and backend]

This step is very critical.

Because the Review Agent holds both the "original requirements" and the "final implementation" simultaneously, it can judge whether there's any deviation and where there are oversights.

Step 4: If Requirements Change, Only Re-run the Relevant Agents

Another particularly practical point about Subagents: the impact of changes is controllable.

For example, later you decide to change "maximum 500 prompts per single export" to "maximum 2000 prompts per single export," and add a "group export by category" feature.

At this point, you don't need to re-run the entire process from scratch.

You only need to:

This is one of the most important values of engineering: changes are locally controllable.

You won't disrupt the entire context just because of a small requirement change.

Why is this step important?

Because for the first time, it turns AI from "an all-capable assistant that wants to do everything" into "multiple collaborative roles, each with their own duties."

Once you figure this out, you'll find many problems naturally disappear.

Don't let one AI do everything.

After splitting, the output quality of each Agent will noticeably improve. Not because the model suddenly got stronger, but because the context became cleaner.

This is the same principle as real team collaboration.

You wouldn't let one person simultaneously do product, design, frontend, backend, testing, and finally Code Review.

The same goes for AI.

Step 9: Skills — Supplement Specialized Capabilities

Subagents solved the division of labor problem.

But within each Agent, there are still a bunch of high-frequency, repetitive actions.

For example:

If these operations are driven by hand-written Prompts every time, the efficiency isn't actually high.

A better approach is: prioritize using already solidified Skills.

Many capabilities have already been written by the community, just install them directly, no need to reinvent the wheel.

For the AI Prompt Asset Management Tool's tech stack of "Vue 3 + Hono + Cloudflare Workers + D1," I would install these:

For the Frontend Agent:

For the Backend and Cloudflare Engineering Agent:

General Capabilities:

After installation, these Skills become the Agent's "built-in skills," so you don't have to teach them step-by-step every time.

Specific operational details like installation methods and triggering methods were already covered in my previous article on Skills, so I won't repeat them here.

Step 10: MCP — Connecting External Capabilities

In the previous steps, what AI did was still at the "code level" — reading code, writing code, generating files.

But a real project isn't just code.

You also need to look at design mockups, query databases, operate browsers, and browse official documentation.

AI needs to operate these external systems.

This is the value of MCP.

This AI Prompt Asset Management Tool uses Vue 3, Hono, Cloudflare Workers, and D1. I would prioritize connecting the following four types of MCPs:

1. Pencil MCP — Generate Components and Pages Directly from .pen Design Files

Earlier, we already used Pencil to generate UI design mockups.

At the development stage, the most natural approach isn't to first move the design mockup to another tool, but to directly connect Pencil MCP.

Previously, when writing a page, I had to open the design mockup on one side and switch to the IDE on the other to copy it. Layout, font sizes, spacing, button states — all translated by eye.

After connecting Pencil MCP, the process becomes:

Give docs/design/UI.pen to Claude, tell it: "Generate the frontend page according to this design mockup"

It will do several things:

The value of this step is very direct:

Use Pencil for UI earlier, then directly use Pencil MCP to implement components and pages later, without manually translating in between.

If your UI design mockups are in Figma, or subsequent design collaboration mainly happens in Figma, then directly use Figma MCP.

The idea is the same: let AI read the design mockup structure, extract style information, and then generate components or pages. The only difference is that Pencil MCP reads .pen files, while Figma MCP reads Figma node links.

2. Cloudflare MCP — Let AI Check Workers, D1, and Pages

After placing the frontend, backend, and database on Cloudflare, debugging isn't just about looking at code locally.

You also need to confirm whether the D1 database exists, whether the DB binding is correct, whether the Worker deployed successfully, and whether the Pages build is normal.

The official Cloudflare MCP covers Workers, D1, Pages, and other APIs. After authorization, you can let AI directly read the current status of these resources.

For example, you can ask:

This step is most suitable for handling three types of things:

Note: Cloudflare MCP connects to a real account. Grant minimal permissions first, and any operations that create, modify, or delete resources must be confirmed separately.

3. Chrome DevTools MCP — Let AI Operate the Browser Itself

Previously, for frontend integration testing, I had to open the browser myself, F12, look at console errors, screenshot and paste to AI, and it would guess the problem.

Now, AI can open Chrome itself, look at the console, check network requests, read the DOM structure, and run performance audits.

A few typical scenarios in the AI Prompt Asset Management Tool:

It's not "guessing" the problem, it's "seeing" the problem.

4. Context7 MCP — Pull Official Documentation in Real-Time

The APIs and configuration methods for Vue, Hono, Drizzle ORM, and Wrangler are all updated, you can't just rely on model memory to write code.

For example, how D1 binding types should be generated, how the Drizzle migration directory should be configured — for the current version, you should first look at the documentation.

Context7 solves this problem.

Before AI writes code, it first pulls the latest official documentation to ensure the API used is for the current version.

MCP is a Key Turning Point

The previous Rules, Commands, Subagents, and Skills all solved the problem of "how AI writes code."

MCP solves the problem of "how AI does work."

And in real development, what takes up the most time is often not writing code.

It's querying data, matching interfaces, operating the browser, browsing documentation, and repeatedly verifying.

Once MCP is connected, AI truly begins to enter the production environment.

Step 11: Hooks — Adding Checkpoints

AI works very fast, but speed also means the speed of making mistakes can be faster.

If you don't watch closely, you won't notice at all.

So Hooks are needed.

The essence of a Hook is an "automatic checkpoint" — automatically inserting a piece of validation logic before or after AI's key operations.

The AI Prompt Asset Management Tool in this article is a full-stack project, both frontend and backend need to be managed. I configured the following set of Hooks, written in .claude/settings.json.

1. Automatic Code Linting (PostToolUse)

Both frontend and backend are TypeScript. Use a PostToolUse Hook to determine the file path, then enter the corresponding directory to execute ESLint:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=\"$CLAUDE_TOOL_INPUT_FILE_PATH\"; case \"$FILE\" in *frontend/*) cd frontend && pnpm eslint --fix \"${FILE#*frontend/}\" || echo 'Frontend ESLint auto-fix failed, please handle during acceptance phase' >&2 ;; *backend/*.ts) cd backend && pnpm eslint --fix \"${FILE#*backend/}\" || echo 'Backend ESLint auto-fix failed, please handle during acceptance phase' >&2 ;; esac"
          }
        ]
      }
    ]
  }
}

Three details here:

There's only one Hook, but the frontend and backend rules are still separate. This reduces duplicate configuration and avoids mixing browser and Cloudflare Workers runtime rules.

2. Intercept Dangerous Delete Commands (PreToolUse)

This is the most critical. Before AI executes rm -rf or DROP TABLE, block it directly.

{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        {
          "type": "command",
          "command": "INPUT=$(cat); CMD=$(echo \"$INPUT\" | jq -r '.tool_input.command'); echo \"$CMD\" | grep -qE 'rm\\s+-rf|DROP\\s+TABLE|DROP\\s+DATABASE|TRUNCATE|git\\s+push.*--force' && echo 'Dangerous command intercepted: '\"$CMD\" >&2 && exit 2 || exit 0"
        }
      ]
    }
  ]
}

A few key points:

3. Desktop Notification When AI Finishes Work (Stop)

When AI runs a long task (e.g., generating 10 APIs, modifying 5 components), you can't keep staring at the screen.

The Stop Hook triggers when the AI finishes responding, perfect for sending a desktop notification.

{
  "Stop": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "osascript -e 'display notification \"Task completed, please check the results\" with title \"Claude Code\" sound name \"Glass\"'"
        }
      ]
    }
  ]
}

macOS uses osascript to call system notifications, with a 'ding' sound.

My current common posture: let AI run backend API generation, switch to the browser to read docs, get a drink of water. Ding, come back and review.

4. Automatically Sync Documentation After API Modification (PostToolUse)

The frontend and backend of the AI Prompt Asset Management Tool synchronize API definitions via docs/api.md (this was agreed upon in the root Rule).

But AI often forgets to update the documentation after modifying Hono routes or API Schemas. Configure a Hook to force a reminder:

{
  "matcher": "Write|Edit",
  "hooks": [
    {
      "type": "command",
      "command": "FILE=\"$CLAUDE_TOOL_INPUT_FILE_PATH\"; case \"$FILE\" in *backend/src/routes/*.ts|*backend/src/schemas/*.ts) echo 'Backend API change detected, please sync update docs/api.md' >&2 ;; esac"
    }
  ]
}

This doesn't intercept, only reminds. The AI sees the stderr output and will proactively update the documentation.

5. SessionStart Automatically Loads Latest API and Table Structures

Every time a new session starts, the AI has to re-explore the project. I make it automatically read the latest api.md and database.md at startup.

{
  "SessionStart": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "echo 'Current API Definitions:'; cat docs/api.md; echo 'Current Database Structure:'; cat docs/database.md"
        }
      ]
    }
  ]
}

The stdout of the SessionStart Hook directly enters the AI's context. This means the AI knows from the start: what APIs currently exist, what fields are in the tables.

No need to make it cat docs/ every time.

The Real Value of Hooks

The most valuable part of Hooks isn't that they help you do one more check.

It's turning "things that originally relied on people to remember" into "things that will definitely happen by default."

People forget. AI also forgets.

But Hooks don't.

AI can be fast, but it cannot be chaotic.

Hooks are the ones responsible for hitting the brakes.

Step 12: Plugin — Solidifying Capabilities

At this point, the entire AI workflow for the AI Prompt Asset Management Tool is already running.

Looking back at the groundwork laid earlier — requirements documents, UI design, and project skeleton — plus the steps from Rules to Hooks, a complete production line has actually been formed. The problem that follows is:

These configurations are scattered all over the project.

Next time you start a new project, you'll have to reconfigure all of this again.

This is the problem Plugins solve.

A Plugin isn't about adding a new capability to AI.

It's more like a storage box: organizing the already smoothly running Rules, Commands, Subagents, Skills, MCPs, and Hooks into an installable, distributable, upgradable capability package.

Let's be clear first: Plugins are not mandatory.

If you're just one person using it in the current project, or this workflow is still in trial and error, doing the first eleven steps is enough. Don't force yourself to make a Plugin just to "look complete."

When is it worth making a Plugin?

At this stage, making a Plugin becomes meaningful.

A Plugin is just packaging all the above things into one directory:

prompt-hub-plugin/
├── .claude-plugin/
│   └── plugin.json
├── CLAUDE.md
├── commands/
├── skills/
├── agents/
├── hooks/
└── .mcp.json

The most critical part here is .claude-plugin/plugin.json.

It's the Plugin's "business card."

It's not responsible for storing specific rules, nor for writing command logic. It's only responsible for telling the AI tool: what this plugin is called, what problem it solves, what the current version is, and who maintains it.

For example, for the AI Prompt Asset Management Tool workflow, it can be written like this:

{
  "name": "prompt-hub-workflow",
  "description": "AI Prompt Asset Management Tool AI Programming Workflow: Includes project rules, standard development commands, frontend/backend Subagents, specialized Skills, MCP configuration, and automatic check Hooks.",
  "version": "1.0.0",
  "author": {
    "name": "XPoet"
  }
}

The Plugin itself is optional, but once you decide to make a Plugin, plugin.json is required.

Other directories can be included as needed. If you only have Skills and Hooks, just put skills/ and hooks/. If you don't have MCP, you don't need .mcp.json. Don't stuff in useless things just to make it look complete.

After packaging, the next project just needs to install this Plugin to bring the entire workflow over.

You can even publish it within the team, or directly release it to the community, letting others use your workflow too.

Step 13: Let AI Plan Autonomously and Continuously Advance According to the Development Plan

The previous twelve steps have already prepared the requirements, design, project rules, and tools.

The last step is to let Codex or Claude Code read these real materials, autonomously break down the roadmap, and continuously complete development, verification, fixing, and committing.

The core process is very simple:

Read project → Inventory current status → Make a plan → Develop by business closed-loop → Verify and fix → Commit → Continue to the next item

delivery-loop.png

To prevent long tasks from only existing in the chat history, we have the AI maintain the roadmap and progress in docs/development-plan.md.

1. First, Have AI Generate a Plan Based on Project Facts

Don't directly say "develop the entire project," and don't manually break down all tasks for the AI.

Let it first read the PRD, UI design, project rules, API documentation, database documentation, and existing code, then plan the sequence based on dependencies.

You can directly use the following prompt:

You are the lead development Agent for the PromptHub full-stack project.

Please first read and cross-check:
- docs/PRD.md and docs/design/UI.pen
- README.md, CLAUDE.md, AGENTS.md in the root directory and frontend/, backend/
- docs/api.md, docs/database.md, docs/deployment.md
- Existing code and configuration in frontend/, backend/
- Git status, commit history, and project scripts

First, inventory completed, partially completed, not started, and blocked capabilities, then create or update
docs/development-plan.md.

Plan Requirements:
1. Split tasks by independently verifiable business functions, not just by frontend, backend, database layers.
2. For each task, clearly state the goal, basis, dependencies, involved files, verification method, acceptance criteria, and commit scope.
3. Preserve existing user modifications, do not read or modify generated directories like node_modules, dist.
4. When APIs are involved, update docs/api.md first; when databases are involved, update docs/database.md and migrations first.
5. Self-review the task coverage, sequence, and verification methods, correct them, then directly start the first task.

The key point is just one sentence: The plan must come from the current project, not be a generic checklist generated out of thin air.

2. Continuously Advance by Business Closed-Loop

Don't split tasks into "write all databases first, then all backends, finally all frontends."

A more suitable split is:

A task typically involves documentation, data, APIs, pages, and verification simultaneously. After completion, the user should be able to actually use this feature.

After the plan is generated, have the AI continuously execute according to the following closed loop:

Please continue advancing according to docs/development-plan.md.

For each task:
1. Check Git status and confirm the scope for this time.
2. Read the corresponding requirements, design, documentation, and code.
3. Update API or database documentation first, then implement the feature.
4. Run matching type checks, tests, builds, API, or browser verifications.
5. Continue fixing and re-verifying based on failure information; cannot leave failures for me.
6. Self-review requirements, boundaries, security, types, documentation sync, and change scope.
7. Update plan status and verification evidence.
8. Only stage files for the current task, create one independent commit after verification passes.
9. Continue to the next task after committing, without waiting for my reply of "continue."

What's truly important here isn't letting AI write more code in one go.

It's binding "implementation, verification, fixing, committing" within the same task. After completing each business function, leave a checkable, recoverable plan status and Git commit.

3. Only Pause When a Real Decision Is Needed

Reducing manual confirmation doesn't mean canceling safety boundaries.

When encountering the following situations, the AI must pause:

Beyond these, directory choices, code reuse, task splitting, test fixing, and plan updates should all be handled by the AI itself.

If the session is interrupted, next time just tell it:

Please read docs/development-plan.md, Git commit history, and current workspace status,
continue from the first incomplete task whose dependencies are met, and follow the original verification and commit rules.

This is the value of Step 13.

Let the lead AI plan the roadmap based on project facts, continuously execute by business closed-loop, and only stop when a real human decision is needed.

Before and After Comparison

After all this talk, how big is the difference really?

Comparison Item Without Engineering With Engineering
UI Design Pages designed while coding, only realizing halfway that the information hierarchy is wrong Use AI design tools to generate initial UI, page structure and component boundaries visible in advance
Task Start Every new task requires re-explaining background, tech stack, and taboos Rules automatically load basic constraints, AI works within correct boundaries from the start
Development Process Do whatever comes to mind, requirements analysis, design, implementation often mixed together /dev follows a fixed process: analyze first, then design, then implement, then self-check
Role Division One AI simultaneously thinks about product, writes frontend, writes backend, does review, context quickly gets messy Subagents each manage their own piece, product, frontend, backend, review responsibilities are clear
Requirement Changes Changing one point often affects a large area, can only have AI re-read the entire context Only re-run relevant Agents, other outputs remain stable
Specialized Capabilities Every time, need to re-teach AI how to generate APIs, documents, export templates Skills encapsulate high-frequency capabilities, directly call according to standards
Risk Control AI might accidentally delete files, run dangerous commands, only discovered when it's too late Hooks can intercept high-risk operations in advance
Cross-Project Reuse Switching projects, configurations copied again, missing one file loses a piece of capability Plugin optional packaging, mature workflows can be migrated with one click
Development Plan One sentence to let AI develop the complete project, process easily gets out of control Lead AI reads project status, autonomously splits the overall roadmap and business closed-loop tasks, and continuously maintains plan status
Acceptance Method AI finishes writing code, you judge by feeling if there are problems AI runs checks according to task acceptance criteria, fixes issues, records verification evidence, commits after passing
Team Collaboration Everyone has their own prompts and habits, output quality is unstable Rules, Commands, Skills, Hooks uniformly solidified, team collaborates according to the same set of standards

You'll find that the real change isn't just "faster."

It's that the entire development process starts to become stable, controllable, and reusable.

It's not that AI got smarter, it's that you systematized it.

With the same model capability, the output quality with and without engineering is not on the same order of magnitude.

Summary

Here, this series has written 9 articles, honestly exceeding my expectations.

Initially, I just wanted to clearly explain a few concepts in Claude Code.

From the first article on "why engineering is needed" to this one, which truly strings all the concepts into a production line, the core of the entire system is still these few things:

Take any single one out, and it's just a feature point.

But string them together, and what you get is no longer just a "tool."

It's a continuously evolvable AI development system.

With each project you do, your Rules will become more refined, Commands more handy, Skills richer, Hooks more stable, Plugins more mature, and the AI's ability to formulate roadmaps, split tasks, verify results, and control commit boundaries will increasingly align with your team's rhythm.

AI's capabilities might change quickly.

But what can truly accumulate over the long term is your engineering system.

What truly creates a gap isn't who uses a stronger model, but who first puts AI into their own engineering system.

ending.png