Unified Feature Analysis & Design SOP. Performs complete feature analysis (read PRD, load system knowledge, function breakdown with [NEW]/[MODIFIED]/[EXISTING] markers) followed by detailed design (frontend/backend/data) and generates complete Feature Spec document using template-first workflow. Combines analysis and design in a single unified workflow without producing intermediate analysis artifacts. Use when Feature Designer needs to analyze PRD requirements and produce Feature Spec in one pass.
Unified Feature Analysis & Design SOP. Performs complete feature analysis (read PRD, load system knowledge, function breakdown with [NEW]/[MODIFIED]/[EXISTING] markers) followed by detailed design (frontend/backend/data) and generates complete Feature Spec document using template-first workflow. Combines analysis and design in a single unified workflow without producing intermediate analysis artifacts. Use when Feature Designer needs to analyze PRD requirements and produce Feature Spec in one pass.
tools
Read, Write, Glob, Grep, search_replace
Methodology Foundation
This skill applies ISA-95 Stages 1-6 as an internal thinking framework:
ISA-95 Stage
Phase
Purpose
Stage 1: Domain Description
Analysis
Understand business context, scope boundaries, glossary
Stage 2: Information Flows
Analysis
Identify data sources, destinations, and cross-module exchanges
Stage 3: Categories of Information
Analysis
Classify data entities and establish information hierarchy
Stage 4: Information Flows
Design
Map cross-module data flows, identify API endpoints
No separate modeling documents. Methodology guides thinking quality.
Trigger Scenarios
PRD has been confirmed, user requests to start feature analysis and design
Feature Designer Agent needs to analyze PRD and produce Feature Spec in one pass
User asks "Design this feature" or "Analyze and design this requirement"
AgentFlow Definition
REQUIRED: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
Workflow
MANDATORY:
Business Perspective Only — Feature Analysis is a PURE BUSINESS document. It describes WHAT the system does from a business/user perspective, NOT HOW it's technically implemented.
Mermaid for all diagrams — ALL business flows, interaction sequences, and cross-function flows MUST use Mermaid syntax (flowchart TB, sequenceDiagram). Plain text ASCII flowcharts are FORBIDDEN.
Absolute Constraints
Violation = task failure
ABORT CONDITIONS:
PRD document missing → HARD STOP
Template file missing → HARD STOP
System overview missing → HARD STOP
FORBIDDEN: Script execution failure — If update-progress.js fails, HARD STOP and report error
FORBIDDEN: Hand-written .checkpoints.json — ALWAYS use update-progress.js script
FORBIDDEN: Skip Checkpoint A — User confirmation required before proceeding to design phase (unless skip_analysis_checkpoint=true)
FORBIDDEN: Skip Checkpoint B — User confirmation required before generating documents (unless skip_checkpoint=true)
FORBIDDEN: Rename features — Output filename MUST use the exact feature_name parameter value. DO NOT translate, abbreviate, paraphrase, or substitute with alternative names found in PRD content. The feature_name parameter is the SINGLE SOURCE OF TRUTH for file naming.
CRITICAL: Script Path Rule
ALL update-progress.js commands MUST use absolute paths with {workspace_path}:
NEVER use relative paths like node scripts/update-progress.js or cd ... ; node scripts/...
The Worker may execute from project root directory, NOT from speccrew-workspace directory.
⛔ ABSOLUTE PROHIBITION — Phase B Content Filling:
NEVER use create_file to rewrite or recreate the document after Step 5 skeleton creation
NEVER abandon search_replace mid-way and switch to create_file
Even if the document is very long, you MUST continue using search_replace for EVERY section
Violation of this rule invalidates the entire output
Mermaid for all diagrams — ALL interaction flows, processing logic flows, and cross-function sequences MUST use Mermaid syntax (sequenceDiagram, flowchart TD). Plain text ASCII flowcharts are FORBIDDEN for these sections. Reference: speccrew-workspace/docs/rules/mermaid-rule.md.
NOTE: Analysis and design process is internal — no intermediate analysis or design-data files are produced.
FORBIDDEN: Rename features — Output filename MUST use the exact feature_name parameter value. DO NOT translate, abbreviate, paraphrase, or substitute with names derived from analysis content. The feature_name parameter is the SINGLE SOURCE OF TRUTH for file naming.
Step 0: Input Parameters
Parameter
Required
Description
prd_path
Yes
Path to the Sub-PRD document
feature_id
No
Feature identifier (e.g., F-CRM-01)
feature_name
No
Feature name in English (e.g., customer-list)
feature_type
No
Page+API or API-only
iteration_id
No
Current iteration identifier
frontend_platforms
No
List of frontend platforms (auto-discover if not provided)
skip_analysis_checkpoint
No
Boolean, default false. Skip Checkpoint A if true (batch mode)
skip_checkpoint
No
Boolean, default false. Skip Checkpoint B if true (batch mode)
output_path
No
Custom output path for Feature Spec (auto-generated if not provided)
Step 0.1: Read PRD Input
0.1.1 Read PRD
Read the PRD document at {prd_path} (typically speccrew-workspace/iterations/{number}-{type}-{name}/01.product-requirement/[module-name]-prd.md)
0.1.2 Focus on Specific Feature (when feature_id provided)
If feature_id is provided:
Locate the specific Feature in PRD Section 3.4 "Feature Breakdown"
Extract only the user stories and requirements related to this Feature
Ignore other Features in the same PRD
0.1.3 Backward Compatibility (when feature_id not provided)
If feature_id is NOT provided, process entire PRD using legacy mode.
Document: User Action → Frontend Response → Backend API Call
Output format: Mermaid sequenceDiagram — Generate interaction flows as Mermaid sequence diagrams showing: User → Frontend → Backend API → Data Store. DO NOT use ASCII text charts.
ISA-95 Stage 4 Thinking — Information Flows
Cross-module flows: Map data flows between feature and other modules
Interface identification: Every data exchange point = potential API endpoint
Exception flows: Document alternative paths, not just happy path
1.4 Backend API Mapping
Frontend Action
Backend API
Purpose
{action}
{API endpoint}
{data exchanged}
Step 2: Backend Design
⚠️ OUTPUT REMINDER: Backend API designs go directly into the output file. DO NOT display API lists or processing logic in conversation.
CRITICAL CONSTRAINT: Backend design in Feature Spec must remain at the BUSINESS API level:
Describe API endpoints as business operations (e.g., "Create Shop" operation with business parameters)
Describe business validation rules in plain language (e.g., "Shop name must be unique within tenant")
Describe data entities as business concepts with business field types (Text, Number, Date, Enum)
Do NOT include: Java class names, SQL statements, ORM mappings, framework annotations, Maven module paths
2.1 API/Interface List
Interface
Method
Description
{name}
{GET/POST/PUT/DELETE}
{purpose}
2.2 Processing Logic Flow
Stage
Description
Input Validation
Business rules validating input
Business Logic
Core processing steps (conceptual)
Data Operations
What data to read/write
Response
What data to return
Output format: Mermaid flowchart TD — Generate processing logic as Mermaid flowcharts showing: business validation → data operation → response. DO NOT use ASCII text charts.
2.3 Data Access Scheme
Operation
Data Target
Type
Read
{data}
[EXISTING]/[NEW]
Write
{data}
[EXISTING]/[NEW]
2.4 Cross-Module Interactions
This Module
Interacts With
Interface
Data Exchanged
{module}
{other module}
{API/Event}
{what data}
Step 3: Data Model & Business Rules
⚠️ OUTPUT REMINDER: Data models and business rules go directly into the output file. DO NOT display tables or validation rules in conversation.
3.1 New Data Structures
Field
Type
Constraints
Description
{field}
{data type}
{required/unique}
{purpose}
ISA-95 Stage 5 Thinking — Categories of Information
Classification: Categorize data (master, transactional, reference, computed)
Dictionary rigor: Every field needs name, type, constraints, semantic description
Function Coverage: "Does this design cover all functions from the analysis? Are any functions missing?"
System Relationship Markers: "Are the [EXISTING]/[MODIFIED]/[NEW] markers accurate for each component?"
UI/UX Approach: "Do the ASCII wireframes and interaction flows match your expectations?"
Backend Interface Scope: "Are the API endpoints and cross-module interactions correctly identified?"
Data Model Completeness: "Does the data model cover all fields and relationships needed?"
CRITICAL — Business Perspective Validation: "Does the specification contain ONLY business concepts and rules? Verify there are NO:
❌ File paths or code directory structures
❌ Framework names or specific technologies (Java, MyBatis, Vue component names, etc.)
❌ Actual code snippets or SQL statements
❌ Component library names or framework-specific syntax
❌ Database table/column names or technical data types
If ANY of these are present, you MUST revise the affected sections to use pure business descriptions before proceeding."
WAIT for user confirmation before proceeding to document generation.
"交互流程" / "Interaction Flow" sections → MUST use Mermaid sequenceDiagram
"核心业务逻辑" / "Processing Logic" sections → MUST use Mermaid flowchart TD
"跨函数流程" / "Cross-Function Flow" sections → MUST use Mermaid sequenceDiagram
Plain text / ASCII flowcharts are FORBIDDEN in these sections
Reference: speccrew-workspace/docs/rules/mermaid-rule.md for syntax compliance
Filling Rules
Use search_replace for each section individually
Preserve all section titles and numbering
No applicable content → "N/A"
Multi-platform: Create separate sub-sections per platform
⚠️ REMINDER: If you find yourself thinking "the document is too long, let me use create_file instead" — STOP. This is explicitly forbidden. Continue with search_replace.
Legacy Master-Sub Mode
If processing Master-Sub structure:
Repeat Step 5+6 for each sub-spec
Master spec contains: Overview, Cross-module diagram, shared data structures
Sub specs contain: Per-feature detailed design
Step 7: Mermaid Diagram Compliance
Verify all Mermaid diagrams follow compliance rules:
NO style definitions — No classDef, style, or CSS-like syntax
NO HTML tags — No <br/>, <b>, or other HTML in labels
function_count: Number of functions defined in the Feature Spec
component_count: Number of frontend components identified
api_count: Number of API endpoints defined
entity_count: Number of data entities defined
⚠️ This step is MANDATORY — the FD Agent relies on this metadata for batch summary in Phase 3c.
Key Rules
Rule
Description
Business Perspective Only (Analysis)
Feature Analysis describes business capabilities and functional requirements. Every section must describe WHAT from user/business perspective
No Technology Decisions
Do NOT specify frameworks, databases, technologies
Focus on WHAT not HOW
Describe what system does, not how it's implemented
ASCII Wireframes Only
Use ASCII art for UI prototypes
FORBIDDEN: Analysis File Paths
Do NOT include any file paths, code paths, or directory structures (e.g., views/appointment/AppointmentIndex.vue, yudao-module-appointment/...)
FORBIDDEN: Framework Code in Analysis
Do NOT include code snippets in any language — no Java classes, SQL DDL/DML, Vue templates, TypeScript API code, HTML markup, annotations (@PreAuthorize, @OperateLog, @TableLogic, @TableName)
FORBIDDEN: Framework/Library Names in Analysis
Do NOT reference specific framework/library names as implementation details (MyBatis-Plus, MapStruct, Element Plus, wot-design-uni, ElDatePicker, wd-cell, BaseMapperX, etc.)
FORBIDDEN: Database Artifacts in Analysis
Do NOT include database table names (appointment_info), column names (customer_id, staff_id), SQL types (BIGINT, VARCHAR), indexes, or any SQL statements
FORBIDDEN: Technical Types in Analysis
Do NOT use programming language types (Long, String, Integer). Use business types: Text, Number, Date, Boolean, Enum, Identifier
FORBIDDEN: ASCII Diagrams in Analysis
Do NOT use plain text or ASCII art flowcharts. ALL diagrams MUST use Mermaid syntax
Mermaid Required
Use flowchart TB for business process flows, sequenceDiagram for interaction flows. Reference mermaid-rule.md for syntax compliance
FORBIDDEN: File Paths
Do NOT include any file paths, code paths, or directory structures (e.g., src/views/..., yudao-module-base/..., pages/...)
FORBIDDEN: Framework Code
Do NOT include actual code snippets in any language — no Java classes, SQL DDL/DML, Vue templates, TypeScript API code, HTML markup
FORBIDDEN: Framework Names as Implementation
Do NOT reference specific framework/library names as implementation choices (MyBatis-Plus, Flyway, Element Plus component names like el-button, wot-design-uni widget names like wd-cell)
FORBIDDEN: Technical Types
Do NOT use database column types (VARCHAR, BIGINT, INT), Java types (Long, String), or ORM annotations (@TableName, @TableId). Use business types: Text, Number, Date, Boolean, Enum
FORBIDDEN: Component Names
Do NOT reference UI component library element names (ElDatePicker, ElMessageBox, wd-date-time-picker). Describe interaction behavior instead
FORBIDDEN: Database Artifacts
Do NOT include table names, column names, index names, or any SQL statements. Use conceptual entity names and business field names
Business Perspective Priority
Feature Spec is a BUSINESS document. Every section must describe WHAT from a user/business perspective, never HOW from a technical implementation perspective
Mermaid Compatibility
Follow mermaid-rule.md guidelines
Clear Markers
Use [EXISTING]/[MODIFIED]/[NEW] consistently
Template-First
Copy template before filling content
search_replace Only
Never use create_file for section updates after template copy
Checkpoint A
Get user confirmation on function breakdown before design (unless skipped)
Checkpoint B
Get user confirmation before writing files (unless skipped)
No Intermediate Files
Analysis and design process is internal — do NOT output any intermediate analysis or design-data artifacts
Checklist
PRD has been read, all P0 requirements covered
[Single Feature Mode] Feature ID and name parameters received
[Single Feature Mode] Only related Feature content extracted from PRD
[Legacy Mode] All sub PRDs have been read (if master-sub structure)
System overview loaded for context
Related module overviews loaded
[Cross-module] Knowledge graph queried for relationship analysis
Function breakdown completed with [EXISTING]/[MODIFIED]/[NEW] markers
[Single Feature Mode] 3-8 focused Functions defined
Checkpoint A passed: function breakdown confirmed with user (or skipped)
.checkpoints.json updated via script for Checkpoint A
All input parameters resolved (feature_id, feature_name, feature_type)
