Frontend structure worker: SCAFFOLD new React project or RESTRUCTURE existing monolith to component-based architecture
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Before using this skill for interface work, read the current global ui-ux-principles skill, especially Design Principles, UX Principles, UI Principles, and Definition of Done - UI. Those rules are authoritative and override conflicting guidance here. Aesthetic recipes are opt-in: use them only when the brief explicitly calls for them and they earn their place. This skill adds only its specialized guidance.
Paths: File paths (
shared/,references/,../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.
Type: L3 Worker Category: 7XX Project Bootstrap Parent: ln-720-structure-migrator
Frontend structure worker with two modes: SCAFFOLD (generate minimal React project from template) or RESTRUCTURE (migrate monolith to component-based architecture).
| Mode | When | Input | Output |
|---|---|---|---|
| SCAFFOLD | CREATE pipeline — no existing frontend | Target stack config from ln-720 | Minimal React + Vite project (~7 files) |
| RESTRUCTURE | TRANSFORM pipeline — existing frontend found | Monolithic React source | Component-based architecture |
| Aspect | Description |
|---|---|
| Input | Target stack config (SCAFFOLD) or monolithic React source (RESTRUCTURE) |
| Output | Minimal project (SCAFFOLD) or component-based architecture (RESTRUCTURE) |
| Framework | React + TypeScript + Vite |
Scope boundaries:
| Phase | Name | Actions | Output |
|---|---|---|---|
| S1 | Generate | Create minimal React + Vite + TypeScript project files | ~7 starter files |
| S2 | Verify | Check file structure, validate configs | Valid project skeleton |
| Phase | Name | Actions | Output |
|---|---|---|---|
| 1 | Analyze | Scan source, detect component types, measure complexity | File inventory, complexity metrics |
| 2 | Plan | Apply split thresholds, calculate file moves, detect conflicts | Migration plan |
| 3 | Execute | Create folders, extract content, update imports | Restructured files |
| 4 | Verify | Run build, check imports, validate structure | Build success report |
Create minimal React + Vite + TypeScript project.
| File | Purpose |
|---|---|
package.json | Dependencies: react, react-dom, typescript, vite, @vitejs/plugin-react |
vite.config.ts | Vite config with React plugin, port, proxy settings |
tsconfig.json | Strict TypeScript config with path aliases |
index.html | Entry HTML with root div |
src/main.tsx | React entry point with StrictMode |
src/App.tsx | Root App component with router placeholder |
src/index.css | Base styles (reset, variables, layout) |
| Check | Method | Expected |
|---|---|---|
| All files created | File existence check | 7 files present |
| package.json valid | JSON parse | No syntax errors |
| tsconfig.json valid | JSON parse | No syntax errors |
| No hardcoded values | Content scan | Project name from config, not hardcoded |
Scan current frontend structure and classify components.
| Step | Action | Reference |
|---|---|---|
| 1.1 | Scan all .tsx and .ts files in source | — |
| 1.2 | Measure file complexity (lines, hooks, types) | transformation_rules.md |
| 1.3 | Classify components by category | component_patterns.md |
| 1.4 | Build import dependency graph | import_strategy.md |
Output: Component inventory with classifications and metrics.
Generate migration plan based on analysis.
| Step | Action | Reference |
|---|---|---|
| 2.1 | Apply split thresholds to identify files to restructure | transformation_rules.md |
| 2.2 | Calculate target paths for each file | react_folder_structure.md |
| 2.3 | Identify import updates needed | import_strategy.md |
| 2.4 | Detect potential conflicts (name collisions, circular deps) | — |
Output: Migration plan with Before/After mapping.
Apply transformations in correct order.
| Step | Action | Notes |
|---|---|---|
| 3.1 | Create directory structure | All target folders |
| 3.2 | Extract types to types.ts | Types have no dependencies |
| 3.3 | Extract constants to constants.ts | Constants depend only on types |
| 3.4 | Extract hooks to hooks.ts | Hooks depend on types, constants |
| 3.5 | Extract sub-components | Components use all above |
| 3.6 | Create barrel exports (index.ts) | For clean imports |
| 3.7 | Update all import paths | Fix references |
Order is critical: Execute in sequence to avoid broken imports.
Validate restructured project.
| Check | Command | Expected |
|---|---|---|
| TypeScript compilation | npx tsc --noEmit | No errors |
| Build | npm run build | Success |
| No orphan files | Manual check | Source location empty |
| Imports resolve | Build success | No module not found errors |
| Transformation | Before State | After State |
|---|---|---|
| Component Split | Single file >300 lines | Feature folder with co-located files |
| Type Extraction | Inline interfaces | Separate types.ts |
| Constant Extraction | Inline magic values | Separate constants.ts |
| Hook Extraction | Inline useState/useEffect | Separate hooks.ts or shared hooks |
| UI Component Move | Scattered in features | Centralized in components/ui/ |
| Layout Component Move | Mixed with features | Centralized in components/layout/ |
npm run build)SCAFFOLD mode:
RESTRUCTURE mode:
npm run build passes successfully| Risk | Detection | Mitigation |
|---|---|---|
| Build failure after restructure | npm run build fails | Rollback: restore from source, investigate specific error |
| Missing imports | Module not found errors | Scan all imports before/after, update missed paths |
| Circular dependencies | Build warning or runtime error | Analyze dependency graph, break cycles by extracting shared code |
| Lost functionality | Tests fail or UI broken | Run existing tests before/after transformation |
| Name collisions | Duplicate export names | Rename with feature prefix before moving |
| File | Purpose |
|---|---|
references/transformation_rules.md | Split thresholds, extraction rules, transformation order |
references/component_patterns.md | Component classification by category |
references/import_strategy.md | Import update rules, path aliases, barrel exports |
references/react_folder_structure.md | Target directory structure template |
Version: 3.0.0 Last Updated: 2026-02-07
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
中文简介正在准备中。当前显示原文说明。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
中文简介正在准备中。当前显示原文说明。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
中文简介正在准备中。当前显示原文说明。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
中文简介正在准备中。当前显示原文说明。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
中文简介正在准备中。当前显示原文说明。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
中文简介正在准备中。当前显示原文说明。