Feature Review

Feature Review

Overview

Use this skill to inspect a local app in the browser and verify whether features, menus, and pages are implemented as intended by the planning, IA, and screen design documents.

The default goal is not to praise the prototype but to find mismatches, missing coverage, partial implementations, and risky assumptions.

Trigger Cases

Use this skill when the user asks for any of these:

• 기능 검토해
• 화면 검토해
• 문서 기준으로 잘 구현됐는지 봐줘
• IA 기준으로 누락된 메뉴 확인해줘
• 기획서/정보구조도/화면설계서 기반으로 피드백 줘

This skill is also appropriate when the user explicitly wants Playwright-based UI inspection before giving feedback.

Review Workflow

1. Identify the source of truth.

• Read the relevant planning and design docs first.
• At minimum check:
  • planning requirements
  • IA or information architecture
  • screen design doc
• If the project uses route IDs like EXT-01, INT-05, or AIX-02, preserve that mapping in the review.

2. Inspect the live app with Playwright first when feasible.

• Open the running local app.
• Navigate key entry points, menus, and representative screens.
• Confirm whether menus, routes, labels, and visible feature blocks match the docs.
• If Playwright fails due to browser session issues, state that clearly and fall back to code plus route inspection.

3. Compare docs against implementation.

• Check whether each documented screen has:
  • a route
  • a menu entry when applicable
  • a page component
  • at least representative UI content
• Separate findings into:
  • implemented
  • partially implemented
  • missing
• Distinguish screen missing from screen exists but behavior is mock-only.

4. Review feature depth, not only screen existence.

• For forms, check whether inputs, buttons, or actions are real or static mock controls.
• For tables, check whether filters, tabs, downloads, and transitions are real or only decorative.
• For role-based screens, verify whether role differences are truly reflected in menus or content.

5. Produce findings first.

• Order by severity:
  • missing high-priority screens or routes
  • missing menu coverage
  • broken document-to-route mapping
  • partial implementations that may be mistaken for completed features
• Use file references for docs and code.
• Keep summary short after the findings.

Playwright Rule

Default to Playwright for UI review.

If Playwright cannot launch:

• explain the concrete cause
• try one reasonable recovery step such as clearing stale Playwright Chrome singleton files
• if it still fails, continue with route and code inspection instead of blocking

Do not pretend the review was browser-verified if it was not.

What To Check

• entry flow and role split
• global navigation
• documented routes
• screen coverage by ID
• key actions on representative screens
• missing or mislabeled menu items
• mismatch between IA intent and actual role exposure
• prototype-only shortcuts that should be called out explicitly

Output Format

When the user asks for a review, answer in this order:

1. Findings

• numbered list
• highest severity first
• include doc path and code path when relevant

2. Open questions or assumptions

• only if needed

3. Short summary

• implementation coverage
• major missing areas
• whether Playwright verification succeeded

Notes

• This skill is for review, not automatic implementation.
• If the user asks to fix the findings, switch to the normal spec-first workflow afterward.