跳到正文
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,502(GitHub 83,502 + cccskills 0)

实测评分 未实测

查看安装方法

适用场景

  • 确定新源文件的存放位置
  • 统一相关测试的放置方式
  • 规划大型文件的拆分结构

中文介绍

功能

本指南整理代码库中的文件命名、目录位置、导出和测试放置规则,涵盖 React 组件、钩子、普通模块及软件包的命名方式,也说明何时使用具名导出。单个模块的测试放在模块旁边;涉及多个模块或真实基础设施的测试放在 __tests__/。对于超过 1200 行的文件,指南建议按状态、功能或处理阶段等实际边界拆成多个模块,同时保留公开导入路径和原有行为。

适用场景

添加新文件、判断测试应放在哪里,或规划大型文件的拆分结构时可以参考。它帮助新文件和拆分出的模块遵循代码库现有习惯,不要求为了统一而批量重命名旧文件。

使用示例

  • “这个功能的钩子和测试应该放在哪里?”
  • “请为拆分这个大型文件建议目录结构。”

注意事项

顶层目录的职责由 AGENTS.md 和 project-overview 规定。本指南处理这些目录之下的放置和命名。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
A良好资料不要求仅为符合约定而改名,并要求保留导入路径和行为。
安装难易度所需工具和 API 密钥是否少且有说明
A良好无需外部服务或凭据,依据现有代码库约定操作。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月26日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md8.5 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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

免费有简介

通过实际操作产品验证交付内容,记录用户可查看的证据,并发布验收报告。可检查已有验证计划或创建检查项,选择合适的操作界面,并使用 `lh` CLI 发布结果。

  • 实际检查更改后的产品行为
  • 收集截图或其他验证证据
  • 编写验证计划和报告
lobehub/lobehub8.4万2026年10月26日 更新

add-model-provider

免费有简介

本技能指导在 LobeHub 中接入 AI 模型提供商,涵盖运行时、模型信息、设置、品牌展示、文档和验收,并帮助判断新增模型是否需要新的提供商集成。

  • 为 LobeHub 接入新的 AI 模型提供商
  • 更新提供商设置说明或介绍
  • 判断添加模型是否需要新的提供商集成
lobehub/lobehub8.4万2026年10月26日 更新

add-setting-env

免费有简介

本技能指导如何用服务器端环境变量设置用户偏好默认值,涵盖变量校验、服务器配置、写入用户状态,以及更新 `.env.example` 和自托管文档。

  • 通过环境变量设置用户偏好默认值
  • 将设置接入服务器配置和用户状态
  • 更新环境变量示例及文档
lobehub/lobehub8.4万2026年10月26日 更新

agent-runtime-hooks

免费有简介

说明如何在智能体执行步骤、工具调用、人工审批、上下文压缩和子智能体调用时注册钩子。钩子可观察事件、模拟本地工具结果,也可通过 Webhook 按配置策略允许或拒绝工具调用。

  • 记录智能体步骤和错误
  • 测试时模拟工具结果
  • 通过 Webhook 允许或拒绝工具调用
lobehub/lobehub8.4万2026年10月26日 更新

agent-signal

免费有简介

此技能用于为智能体设计事件驱动的后台工作流,划分来源、信号、动作和策略的职责,并处理异步交接、去重、执行范围、完成记录与运行观测。

  • 添加事件触发的后台任务
  • 将工作移出对话请求
  • 防止动作重复执行
lobehub/lobehub8.4万2026年10月26日 更新

agent-testing-bot

免费有简介

本技能在 macOS 桌面聊天应用中测试机器人频道:打开应用、进入频道或联系人、发送消息、等待回复并截图。支持 Discord、Slack、Telegram、微信、飞书和 QQ;iMessage 使用 BlueBubbles 桥接。

  • 检查真实 Discord 频道中的机器人回复
  • 测试 Slack 或 Telegram 的对话流程
  • 记录 macOS 应用中的操作结果
lobehub/lobehub8.4万2026年10月26日 更新

查看 lobehub 的全部技能

报告此技能的问题