本文へ移動
cccskills
無料GitHub で公開日本語紹介

source-layout

コードやテストをどのディレクトリに置き、どう命名するかを整理し、1200行を超えるファイルの分割方針やテスト配置の基準を示します。

原文原文の説明を見る

Use for where a file lives, how it is named, where its tests go, and how to split a source or test file over 1200 lines (拆分大文件, 目录结构, 文件命名).

lobehub/lobehubスター 83,506(GitHub 83,506 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 新しいソースファイルの置き場所を決めたいとき
  • テストファイルの配置を揃えたいとき
  • 大きなファイルの分割方針を決めたいとき

日本語での紹介

できること

コードベース内でのファイル名、配置、テストの置き場所を決めるための規約を示します。Reactコンポーネント、フック、通常のモジュール、パッケージなどの命名形式や、名前付きエクスポートを使う基準を確認できます。単一モジュールのテストは隣に置き、複数モジュールや実インフラを扱うテストは __tests__/ に置くなど、テストの分類も説明します。1200行を超えるファイルは、状態や機能のまとまりを保ってディレクトリに分け、公開インポート経路や動作を維持する方針です。

こんなときに便利

新しいファイルを追加するとき、テストをどこに置くか迷うとき、肥大化したファイルの分割先や構成を決めたいときに役立ちます。既存のコードを一律に改名するためではなく、新規作成や分割時にコードベースの慣習を揃えるためのガイドです。

使い方の例

  • 「この機能のフックとテストをどこに置くべきか整理してください」
  • 「この大きなファイルを分割する場合のディレクトリ構成を提案してください」

注意点

ルートディレクトリごとの担当範囲は AGENTS.md と project-overview が定めます。このガイドはその配下の配置や命名を扱います。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

資料チェック

SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。

安全面送信・削除・コマンド実行などの扱いが明示されているか
A良好既存ファイルを規約だけで改名せず、公開経路と動作を保つ方針です。
導入のしやすさ必要なツールや API キーが少ないか、書かれているか
A良好外部サービスや認証情報の前提はなく、既存コードベースの規約を参照します。

点数には入れていません。 2026年10月26日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。

評価が違うと思ったら、見直しを依頼する

どの項目が、なぜ違うと思うかを書いてください。ログインは不要です。内容を SKILL.md と照らし合わせて評価を作り直し、この欄に反映します。

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

含まれるファイル(1)

  • SKILL.md8.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Source Layout

Top-level ownership (src/features, src/routes, apps/server/src, packages, …) is in AGENTS.md and project-overview. This skill owns placement and naming inside those roots, test placement, and how a large file becomes a directory. The rules record the conventions the codebase already follows; where it was split between two forms, the rule names the one to use for new files. Do not rename existing files only to match.

1. Names

WhatFormExample
React component file / component directoryPascalCasePlanCard.tsx, ChatInput/ControlBar/
HookuseXxx.ts(x)ChatInputNotice/useChatInputNotice.ts
Other modulecamelCase or one wordoriginLink.ts, recentDirs.ts
Server class modulethe class nameservices/agentRuntime/StaleOperationReaper.ts
Service, router, store, and other non-component dirscamelCaseservices/aiAgent/, store/chat/slices/
Package directorykebab-casepackages/agent-runtime/
Files inside a packagecamelCasepackages/database/src/models/

A package whose files are already kebab-case (alint, openapi, builtin-skills) keeps kebab-case internally. Shared per-directory modules are constants.ts, types.ts, style.ts, and utils.ts, not const.ts, type.ts, styles.ts, or helpers.ts. Create one only when two or more modules in that directory use it; a constant or type used by one module stays in that module.

New files use named exports (export const PlanCard = …), even when the neighboring files default-export; do not copy the older default-export habit. The exceptions are modules a framework, tool, or loader imports by their default export: route segments under src/routes (see spa-routes), Next.js special files (page.tsx, layout.tsx, not-found.tsx), *.config.ts files, desktop controllers and services (*Ctr.ts, *Srv.ts, globbed by apps/desktop/src/main/core/App.ts), and locale resource files. Lint does not enforce this: this repository's eslint.config.mjs overrides no-restricted-syntax, which drops the shared @lobehub/lint warning on export default. When moving an existing file, keep its exports unchanged so its callers do not change.

2. Tests

One rule for every app and package:

  • A test of one module sits beside it: Foo.ts → Foo.test.ts; a directory entry's test is index.test.ts.
  • __tests__/ holds only tests that do not belong to one module: integration tests that run several modules together or real infrastructure (database, Redis, the tRPC or Hono request stack), such as routers/lambda/__tests__/integration/ and the database model and repository tests in testing, plus their shared setup, fixtures, and fakes.
  • New tests follow this rule even in a directory whose existing unit tests sit in __tests__/. Move an existing unit test beside its module when you split or rewrite that test file; do not migrate tests as a side task.
  • Split a large test file by scenario: Foo.<scenario>.test.ts(x), keeping the original extension (index.<scenario>.test.ts(x) for a directory entry). Put shared mock factories and fixtures in a testUtils.ts beside them; each test file keeps its own vi.mock calls, because Vitest hoists them per file.
  • Do not add React component tests, including to guard a split. Extract the logic into a hook or pure function and test that in .test.ts (testing).

3. File size

Source and test files stay at or below 1200 lines. Generated code (*.gen.ts, generated/ directories) and the locales/default/ tables are exempt:

  • A new file over 1200 lines, or an existing file that crosses 1200 lines in this change, is split in the same change. bun run check, the pre-commit hook, and the PR's File Size Gate job fail on both.
  • A file already over 1200 lines must not grow, including for a bug fix: the change may only keep or reduce its line count. Before adding code, extract the cohesive part the change touches into a sibling inside the file's own directory (Foo.ts becomes Foo/index.ts, §4), not into a neighboring file or another slice. Put a new test in a scenario test file under the limit (§2), splitting the old test file first when the test belongs to one of its scenarios. Because hundreds of legacy files are over the limit, these checks report their growth as an advisory (a warning annotation in CI) instead of failing; it is still a required fix.

The limit says when to split, not where. Split on a real boundary (state, reuse, render update, sub-domain, pipeline stage), as react requires; never cut a file at an arbitrary line count. When a heavy feature is mounted by several hosts, use compose-atoms instead.

4. Turning a file into a directory

A split keeps the public import path: Foo.tsx becomes Foo/index.tsx, so import Foo from './Foo' keeps working and callers do not change. Commit the move (mkdir -p Foo && git mv Foo.tsx Foo/index.tsx) alone before extracting, so reviewers can read the extraction diff separately and Git keeps the rename while those commits stay intact (a squash merge folds them together). split-large-file has the full procedure.

Kindindex keepsSiblingsPrecedent
React componentPublic API, shared top-level state, compositionChild components (PascalCase), useXxx.ts for state transitions and side effects, pure logic modules with their own testsConversation/Messages/GoalTaskCard/
Server serviceThe class and its orchestration methodsStage functions taking an explicit deps object (pipeline/<stage>.ts), sub-domain foldersservices/aiAgent/, services/comfyui/
tRPC routerThe merged routerOne sub-router per sub-domain (market/agent.ts exports agentRouter)routers/lambda/market/
Zustand storeThe action class and its public method signaturesLogic modules exporting a function that takes one params object plus get; the class method delegates to itagentRun/actions/entries/conversationLifecycle/
  • Prefer flat siblings. Add a sub-folder for a sub-area with several files of its own (ChatInput/ControlBar/).
  • Kind folders (components/, hooks/, utils/) follow who uses the code:
    • One user: keep it in that file or beside it (PlanGrid/usePlanActions.ts).
    • A few modules in the directory share it: flat siblings for hooks and components, one utils.ts for pure functions.
    • Three or more files of one kind shared by sibling modules: collect them in a kind folder (Dashboard/utils/, ChatInput/hooks/, ResourceManager/components/).
    • Shared across features: src/utils, src/hooks, src/components, or a packages/* package.
    • Do not create helpers/; name the module by its content or use utils.
  • A split moves code without changing behavior. Collapsing duplicated branches that become one component is in scope when existing tests cover each branch; any other behavior change belongs in a separate commit.
  • Move the matching tests with the code they cover, then run bun run check with the test files passed explicitly: related-test discovery finds only <name>.test.* and <name>.<scenario>.test.* of each changed file, so the entry's tests do not run for an extracted sibling such as usePlanActions.ts.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

acceptance

無料概要あり

実際の製品を操作して、利用者が確認できる動作証拠を集め、検証計画に沿った受け入れレポートとして公開するスキルです。

  • 変更後の製品動作を実地で検証したいとき
  • 画面キャプチャなどの証拠を集めたいとき
  • 検証計画とレポートを作成したいとき
lobehub/lobehub8.4万2026年10月26日 更新

add-model-provider

無料概要あり

LobeHubにAIモデルプロバイダーを追加し、実行時連携からモデル表示、設定、ブランド表記、文書化、動作確認まで進めるスキルです。

  • 新しいAIモデルプロバイダーを追加したいとき
  • プロバイダーの設定手順や説明文を更新したいとき
  • 既存プロバイダーへのモデル追加要件を見極めたいとき
lobehub/lobehub8.4万2026年10月26日 更新

add-setting-env

無料概要あり

ユーザー設定の初期値をサーバー側の環境変数で切り替えるため、型定義や設定の組み立て、ユーザーストアへの反映、環境変数の例と説明書きを追加する手順です。

  • 設定の初期値を環境変数で変えたいとき
  • 設定項目をサーバー設定に追加したいとき
  • 環境変数の例と説明を更新したいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-runtime-hooks

無料概要あり

エージェント実行中の各段階をフックで監視し、ツール呼び出しの模擬・制御や人の承認、圧縮、サブエージェント処理に介入する仕組みを扱います。

  • エージェントの実行状況を記録したいとき
  • ツール結果をテスト用に模擬したいとき
  • Webhookでツール実行を許可・拒否したいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-signal

無料概要あり

イベントを起点にエージェントのバックグラウンド処理を組み立て、ソース・シグナル・アクション・ポリシーの役割分担や非同期連携を実装するためのスキルです。

  • イベント起点の処理を追加したいとき
  • バックグラウンド処理を非同期化したいとき
  • 重複実行を防ぐ仕組みを整えたいとき
lobehub/lobehub8.4万2026年10月26日 更新

agent-testing-bot

無料概要あり

DiscordやSlackなどの実際のチャットアプリでボットにメッセージを送り、応答を画面で確認する受け入れテストを行うスキルです。

  • 実際のDiscordでボット応答を確かめたいとき
  • SlackやTelegramの会話経路をテストしたいとき
  • macOSアプリ上の操作結果を画面で記録したいとき
lobehub/lobehub8.4万2026年10月26日 更新

lobehub のスキルをすべて見る

このスキルの問題を報告する