pdd-generate-spec

Specification Generation - Generate development specifications and acceptance criteria based on feature points

Input: Feature Point Matrix (feature-matrix.md)

Output:

• spec.md (Development Specification)
• checklist.md (Acceptance Criteria)

Version History

1. Skill Integration

1.1 Architect Consultation

During the specification generation process, architect skills can be invoked as needed:

1.2 Invocation Conditions

Must invoke system-architect:

• New technology stack introduction
• System architecture changes
• Major technical decisions

Must invoke software-architect:

• Unclear module boundaries
• Complex interface design
• Design pattern recommendations needed

2. Process Steps

Step 1: Read Feature Point Matrix

Read the feature point list and details from dev-specs/feature-matrix.md.

Step 2: Determine Technology Stack

Determine the technology stack based on project configuration:

• Backend: Spring Boot + MyBatis (RuoYi Framework)
• Frontend: Vue.js + Element UI
• Database: MySQL

Architecture Consultation (As Needed): If new technology selection is involved, invoke system-architect for recommendations.

Step 3: Module Design

Analyze the modules to which feature points belong:

• Determine module boundaries
• Determine module dependencies

Architecture Consultation (As Needed): If module boundaries are unclear, invoke software-architect for recommendations.

Step 4: Generate Specifications for Each Feature Point

Process feature points in priority order:

a. Analyze Feature Point Requirements

• Business description
• Pre-conditions/Post-conditions
• Business rules
• Test scenarios

b. Design Interfaces

• Determine interface paths (RESTful style)
• Determine request methods (GET/POST/PUT/DELETE)
• Design request parameters
• Design response structure
• Define error codes

Interface Naming Conventions:

c. Design Data Model

Data model naming conventions:

d. Design Business Logic

• Processing flow
• Validation rules
• State transitions
• Exception handling

Architecture Consultation (As Needed): If business logic is complex, invoke software-architect for design recommendations.

e. Design Test Cases

• Positive scenarios
• Exception scenarios
• Boundary conditions

Step 5: Generate Development Specification Document

Output to dev-specs/FP-{sequence}/spec.md:

# {Feature Point Name} Development Specification

## Document Information
| Item | Content |
|------|------|
| Specification ID | SPEC-{ModuleNumber}-{FeaturePointSequence} |
| Related Feature Point | FP-XXX-NNN |

## Interface Definition
### Interface 1: {Interface Name}
- Interface Path: `/api/xxx`
- Request Method: POST
- Request Parameters: [...]
- Response Structure: {...}
- Error Codes: [...]

## Data Model
### Entity: {Entity Name}
| Field Name | Type | Required | Description |

## Business Logic
### Processing Flow
### Validation Rules
### State Transitions

## Test Cases
### Positive Scenarios
### Exception Scenarios
### Boundary Conditions

Step 6: Generate Acceptance Criteria Document

Output to dev-specs/FP-{sequence}/checklist.md:

# {Feature Point Name} Acceptance Criteria

## Document Information
| Item | Content |
|------|------|
| Acceptance Criteria ID | AC-{ModuleNumber}-{FeaturePointSequence} |

## Business Acceptance
| No. | Acceptance Scenario | Expected Result | Verification Method | Status |

## Technical Acceptance
| No. | Acceptance Item | Standard | Status |

## Integration Acceptance
| No. | Acceptance Item | Verification Method | Status |

Step 7: Generate Code Framework (Optional)

For P0 feature points, generate code framework:

• Backend Controller/Service/Mapper/Domain
• Frontend Vue components

3. Architecture Consultation Process

pdd-generate-spec starts
    │
    ├─► Identify technology selection needs
    │       │
    │       ▼
    │   system-architect consultation
    │       │
    │       ▼
    │   Return technology stack recommendations
    │
    ├─► Identify module design needs
    │       │
    │       ▼
    │   software-architect consultation
    │       │
    │       ▼
    │   Return module boundary recommendations
    │
    └─► Continue generating specifications

3.1 system-architect Invocation Example

Trigger Condition: Need to introduce new technology stack
Invoke: system-architect
Input:
  - Feature Requirements: Message push functionality
  - Constraints: Need to support multi-channel push
  - Existing Technology Stack: Spring Boot

Return:
  - Technology selection recommendations
  - Architecture Decision Record (ADR)
  - Project structure recommendations

3.2 software-architect Invocation Example

Trigger Condition: Unclear module boundaries
Invoke: software-architect
Input:
  - Feature Requirements: Transfer application and approval module
  - Existing Modules: Asset management base module
  - Complexity: High

Return:
  - Module division plan
  - Interface boundary definition
  - Design pattern recommendations

4. Guardrails

• Interface design must follow RESTful specifications
• Data models must include audit fields
• Business rules must be consistent with PRD
• Test cases must cover all business rules
• Architecture decisions must consult architect skills
• Module design must follow high cohesion and low coupling principles

5. Collaboration with Other Skills

6. Document System Specifications

This Skill follows the PDD framework document system specifications.

6.1 Output Documents

6.2 Naming Conventions

dev-specs/FP-{ModuleNumber}-{Sequence}/
├── spec.md
└── checklist.md

6.3 Version Management

• Every document modification must update the change history
• Record modification date, modifier, and change content

7. PDD Implementation Specification Reference

This Skill follows the PDD framework implementation specifications, see pdd-framework-design.md Chapter 9.