Frontend Solution Evaluator

A dual-mode evaluation skill for frontend projects. Supports both technical solution comparison and product idea feasibility assessment.

Mode Selection (Step 0) — Smart Auto-Detection

Automatically determine the evaluation mode based on the user's input. Do NOT ask the user to choose a mode unless truly ambiguous.

Auto-detection Rules (in priority order):

| User Input Pattern | Auto-select | Confidence |

|-------------------|-------------|------------|

| Provides ≥2 code files/descriptions + words like "对比"/"哪个好"/"比较" | Mode A (multi) | High |

| Provides 1 code file/description + words like "评估"/"体检"/"健康度"/"怎么样" | Mode A (single) | High |

| No code, describes a product idea + "能做吗"/"可行性"/"多久"/"多难" | Mode B Entry 1 | High |

| Provides code + "创意"/"可行性"/"做成产品"/"上线"/"demo" | Mode B Entry 2 | High |

| Provides code only, no clear intent keywords | Mode A (single) | Medium — confirm with user |

| Ambiguous or mixed signals | Ask user | Low |

When auto-detected (High confidence):

Directly proceed to the corresponding step. Inform the user which mode was selected:

> "已识别为 [模式名称]，开始评估..."

When uncertain (Medium confidence):

Provide a one-line confirmation:

> "看起来你想对这个方案做技术健康度评估，对吗？还是想评估它作为产品创意的可行性？"

When ambiguous (Low confidence):

Ask the user:

> "你是想评估已有的技术方案，还是想评估产品创意的技术可行性？"

Mode A — Implementation Evaluation (实现方案评估)

• Trigger: User wants to evaluate one or more concrete technical solutions
• Input: Code files, technical specs, architecture descriptions (one or multiple)
• Output: When multiple → side-by-side comparison with ranking. When single → technical health assessment with optimization suggestions
• Proceed to → [Implementation Mode: Step A1]

Mode B — Ideation Feasibility (创意可行性评估)

• Trigger: User wants to assess if a product idea is technically feasible, or evaluate AI-generated demo code for production readiness
• Input: Product descriptions, feature lists, OR AI-generated demo code
• Output: Feasibility verdict, resource estimation, risk warnings, demo-to-production gap analysis
• Proceed to → [Ideation Mode: Step B1]

═══════════════════════════════════════════

MODE A — Implementation Evaluation (实现方案评估)

═══════════════════════════════════════════

Step A1: Collect Solution Information

Ask the user to provide the following:

1. Solution descriptions (one or more): Accept any combination of:
• Natural language descriptions of each solution
• Code file references via @file
• Pasted design specs or screenshots

1. Target device scope: Ask which devices to evaluate. Options:
• PC only — Evaluate only PC devices (low/mid/high-end)
• Mobile only — Evaluate only mobile devices (low-end Android/high-end phone/tablet)
• PC + Mobile — Evaluate both (default if not specified)

1. Evaluation dimensions: Ask if they want full evaluation or specific dimensions:
• Full — All three dimensions (default if not specified)
• Complexity only — Only complexity analysis
• Performance only — Only performance bottleneck analysis
• Device only — Only device compatibility analysis

If the user does not specify device scope or dimensions, use the defaults (PC + Mobile, Full evaluation).

Single vs. Multiple solutions: Detect the number of solutions provided:

• Multiple solutions (≥2): Proceed with comparative evaluation (default behavior)
• Single solution (=1): Switch to Technical Health Assessment mode:
• All evaluation steps (A2-A4) remain identical
• In Step A5, the report output changes — see [Single Solution Report Adjustments]

Summarize the collected information back to the user for confirmation before proceeding.

Step A2: Complexity Evaluation

Read the detailed scoring criteria from references/evaluation-criteria.md in this skill's directory.

For each solution, evaluate the following sub-dimensions and assign a score from 1 to 5:

| Sub-dimension | What to evaluate |

|---------------|-----------------|

| Component Structure | Number of components, nesting depth, inter-component communication patterns |

| State Management | State complexity, need for global state, data flow clarity |

| Third-party Dependencies | Number and bundle size of dependencies, risk of unmaintained packages |

| Development Cost | Estimated person-days, required skill set breadth |

| Maintainability | Code readability, module decoupling, testability, upgrade path clarity |

For each sub-dimension:

• Assign a numeric score (1-5) based on the criteria in references/evaluation-criteria.md
• Provide a one-sentence qualitative assessment
• Flag any high-risk items (score >= 4)

