generator-mico-cli 0.2.31 → 0.2.32

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: biz-app-analyzer
+description: Analyze a business application's codebase and generate a structured AI knowledge base — four Markdown documents that capture project context, architecture, development patterns, and domain glossary. Use this skill whenever the user mentions "analyze project", "generate project docs", "help AI understand my project", "project knowledge base", "project context", or complains that "AI doesn't understand my project" or "I have to re-explain the project every time". Also use it when the user provides a PRD but the AI lacks project context to act on it, or when onboarding to an unfamiliar codebase. Even if the user just says "look at this project" or "what does this codebase do", this skill is likely the right tool.
+---
+
+# Biz App Analyzer
+
+Generate a structured AI knowledge base from any business application codebase. The output is a set of Markdown documents that give future AI conversations deep understanding of the project — its purpose, architecture, mechanisms, development patterns, and domain vocabulary.
+
+## What This Skill Produces
+
+Four documents, saved to `.ai-docs/` in the project root:
+
+| Document | Core Question It Answers |
+|----------|------------------------|
+| `PROJECT_CONTEXT.md` | What is this project, how is the code organized, and how do things work under the hood? |
+| `DEV_PATTERNS.md` | When given a new requirement, what's the standard way to implement it in this project? |
+| `MODULE_MAP.md` | For a specific page/module, what routes, APIs, stores, and components are involved? |
+| `GLOSSARY.md` | What do project-specific terms mean, and how do PRD terms map to code? |
+
+Together these documents enable an AI to behave like a developer who has spent months on the project — knowing where things are, how things connect, and what patterns to follow.
+
+## Execution Flow
+
+The analysis runs in five phases. Each phase builds on the previous one's findings. For detailed instructions on each phase, read the corresponding reference file.
+
+### Phase 1: Project Scanning
+
+Read `references/phase-1-scanning.md` for detailed instructions.
+
+Identify what this project is at a technical level. Locate the dependency manifest (package.json, requirements.txt, go.mod, Cargo.toml, etc.), scan the source directory tree, read build configuration, and extract environment variable names.
+
+**What to read:** Dependency manifest, build config files, `.env*` files (names only), source directory tree (3 levels deep).
+
+**What to produce:** A mental model of the tech stack, directory layout, and environment setup. This guides all subsequent phases.
+
+### Phase 2: Context Analysis
+
+Read `references/phase-2-context-analysis.md` for detailed instructions.
+
+Understand how the project works by analyzing its core mechanisms — not file-by-file, but as interconnected systems. Find and analyze these five mechanisms:
+
+1. **Request layer** — How HTTP requests are made, authenticated, and error-handled
+2. **Routing & navigation** — How URLs map to pages, how navigation guards work
+3. **State management** — What data is shared across components and how
+4. **Auth & permissions** — How users are authenticated and how access is controlled
+5. **Shared capabilities** — What reusable components, hooks, and utilities exist and how they're meant to be used together
+
+**What to produce:** Fill in the `PROJECT_CONTEXT.md` template from `references/templates/`.
+
+### Phase 3: Pattern Extraction
+
+Read `references/phase-3-pattern-extraction.md` for detailed instructions.
+
+Discover how developers in this project typically build things. Sample 2-3 representative pages from different business modules, read their full source code, and identify recurring structural patterns — the "recipes" that get repeated across the codebase.
+
+**What to produce:** Fill in the `DEV_PATTERNS.md` template from `references/templates/`.
+
+### Phase 4: Module Mapping
+
+Read `references/phase-4-module-mapping.md` for detailed instructions.
+
+Build an index of every page/module and its dependencies. For each page, extract which route it serves, which APIs it calls, which stores it uses, and which shared components it imports.
+
+**What to produce:** Fill in the `MODULE_MAP.md` template from `references/templates/`.
+
+### Phase 5: Glossary Generation
+
+Read `references/phase-5-glossary.md` for detailed instructions.
+
+Extract domain-specific vocabulary from all previous phases. Identify terms that a newcomer (human or AI) would not immediately understand — both business terms and project-specific technical terms.
+
+**What to produce:** Fill in the `GLOSSARY.md` template from `references/templates/`.
+
+### Finalization: Meta File and Cursor Rule
+
+After all five phases are complete and the four documents are written to `.ai-docs/`, do two more things:
+
+**1. Write `.ai-docs-meta.json`** — a snapshot of the project's current state, used by the update mode to detect changes later. The structure:
+
+```json
+{
+  "generated_at": "ISO 8601 timestamp",
+  "project_root": "absolute path",
+  "files_snapshot": {
+    "views_modules": ["list of top-level directories under views/"],
+    "pages": ["list of all .vue/.tsx page file paths under views/"],
+    "components": ["list of files/directories under components/"],
+    "hooks": ["list of files under hooks/ or composables/"],
+    "stores": ["list of files under store/ or stores/"],
+    "critical_files": {
+      "path/to/request-wrapper": "last modified ISO timestamp",
+      "path/to/router-entry": "last modified ISO timestamp",
+      "path/to/auth-guard": "last modified ISO timestamp",
+      "path/to/main-entry": "last modified ISO timestamp",
+      "package.json": "last modified ISO timestamp"
+    }
+  }
+}
+```
+
+**2. Generate `.cursor/rules/ai-docs.mdc`** — a Cursor Rule that tells future AI sessions how to consume the knowledge base. Read `references/cursor-rule-template.md` for the template. This rule ensures that AI automatically reads `PROJECT_CONTEXT.md` for context and checks document freshness before starting work.
+
+## Output Quality Standards
+
+### PROJECT_CONTEXT.md
+
+This is the most important document. An AI reading only this file should understand 80% of what it needs to work in the project. Quality checks:
+
+- The project overview should make sense to someone who has never seen the codebase. Explain what the product does, who uses it, and why it exists — not just "a Vue 3 project".
+- Every mechanism must describe the **flow**, not just list files. "A request goes through proxy.js which adds auth headers, hits the backend at /proxy/maidocha_svr/*, checks for 20x status codes, and extracts data from response.content" is useful. "proxy.js handles API requests" is not.
+- Shared components must document their **collaboration patterns**, not just their Props. "CustomTable watches readParam for changes and auto-fetches data from readURL" tells the AI how to use it. A Props table alone does not.
+- Include concrete examples where they clarify a mechanism. A snippet of how a typical page calls an API is worth more than an abstract description.
+
+### DEV_PATTERNS.md
+
+This document bridges understanding and action. An AI reading a PRD should be able to match the requirement to a pattern and know exactly what files to create and modify. Quality checks:
+
+- Each pattern must have a **trigger condition** — what kind of PRD requirement maps to this pattern.
+- Each pattern must list the **complete set of files** to create and modify, including side-effects like route registration and i18n entries.
+- Each pattern must name a **reference page** — a real existing page that exemplifies the pattern, so the AI can read it as a concrete template.
+- Patterns should be ordered by frequency. The most common pattern first.
+
+### MODULE_MAP.md
+
+This is a lookup table. When an AI needs to modify a specific page, it checks here to understand the blast radius. Quality checks:
+
+- Every page should have its route path, API endpoints, stores, and component dependencies listed.
+- Group by business module for easy scanning.
+- For large projects (50+ pages), focus on key pages per module rather than exhaustive listing.
+
+### GLOSSARY.md
+
+This prevents misunderstanding. Quality checks:
+
+- Include both business terms (what the domain calls things) and technical terms (what the codebase calls things).
+- If PRD language differs from code language, explicitly map between them.
+- Keep definitions concise — one line per term is ideal.
+
+## Analysis Principles
+
+These principles apply across all phases. They represent the difference between a document that merely describes files and one that truly transfers understanding.
+
+### Analyze mechanisms, not files
+
+Don't produce a tour of the filesystem. Instead, trace how things actually work end-to-end. "When a user visits a page, what happens?" is a better organizing question than "What does router/index.ts contain?"
+
+Files are containers for mechanisms. The mechanism is what matters. A request might flow through three files — describe the flow once, mentioning the files as waypoints.
+
+### Document connections, not islands
+
+A component's value is not in what Props it accepts — it's in how it collaborates with other parts of the system. CustomTable's readParam + readURL pattern, combined with CustomSearchBar's @update event, forms a cohesive data-fetching mechanism. Document that mechanism, not two isolated component descriptions.
+
+Similarly, a Store's value is in which pages consume it and how. An API endpoint's value is in which page calls it and what triggers the call.
+
+### Capture patterns, not instances
+
+If ten pages follow the same CRUD structure, describe the pattern once and list which pages follow it. Don't repeat the same structure ten times. This is both more concise and more useful — when the AI builds page eleven, it needs the pattern, not a list of examples.
+
+### Serve action, not comprehension
+
+Every piece of information should help the AI make a decision. Ask: "If I were implementing a PRD requirement, would this information help me decide what to do?" If not, it's noise.
+
+"The project uses Pinia for state management" is trivia. "User permissions are stored in permissStore — read permissStore.userInfo.side_menus to check menu access, and call permissStore.getUser() in route guards to refresh auth state" is actionable.
+
+## Adapting to Different Project Types
+
+This skill works with any business application. The five mechanisms in Phase 2 exist in virtually every app — they just manifest differently.
+
+**Frontend apps** (SPA, SSR): All five mechanisms are typically present. The request layer might be axios/fetch wrappers. Routing is client-side. State management varies by framework. Shared capabilities include UI components and composables/hooks.
+
+**Backend services** (API servers, microservices): The "request layer" becomes the API framework's middleware and handler pattern. "Routing" becomes API route definitions. "State management" becomes database models and caching. "Shared capabilities" becomes middleware, validators, and utility modules.
+
+**Full-stack apps** (Next.js, Nuxt, etc.): Analyze the frontend and backend aspects separately, then document how they connect (API routes, server actions, data fetching patterns).
+
+**Mobile apps** (React Native, Flutter): Similar to frontend apps but with platform-specific navigation patterns and native module integrations.
+
+If a mechanism doesn't exist in a project (e.g., a simple CLI tool has no routing), skip it. Don't force the framework — document what's actually there.
+
+## Update Mode
+
+When the user says "update project docs", "refresh the knowledge base", or similar — don't rerun the full analysis. Instead, run a lightweight incremental update.
+
+Read `references/update-mode.md` for the detailed detection and update procedure.
+
+The core idea: read `.ai-docs-meta.json` (generated during the initial run), compare it against the current project state, and determine what changed. Changes fall into three tiers:
+
+**Tier 1 — Auto-fixable.** Pages added or removed. Update `MODULE_MAP.md` by reading the new page's imports (for additions) or removing the entry (for deletions). No user interaction needed beyond confirmation.
+
+**Tier 2 — Targeted update.** New shared components, hooks, or stores added. Read the new files, analyze their interface and purpose, and update the relevant section of `PROJECT_CONTEXT.md`. Ask the user to confirm the additions look right.
+
+**Tier 3 — Full regeneration recommended.** Architectural changes detected (request wrapper, router guards, auth mechanism modified), new business modules appeared, or package.json has major dependency changes. Inform the user and suggest rerunning the full analysis. The existing documents are likely stale in ways that targeted patches can't reliably fix.
+
+After any update, rewrite `.ai-docs-meta.json` with the new snapshot.
+
+## After Generation
+
+Once the four documents are generated in `.ai-docs/` (or updated via Update Mode):
+
+1. **Cursor Rule auto-generated**: The Finalization step creates `.cursor/rules/ai-docs.mdc`, which tells future AI sessions to read `PROJECT_CONTEXT.md` for context and check document freshness. If this rule already exists (from a previous run), it will be overwritten with the latest version.
+
+2. **Other documents on demand**: `DEV_PATTERNS.md`, `MODULE_MAP.md`, and `GLOSSARY.md` are read by AI when relevant — when implementing a feature, modifying a specific module, or encountering unfamiliar terms. The Cursor Rule includes guidance on when to consult each document.
+
+3. **Freshness checking**: The generated Cursor Rule instructs AI to read `.ai-docs-meta.json` and compare against the current project state before starting work. If significant drift is detected, the AI will suggest running this skill in Update Mode.
+
+## Limitations
+
+Be upfront about what this skill cannot do:
+
+- Analysis is based on static code reading. It does not execute code, run tests, or observe runtime behavior. Dynamic patterns (like plugin systems or reflection-heavy code) may be incompletely captured.
+- The quality of generated documents depends on how well-structured the project is. A chaotic codebase with no consistent patterns will produce less useful output — but the analysis will honestly reflect that chaos rather than invent patterns that don't exist.
+- Business domain understanding is inferred from code structure, naming, and comments. If the codebase uses cryptic naming with no comments, domain analysis will be shallow. The glossary section will flag terms it cannot confidently define.
+- For monorepos with multiple distinct applications, run the analysis separately on each application's source directory rather than on the repo root.

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "biz-app-analyzer",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "帮我分析一下 maidocha-dashboard 这个项目，生成 AI 知识库文档，让后续 AI 能快速理解这个项目",
+      "expected_output": "在项目 .ai-docs/ 目录下生成 4 份 Markdown 文件：PROJECT_CONTEXT.md（包含技术栈、目录结构、请求机制、路由权限、共享组件等完整上下文）、DEV_PATTERNS.md（包含 CRUD 等开发模式及参考页面）、MODULE_MAP.md（按业务模块列出每个页面的路由/API/Store/组件依赖）、GLOSSARY.md（业务术语和技术术语定义）",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "我每次跟 AI 聊这个项目都要重新解释一遍技术栈和目录结构，太烦了。能不能帮我生成一套文档，以后 AI 读了就能直接干活？项目在 /Users/mico/Micos/maidocha-dashboard",
+      "expected_output": "同上，生成 4 份结构化文档。重点检查：PROJECT_CONTEXT.md 中对请求模式的描述是否足够详细（包括 proxy 模式和活动 API 模式的区分），DEV_PATTERNS.md 中是否提取了 CRUD 管理页面的标准模式并给出了参考页面路径",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "look at the project at /Users/mico/Micos/maidocha-dashboard and help me understand how it's structured. I want documentation that will help AI assistants work with this codebase effectively.",
+      "expected_output": "Same 4 documents generated. Key quality check: the analysis should work even when prompted in English, producing documents that accurately capture the Chinese-language business domain (guild management, soulstar activities, etc.) with proper term definitions in the glossary",
+      "files": []
+    }
+  ]
+}

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/references/cursor-rule-template.md

