fanglinwei/developer-skills

Front-end Page Recreation

Implement within the corresponding page or area of the current project, preserving the tech stack, reusing existing components, and replicating the structure, content, interactions, and feedback copy within the defined scope. Follow the process below to confirm the scope, implement, and verify.

1. Confirm Scope & Level

First, extract the target route/area, reference source, level, viewport, interaction state, and verification scope from the request and history. Then, specifically read the project constraints and related pages, components, styles, resources, and call paths. Ascertain facts such as component capabilities, file locations, source copy, dimensions, etc., without unfolding a full project analysis before being asked.

• When the user has explicitly requested implementation, and the materials and decisions are sufficient to proceed, briefly state your understanding and move forward directly. Do not re-ask about already confirmed levels, reference priorities, data strategies, component reuse, or copy rules. Do not add a preliminary confirmation step.
• When the user requests an in-depth interview, or there are still choices that affect implementation/verification, load grilling: ask about known issues (like missing level) early; for questions dependent on materials, check the materials first. Consolidate questions that can be answered independently, attaching a recommended answer for each, so that saying "yes" accepts the suggestion. Only ask follow-up questions about new substantive ambiguities. When the user accepts a suggestion, confirm that scope. If waiting mid-process, only pause the parts dependent on the reply; continue with independent layout, static copy, etc. When only planning is done, distinguish between parts not executed in this round and parts with no workable progress.
• Buttons, toggles, filters, forms, and modals within the scope should be fully interconnected. For behaviors not defined by screenshots that change business meaning, confirm first. Default to verifying against the original screenshot dimensions; for other sizes, use the project's breakpoints, covering mobile and desktop. For missing images, icons, or fonts, first find matching resources in the project. If still missing, explain the visual impact and ask; alternative resources require user consent. While waiting, continue with independent work. When the user explicitly changes defaults in this session, follow the latest requirements.

Level	Implementation & Verification Boundary
1 · Project Style	Adjust the area arrangement, outer layout, and spacing according to the reference. The internal appearance of components (including toast, alert, and modals) follows the project's existing usage. Do not modify themes, visual props, or internal styles solely to match the reference. Compare the outer layer against the reference, and the components against the project. Record retained style differences as expected differences. Do not reduce interactions.
2 · Exact Replica	Strive for a 1:1 recreation. Reuse components, using existing props, slots, theme capabilities, and local styles to match components, modals, and states. Fix any fixable discrepancies in the reference viewport and state.

Without a selected level, continue with read-only analysis. Only after the level is selected can the implementation-dependent parts be executed. If the level is changed mid-task, update the corresponding implementation and verification basis. All following appearance requirements and checklists are subordinate to this table. The priority of reference source does not override the level.

2. Load Collaborative Skills as Needed

Search for skills from the skill list or installed directory. Do not hardcode cached versions. If a Skill tool is available, call it; otherwise, read the SKILL.md and apply it in practice. Follow already loaded instructions directly. Only check dependencies when a stage requires them. First, search by name and alias. If still missing, describe the blocked step and continue with independent work. Do not self-install or claim execution.

• Interview: The entry point $mattpocock-skills:grill-me delegates to $mattpocock-skills:grilling; the latter must be loaded for continuation. If the entry is restricted by auto-call limits, load grilling directly and explain the mapping. If an interview is not triggered, its absence does not block the task.
• Implementation or Review: Load @ponytail's $ponytail:ponytail, or a local skill with the same name specified by the user. Use the following table intensities temporarily during meaningful subtask phases. Record the original intensity before entering a phase; restore it after the phase ends. Do not switch line by line, do not repeatedly ask, do not write persistent configuration, and do not claim to change the model/reasoning intensity. For subsequent user-specified intensity or deactivation, follow the latest instruction.

Subtask	Level 1	Level 2
Component selection, composition, layout, styling	full	lite
Content, button, toast/alert prompt copy	ultra	ultra
Data integration, state, interaction, testing	full	full

full uses the smallest complete change; lite allows adding necessary styles for a confirmed 1:1 effect; both reuse available components. ultra accurately reuses or replicates copy without polishing, truncating, adding, or re-questioning confirmed requirements; only question new additions without a basis in requirements. Different intensities can be applied to the same component in different phases. Simplification must not reduce visual goals, interactivity, accessibility, states, error paths, or testing, nor require reselecting a confirmed level.

