six-layer-architect

Original：🇨🇳 Chinese
Translated

Full-stack development skill with six-layer architecture, supporting cross-layer modifications initiated from any layer. It automatically coordinates the collaboration of six layers: UI Layer/Frontend Service Layer/Frontend API Layer/Backend API Layer/Backend Service Layer/Data Layer, enabling cross-layer consistent code generation and refactoring. Suitable for Vue3+FastAPI+PostgreSQL tech stack

2installs
Sourcemorning-start/coze-skills
Added on

NPX Install

npx skill4agent add morning-start/coze-skills six-layer-architect

Tags

Translated version includes tags in frontmatter
six-layer-architecturefull-stack-code-generationcross-layer-modificationcode-refactoringvue3-fastapi-postgresql

SKILL.md Content (Chinese)

View Translation Comparison →

Six-Layer Architecture Full-Stack Generator

Task Objectives

Core Capabilities
  • This Skill is used to: automatically generate or modify complete implementation plans that comply with the six-layer architecture specifications based on user-provided functional intentions or modification requirements
  • Capabilities include:
    • Cross-layer Modification: Initiate modifications from any layer, automatically deduce and coordinate the collaboration of the other five layers
    • Requirement Parsing and Domain Identification: Analyze user intentions, identify involved business domains and data entities
    • Layer-by-layer Code Generation/Modification: Generate or modify code for each layer in the order of data flow
    • Cross-layer Consistency Check: Ensure field names, types, and error handling remain consistent across all layers
  • Trigger Conditions:
    • User proposes new functional requirements (e.g., "Add user comment function")
    • User proposes modification requirements (e.g., "Change the user name field from optional to required")
    • User proposes modifications from a specific layer (e.g., "Backend API needs to add a field")
Optional Capabilities
  • Type synchronization check (refer to code_patterns.md)
  • Security review check (refer to security_checklist.md)
  • Database migration script generation

Overview of Six-Layer Architecture

┌─────────────────────────────────────────────────────────────┐
│   ┌──────────┐    ┌──────────┐    ┌──────────┐             │
│   │  UI 层   │───▶│ 前端服务 │───▶│ 前端 API │              │
│   │(Vue3)    │    │(Pinia)   │    │(Axios)   │              │
│   └──────────┘    └──────────┘    └────┬─────┘             │
│                              HTTP Request                   │
│                                        ▼                    │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐             │
│   │ 数据层   │◀───│ 后端服务 │◀───│ 后端 API │              │
│   │(SQLAlch) │    │(Service) │    │(FastAPI) │              │
│   └──────────┘    └──────────┘    └──────────┘             │
└─────────────────────────────────────────────────────────────┘

Cross-layer Modification Workflow

Phase 1: Identify the Modification Entry Layer

User Description KeywordsIdentified as Entry LayerExample
"UI display...", "page..."UI Layer"User detail page needs to display registration time"
"Store...", "state management..."Frontend Service Layer"Login state needs to persist after refresh"
"Frontend call...", "API interface..."Frontend API Layer"Frontend needs to call the order list interface"
"Backend interface...", "API returns..."Backend API Layer"User list interface needs to support pagination"
"Business logic...", "data processing..."Backend Service Layer"Check inventory when creating an order"
"Database...", "table structure...", "field..."Data Layer"User table needs to add a phone number field"

Phase 2: Deduce Cross-layer Impacts

Modification Impact Deduction Matrix
Entry LayerForward Deduction (→ UI)Backward Deduction (→ DB)
UI LayerNoneUI → 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 ← UINone

Phase 3: Execute Cross-layer Modification

  1. Modify Entry Layer: Modify the entry layer code according to user requirements
  2. Forward Deduction Modification: Deduce required collaborative modifications layer by layer from the entry layer towards the UI direction
  3. Backward Deduction Modification: Deduce required collaborative modifications layer by layer from the entry layer towards the database direction
  4. Cross-layer Consistency Check: Check field names, types, and interface contracts

Operation Steps

Step 1: Parse Modification Requirements

  1. Identify Entry Layer: Analyze user description, use the keyword mapping table to determine which layer to start modification from
  2. Analyze Modification Type: New feature addition / Field change / Logic change / Interface change
  3. Determine Impact Scope: Simple modification (2-3 layers) / Complex modification (all six layers)

Step 2: Execute Cross-layer Modification

Select modification mode based on the entry layer:
Mode A: Start from UI Layer (Backward Deduction)
  • UI Layer → Frontend Service Layer → Frontend API Layer → Backend API Layer → Backend Service Layer → Data Layer
  • Scenario: "User detail page needs to display registration time"