@@ -0,0 +1,60 @@
+# Cursor Rule Template
+
+After generating the AI knowledge base, create a Cursor Rule file at `.cursor/rules/ai-docs.mdc` in the target project. This rule ensures future AI sessions automatically consume the knowledge base.
+
+Use the template below. Replace `{project_name}` with the actual project name discovered during Phase 1.
+
+---
+
+## Template Content
+
+```
+---
+description: AI knowledge base for {project_name}. Provides project context, architecture, development patterns, module mapping, and domain glossary. This rule is auto-generated by the biz-app-analyzer skill.
+globs:
+alwaysApply: true
+---
+
+# AI Knowledge Base
+
+This project has a structured AI knowledge base in `.ai-docs/`. Use it to understand the project before making changes.
+
+## Before Starting Any Development Task
+
+1. Read `.ai-docs/PROJECT_CONTEXT.md` to understand the project's tech stack, architecture, request mechanisms, routing, state management, permissions, and shared components.
+
+2. Check document freshness: read `.ai-docs-meta.json` and compare `generated_at` against today's date. If more than 30 days have passed, or if the current task involves modules/files not mentioned in the documents, suggest the user run `biz-app-analyzer` to refresh the knowledge base.
+
+## When Implementing a New Feature or PRD Requirement
+
+1. Read `.ai-docs/DEV_PATTERNS.md` to identify which development pattern matches the requirement.
+2. Read `.ai-docs/GLOSSARY.md` if the requirement contains domain-specific terms.
+3. Follow the matched pattern's file checklist, standard structure, and data flow.
+4. Use the pattern's reference page as a concrete implementation template.
+
+## When Modifying an Existing Page or Module
+
+1. Read `.ai-docs/MODULE_MAP.md` to see the page's dependencies — routes, APIs, stores, and components involved.
+2. Assess the blast radius: which other pages share the same stores or components?
+
+## When Encountering Unfamiliar Terms
+
+1. Check `.ai-docs/GLOSSARY.md` for business and technical term definitions.
+
+## Freshness Check Details
+
+Read `.ai-docs-meta.json` and quickly compare:
+- Are there new directories under views/ not listed in `files_snapshot.views_modules`? → New business module, suggest update.
+- Are there new files under components/ or hooks/ not in the snapshot? → New shared capabilities, suggest update.
+- Is `generated_at` more than 30 days ago? → Suggest full refresh.
+
+If changes are detected, inform the user: "The project knowledge base may be outdated. Consider running the biz-app-analyzer skill to update it."
+```
+
+---
+
+## Notes
+
+- Set `alwaysApply: true` so this rule is active in every conversation about the project.
+- The `globs` field is left empty intentionally — this rule applies globally, not to specific file patterns.
+- If the project already has a `.cursor/rules/ai-docs.mdc` from a previous run, overwrite it. The content may have been updated.

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/references/phase-1-scanning.md