Step A3: Performance Bottleneck Analysis

Skip this step if the user chose "Complexity only" or "Device only" in Step A1.

For each solution, analyze:

| Sub-dimension | What to analyze |

|---------------|----------------|

| First Paint / LCP | Estimated bundle size, critical rendering path, lazy loading strategy |

| Runtime Performance | Render frequency, DOM operation volume, memory footprint |

| Animation / Interaction | Complex animation presence, 60fps achievability, GPU acceleration needs |

| Network | Request count, data volume, caching strategy, real-time connection needs |

For each sub-dimension:

• Assign a risk level: 🟢 Low / 🟡 Medium / 🔴 High
• Describe the specific bottleneck and its impact
• Suggest mitigation strategies for medium and high risk items

Step A4: Multi-Device Compatibility Evaluation

Skip this step if the user chose "Complexity only" or "Performance only" in Step A1.

Based on the device scope selected in Step A1, evaluate each solution against the relevant device tiers.

Mobile device tiers (evaluate if scope includes Mobile):

| Tier | Reference Config | Key Concerns |

|------|-----------------|--------------|

| Low-end Android | 2GB RAM, quad-core 1.5GHz, 720p | DOM count limits, animation degradation, memory overflow |

| High-end Phone | 6GB+ RAM, flagship SoC, 1080p+ | Smooth interaction, efficient resource usage |

| Tablet | 4GB+ RAM, large screen, stylus support | Layout adaptation, touch target sizing |

PC device tiers (evaluate if scope includes PC):

| Tier | Reference Config | Key Concerns |

|------|-----------------|--------------|

| Low-end PC | Integrated GPU, 4GB RAM, HDD, older CPU | DOM count ceiling, complex animation stuttering, memory overflow risk |

| Mid-range PC | Entry discrete GPU, 8GB RAM, SSD | General smoothness, large data list rendering |

| High-end PC | High-perf GPU, 16GB+ RAM, high refresh display | Full hardware utilization, 4K/high-refresh adaptation |

PC-specific additional dimensions:

• Browser compatibility (Chrome/Firefox/Safari/Edge, legacy browser needs)
• Screen resolution adaptation (1080p / 2K / 4K)
• Multi-tab memory pressure
• Window zoom stability (75%-150%)

For each solution × device tier combination:

• Assign a risk level: 🟢 Low / 🟡 Medium / 🔴 High
• Note the primary bottleneck on that device tier

Step A5: Generate HTML Report

Read the report template from assets/report-template.html in this skill's directory.

Generate a complete, self-contained HTML file by replacing the {{PLACEHOLDER}} tokens in the template with the actual evaluation data:

1. {{REPORT_TITLE}} — Title including the evaluation scope
2. {{QUICK_OVERVIEW}} — One-sentence conclusion + recommended solution (or health summary for single solution)
3. {{EXECUTIVE_SUMMARY}} — 3-5 sentence executive summary: conclusion, key metrics, top risk, recommended next action
4. {{EVAL_PARAMS}} — Evaluation parameters (device scope, dimensions, number of solutions, timestamp)
5. {{SOLUTION_NAMES}} — JSON array of solution names
6. {{COMPLEXITY_DATA}} — JSON object with complexity scores for radar chart
7. {{COMPLEXITY_TABLE}} — HTML table rows for complexity details
8. {{PERFORMANCE_DATA}} — JSON object with performance risk data for bar chart
9. {{PERFORMANCE_TABLE}} — HTML table rows for performance details
10. {{DEVICE_HEATMAP_DATA}} — JSON object for device compatibility heatmap
11. {{DEVICE_TABLE}} — HTML table rows for device evaluation details
12. {{OVERALL_RANKING}} — HTML for final ranking and risk summary
13. {{GENERATION_TIME}} — Current timestamp

Save the generated HTML file to the workspace root as solution-evaluation-report.html.

After saving, use the preview_url tool or inform the user to open the file in their browser.

Single Solution Report Adjustments

When only one solution is provided, adjust the report output as follows:

1. Report title: Use "技术健康度评估" instead of "方案对比评估"

1. Quick overview: Instead of "推荐方案X", provide an overall health verdict:
• Use the weighted score to determine health level:
• Score ≤ 2.0 → "✅ 技术健康度良好，架构合理，风险可控"
• Score 2.1-3.5 → "⚠️ 技术健康度一般，存在优化空间"
• Score > 3.5 → "🔴 技术健康度堪忧，建议重点关注高风险项"

