Content
# Vibe Coding MCP Design
[English](README.en.md) | 中文
## Overview
Designed a set of tools to support the documentation workflow based on the principle of "writing documents, not code," generating structured document content, and refining this content into structured data to be stored in a database.
## Core Requirements
- Manage project requirements, testing, and issue tracking through a fixed document format (feature description, UI style, usage process, layout, test cases, bug records, release records).
- These documents need to be refined into structured data and stored in the database according to predefined field requirements.
- Each document format requires accompanying tools for:
- Extraction: Extracting key information from documents and converting it into structured data.
- Reading: Retrieving structured data from the database and generating documents in a fixed format.
### Specific Operational Processes Include:
1. Writing requirement documents to generate initial structured data.
2. Writing test cases to generate acceptance results.
3. Recording bugs to regenerate related documents or data.
## Key Point Analysis
### Fixed Format
Seven document formats (feature description, UI style, usage process, layout, test cases, bug records, release records) require clearly defined field names for each format to ensure a unified and easily extractable and storable data structure.
### Tool Design
Each format needs two types of functionalities:
- Extraction Tool: Extracts key information from user-submitted documents and converts it into structured data for storage in the database.
- Reading Tool: Retrieves structured data from the database and generates documents in a fixed format.
### Database Storage
A database schema needs to be designed to accommodate all format fields, with fields that are general and flexible to meet the needs of different formats.
### Operational Closed Loop
Requirements -> Test Cases -> Acceptance Results -> Bug Records -> Regeneration, forming a complete workflow that the tools need to support.
### Field Naming
Field names need to be intuitive, general, and easy to understand while supporting different document formats. For example:
- "Feature Description" may require fields like "Feature Name," "Feature Objective," "Inputs and Outputs," etc.
- "Bug Records" need fields like "Bug Description," "Severity," "Reproduction Steps," etc.
### Tool Design
Tools need to support document parsing (e.g., extracting data from Markdown, Word, or plain text) and map the parsing results to database fields. The reading tools need to render database data into user-friendly document formats.
### Extraction and Reading
#### Extraction
A parser is needed that can extract information from unstructured or semi-structured documents based on predefined field rules. For example, using regular expressions or Natural Language Processing (NLP) techniques to identify titles, lists, tables, etc., in the documents.
#### Reading
A template engine is needed to fill structured data from the database into predefined document templates, generating formatted documents.
### Database Design
The database needs a flexible schema that supports fields for different document types, potentially using a relational database (like MySQL) or NoSQL database (like MongoDB) to accommodate dynamic fields.
### Workflow Support
Tools need to support closed-loop operations from requirements to bug records, such as tracking the relationships between requirements, test cases, and bugs through version control or associated IDs.
## Field Name Design
Design clear field names for each document format to ensure fields are intuitive and cover the core information of the documents. Below are suggested field names for each format:
### Feature Description
- FeatureID: Unique identifier for the feature
- FeatureName: Feature name
- Description: Feature description
- Objective: Feature objective
- Inputs: Input parameters
- Outputs: Output results
- Dependencies: Dependencies
- Priority: Priority (High/Medium/Low)
- Status: Status (e.g., Pending Development, In Development, Completed)
- CreatedAt: Creation time
- UpdatedAt: Update time
### UI Style
- UIID: Unique identifier for the UI design
- ComponentName: Component name
- StyleDescription: Style description
- ColorScheme: Color scheme
- Typography: Font style
- LayoutType: Layout type (e.g., Responsive, Fixed)
- Assets: Related resources (e.g., images, icons)
- Status: Status (e.g., Designing, Completed)
- CreatedAt: Creation time
- UpdatedAt: Update time
### Usage Process
- FlowID: Unique identifier for the process
- FlowName: Process name
- Steps: Operation steps (list or JSON format)
- Actors: Participating roles (e.g., User, Administrator)
- Preconditions: Preconditions
- Postconditions: Postconditions
- Exceptions: Exception handling
- Status: Status (e.g., Pending Confirmation, Confirmed)
- CreatedAt: Creation time
- UpdatedAt: Update time
### Layout
- LayoutID: Unique identifier for the layout
- LayoutName: Layout name
- Structure: Layout structure (e.g., Grid, Flow)
- Components: List of included components
- Constraints: Layout constraints (e.g., screen size)
- ResponsiveRules: Responsive rules
- Status: Status (e.g., Designing, Completed)
- CreatedAt: Creation time
- UpdatedAt: Update time
### Test Cases
- TestCaseID: Unique identifier for the test case
- TestCaseName: Test case name
- FeatureID: Associated feature ID
- Description: Test description
- Preconditions: Test preconditions
- Steps: Test steps
- ExpectedResult: Expected result
- ActualResult: Actual result
- Status: Status (e.g., Passed, Failed, Pending)
- CreatedAt: Creation time
- UpdatedAt: Update time
### Bug Records
- BugID: Unique identifier for the bug
- FeatureID: Associated feature ID
- TestCaseID: Associated test case ID
- Description: Bug description
- Severity: Severity (Critical/High/Medium/Low)
- ReproduceSteps: Reproduction steps
- Environment: Operating environment (e.g., OS, Browser)
- Status: Status (e.g., Open, Fixing, Fixed)
- Assignee: Responsible person
- CreatedAt: Creation time
- UpdatedAt: Update time
### Release Records
- ReleaseID: Unique identifier for the release record
- FeatureID: Associated feature ID
- Version: Version number
- ReleaseDate: Release date
- Changes: Change content
- Status: Status (e.g., Planned, Released)
- Notes: Remarks
- CreatedAt: Creation time
- UpdatedAt: Update time
## Tool Design
Tools designed for each document format are divided into extraction tools and reading tools, all adhering to the principle of "writing documents, not code," focusing on describing functionalities, processes, and data handling methods.
### 1. Feature Description Tool
#### Extraction Tool
**Function**: Extract key information from feature description documents to generate structured data.
**Input**: User-submitted documents (Markdown, Word, or plain text) containing feature name, description, objective, inputs, outputs, etc.
**Processing Flow**:
1. Parse the document, identifying titles (e.g., "Feature Name"), paragraphs (e.g., description), lists (e.g., inputs and outputs).
2. Extract content according to predefined fields (FeatureID, FeatureName, Description, etc.).
3. Validate data integrity (e.g., check if the feature name is empty).
4. Store the extracted data in the features table of the database, generating a unique FeatureID.
**Output**: Structured data stored in the database.
#### Reading Tool
**Function**: Read feature description data from the database to generate formatted feature description documents.
**Input**: User-specified FeatureID or query conditions (e.g., status, priority).
**Processing Flow**:
1. Query the specified data from the features table in the database.
2. Use a predefined document template (e.g., Markdown template) to fill in the data.
3. Generate a formatted document containing titles, descriptions, inputs, outputs, etc.
**Output**: Formatted feature description document (Markdown or PDF format).
### 2. UI Style Tool
#### Extraction Tool
**Function**: Extract color schemes, fonts, layouts, etc., from UI style documents.
**Input**: UI design documents containing style descriptions, color schemes, font styles, etc.
**Processing Flow**:
1. Parse the document, identifying key fields (e.g., "Color Scheme: Blue Theme").
2. Extract field content and map it to UIID, ComponentName, ColorScheme, etc.
3. Store it in the UI styles table of the database, generating a unique UIID.
**Output**: Structured data stored in the database.
#### Reading Tool
**Function**: Read UI style data from the database to generate UI design documents.
**Input**: User-specified UIID or query conditions.
**Processing Flow**:
1. Query the UI styles table in the database.
2. Use a template to render the data into a document, including color schemes, fonts, layouts, etc.
**Output**: Formatted UI style document.
### 3. Usage Process Tool
#### Extraction Tool
**Function**: Extract steps, roles, preconditions, etc., from usage process documents.
**Input**: Process documents containing step lists, role descriptions, etc.
**Processing Flow**:
1. Parse the document, identifying ordered lists (steps), roles, preconditions, etc.
2. Extract fields and store them in the flows table of the database, generating FlowID.
**Output**: Structured data.
#### Reading Tool
**Function**: Generate usage process documents.
**Input**: FlowID or query conditions.
**Processing Flow**:
1. Query the flows table in the database.
2. Use a template to generate the process document, including steps, roles, etc.
**Output**: Formatted process document.
### 4. Layout Tool
#### Extraction Tool
**Function**: Extract structure, components, constraints, etc., from layout documents.
**Input**: Layout documents containing grid structures, component lists, etc.
**Processing Flow**:
1. Parse the document, extracting layout structures, components, and other information.
2. Store it in the layouts table of the database, generating LayoutID.
**Output**: Structured data.
#### Reading Tool
**Function**: Generate layout documents.
**Input**: LayoutID or query conditions.
**Processing Flow**:
1. Query the layouts table in the database.
2. Use a template to generate the layout document.
**Output**: Formatted layout document.
### 5. Test Case Tool
#### Extraction Tool
**Function**: Extract test steps, expected results, etc., from test case documents.
**Input**: Test case documents containing descriptions, steps, expected results.
**Processing Flow**:
1. Parse the document, extracting fields like TestCaseName, Steps, ExpectedResult.
2. Store it in the test cases table of the database, generating TestCaseID and associating it with FeatureID.
**Output**: Structured data.
#### Reading Tool
**Function**: Generate test case documents or acceptance results.
**Input**: TestCaseID or query conditions.
**Processing Flow**:
1. Query the database to retrieve test case data.
2. Generate test case documents or acceptance result reports (including ActualResult).
**Output**: Formatted test case document or acceptance report.
### 6. Bug Record Tool
#### Extraction Tool
**Function**: Extract bug descriptions, severity, etc., from bug record documents.
**Input**: Bug record documents containing descriptions, reproduction steps, etc.
**Processing Flow**:
1. Parse the document, extracting fields like Description, Severity, ReproduceSteps.
2. Store it in the bugs table of the database, generating BugID and associating it with FeatureID and TestCaseID.
**Output**: Structured data.
#### Reading Tool
**Function**: Generate bug record documents.
**Input**: BugID or query conditions.
**Processing Flow**:
1. Query the bugs table in the database.
2. Use a template to generate the bug record document.
**Output**: Formatted bug document.
### 7. Release Record Tool
#### Extraction Tool
**Function**: Extract version numbers, change content, etc., from release record documents.
**Input**: Release record documents containing version numbers, change descriptions, etc.
**Processing Flow**:
1. Parse the document, extracting fields like Version, Changes.
2. Store it in the release records table of the database, generating ReleaseID.
**Output**: Structured data.
#### Reading Tool
**Function**: Generate release record documents.
**Input**: ReleaseID or query conditions.
**Processing Flow**:
1. Query the release records table in the database.
2. Use a template to generate the release record document.
**Output**: Formatted release record document.
## Database Schema Design
To support the above tools, design a unified database schema using a relational database (e.g., MySQL):
```sql
-- Features Table
CREATE TABLE Features (
FeatureID VARCHAR(50) PRIMARY KEY,
FeatureName VARCHAR(100),
Description TEXT,
Objective TEXT,
Inputs TEXT,
Outputs TEXT,
Dependencies TEXT,
Priority ENUM('High', 'Medium', 'Low'),
Status ENUM('Pending', 'InProgress', 'Completed'),
CreatedAt DATETIME,
UpdatedAt DATETIME
);
-- UI Styles Table
CREATE TABLE UIStyles (
UIID VARCHAR(50) PRIMARY KEY,
ComponentName VARCHAR(100),
StyleDescription TEXT,
ColorScheme TEXT,
Typography TEXT,
LayoutType VARCHAR(50),
Assets TEXT,
Status ENUM('Designing', 'Completed'),
CreatedAt DATETIME,
UpdatedAt DATETIME
);
-- Flows Table
CREATE TABLE Flows (
FlowID VARCHAR(50) PRIMARY KEY,
FlowName VARCHAR(100),
Steps TEXT,
Actors TEXT,
Preconditions TEXT,
Postconditions TEXT,
Exceptions TEXT,
Status ENUM('Pending', 'Confirmed'),
CreatedAt DATETIME,
UpdatedAt DATETIME
);
-- Layouts Table
CREATE TABLE Layouts (
LayoutID VARCHAR(50) PRIMARY KEY,
LayoutName VARCHAR(100),
Structure TEXT,
Components TEXT,
Constraints TEXT,
ResponsiveRules TEXT,
Status ENUM('Designing', 'Completed'),
CreatedAt DATETIME,
UpdatedAt DATETIME
);
-- Test Cases Table
CREATE TABLE TestCases (
TestCaseID VARCHAR(50) PRIMARY KEY,
TestCaseName VARCHAR(100),
FeatureID VARCHAR(50),
Description TEXT,
Preconditions TEXT,
Steps TEXT,
ExpectedResult TEXT,
ActualResult TEXT,
Status ENUM('Passed', 'Failed', 'Pending'),
CreatedAt DATETIME,
UpdatedAt DATETIME,
FOREIGN KEY (FeatureID) REFERENCES Features(FeatureID)
);
-- Bugs Table
CREATE TABLE Bugs (
BugID VARCHAR(50) PRIMARY KEY,
FeatureID VARCHAR(50),
TestCaseID VARCHAR(50),
Description TEXT,
Severity ENUM('Critical', 'High', 'Medium', 'Low'),
ReproduceSteps TEXT,
Environment TEXT,
Status ENUM('Open', 'Fixing', 'Fixed'),
Assignee VARCHAR(100),
CreatedAt DATETIME,
UpdatedAt DATETIME,
FOREIGN KEY (FeatureID) REFERENCES Features(FeatureID),
FOREIGN KEY (TestCaseID) REFERENCES TestCases(TestCaseID)
);
-- Releases Table
CREATE TABLE Releases (
ReleaseID VARCHAR(50) PRIMARY KEY,
FeatureID VARCHAR(50),
Version VARCHAR(50),
ReleaseDate DATE,
Changes TEXT,
Status ENUM('Planned', 'Released'),
Notes TEXT,
CreatedAt DATETIME,
UpdatedAt DATETIME,
FOREIGN KEY (FeatureID) REFERENCES Features(FeatureID)
);
```
## Workflow Support
The tools support the following workflows:
### Write Requirements -> Generate
1. Users submit feature description documents, using the "Feature Description Extraction Tool" to extract data and store it in the Features table.
2. Use the "Feature Description Reading Tool" to generate formatted requirement documents.
### Write Test Cases -> Acceptance Results
1. Users submit test case documents, using the "Test Case Extraction Tool" to extract data and store it in the TestCases table, associating it with FeatureID.
2. After executing tests, update ActualResult, using the "Test Case Reading Tool" to generate acceptance result documents.
### Record Bugs -> Regenerate
1. Users submit bug record documents, using the "Bug Record Extraction Tool" to extract data and store it in the Bugs table, associating it with FeatureID and TestCaseID.
2. Use the "Bug Record Reading Tool" to generate bug reports or regenerate related documents after fixes.
## Summary
By designing fields and accompanying extraction/reading tools for each document format, combined with a unified database schema, it is possible to achieve the conversion from documents to structured data and support a closed-loop workflow for requirements, testing, and bug tracking. The tool design emphasizes user-friendliness, automating the document parsing and generation process, with intuitive and flexible field names, and the database supports relational queries to track data relationships.