@@ -0,0 +1,102 @@
+# Phase 1: Project Scanning
+
+The goal of this phase is to build a technical profile of the project — what it's built with, how files are organized, and what environments it targets. This profile guides every subsequent phase.
+
+## Step 1: Locate the Project Root
+
+Find the dependency manifest file. This is the anchor that identifies the project root:
+
+- **JavaScript/TypeScript**: `package.json`
+- **Python**: `pyproject.toml`, `requirements.txt`, or `setup.py`
+- **Go**: `go.mod`
+- **Rust**: `Cargo.toml`
+- **Java**: `pom.xml` or `build.gradle`
+- **Ruby**: `Gemfile`
+- **PHP**: `composer.json`
+
+If the user provided a path to a subdirectory, walk up until you find the manifest. If the project is a monorepo (multiple manifest files at different levels), ask the user which application to analyze, or analyze the one at the path they specified.
+
+## Step 2: Identify the Tech Stack
+
+Read the dependency manifest and extract:
+
+**Core framework and version.** Not just "Vue" but "Vue 3.5.13". Not just "React" but "React 18.2 with Next.js 14". The version matters because APIs and patterns differ significantly across major versions.
+
+**UI library.** Element Plus, Ant Design, Vant, Material UI, Chakra, Tailwind — this determines what component vocabulary the project speaks.
+
+**State management.** Pinia, Vuex, Redux, Zustand, MobX, Jotai — or none (prop drilling / context only).
+
+**Build tool.** Vite, Webpack, Rollup, esbuild, Turbopack — and its version.
+
+**Language.** TypeScript (check for tsconfig.json and its strict mode setting) or JavaScript. Check for type-checking strictness.
+
+**Other significant dependencies.** Internationalization (vue-i18n, react-intl), HTTP clients (axios, ky, ofetch), charting (echarts, chart.js), rich text editors, file upload, monitoring (Sentry), etc. Focus on dependencies that shape how code is written, not utility libraries like lodash.
+
+## Step 3: Scan the Source Directory
+
+Generate a directory tree of the source root (typically `src/` or `app/`), 3 levels deep. For each top-level directory, note what kind of files it contains based on naming patterns:
+
+- Directories like `views/`, `pages/`, `screens/` → page components
+- Directories like `components/`, `ui/` → shared/reusable components
+- Directories like `hooks/`, `composables/`, `lib/` → shared logic
+- Directories like `store/`, `stores/`, `state/` → state management
+- Directories like `api/`, `services/`, `requests/` → API layer
+- Directories like `router/`, `routes/` → routing configuration
+- Directories like `utils/`, `helpers/`, `common/` → utility functions
+- Directories like `types/`, `interfaces/`, `models/` → type definitions
+- Directories like `assets/`, `static/`, `public/` → static resources
+- Directories like `locale/`, `i18n/`, `lang/` → internationalization
+- Directories like `middleware/`, `guards/`, `permission/` → access control
+- Directories like `plugins/`, `directives/` → framework extensions
+- Directories like `config/`, `constants/`, `enums/` → configuration and constants
+
+Not every project will have all of these. Record what's actually there.
+
+## Step 4: Read Build Configuration
+
+Read the build configuration file (vite.config.ts, webpack.config.js, next.config.js, etc.) and extract information that affects development:
+
+- **Path aliases**: `@/` → `src/`, `@components/` → `src/components/`, etc. These are essential for understanding import paths throughout the codebase.
+- **Dev server proxy rules**: These reveal how the frontend connects to backend services during development. Proxy paths like `/api` → `https://backend.example.com` indicate the real API structure.
+- **Environment-specific behavior**: Different build targets (development, staging, production) and how they're configured.
+- **Plugin configuration**: Auto-import plugins, component resolvers, and other build-time transforms that affect how code is written.
+
+## Step 5: Extract Environment Variables
+
+Read `.env`, `.env.development`, `.env.production`, and similar files. Extract **variable names only**, never values. Group them by purpose:
+
+- API endpoints (e.g., `VITE_API_BASE_URL`, `NEXT_PUBLIC_API_URL`)
+- Feature flags (e.g., `VITE_ENABLE_ANALYTICS`)
+- Third-party service keys (e.g., `VITE_SENTRY_DSN` — note the name, not the value)
+
+This reveals what external services the project depends on and how environments differ.
+
+## Step 6: Check for Existing Documentation
+
+Quickly check if the project already has useful documentation:
+
+- `README.md` — read it; it may contain setup instructions, architecture notes, or business context
+- `docs/` directory — note what's there
+- `.cursor/rules/` — the project may already have AI rules that inform the analysis
+- `CHANGELOG.md` — recent entries reveal what's actively being developed
+- `CONTRIBUTING.md` — may describe conventions
+
+Don't spend too long on this. Just note what exists so later phases can leverage it.
+
+## Phase 1 Output
+
+By the end of this phase, you should be able to fill in these sections of `PROJECT_CONTEXT.md`:
+
+- **Project overview**: What the product is, based on README + dependency analysis + directory structure clues
+- **Tech stack table**: Framework, UI library, state management, build tool, language — all with versions
+- **Directory structure**: The tree with per-directory role annotations
+- **Environment configuration**: Variable names grouped by purpose, proxy rules
+
+You should also have a clear mental map of where to look in subsequent phases:
+- Where are the route definitions?
+- Where is the HTTP request wrapper?
+- Where are the stores?
+- Where are the shared components?
+- Where are the page components organized?
+
+Carry these answers forward — Phase 2 will dive deep into each of these locations.

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/references/phase-2-context-analysis.md

