Frontend structure worker: SCAFFOLD new React project or RESTRUCTURE existing monolith to component-based architecture
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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`.
日本語の概要は準備中です。原文の説明を表示しています。