Mode B: Start from Data Layer (Forward Deduction)
  • Data Layer → Backend Service Layer → Backend API Layer → Frontend API Layer → Frontend Service Layer → UI Layer
  • Scenario: "User table needs to add a phone number field"
Mode C: Start from Middle Layer (Bidirectional Deduction)
  • Backward: Middle Layer → Backend Service Layer → Data Layer
  • Forward: Middle Layer ← Frontend API Layer ← Frontend Service Layer ← UI Layer
  • Scenario: "Backend API needs to add search parameters"

Step 3: Cross-layer Consistency Check

Field Name Consistency
LayerNaming ConventionExample
UI Layer / Frontend Service LayercamelCase
registrationTime
Frontend API Layer / Backend Layers / Data Layersnake_case
registration_time
Type Matching Check
TypeScriptPydanticSQLAlchemy
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 Modification Plan

Output in the following structure:
markdown
## Modification Plan: [Feature Name]

### Modification Entry
- **Entry Layer**: [Layer Name]
- **Modification Reason**: [Original User Requirement]

### Layer-by-layer Modification Details
#### 1. [Layer 1] Modification
**Change Content**: [Specific Modification Points]
**Code Changes**: [Code Snippets]

### Cross-layer Consistency Check
- [ ] Field name consistency
- [ ] Type matching
- [ ] Interface contract

### Database Migration (if needed)
```bash
alembic revision --autogenerate -m "description"

## Resource Index

| Resource | Path | Purpose |
|----------|------|---------|
| Cross-layer Modification Workflow | [references/cross_layer_workflow.md](references/cross_layer_workflow.md) | Detailed cross-layer modification workflow and examples |
| Architecture Layer Description | [references/architecture_layers.md](references/architecture_layers.md) | Detailed responsibilities and constraints of six-layer architecture |
| Code Patterns | [references/code_patterns.md](references/code_patterns.md) | Common code patterns, type synchronization |
| Security Checklist | [references/security_checklist.md](references/security_checklist.md) | Security review key points |
| Code Templates | [assets/templates/](assets/templates/) | Code template files for each layer |

## Notes

- **Identifying the entry layer is crucial**: Accurately determining which layer the user initiates modification from determines the deduction direction
- **Bidirectional deduction**: Modifications in middle layers require both forward and backward impact deduction
- **Maintain consistency**: Field naming, type definitions, and interface contracts must remain consistent across all layers
- **Database migration**: Data layer changes must generate Alembic migration scripts
- **Make full use of agent capabilities**: Let the agent automatically deduce cross-layer impacts to avoid omissions

## Usage Examples

### Example 1: Modification Initiated from UI Layer

**User Requirement**: "User detail page needs to display registration time"

**Entry Layer Identification**: UI Layer (keyword "page display")

**Deduction Process**: UI layer needs to display → requires Store to provide → requires API to return → backend needs to query → database needs the field

**Modification Plan**:
1. **Data Layer**: Add `registration_time` field to users table
2. **Backend Service Layer**: Add field to User model
3. **Backend API Layer**: Add `registration_time` field to UserResponse
4. **Frontend API Layer**: Add field to TypeScript User interface
5. **Frontend Service Layer**: Add `registrationTime` state to userStore
6. **UI Layer**: Add registration time display to UserProfile component

### Example 2: Modification Initiated from Data Layer

**User Requirement**: "User table needs to add a phone number field for SMS notifications"

**Entry Layer Identification**: Data Layer (keyword "table add field")

**Deduction Process**: Database has the field → backend can access and store → API can transmit → frontend can call → Store can manage → UI can input/display

**Modification Plan**:
1. **Data Layer**: Add `phone_number` field to users table
2. **Backend Service Layer**: Add phone number verification logic to UserService
3. **Backend API Layer**: Add phone number parameter validation
4. **Frontend API Layer**: Update User interface
5. **Frontend Service Layer**: Add phone number state to userStore
6. **UI Layer**: Add phone number input box to user profile edit page

### Example 3: Modification Initiated from Middle Layer

**User Requirement**: "Backend API needs to add order filtering by status"

**Entry Layer Identification**: Backend API Layer (keyword "API add")

**Deduction Process**:
- Backward: API parameters → Service layer filtering logic → Database query conditions
- Forward: API parameters ← Frontend call ← Store method ← UI component

**Modification Plan**:
1. **Backend API Layer**: Add `status` query parameter to `GET /orders`
2. **Backend Service Layer**: Add status-based filtering logic to OrderService
3. **Data Layer**: Ensure orders table has index for `status` field
4. **Frontend API Layer**: Add `status` parameter to `getOrders()`
5. **Frontend Service Layer**: Add filter status to orderStore
6. **UI Layer**: Add status filter dropdown to order list page