1. Complexity section: Add a qualitative interpretation for each sub-dimension:
• Score 1-2: "优于多数同类项目"
• Score 3: "与同类项目持平"
• Score 4-5: "高于同类项目平均水平，建议关注"

1. Overall ranking section: Replace the ranking cards with a Health Dashboard:
• Show three gauge-style indicators (complexity / performance / device compatibility)
• Below each gauge, list the top issues and their severity

1. Optimization suggestions (automatically included for single solution):

Generate a "Top 3 优化建议" section at the end of the report:

• For each sub-dimension with score ≥ 3 or risk ≥ 🟡, provide:
• 问题: One sentence describing the issue
• 建议: Concrete, actionable optimization suggestion
• 预期收益: What improves after optimization
• Sort by impact (highest score/risk first)

═══════════════════════════════════════════

MODE B — Ideation Feasibility (创意可行性评估)

═══════════════════════════════════════════

Step B1: Collect Creative Input

Accept input in two forms:

Entry 1 — Text Description (产品描述入口)

The user describes their product idea in natural language. Examples:

• "做一个实时协作白板"
• "做一个弹幕互动小游戏"
• "做一个 AI 对话机器人界面"

Entry 2 — Code Analysis (代码分析入口)

The user provides AI-generated demo code or prototype files. When code is provided:

1. Read all provided code files thoroughly
2. Extract core feature points by analyzing:
• Event listeners → identify interaction patterns (drag, real-time, gesture, etc.)
• API calls / WebSocket / SSE usage → identify data communication patterns
• Canvas / WebGL / Three.js usage → identify rendering patterns
• State management patterns → identify data complexity
• Third-party library imports → identify capability dependencies
• Component structure → identify UI complexity
3. Present the extracted feature list to the user for confirmation:

> "我从代码中识别出以下核心功能点：

> 1. [Feature A] — 技术本质：[paradigm]

> 2. [Feature B] — 技术本质：[paradigm]

> ...

> 是否正确？需要补充或修正吗？"

Also ask:

1. Target device scope: Same as Mode A (PC only / Mobile only / PC + Mobile, default: PC + Mobile)

1. Post-evaluation options:
• Ask: "评估完成后是否需要生成改进建议（功能降级方案 + 分阶段路线图）？"
• Default: No (only generate if user opts in)

Step B2: Tech Paradigm Decomposition

Read the tech paradigm reference from references/tech-paradigms.md in this skill's directory.

For each core feature identified in Step B1:

1. Map to tech paradigm(s): Identify which fundamental technical paradigms the feature requires (e.g., real-time communication, Canvas rendering, complex state machine, etc.)

1. Assess inherent complexity: Each tech paradigm has a baseline complexity that exists regardless of implementation quality. Score 1-5 based on the paradigm reference.

1. Identify coupling amplification: When multiple paradigms coexist, analyze if they amplify each other's complexity. Common amplification patterns:
• Real-time sync + Canvas rendering → state synchronization complexity explodes
• Rich text editing + collaborative editing → cursor/selection conflict resolution
• Complex forms + real-time validation + undo/redo → state management explosion

Output a Feature-Paradigm Mapping Table:

| Core Feature | Tech Paradigm(s) | Inherent Complexity (1-5) | Coupling Risk |

|-------------|-------------------|--------------------------|---------------|

| Feature A | Paradigm X + Y | 4 | High: X+Y amplify |

| Feature B | Paradigm Z | 2 | None |

Step B3: Demo-to-Production Gap Analysis

This step is ONLY executed when code is provided (Entry 2). Skip for text-only input (Entry 1).

Analyze the gap between the provided demo code and a production-ready implementation:

| Dimension | What demo typically has | What production needs | Gap Level |

|-----------|----------------------|---------------------|-----------|

| Error Handling | Happy path only | Comprehensive error boundaries, retry, fallback | 🟢/🟡/🔴 |

| Multi-user | Single user scenario | Concurrency, permissions, role-based access | 🟢/🟡/🔴 |

| Data Persistence | In-memory state | Database, caching strategy, data migration | 🟢/🟡/🔴 |

| Device Adaptation | Desktop only | Responsive, touch events, low-end device degradation | 🟢/🟡/🔴 |

| Data Scale | Small dataset (<100 items) | Virtual scrolling, pagination, lazy loading | 🟢/🟡/🔴 |

