pdd-implement-feature

Feature Point Implementation - Implement feature point code based on development specifications

Input:

• Development Specification (spec.md)
• Acceptance Criteria (checklist.md)
• Test Cases (test-cases.md, optional)

Output:

• Code files
• Acceptance report

Version History

1. Skill Integration

1.1 Software Engineer Invocation

During code implementation, call the software-engineer skill:

1.2 Expert Skill Invocation

When encountering technical issues during implementation, call expert-xxx as needed:

1.3 Invocation Conditions

Must call software-engineer:

• Entering code implementation phase
• Need to write test code

Call expert-xxx as needed:

• Encountering RuoYi framework issues
• Encountering database design issues
• Encountering code quality issues

2. Process Steps

Step 1: Read Development Specification

Read from dev-specs/FP-{sequence}/spec.md:

• Interface definitions
• Data models
• Business logic
• Test cases

Step 2: Read Acceptance Criteria

Read acceptance items from dev-specs/FP-{sequence}/checklist.md.

Step 3: Determine Implementation Order

Determine implementation order based on feature point dependencies:

• Data models → Database scripts
• Backend interfaces → Controller/Service/Mapper
• Frontend pages → Vue components

Step 4: Generate Database Scripts

Generate SQL scripts based on data models:

CREATE TABLE `{table_name}` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',
  -- Business fields
  `create_time` datetime DEFAULT NULL COMMENT 'Creation Time',
  `update_time` datetime DEFAULT NULL COMMENT 'Update Time',
  `create_by` varchar(64) DEFAULT NULL COMMENT 'Creator',
  `update_by` varchar(64) DEFAULT NULL COMMENT 'Updater',
  `status` char(1) DEFAULT '0' COMMENT 'Status',
  `del_flag` char(1) DEFAULT '0' COMMENT 'Delete Flag',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='{Table Comment}';

Step 5: Generate Backend Code

Call software-engineer to generate code that complies with standards:

a. Domain Entity Class

@Data
@TableName("{table_name}")
public class {EntityName} {
    @TableId(type = IdType.AUTO)
    private Long id;
    // Business fields
    @TableField(fill = FieldFill.INSERT)
    private Date createTime;
    @TableField(fill = FieldFill.INSERT_UPDATE)
    private Date updateTime;
    // ...
}

b. Mapper Interface

@Mapper
public interface {EntityName}Mapper extends BaseMapper<{EntityName}> {
    // Custom query methods
}

c. Service Interface and Implementation

public interface I{EntityName}Service extends IService<{EntityName}> {
    // Business methods
}

@Service
public class {EntityName}ServiceImpl extends ServiceImpl<{EntityName}Mapper, {EntityName}> implements I{EntityName}Service {
    // Business implementation
}

d. Controller

@RestController
@RequestMapping("/{module}")
public class {EntityName}Controller {
    @Autowired
    private I{EntityName}Service service;

    // Interface methods
}

Step 6: Generate Frontend Code

Call software-engineer to generate frontend code:

a. API Interface

import request from '@/utils/request'

export function list{EntityName}(query) {
  return request({
    url: '/{module}/list',
    method: 'get',
    params: query
  })
}

b. Vue Component

<template>
  <!-- Page template -->
</template>

<script>
export default {
  name: '{EntityName}',
  data() {
    return {
      // Data
    }
  },
  methods: {
    // Methods
  }
}
</script>

Step 7: Implement Business Logic

Implement based on business logic in specifications:

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

Expert Consultation (as needed):

• RuoYi issues → expert-ruoyi
• Database issues → expert-mysql

Step 8: Run Test Validation

If test cases exist, run test validation:

• Unit tests
• Interface tests
• Integration tests

Step 9: Update Acceptance Status

Update acceptance status in checklist.md:

• Business acceptance items
• Technical acceptance items
• Integration acceptance items

Step 10: Generate Acceptance Report

Output acceptance results:

## Acceptance Report

**Feature Point**: FP-XXX-NNN
**Feature Name**: xxx
**Acceptance Date**: {Date}

### Business Acceptance
| No. | Acceptance Scenario | Expected Result | Actual Result | Status |
|------|---------|---------|---------|------|
| 1 | xxx | xxx | xxx | ✓/✗ |

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

### Issue Log
- [Issue1]: Description
- [Issue2]: Description

### Conclusion
- [ ] Pass
- [ ] Fail, needs modification

3. Expert Consultation Process