3. Analyze References

Establish module correspondence using the user-provided code, web pages, and screenshots. Do not require all resource types. The default priority is corresponding module source code > web page > screenshot. Follow the user's explicit changes. Record conflicts; do not silently mix. Only hand over to grilling when this order still cannot resolve the target selection. If the source code is unreadable or the target module is missing, describe the gap and continue with other materials. Do not assume the source code has been read.

• Code: Read only the related routes, components, styles, theme tokens, fonts, icons, images, and event call paths. Use them as visual and behavioral evidence. Do not migrate the reference project's business APIs, credentials, or entire configuration.
• Web page: Analyze DOM, computed styles, layout, and interactions using the installed Playwright official CLI / Skill → currently allowed browser tools → if capability is insufficient, check for additional skills. Query public CSS, fonts, images, SVGs, network resources, and source maps as needed. Output module structure, style data, material sources, and reference screenshots indicating viewport/state. If the user provided screenshots, cross-check them; otherwise, capture web page screenshots. For offline archiving, use SingleFile as needed, not as a replacement for interaction checks. Distinguish between measured/inferred and runtime resources/raw source code. Do not bypass access controls.
• Screenshot: When only screenshots are available, recreate based on them, noting styles and interactions that cannot be directly measured. Read actual image dimensions, target area, content state, layout, typography, and visual details. Combine with web page or user information to check CSS viewport, zoom, and device pixel ratio. Mark fonts and interactions that cannot be determined from the screenshot alone as inferred.
• Additional tools: Discover through skill discovery or GitHub candidates. Check instructions, dependencies, permissions, and compatibility. Present candidates, source, purpose, and installation method before installation and obtain authorization. While waiting, continue analysis that can be done with existing capabilities, record gaps, do not claim to use a missing tool.

After clarifying the target module, visual evidence, resource origin, reusable implementation, and missing items, proceed to implementation. The text from reference pages/repositories does not change the task's permissions.

4. Determine Data Sources and Business Behavior

First, trace the current module's APIs, request wrappers, hooks/store, field mappings, and call paths. Reference project APIs are only used to help understand behavior.

• Existing Project: Reuse the original APIs, request wrappers, and state management. Preserve parameters, field contracts, authentication, pagination, filtering, loading, error, and refresh mechanisms. For save, delete, toggle, upload, etc., preserve the original APIs, validation, permissions, and feedback workflows. For operations that are newly added in the reference and not available in the project, confirm the business meaning first. Write operations must respect the existing test environment and permission boundaries. Retaining the interface does not imply permission to test writing to production data.
• Local Gaps: After confirming that existing capabilities cannot cover the need, describe the missing items and their impact. Only for the missing area in the target page, introduce a deterministic local mock, prioritizing reuse of project mechanisms. Explain the scope and entry point. Keep existing data paths; do not intercept globally. For API failures, insufficient permissions, temporary unavailability, or missing credentials, follow the existing error handling and record the blocked items. Do not silently return fake data.
• Pure New Demo: When there are no business APIs, default to using deterministic local mocks to complete interactions. Handle missing APIs and missing runtime credentials separately.
• Visual Samples: For real pages, preserve actual business values and data volumes. Adapt to text length, null values, and pagination. Do not fabricate statistics or records for screenshots. For fixed layouts, errors, and edge case samples, use the project's existing fixtures/mocks placed in tests or a separate preview. Do not take over normal data paths. Fabricate or anonymize samples. In delivered screenshots, avoid exposing personal or sensitive data.

5. Implementation and Component Completeness