| Security | No protection | XSS prevention, input validation, auth, CSP | 🟢/🟡/🔴 |

| Accessibility | Not considered | Keyboard navigation, screen reader, ARIA | 🟢/🟡/🔴 |

| Testing | None | Unit tests, E2E tests, visual regression | 🟢/🟡/🔴 |

| Performance Optimization | No optimization | Code splitting, tree shaking, caching, CDN | 🟢/🟡/🔴 |

| Monitoring | No monitoring | Error tracking, performance monitoring, analytics | 🟢/🟡/🔴 |

For each dimension:

• 🟢 Low gap: Demo already covers this adequately, or the feature doesn't need it
• 🟡 Medium gap: Needs additional work (1-3 person-days per item)
• 🔴 High gap: Significant engineering effort required (3+ person-days per item), or requires architectural changes

Classify each gap as:

• 必须 (Must have): Cannot ship without this
• 建议 (Should have): Significantly improves quality
• 可选 (Nice to have): Enhancement for mature products

Step B4: Feasibility Verdict & Risk Assessment

For each creative idea / demo, generate:

1. Feasibility Verdict

One of four levels:

• ✅ 可行 (Feasible) — Standard engineering work, no major technical barriers
• ⚠️ 可行但有挑战 (Feasible with challenges) — Achievable but requires specific expertise or careful architecture
• 🔶 高难度 (Difficult) — Significant technical challenges, requires senior engineers or specialized skills
• ❌ 当前不建议 (Not recommended) — Technical barriers too high, or cost-benefit ratio too unfavorable

2. Resource Estimation

Provide an order-of-magnitude range, NOT precise numbers:

• 👤 Team size: 1 person / 2-3 people / small team (4-6) / dedicated team (7+)
• ⏱️ Timeline range: 1 person-week / 1 person-month / multi-person-month / multi-quarter
• 🎯 Skill requirements: List specific technical skills needed (e.g., WebGL experience, real-time system design)

3. Top 3 Technical Risks

For each risk:

• Risk description (one sentence)
• Impact level (🟡 Medium / 🔴 High)
• Probability (likely / possible / unlikely)
• What happens if this risk materializes

4. Device Compatibility Assessment

Same methodology as Mode A Step A4, but evaluate against the tech paradigms rather than specific code.

Step B5: Generate Ideation Report

Read the report template from assets/ideation-report-template.html in this skill's directory.

Generate a complete, self-contained HTML file by replacing the {{PLACEHOLDER}} tokens:

1. {{REPORT_TITLE}} — Title including the idea/project name
2. {{GENERATION_TIME}} — Current timestamp
3. {{QUICK_OVERVIEW}} — One-sentence feasibility verdict + key insight
4. {{EXECUTIVE_SUMMARY}} — 3-5 sentence executive summary: feasibility verdict, key data, top risk, recommended next action
5. {{EVAL_PARAMS}} — Evaluation parameters (device scope, input type, number of ideas, timestamp)
6. {{IDEA_NAMES}} — JSON array of idea/demo names
7. {{FEATURE_PARADIGM_DATA}} — JSON object for feature-paradigm mapping visualization
8. {{FEATURE_PARADIGM_TABLE}} — HTML table rows for feature decomposition details
9. {{GAP_ANALYSIS_DATA}} — JSON object for gap analysis chart (null if no code provided)
10. {{GAP_ANALYSIS_TABLE}} — HTML table rows for gap analysis details (empty string if no code)
11. {{FEASIBILITY_VERDICTS}} — HTML for feasibility verdict cards
12. {{RESOURCE_ESTIMATION}} — HTML for resource estimation display
13. {{RISK_MATRIX_DATA}} — JSON object for risk priority matrix (impact × probability)
14. {{RISK_TABLE}} — HTML table rows for risk details
15. {{DEVICE_HEATMAP_DATA}} — JSON object for device compatibility heatmap
16. {{DEVICE_TABLE}} — HTML table rows for device evaluation details
17. {{IMPROVEMENT_SECTION}} — HTML for improvement suggestions (empty string if user opted out)

Save the generated HTML file to the workspace root as ideation-feasibility-report.html.

After saving, use the preview_url tool or inform the user to open the file in their browser.

Step B6 (Optional): Improvement Suggestions

Only execute if the user opted in during Step B1.

Generate actionable improvement advice:

1. Feature Degradation Suggestions

For each high-complexity or high-risk feature, propose a simplified alternative:

| Original Feature | Simplified Version | Complexity Reduction | UX Impact |

