ワンクリックでManusで任意のスキルを実行

frontend-architecture

スター4

フォーク0

更新日2026年4月3日 19:40

Use when moving frontend files, creating React modules, refactoring UI, or deciding whether code belongs in app, domains, features, or shared.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

BrainerVirus

BrainerVirus/Timely

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Frontend Architecture

Keep the frontend readable by enforcing structure, direct imports, and small files.

Non-Negotiable Rules

Never create public/, index.ts, or index.tsx anywhere under src/.
Never create components/ or utils/ as first-level folders inside src/features/* or src/domains/*.
Use only these first-level folders inside features/domains: screens, sections, ui, hooks, state, services, lib, types, internal.
shared is only for generic code. If code knows about GitLab, schedule logic, worklog, settings, or another business concept, it does not belong in shared.
Cross-feature reusable domain code belongs in src/domains/*.
Route containers, app shell, global providers, desktop integration, and Zustand access belong in src/app/*.
Prefer props over store access. Route/layout/bootstrap code may read useAppStore; feature and domain UI should receive data through props.
Use direct file imports only.
Colocate tests with the source file using Thing.tsx and Thing.test.tsx.

Placement Guide

src/app/*: router, layouts, boot flow, providers, desktop bridge, overlays, state.
src/domains/*: reusable domain modules shared by multiple features or routes.
src/features/*: user-facing flows that are owned by one feature.
src/shared/ui/*: generic UI primitives.
src/shared/lib/*: generic pure helpers.
src/shared/testing/*: shared test-only helpers and fixtures.

Size Discipline

Split screens/*.tsx before they exceed 300 lines.
Split ui/*.tsx before they exceed 220 lines.
Split hooks, state, services, and lib files before they exceed 250 lines.
Use internal/ folders for private parts of a single unit when a file is getting crowded.

Import Boundaries

shared must not import from app, domains, or features.
domains must not import from features.
features must not import from other features.
internal/* may only be imported by the owning unit.

Workflow

Decide whether the code is app-level, domain-level, feature-level, or shared.
Put it in the smallest folder scope that still matches its reuse boundary.
Add or move the colocated test with the file.
Run npm run lint and npm run build.

このリポジトリの他の Skills

同じリポジトリ

compress

BrainerVirus/Timely

Compress natural language memory files (CLAUDE.md, todos, preferences) into caveman format to save input tokens. Preserves all technical substance, code, URLs, and structure. Compressed version overwrites the original file. Human-readable backup saved as FILE.original.md. Trigger: /caveman:compress <filepath> or "compress memory file"

2026-04-254

timely-release-manager

BrainerVirus/Timely

Use this whenever the user asks to prepare, verify, or publish a Timely release or prerelease, bump versions, generate GitHub release notes, validate updater channels, update localized in-app What's New notes, or work on release/localization rules. Trigger on release, prerelease, beta, tag, changelog, updater manifest, gh release, publish, cut release, ship build, localization, i18n, release notes, highlights, Spanish, Portuguese, es, pt.

2026-03-244

timely-design-system

BrainerVirus/Timely

Use this whenever working on Timely UI, styling, visual polish, component consistency, spacing, shadows, surfaces, interaction states, or control sizing. This skill is the entrypoint for Timely's full design system: claymorphism treatment, theme tokens, shared control sizes, button depth rules, component constraints, and consistency patterns. It should trigger for any request to add or revise Timely components so the app stays visually coherent instead of drifting into one-off styling.

2026-03-134

Frontend Architecture

Keep the frontend readable by enforcing structure, direct imports, and small files.

Non-Negotiable Rules

Never create public/, index.ts, or index.tsx anywhere under src/.

Never create components/ or utils/ as first-level folders inside src/features/* or src/domains/*.

Use only these first-level folders inside features/domains: screens, sections, ui, hooks, state, services, lib, types, internal.

shared is only for generic code. If code knows about GitLab, schedule logic, worklog, settings, or another business concept, it does not belong in shared.

Cross-feature reusable domain code belongs in src/domains/*.

Route containers, app shell, global providers, desktop integration, and Zustand access belong in src/app/*.

Prefer props over store access. Route/layout/bootstrap code may read useAppStore; feature and domain UI should receive data through props.

Use direct file imports only.

Colocate tests with the source file using Thing.tsx and Thing.test.tsx.

Placement Guide

src/app/*: router, layouts, boot flow, providers, desktop bridge, overlays, state.

src/domains/*: reusable domain modules shared by multiple features or routes.

src/features/*: user-facing flows that are owned by one feature.

src/shared/ui/*: generic UI primitives.

src/shared/lib/*: generic pure helpers.

src/shared/testing/*: shared test-only helpers and fixtures.

Size Discipline

Split screens/*.tsx before they exceed 300 lines.

Split ui/*.tsx before they exceed 220 lines.

Split hooks, state, services, and lib files before they exceed 250 lines.

Use internal/ folders for private parts of a single unit when a file is getting crowded.

Import Boundaries

shared must not import from app, domains, or features.

domains must not import from features.

features must not import from other features.

internal/* may only be imported by the owning unit.

Workflow

Decide whether the code is app-level, domain-level, feature-level, or shared.

Put it in the smallest folder scope that still matches its reuse boundary.

Add or move the colocated test with the file.

Run npm run lint and npm run build.

name	frontend-architecture
description	Use when moving frontend files, creating React modules, refactoring UI, or deciding whether code belongs in app, domains, features, or shared.