Page Generator Skill

Task Objectives

• This Skill is used to: Quickly generate new pages that comply with project architecture specifications in the

  apps/web/src/pages

  directory.
• Core Philosophy: Architecture First. Generate code skeletons (scaffolds) that comply with specifications first, then let developers or AI fill in business logic.

Working Principle

1. Analyze page requirements, determine UI complexity and state management needs
2. Strictly follow the code structure and patterns in best-practice-examples/
3. Generate corresponding Content components based on UI complexity
4. If a Store is needed, determine whether to generate a new Store or use an existing one; if generating a new Store, use the store-best-practice skill to generate the Store module
5. Create a Wrapper component to handle dependency injection
6. Implement an Index file to provide a clean export interface
7. Register the route in the application and use the generated page

• Trigger Conditions: When the user requests "create new page", "add route page" or "generate page scaffold".

Generation Modes

Unsupervised Generation

• Applicable Scenarios: The Anatomy specification is sufficiently complete, and AI can automatically deduce the complete structure.
• Features: Fully automated operation, no manual intervention required.
• Process: Directly use the logic of judgeHasStore.ts to judge all options and generate the complete structure.

Supervised Generation

• Applicable Scenarios: There is uncertainty in option judgment, requiring manual confirmation.
• Features: Ask for confirmation at key nodes (such as whether a Store is needed), AI provides recommendations but the user makes the decision.
• Process: Use the logic of judgeHasStore.ts to provide recommended values, then ask the user to confirm whether to adopt them.

Active Mode Selection

Inquiry Timing

• Trigger Condition: When the user requests to create a new page
• Inquiry Position: Before all analysis and judgment
• Mandatory Requirement: This step cannot be skipped or a mode selected by default

Selection Interface

• Mode Name: Unsupervised Generation / Supervised Generation
• Brief Description: Features and applicable scenarios of each mode
• Recommendation Suggestion: Intelligent recommendation based on page complexity (optional)

User Decision

• Wait for Confirmation: Must wait for the user's clear selection before proceeding
• Cannot Skip: If the user does not select, do not continue execution
• Cancellable: Allow users to cancel the operation

UI Complexity Control

Complexity Levels

• Simple Mode: Basic layout + basic components, suitable for display-type pages
• Standard Mode: Search/filter + list display, suitable for data management pages
• Complex Mode: Multiple tabs + advanced interactions, suitable for feature-rich pages

Function Adaptation Principles

• Generate Based on Requirements: Select the appropriate UI complexity according to the actual page requirements
• Avoid Over-Design: Do not add functions that users do not need
• Maintain Consistency: Follow the design patterns and interaction methods of existing pages

Complexity Judgment Logic

• Use judgeUIComplexity.ts to intelligently judge the UI complexity level
• Automatically deduce based on page name, description and functional requirements
• Support manual specification of complexity to override automatic judgment

Usage Methods

• Page Best Practice Guide - Detailed rules for page design and implementation
• Best Practice Examples - Must strictly follow page structure and code examples
  • standard-with-store/ - Example of a standard complexity page with Store
  • simple-no-store/ - Example of a simple complexity page without Store

Usage Examples

Typical Usage Scenarios

1. Proactively Ask for Generation Mode: Display the mode selection interface and require the user to select Unsupervised or Supervised Generation
2. Based on the user's selection, automatically analyze requirements, determine that a Store and standard complexity are needed
3. Generate the complete page structure and code
4. Provide route registration guidance

Output

• Index file (index.ts, provides a clean export interface)
• Wrapper component ([PageName].tsx, handles dependency injection)
• Content component ([PageName]Content.tsx, implements UI and interactions)
• Optional Store module (_store/, if state management is needed)

Example of Generated Results

Core Specifications (Knowledge Base)

Input Parameter Specifications

• pageName

  : Page name, must be in PascalCase format

• features.hasStore

  : Whether state management is needed (automatically judged by the system)

• features.useExistingStore

  : If a store is needed, whether to use an existing store (true/false, automatically judged by the system)

• features.existingStorePath

  : If using an existing store, specify the import path of the store (e.g., "@/pages/UserPage/_store")

• features.uiComplexity

  : UI complexity level (simple/standard/complex, automatically judged by the system)

• description

  : Page function description, used for intelligent complexity judgment

1. Overall Structure: references/ANATOMY.md (directory structure, naming specifications)
2. Page Best Practice Guide: references/page-best-practice-guide.md (detailed rules for page design and implementation)
3. Best Practice Examples: best-practice-examples/ (page structure and code examples that must be strictly followed)
4. Input Specifications: references/schema.ts (parameter validation)
5. Store Judgment Logic: references/judgeHasStore.ts (intelligently judge whether a Store is needed)
6. UI Complexity Judgment: references/judgeUIComplexity.ts (intelligently judge UI complexity level)
7. Index Template: references/TEMPLATE_INDEX.md (entry file writing method)
8. Wrapper Template: references/TEMPLATE_WRAPPER.md (dependency injection layer writing method)
9. View Template: references/TEMPLATE_VIEW.md (UI layer writing method)

store-best-practice

Quality Assurance

Code Generation Principles