|-----------------|-------------------|---------------------|-----------|

| Real-time collaboration | Periodic auto-save + manual sync | High → Low | Medium: users see slight delay |

2. Phased Implementation Roadmap

Break the product into phases:

• Phase 1 (MVP): Core features only, minimal viable experience. Target: [timeline]
• Phase 2 (Enhancement): Add missing features, polish UX. Target: [timeline]
• Phase 3 (Scale): Optimization, edge cases, advanced features. Target: [timeline]

3. Technical Pre-research Checklist

List items that should be validated BEFORE committing to full development:

• [ ] Item 1: [description] — Estimated research time: [X days]
• [ ] Item 2: [description] — Estimated research time: [X days]

Include improvement suggestions in the {{IMPROVEMENT_SECTION}} placeholder of the report.

═══════════════════════════════════════════

SHARED GUIDELINES

═══════════════════════════════════════════

Important Notes

• All evaluation text in the report should be written in Chinese (中文)
• Scores and risk levels must be based on the criteria in references/evaluation-criteria.md and references/tech-paradigms.md, not arbitrary
• All HTML reports must be fully self-contained (inline CSS, Chart.js via CDN) — no local server required
• If a dimension is skipped due to user preference, the corresponding section should show "未评估"
• When evaluating code files, focus on architectural patterns and design choices, not code style
• Keep the quick overview concise — one sentence for conclusion, one sentence for key insight
• For each high-risk item, always provide a concrete mitigation suggestion
• Resource estimations should be ranges, never single-point estimates
• When extracting features from code (Mode B Entry 2), present findings to user for confirmation before proceeding

Progress Feedback

During evaluation, provide brief progress indicators to the user at each major step. This is especially important for full evaluations which involve multiple steps:

• Mode A: "📊 正在分析复杂度...（1/4）" → "⚡ 正在评估性能瓶颈...（2/4）" → "📱 正在评估设备适配...（3/4）" → "📝 正在生成报告...（4/4）"
• Mode B: "🔍 正在分解技术范式...（1/4）" → "📏 正在分析 Demo→产品级差距...（2/4）" → "⚖️ 正在进行可行性判定...（3/4）" → "📝 正在生成报告...（4/4）"

Emit these as short messages before each step. Do NOT wait for the user to acknowledge — proceed immediately.

Large Project Sampling Strategy

When the user provides a large codebase (>15 files or >5000 total lines), do NOT attempt to read every file. Instead:

1. Priority files (always read):
• package.json / package-lock.json — dependency analysis
• Entry files: main.ts, App.vue, index.tsx, etc.
• Router configuration: router/index.ts, routes.ts
• Store definitions: stores/*.ts, store/index.ts
• Config files: vite.config.ts, tsconfig.json, tailwind.config.js

1. Sampling strategy (read selectively):
• Read the top-level src/ directory structure
• Read 2-3 representative page/view components
• Read 2-3 representative reusable components
• Read API layer entry file

1. Inform the user:

> "项目较大（X 个文件），我将重点分析核心架构和入口文件。如需深入分析特定模块，请指定文件路径。"

1. Mark confidence: When using sampling, mark the evaluation confidence as "Medium" (see below).

Evaluation Confidence Levels

Each evaluation section should include a confidence indicator to help users understand the reliability of the assessment:

| Level | Badge | When to use |

|-------|-------|-------------|

| 🟢 高置信度 | 🟢 高置信度 | Based on complete code analysis, or well-described technical spec |

| 🟡 中置信度 | 🟡 中置信度 | Based on sampled code (large project), or moderately detailed description |

| 🔴 低置信度 | 🔴 低置信度 | Based on brief text description only, or very incomplete information |

Include the confidence badge in:

• The executive summary (overall confidence)
• Each major evaluation section header (section-level confidence)

Executive Summary Guidelines

Both Mode A and Mode B reports must include an {{EXECUTIVE_SUMMARY}} section. Write it as 3-5 concise sentences covering:

1. Conclusion: The core verdict (recommended solution / health status / feasibility level)
2. Key metric: The most important number (e.g., "综合复杂度 3.2/5" or "预估 2-3 人月")
3. Top risk: The single biggest concern, one sentence
4. Next action: What the team should do next (e.g., "建议优先解决 X 问题" or "可以进入开发阶段")

Also include {{EVAL_PARAMS}} with: evaluation mode, device scope, dimensions evaluated, number of solutions/ideas, timestamp.