PRD-to-Feature-List Automation Cuts a One-Hour Chore to 25 Minutes
Use TRAE Work to turn the PRD + prototype delivered by the product manager into a requirement feature list with screenshots
This article participates in the TRAE Work Practical Help essay event.
Before every version iteration, frontend developers always have a task: extract the requirement changes from the PRD one by one, organize them into a requirement feature list, and align each requirement with the product manager.
As a frontend developer, this task isn't hard, but it's time-consuming. Open the PRD document, pick out key points one by one, open the prototype page screenshots, open the Excel template, paste the text in, insert the images, adjust formatting, column widths, row heights… one requirement takes seven or eight minutes, and six changes take an hour.
This time I tried using TRAE Work to do it. From issuing the command to getting the finished product, 25 minutes. And the output was more complete than what I manually organized—because AI won't miss any rule in the PRD.
Finally, I also had it distill a reusable Skill, so next time I switch projects I can just apply it directly.
How it was done before
The manual process for organizing a requirement list went roughly like this:
First open the PRD document, read through the requirement changes, and remember the items in your head. Then open the prototype HTML, take screenshots scene by scene—sometimes the prototype page is long and you need two screenshots stitched together. Then open the Excel template, and fill in the requirement title, description, rules, interfaces, and notes column by column according to the template structure. Finally, check the formatting to make sure it matches the template.
This process has several problems:
First, easy to miss things. A requirement in the PRD often contains a summary, rules, operation steps, and acceptance criteria. When manually extracting, you often only write a title and a short description, skipping the rule details and acceptance criteria. When you remember the details later, you have to go back to the PRD to find them. As a frontend developer, the most feared thing is missing interaction rules, and only discovering when writing code that the PRD clearly stated it but you didn't record it at the time.
Second, only understandable by yourself. Manually written requirement descriptions are often abbreviations and shorthand. You understand them at the time, but two days later you forget what they specifically refer to.
Third, taking screenshots is manual labor. Six prototype scenes, each requiring opening the browser, navigating to the corresponding page, taking a screenshot, cropping, and inserting into Excel. The prototype is in HTML format, and scenes switch via URL parameters. Manually clicking through one by one and capturing each is tedious and error-prone.
How it was done this time
Step 1: Put the files in place and clearly state what you want
I created a folder on the desktop and threw three things into it: the PRD document (HTML format), the interaction prototype (HTML format), and the requirement feature list template (xlsx format).
Three input files: PRD document, interaction prototype, Excel template
Then I opened TRAE Work, selected this folder as the working directory, and entered the command:
Read the product document in the folder, and based on the requirement feature list template in the folder,
generate a Fupanbao v1.2 requirement feature list.
Requirements:
1. Must include prototype screenshots; you can run the HTML files yourself to take screenshots.
2. Strictly follow the template style for the output file.
3. Pay attention to requirement details and change content.
The command is simple; the key is clearly stating the requirements
The command itself has no special tricks—just listing the task and constraints. But a few points I think are quite important: "Strictly follow the template style"—this prevents it from freely inventing formatting; "Pay attention to requirement details and change content"—this makes it dig out the complete rules from the PRD, rather than just writing a title.
Step 2: AI reads the document and extracts requirements
After the command was issued, TRAE Work first scanned the folder and identified the purpose of the three files. Then it read the PRD HTML; each requirement had fields like number, title, summary, rule list, operation steps, and acceptance criteria.
This step was done quickly, extracting all structured data for the 6 requirement changes in about two or three minutes. The complete rules and operation steps for each were captured.
Step 3: Analyze the template structure (got stuck here for a while)
After extracting the requirement data, TRAE Work needed to analyze the Excel template structure—column widths, fonts, header colors, merged cells, and the positions and sizes of existing images. This step took the longest time and was the biggest detour in the whole process.
Many detours were taken when parsing the xlsx template; the red boxes mark the repeatedly attempted steps
The problem was that there was no Python in the environment. TRAE Work first tried calling Python's openpyxl library—not installed. Then tried MCP tools—also didn't work. Finally fell back to using PowerShell to decompress the xlsx file (xlsx is essentially a ZIP archive) and directly read the XML files inside to extract style information. It also hit a Chinese path issue in the middle: PowerShell's .NET methods threw errors when handling Chinese paths, so it had to first copy the file to a pure English path before parsing.
As a developer, I understand this feeling of finding alternatives in a constrained environment. xlsx files are essentially Open XML format; after decompression, there are files like sharedStrings.xml (shared strings), styles.xml (style definitions), xl/drawings/ (image positions), etc. Using PowerShell's System.IO.Compression to directly read XML nodes can indeed get all the information, it's just more troublesome to write than openpyxl.
This back and forth, just reading the template took several minutes.
Step 4: Automatically screenshot the prototype
This step was the most surprising to me in the whole process. TRAE Work came up with a screenshot solution on its own:
It first started a local HTTP server to host the prototype HTML files. Then, using the scene IDs from the PRD, it constructed URL parameters (like ?prd-scene=file-sync-settings), used a browser to visit each prototype scene one by one, waited for the page to finish loading, and automatically took screenshots.
AI automatically starts an HTTP server, navigates to prototype scenes, and takes screenshots; the right side shows the prototype page being controlled
Screenshots for six scenes took about three or four minutes.
Step 5: Generate the final file
After the data and images were ready, TRAE Work used Excel COM automation to generate the final file.
From issuing the command to getting the finished product, a total of 25 minutes. Started at 11:14, ended at 11:39.
Task completed, all to-dos on the right are checked, output file generated. Token consumption 191.44
Actual effect and time comparison
| Manual organization | TRAE Work |
|---|---|
| 60min | 25min |
| About 1 hour | 14 min→39 min |
Time saved 58%
Time is only one dimension. More important is the difference in output quality:
| Comparison item | Manual organization | TRAE Work |
|---|---|---|
| Number of requirement items | Only organized 5 items | Completely extracted all 6 changes |
| Rule details | Only wrote summaries, details omitted | Completely retained all rule text from PRD |
| Operation steps | Usually not written | Each requirement includes key interaction descriptions |
| Prototype screenshots | Manual screenshots, easy to miss scenes | Automatically navigates to correct scenes and screenshots |
| Readability | Mainly shorthand, only understandable by oneself | Structured descriptions, team members can directly understand |
| Format consistency | Manually adjusted format each time, always deviations | Strictly replicates template format, completely consistent |
Honestly, the time compressed from 1 hour to 25 minutes is already a very impressive number. But what helps me more is the third point—the completeness of the output. Before, when manually writing requirement lists, the quality noticeably declined as I kept writing. AI doesn't get tired; all content has the same level of detail.
As a frontend developer, the clearer the requirement list is written, the less rework there is when writing code later. Before, I often discovered halfway through writing that some interaction rule in the PRD wasn't recorded, and had to go back to the document, interrupting my flow. Now, with all rules, operation steps, and acceptance criteria clearly listed at once, I can just follow the list when developing.
Made a reusable Skill on the side
After the task was completed, I thought of a question: can this workflow be used next time I switch projects? The PRD format might be different, the template might be different, but the workflow is the same—read documents, extract requirements, take screenshots, generate a list according to the template.
So I gave TRAE Work another command, asking it to distill the just-completed process into a Skill:
Letting AI distill the process into a reusable Skill
5 minutes later, it generated a complete Skill package:
Skill creation completed, including the main instruction file and 5 reference scripts
The Skill structure is like this:
.trae/skills/requirement-list-generator/
├── SKILL.md # Main skill instruction (6-stage workflow)
└── references/
├── http_server.ps1 # Local HTTP server (solves file:// being blocked by browsers)
├── parse_xlsx_template.ps1 # xlsx template structure parsing (no Python needed)
├── crop_screenshots.ps1 # Screenshot cropping and scaling
├── generate_xlsx.ps1 # Excel COM automation to generate xlsx
└── data_template.json # JSON data format template (encoding safe)
This Skill doesn't just record the operation steps just done; it also has a two-layer design: the general layer applies to any product document scenario (supports PRD in HTML/Markdown/Word/PDF formats), and the enhancement layer is specifically optimized for HTML documents + xlsx template scenarios (such as automatically detecting JavaScript data structures in PRD, identifying prototype scene navigation parameters, using PowerShell to parse xlsx internal XML).
Next time I switch projects, as long as I copy the Skill directory over, TRAE Work will automatically trigger this workflow when encountering a "generate requirement feature list" task. No need to rewrite the command each time.
Defects
There are two obvious defects in the whole process:
One: Reading xlsx files took too long
TRAE Work took many detours when parsing the Excel template. First tried Python's openpyxl—not installed in the environment. Then tried MCP tools—also didn't work. Finally fell back to PowerShell decompressing xlsx and reading XML, and encountered Chinese path encoding issues in the middle. This step alone took several minutes, accounting for nearly one-third of the entire process time.
Two: The bottom of screenshots is incomplete
The bottom part of the prototype screenshots was cut off. The guess is that when TRAE Work ran the prototype HTML in the browser, there was a "console log" bar at the bottom blocking the page content, causing the screenshot to miss the lowest part.
Written at the end
The task of requirement feature lists, I used to think it was "something you have to do but has no technical content." After doing it once with TRAE Work, my feeling is: this kind of manual labor should be handed over to tools to do. Frontend time should be spent writing code and adjusting interactions, not on copying, pasting, and adjusting formatting.
25 minutes vs 1 hour, numerically it's more than half saved. But the real value isn't just saving time—it's that the completeness and readability of the output have gone up a level. Before, the requirement lists I wrote were only understandable by myself; now team members can directly use them when they get them.
That Skill distilled at the end is what I think is the most valuable part. Switch projects, switch products, as long as the file formats are similar, just reuse it directly.