@@ -0,0 +1,102 @@
+# Phase 2: Context Analysis
+
+The goal of this phase is to understand how the project actually works — not what files exist, but how data flows, how users are authenticated, how pages get rendered, and how shared code is meant to be used. This is the most important phase because it produces the core knowledge document.
+
+Read the relevant files identified in Phase 1. For each mechanism below, trace the flow end-to-end rather than describing files in isolation.
+
+## Mechanism A: Request Layer
+
+Find the HTTP client setup — typically an axios instance, fetch wrapper, or framework-specific data fetching utility. There may be more than one.
+
+**What to extract for each request pattern:**
+
+1. **Base URL strategy.** Is it hardcoded, from environment variables, or determined by proxy rules? Does it differ per API domain?
+2. **Authentication injection.** How are auth tokens attached? Headers? Cookies? Where does the token come from (localStorage, cookie, store)?
+3. **Request lifecycle.** What happens before a request (interceptors, middleware)? What happens on success (data extraction — is it `response.data`, `response.data.content`, something else)? What happens on error (status code handling, redirects, user-facing messages)?
+4. **Loading state.** Is there a global loading indicator? How do individual pages manage loading states?
+5. **Multiple instances.** If the project has multiple request configurations (e.g., one for the main API, another for a third-party service), document each one and explain when each is used.
+
+**Output format:** Describe each request pattern as a narrative flow, not a file description. Example of the level of detail needed:
+
+> Business API requests go through `share/proxy.js`. The `axiosPostConfig(url, params)` function prepends `proxy/maidocha_svr/` to the URL, adds `Authtoken`, `oid`, and `lang` headers from cookies, shows a global loading spinner (unless `__NO_LOADING__` is set), and checks if the response code starts with "20" for success. On 401/403, the user is redirected to `/logout`. Success data is extracted from `response.content` or `response.data`.
+
+## Mechanism B: Routing & Navigation
+
+Find the router configuration — the entry file and any module/route definition files.
+
+**What to extract:**
+
+1. **Router mode.** Hash or history mode? This affects URL structure and deployment.
+2. **Route organization.** Are routes in one file or split by module? What's the grouping logic?
+3. **Layout structure.** Is there a shared layout component that wraps page content? What does it include (header, sidebar, breadcrumbs, tabs)?
+4. **Navigation guards.** What checks happen before a route loads? Authentication verification? Permission checking? Data prefetching?
+5. **Lazy loading.** Are page components loaded lazily? What's the import pattern?
+6. **Route metadata.** What custom metadata is attached to routes (titles, permissions, icons)?
+7. **The full page render chain.** Trace what happens from URL entry to visible page: URL → router match → guard execution → layout rendering → page component mounting. This chain is critical for understanding where to intervene when adding new pages.
+
+## Mechanism C: State Management
+
+Find the store directory and read each store file.
+
+**What to extract for each store:**
+
+1. **Responsibility.** What domain does this store own? User data? UI state? Business entity cache?
+2. **Data structure.** What are the key state fields and their types? Don't list every field — focus on the ones that other parts of the codebase depend on.
+3. **Core methods.** What are the main actions/getters? How do they interact with the API layer?
+4. **Caching strategy.** Does the store cache data? How is freshness managed? Is there a TTL or manual invalidation?
+5. **Consumption pattern.** How do pages typically access this store? Direct import? Injection? A composable/hook wrapper?
+
+Also note **cross-store dependencies** — if one store reads from or triggers another, that relationship matters.
+
+## Mechanism D: Auth & Permissions
+
+Find the authentication and permission logic. This often spans multiple files — the login flow, route guards, permission utilities, and the user/auth store.
+
+**What to extract:**
+
+1. **Authentication flow.** How does a user prove their identity? Token-based? Session? OAuth? Where is the credential stored client-side?
+2. **Session lifecycle.** When is auth state checked? On every navigation? On app init? How is session expiry handled?
+3. **Route-level access control.** How does the system decide whether a user can access a given route? Is it role-based, permission-list-based, or menu-tree-based?
+4. **In-page access control.** Beyond "can you see this page", how does the system control what a user can do within a page? Button visibility? Tab filtering? Field editability?
+5. **Permission data source.** Where does permission information come from? An API call on login? A field in the user object? A separate permission service?
+
+Document this as a flow: user opens app → auth check → permission tree constructed → routes filtered → page-level controls applied.
+
+## Mechanism E: Shared Capabilities
+
+Analyze the shared components, hooks/composables, and utility functions directories.
+
+**For shared components,** don't just list Props. For each significant component, document:
+
+1. **Purpose and when to use it.** Under what circumstances should a developer reach for this component instead of building from scratch?
+2. **Key interface.** The most important Props and Events — not all of them, just the ones that define how the component behaves.
+3. **Collaboration pattern.** How does this component work with other parts of the system? Does CustomTable auto-fetch data when readParam changes? Does a Dialog component pair with a specific hook?
+4. **Gotchas.** Anything non-obvious about its behavior — auto-refresh triggers, special parameter names, data format expectations.
+
+**For hooks/composables,** document:
+
+1. **What problem it solves.** Why does this hook exist? What repetitive code does it eliminate?
+2. **Parameters and return values.** Types and purpose.
+3. **Typical usage.** A one-sentence description of how it's used in pages.
+
+**For utilities,** briefly note the key functions and what they do. Only detail functions that are widely used or have non-obvious behavior.
+
+## Bringing It Together
+
+After analyzing all five mechanisms, the information should interconnect naturally. A page render involves routing (B) which triggers auth checks (D) which reads from the user store (C). The page then uses shared components (E) that call APIs through the request layer (A) which also populates stores (C).
+
+When writing PROJECT_CONTEXT.md, let these connections show. If a shared component internally uses a specific API pattern, mention it in the component's documentation. If the auth mechanism stores data in a specific store, cross-reference it.
+
+## Phase 2 Output
+
+Fill in the `PROJECT_CONTEXT.md` template with:
+
+- Project overview (from Phase 1, enriched with business context discovered during file reading)
+- Directory structure with role annotations (from Phase 1)
+- Request mechanism section (Mechanism A)
+- Routing & navigation section (Mechanism B)
+- State management section (Mechanism C)
+- Auth & permissions section (Mechanism D)
+- Shared components section (Mechanism E — components)
+- Hooks / composables section (Mechanism E — hooks)
+- Utility functions section (Mechanism E — utils)