pdd-implement-feature starts
    │
    ├─► Identify RuoYi framework issues
    │       │
    │       ▼
    │   expert-ruoyi consultation
    │       │
    │       ▼
    │   Return solution
    │
    ├─► Identify database issues
    │       │
    │       ▼
    │   expert-mysql consultation
    │       │
    │       ▼
    │   Return optimization solution
    │
    ├─► Identify code quality issues
    │       │
    │       ▼
    │   expert-code-quality consultation
    │       │
    │       ▼
    │   Return refactoring recommendations
    │
    └─► Continue implementation

3.1 expert-ruoyi Invocation Example

Trigger Condition: Encountering permission validation issues
Call: expert-ruoyi
Input:
  - Issue: @PreAuthorize annotation not working
  - Code snippet: [Related code]
  - Error message: Permission validation failed

Return:
  - Solution
  - Best practices
  - sys_menu configuration recommendations

3.2 expert-mysql Invocation Example

Trigger Condition: Encountering query performance issues
Call: expert-mysql
Input:
  - SQL: SELECT * FROM large_table WHERE ...
  - Table size: 10 million records
  - Execution plan: [EXPLAIN result]

Return:
  - Optimization solution
  - Index recommendations
  - SQL rewrite

4. Code Standards

4.1 Backend Standards

• Class names use PascalCase
• Method names use camelCase
• Constants use UPPER_SNAKE_CASE
• Comments use Javadoc format

4.2 Frontend Standards

• Component names use PascalCase
• Method names use camelCase
• CSS class names use kebab-case
• Use ES6+ syntax

4.3 software-engineer Standards

Follow the core rules of software-engineer skill:

• Read existing code style before writing new code
• Error handling first
• Keep it minimal
• PR-ready code

5. Guardrails

• Code must comply with project standards
• Must implement all interfaces defined in specifications
• Must handle all exceptions defined in specifications
• Must pass all acceptance items before marking as complete
• Must synchronize specification documents after code changes
• Must consult expert skills when encountering technical issues
• Code implementation must follow software-engineer standards

6. Collaboration with Other Skills

7. PR Management Layer Prompts

7.1 Prompt After Feature Point Completion

After feature point implementation and validation passes, prompt user that PR management skills can be used:

## Feature Point Implementation Complete

**Feature Point**: FP-XXX-NNN
**Status**: Acceptance passed

### Available PR Management Operations

If you need to create a PR, you can manually call the following skills:
- `/pdd-pr-create {change-id}` - Create PR and execute automated review
- `/pdd-pr-review {change-id}` - View PR review results
- `/pdd-pr-merge {change-id}` - Merge PR and archive

### Manual Operation Steps

1. Create OpenSpec Change (optional):

/openspec-new-change {change-name}

2. Create PR:

/pdd-pr-create {change-id}

3. Confirm merge:

/pdd-pr-merge {change-id}

7.2 Do Not Automatically Call PR Skills

Important Principles:

• PDD framework will not automatically call pdd-pr-* skills
• Users need to manually decide whether to use PR management features
• PR management skills are optional, not required

7.3 PR Management Skill Description

8. Guardrails (Updated)

• Code must comply with project standards
• Must implement all interfaces defined in specifications
• Must handle all exceptions defined in specifications
• Must pass all acceptance items before marking as complete
• Must synchronize specification documents after code changes
• Must consult expert skills when encountering technical issues
• Code implementation must follow software-engineer standards
• Prompt user about available PR management skills after feature point completion, but do not automatically call

9. Error Handling and Fallback Specifications

9.1 Error Classification

9.2 Retry Strategy

Limit: Maximum 3 times per feature point
Count: Each re-review/validation after fix counts as 1 time
Exceed limit: Pause process, wait for manual decision

9.3 Fallback Rules

9.4 Failure Recording

• Location: dev-specs/FP-{module}-{sequence}/review-report.md
• Record Content:
  • Failure time
  • Failure stage
  • Failure reason
  • Number of attempts
  • Related error logs

9.5 Manual Intervention Process

Retry count exceeds 3 times
    │
    ▼
Pause process
    │
    ▼
Generate pause report
    ├── Current status
    ├── Failure history
    ├── Attempted fixes
    └── Issues requiring manual decision
    │
    ▼
Wait for manual decision
    ├── Continue fixing
    ├── Skip current feature point
    ├── Terminate process
    └── Other solutions

10. PDD Implementation Specification Reference

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

Core Specification Summary