Task Objective
Core Capabilities
- This Skill is used to: based on the functional intent or modification requirements provided by the user, automatically generate or modify a complete implementation plan that conforms to the six-layer architecture specification
- Capabilities include:
- Cross-cutting modification: initiate modifications from any layer, automatically derive and coordinate the collaboration of the other five layers
- Requirement parsing and domain identification: analyze user intent, identify the business domains and data entities involved
- Layer-by-layer code generation/modification: generate or modify the code of each layer in data flow order
- Cross-layer consistency validation: ensure that field names, types, and error handling remain consistent across layers
- Trigger conditions:
- The user proposes a new feature requirement (e.g., "add a user comment feature")
- The user proposes a modification requirement (e.g., "change the username field from optional to required")
- The user proposes a modification from a specific layer (e.g., "the backend API needs to add a field")
Optional Capabilities
- Type synchronization validation (refer to code_patterns.md)
- Security review check (refer to security_checklist.md)
- Database migration script generation
Six-Layer Architecture Overview
┌─────────────────────────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ UI 层 │───▶│ 前端服务 │───▶│ 前端 API │ │
│ │(Vue3) │ │(Pinia) │ │(Axios) │ │
│ └──────────┘ └──────────┘ └────┬─────┘ │
│ HTTP Request │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 数据层 │◀───│ 后端服务 │◀───│ 后端 API │ │
│ │(SQLAlch) │ │(Service) │ │(FastAPI) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
Cross-Cutting Modification Workflow
Phase 1: Identify the modification entry layer
| User description keywords | Identified as entry layer | Example |
|---|---|---|
| "the interface displays...", "on the page..." | UI layer | "the user detail page should display the registration time" |
| "in the Store...", "state management..." | Frontend service layer | "the login state needs to persist after refresh" |
| "the frontend calls...", "API interface..." | Frontend API layer | "the frontend needs to call the get order list interface" |
| "backend interface...", "API returns..." | Backend API layer | "the user list interface needs to support pagination" |
| "business logic...", "data processing..." | Backend service layer | "inventory should be checked when an order is created" |
| "database...", "table structure...", "field..." | Data layer | "the user table needs to add a phone number field" |
Phase 2: Derive cross-layer impact
Modification impact derivation matrix
| Entry layer | Forward derivation (→ UI) | Backward derivation (→ DB) |
|---|---|---|
| UI layer | None | UI → frontend service → frontend API → backend API → backend service → data layer |
| Frontend service layer | ← UI | → frontend API → backend API → backend service → data layer |
| Frontend API layer | ← frontend service ← UI | → Backend API → Backend Service → Data Layer |
| Backend API Layer | ← Frontend API ← Frontend Service ← UI | → Backend Service → Data Layer |
| Backend Service Layer | ← Backend API ← Frontend API ← Frontend Service ← UI | → Data Layer |
| Data Layer | ← Backend Service ← Backend API ← Frontend API ← Frontend Service ← UI | None |
Phase 3: Execute End-to-End Modifications
- Modify the Entry Layer: Modify the entry layer code according to user requirements
- Derive Modifications Forward: Starting from the entry layer, derive layer by layer toward the front (UI direction) the modifications that need to be coordinated
- Derive Modifications Backward: Starting from the entry layer, derive layer by layer toward the back (database direction) the modifications that need to be coordinated
- Cross-Layer Consistency Validation: Check field names, types, and interface contracts
Operation Steps
Step 1: Parse the Modification Requirements
- Identify the Entry Layer: Analyze the user's description and use the keyword mapping table to determine which layer to start modifying from
- Analyze the Modification Type: New feature / field change / logic change / interface change
- Determine the Scope of Impact: Simple modification (2-3 layers) / complex modification (all six layers)
Step 2: Execute End-to-End Modifications
Select the modification mode based on the entry layer:
Mode A: Start from the UI Layer (derive backward)
- UI Layer → Frontend Service Layer → Frontend API Layer → Backend API Layer → Backend Service Layer → Data Layer
- Scenario: "The user's registration time needs to be displayed on the page"
Mode B: Start from the Data Layer (derive forward)
- Data Layer → Backend Service Layer → Backend API Layer → Frontend API Layer → Frontend Service Layer → UI Layer
- Scenario: "The user table needs a phone number field added"
Mode C: Start from the Middle Layer (derive in both directions)
- Backward: Middle Layer → Backend Service Layer → Data Layer
- Forward: Middle Layer ← Frontend API Layer ← Frontend Service Layer ← UI Layer
- Scenario: "The backend API needs a search parameter added"
Step 3: Cross-Layer Consistency Validation
Field Name Consistency
| Layer | Naming Style | Example |
|---|---|---|
| UI Layer / Frontend Service Layer | Camel case | registrationTime |
| Frontend API Layer / Backend Layer / Data Layer | Snake case | registration_time |
Type Matching Check
| TypeScript | Pydantic | SQLAlchemy |
|---|---|---|
string |
str |
String |
number |
int/float |
Integer/Float |
boolean |
bool |
Boolean |
Date/string |
datetime |
DateTime |
T | null |
Optional[T] |
nullable=True |
Interface Contract Check
- Frontend API request parameters ↔ Backend API received parameters
- Backend API response format ↔ Frontend API expected format
- Frontend Service Layer state ↔ UI Layer display binding
Step 4: Output the Modification Plan
Output according to the following structure:
## 修改方案：[功能名称]
### 修改入口
- **入口层**：[层级名称]
- **修改原因**：[用户原始需求]
### 逐层修改详情
#### 1. [层级1] 修改
**变更内容**：[具体修改点]
**代码变更**：[代码片段]
### 跨层一致性校验
- [ ] 字段名一致性
- [ ] 类型匹配
- [ ] 接口契约
### 数据库迁移（如需要）
```bash
alembic revision --autogenerate -m "描述"
## 资源索引
| 资源 | 路径 | 用途 |
|------|------|------|
| 贯穿式修改工作流 | [references/cross_layer_workflow.md](references/cross_layer_workflow.md) | 详细的跨层修改流程和示例 |
| 架构层说明 | [references/architecture_layers.md](references/architecture_layers.md) | 六层架构详细职责与约束 |
| 代码模式 | [references/code_patterns.md](references/code_patterns.md) | 常见代码模式、类型同步 |
| 安全检查清单 | [references/security_checklist.md](references/security_checklist.md) | 安全审查要点 |
| 代码模板 | [assets/templates/](assets/templates/) | 各层代码模板文件 |
## 注意事项
- **识别入口层是关键**：准确判断用户从哪一层发起修改，决定推导方向
- **双向推导**：中间层修改需要同时向前和向后推导影响
- **保持一致性**：字段命名、类型定义、接口契约必须在各层保持一致
- **数据库迁移**：数据层变更必须生成 Alembic 迁移脚本
- **充分利用智能体能力**：让智能体自动推导跨层影响，避免遗漏
## 使用示例
### 示例 1：从 UI 层发起的修改
**用户需求**："用户详情页要显示注册时间"
**入口层识别**：UI 层（关键词"页面显示"）
**推导过程**：UI 层需要显示 → 需要 Store 提供 → 需要 API 返回 → 后端需要查询 → 数据库需要字段
**修改方案**：
1. **数据层**：添加 `registration_time` 字段到 users 表
2. **后端服务层**：User 模型添加字段
3. **后端 API 层**：UserResponse 添加 `registration_time` 字段
4. **前端 API 层**：TypeScript User 接口添加字段
5. **前端服务层**：userStore 添加 `registrationTime` 状态
6. **UI 层**：UserProfile 组件添加注册时间显示
### 示例 2：从数据层发起的修改
**用户需求**："用户表需要添加手机号字段，用于短信通知"
**入口层识别**：数据层（关键词"表添加字段"）
**推导过程**：数据库有字段 → 后端可以存取 → API 可以传输 → 前端可以调用 → Store 可以管理 → UI 可以输入/显示
**修改方案**：
1. **数据层**：添加 `phone_number` 字段到 users 表
2. **后端服务层**：UserService 添加手机号验证逻辑
3. **后端 API 层**：添加手机号参数验证
4. **前端 API 层**：更新 User 接口
5. **前端服务层**：userStore 添加手机号状态
6. **UI 层**：用户资料编辑页添加手机号输入框
### 示例 3：从中间层发起的修改
**用户需求**："后端 API 需要增加按状态筛选订单的功能"
**入口层识别**：后端 API 层（关键词"API增加"）
**推导过程**：
- 向后：API 参数 → 服务层筛选逻辑 → 数据库查询条件
- 向前：API 参数 ← 前端调用 ← Store 方法 ← UI 组件
**修改方案**：
1. **后端 API 层**：`GET /orders` 添加 `status` 查询参数
2. **后端服务层**：OrderService 添加按状态筛选逻辑
3. **数据层**：确保 orders 表有 `status` 字段索引
4. **前端 API 层**：`getOrders()` 添加 `status` 参数
5. **前端服务层**：orderStore 添加筛选状态
6. **UI 层**：订单列表页添加状态筛选下拉框