package/generators/h5-react/templates/.cursor/skills/biz-app-analyzer/references/phase-3-pattern-extraction.md

@@ -0,0 +1,105 @@
+# Phase 3: Pattern Extraction
+
+The goal of this phase is to discover the "recipes" that developers follow when building features in this project. These patterns are what make the difference between an AI that understands the project and an AI that can actually build things in it.
+
+## Strategy: Sample, Compare, Generalize
+
+Don't try to read every page. Instead:
+
+1. **Sample broadly.** Pick 2-3 pages from different business modules. Choose pages that look like they represent common feature types — a list/table page, a form/detail page, a dashboard/stats page.
+
+2. **Read each sample page fully.** Read the complete source — template, script, and style. Note everything: what it imports, how it structures data, how it fetches data, how it handles user interactions, what components it uses.
+
+3. **Compare across samples.** Look for structural similarities. Do multiple pages use the same component arrangement? The same data-fetching pattern? The same form-submit flow? These similarities are your patterns.
+
+4. **Generalize.** Abstract the pattern from the concrete examples. A pattern is not "GiftManage.vue uses CustomTable with readURL" — it's "CRUD list pages use CustomTable with a readURL pointing to the list API, driven by a readParam object that CustomSearchBar updates on search."
+
+## What Makes a Good Pattern
+
+A pattern should contain everything an AI needs to replicate it from scratch given a new requirement. Specifically:
+
+### Trigger Condition
+
+When should this pattern be used? Express this in terms of **PRD language**, not code language. Think about what words in a requirement document would signal this pattern:
+
+- "manage", "list", "add/edit/delete" → CRUD management page
+- "view details", "review", "approve" → Detail/review page
+- "statistics", "dashboard", "chart" → Data visualization page
+- "configure", "settings", "toggle" → Configuration page
+- "upload", "import", "batch" → Batch operation page
+
+### File Checklist
+
+What files need to be created or modified? Be exhaustive — this is where AI implementations typically miss steps:
+
+**Files to create:**
+- The page component itself (where, naming convention)
+- Sub-components if the page is complex (where, when to split)
+- Page-specific API file if needed (when vs using the shared request layer directly)
+
+**Files to modify:**
+- Route registration (which file, what format)
+- Navigation/menu configuration (if separate from routes)
+- Internationalization entries (which files, what keys)
+- Permission configuration (if permission entries need manual registration)
+
+### Standard Structure
+
+What does the page component look like structurally? Describe in terms of the project's own vocabulary — which shared components form the skeleton, how they're arranged, and how data flows between them.
+
+Don't write actual code. Describe the structure:
+
+> The page has three sections: a CustomSearchBar at the top configured with searchContent array, a CustomTable in the middle bound to readURL and readParam, and a CustomDialog for add/edit triggered by toolbar buttons. When SearchBar emits @update, the handler merges search values into readParam and resets pagination to page 1. CustomTable watches readParam and auto-fetches. Dialog submission calls axiosPostConfig, then refreshes the table by touching readParam.
+
+### Data Flow
+
+Trace the data lifecycle for the page's primary operation:
+
+- Where does configuration data come from? (enums, constants, API)
+- How is list data fetched? (which API, what triggers it, how is it paginated)
+- How is item data submitted? (which API, what format, what happens after)
+- How are errors handled? (validation, API errors, user feedback)
+
+### Reference Page
+
+Name the actual file path of an existing page that best exemplifies this pattern. This is crucial — when the AI implements a new page, it can read this reference to see every concrete detail that the pattern description might miss.
+
+## Discovering Patterns: What to Look For
+
+When reading sample pages, pay attention to:
+
+**Template structure.** Do pages share a similar component arrangement? A search bar + table + dialog is one pattern. A tab bar + conditional content is another. A form with save/cancel buttons is another.
+
+**Data initialization.** How does the page set up its data on mount? Does it fetch enums? Load a list? Check permissions?
+
+**User interaction flows.** Search → fetch → display. Click add → open dialog → fill form → submit → refresh. Click row → navigate to detail. These interaction flows tend to repeat.
+
+**Component usage patterns.** Which shared components appear together frequently? If CustomTable and CustomSearchBar always appear as a pair, that's a pattern element.
+
+**API call patterns.** Are APIs called directly in the page, through a composable, or through a centralized function? Is there a consistent error handling approach?
+
+## Side-Effect Checklist
+
+Beyond the page itself, document the "new page setup tax" — everything a developer must do beyond writing the component:
+
+1. **Route registration.** Where to add the route, what fields are required (path, component, meta).
+2. **Menu/sidebar entry.** Is it automatic from routes, or does it need a separate configuration?
+3. **Internationalization.** What language files need new entries? What's the key naming convention?
+4. **Permission setup.** Does the new page need permission entries in a backend system or configuration file?
+5. **Navigation.** Does any existing page need to link to this new page?
+
+## Handling Variation
+
+Not every page will fit neatly into a pattern. That's fine. Your output should:
+
+- Cover the most common patterns (the ones that account for 70-80% of pages)
+- Note known variations on each pattern (e.g., "some CRUD pages use a drawer instead of a dialog for editing")
+- Acknowledge that unusual pages exist without forcing them into a pattern
+
+## Phase 3 Output
+
+Fill in the `DEV_PATTERNS.md` template with:
+
+- A "New Page Checklist" section listing the universal side-effects for any new page
+- Pattern sections ordered by frequency (most common first)
+- Each pattern containing: trigger condition, file checklist, standard structure, data flow, and reference page path