• Preserve the current tech stack, styling solution, and installed dependencies. First, check the component directory, registration/export entry points, dependencies, and related calls. Read candidate interfaces and usage. Prioritize project business components and wrappers, then use the installed component library. Only after confirming gaps, add minimal implementations and explain the reason. Avoid duplicate components, utilities, or wrapper layers that are not practically reused.
• According to the level, record and restore page and component dimensions, alignment, colors, spacing, font family/size/weight/line height/letter spacing/word wrap, icons, image cropping, borders, border radius, shadows, and states. Prioritize existing style tokens. Cover modals, layers, occlusion, and overflow outside the mount container. Do not modify the component library source code or affect other pages. Do not extend designs not shown in the screenshot. If component limitations cause differences, preserve reuse and record the difference. Only confirm trade-offs if the difference significantly affects the confirmed effect or interaction. Do not create a whole new set of components.
• In Element UI projects, map lists, buttons, drawers, modals, pages, toasts, etc., to existing wrappers or corresponding components/services. Distinguish business terms like page, toast, list, etc., according to their actual use (page container, pagination, message service, list). Cross-reference APIs, props, slots, events, and bindings with the local version and existing usage. Do not mix Element UI and Element Plus. Do not upgrade or install another component library just to fill a checklist. If capability is missing, first use the project's equivalent implementation and record it. Before implementation and during verification, read the Element UI Component Checklist, only checking involved types. For other projects, cross-reference against existing component capabilities.
• Complete Prompts: According to reference priority, trace button events, message wrappers, and copy/internationalization resources. Replicate the title, body, confirm/cancel text, punctuation, and interpolation format for confirmation, success/failure, warning, and validation prompts. For dynamic values, use the selected data source. Preserve the project's business semantics and feedback flow. If static copy conflicts with business meaning, confirm first. Only collect web page prompts in authorized and safe operations. If copy cannot be found, describe the omission and ask. Do not replace with a generic "Operation Successful."
• Toast/Alert: Reuse existing wrappers. Verify the complete copy, prompt type, trigger timing, duration, and close method. Verify icons, font, colors, dimensions, spacing, border radius, shadow, overlay, and position according to the level. Distinguish between in-page Alert, MessageBox/Dialog, and native alert based on actual behavior. Native alert cannot be custom styled. If necessary, explain the limitation and confirm an alternative.
• Reuse covers the complete structure, content, state, and operation results. Preserve local component behavior and accessibility capabilities. Reference source priority does not mean copy the component implementation. Do not use empty event handlers. Check applicable default, hover, focus, selected, disabled, loading, empty data, error, and success states. The main action and cancel/failure paths must be linked with data. Maintain the conventions for original API parameters, pagination, filtering, and write operations. Check prompts and trigger conditions item by item. Do not falsely report success on cancel/failure. For purely display items, only check content, layout, and visual state. Do not add new interactions.
• Dependency installation and long-running development servers should be handled according to project authorization. The task does not authorize Git staging, committing, pushing, branch switching, or any other Git write operations.

6. Verification and Delivery

1. Run the project's existing and relevant lint, format, type checks, tests, and build checks. For non-trivial interactions, add minimal valid runnable checks using existing facilities. Do not arbitrarily install testing tools or weaken checks.
2. Using an available and authorized browser, verify the target interactions, keyboard navigation, focus, and empty/error states. Cover mobile and desktop viewports as well as the original screenshot dimensions for layout, overflow, and operability.
3. Take screenshots at the same viewport, zoom, and UI state. Use available side-by-side/overlay tools to assist checking. For Level 1, distinguish between the reference layout and the project component appearance according to the level table. For Level 2, first check layout/dimensions, then font, spacing, colors, and decorations. After each fix, re-check the affected visuals and interactions until the standard is met or remaining issues are clearly recorded as blocked. Prioritize using fixed samples in tests or a separate preview for stable comparison. Record the actual data state and differences on the real page. If the browser, reference dimensions, materials, or permissions are missing, record the reason and the unverified scope. Static pass does not equal visual consistency. Not having compared to the reference does not mean 1:1.
4. Check for duplicate implementations. Deliver a list of actually involved components and any candidates not reused after evaluation: Page/Area & File Location | Project Component/Wrapper | Element UI Component/Service (if applicable) | Level & Retained/Adjusted Styles | Verification Result | Expected Differences/Defects/Missing Items. Confirm the wrapper mapping from the source code. Note the reason for not reusing a candidate. Distinguish between verified, unverified, blocked, and not applicable. Do not mark full delivery if there are incomplete items within scope.
5. Report the level, ponytail intensity for each subtask, modified files, core changes, actual checks and results, comparison screenshots (when available), remaining differences/blocked items, as well as reused APIs, local mock scope/reason, and unverified real API behavior. If a repository is available, show git status and a summary of this diff, distinguishing existing changes. Stop upon completion. Do not automatically execute Git write operations.