• Type Safety: All generated code must pass TypeScript compilation
• Performance Optimization: Mandatory use of Zustand selectors to avoid unnecessary re-renders
• Architectural Consistency: Strictly follow the project's tech stack and patterns
• Maintainability: Generated code should be easy to understand and extend

Error Handling

• Verify that the target path does not exist before generation to avoid overwriting
• Provide clear error messages and repair suggestions
• Support rollback mechanism (if generation fails)

Workflow

0. Mode Selection - Must Proactively Ask

• Proactive Inquiry: Display a clear selection interface for users to select the generation mode
• Option Description:
  • Unsupervised Generation: Fully automatic judgment of all parameters, suitable for standard scenarios
  • Supervised Generation: Ask users for confirmation at key decision points, suitable for uncertain or complex scenarios
• User Decision: Wait for the user's clear selection before proceeding

0.1. Existing Code Analysis

• Check whether page files already exist in the target path
• If they exist, analyze the existing code structure, styles and component usage
• Ask the user whether to:
  • Refactor Existing Code: Retain business logic and styles, only standardize the architecture
  • Regenerate: Completely replace with the new architecture
  • Incremental Improvement: Add missing architectural elements on the existing basis

1. Intent Parsing and Validation

• Read the user's instruction and determine the generation mode
• Use the rules in

  schema.ts

  to validate parameters
• Automatically Generate Page Name: Automatically generate a PascalCase page name based on the user's description and instruction (e.g., if the user says "create user management page", generate "UserManagementPage")

1.1. Store Judgment Logic

• Unsupervised Mode: Directly call

  judgeHasStoreFromDescription()

  to automatically judge whether a store is needed; if needed, further call

  judgeUseExistingStoreFromDescription()

  to judge whether to use an existing store; if using an existing store, call

  inferExistingStorePath()

  to deduce the path
• Supervised Mode: Call

  judgeHasStoreSupervised()

  to get recommendations, ask the user to confirm whether to adopt them; if a store is needed, further call

  judgeUseExistingStoreSupervised()

  to ask whether to use an existing store; if yes, ask the user to specify the path or use the deduced path
• Important: If a new Store is judged to be needed, use the

  store-best-practice

  skill to generate the corresponding Store module; if using an existing store, no need to generate

2. File List Planning

ANATOMY.md

hasStore

useExistingStore

• Basic Files:

  index.ts

  ,

  [PageName].tsx

  ,

  [PageName]Content.tsx

• Optional Files:

  _store/index.ts

  ,

  _store/provider.tsx

  ,

  _store/[camelCase]Slice.ts

  ,

  _store/[camelCase]Store.ts

  (only when

  hasStore=true

  and

  useExistingStore=false

  , generated via the

  store-best-practice

  skill)

3. Code Generation (In Order)

{{PageName}}

{{camelCasePageName}}

• If

  hasStore=true

  and

  useExistingStore=false

  , use the

  store-best-practice

  skill to generate the corresponding Store module
• If

  hasStore=true

  and

  useExistingStore=true

  , use the specified

  existingStorePath

  to import the existing Store
• Store files will be placed in the

  _store/

  directory (only when generating a new Store)

• Refer to TEMPLATE_VIEW.md.
• Select the appropriate UI complexity based on the

  uiComplexity

  parameter:
  • simple: Basic layout, no search/sort functions, only basic display
  • standard: Add search and sort functions, suitable for data management pages
  • complex: Add tabs, advanced filtering, batch operations, etc., suitable for feature-rich pages
• If

  hasStore=true

  , replace

  {{StoreImport}}

  with the corresponding import statement:
  • If

    useExistingStore=false

    :

    import { useStore } from "zustand"; import { use{{PageName}}Store } from "./_store";

  • If

    useExistingStore=true

    :

    import { useStore } from "zustand"; import { use{{PageName}}Store, {{PageName}}StoreProvider } from "{{existingStorePath}}";

• If

  hasStore=true

  , replace

  {{StoreConnection}}

  with

  const { loading, searchQuery, selectedSort, viewMode } = use{{PageName}}Store();

  , otherwise replace with empty
• Use

  cn

  and Flex layout to generate the basic skeleton.
• Important: Avoid over-design, only generate the functions actually needed

• Refer to TEMPLATE_WRAPPER.md.
• Key: If a Store is needed, the Wrapper must correctly introduce and nest

  <StoreProvider>

  :
  • If

    useExistingStore=false

    : Import

    {{PageName}}StoreProvider

    from "./_store"
  • If

    useExistingStore=true

    : Import

    {{PageName}}StoreProvider

    from "{{existingStorePath}}"
• If no Store is needed, do not introduce it.
• Layout Handling: Prioritize using the unified layout at the routing level, only include layout components in the Wrapper if the page requires a unique layout.

• Refer to TEMPLATE_INDEX.md.
• Only export the Wrapper component, do not export the Content component

• Verify whether the generated code complies with project specifications
• Check type safety and code quality
• Confirm that dependency injection is correct

4. Output Confirmation

• Inform the user that the page has been generated to the specified path.
• Remind the user to register the page in the route file (such as

  routeTree

  or

  router.tsx

  ).
• Provide usage examples of the generated components.
• Suggest running tests to verify the generated code.