본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

source-layout

코드베이스에서 소스와 테스트 파일의 이름, 위치, 내보내기 규칙을 따르는 방법을 안내합니다. 단일 모듈 테스트와 통합 테스트의 배치, 1,200줄이 넘는 파일을 분할하면서 가져오기 경로와 동작을 유지하는 기준도 설명합니다.

원문원문 설명 보기

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,500(GitHub 83,500 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • 새 소스 파일의 위치 결정
  • 관련 테스트의 배치 기준 정리
  • 대형 파일 분할 구조 계획

한국어 소개

할 수 있는 일

이 가이드는 코드베이스 안에서 파일 이름, 위치, 내보내기와 테스트 배치에 적용되는 규칙을 설명합니다. React 컴포넌트, 훅, 일반 모듈, 패키지의 이름 형식과 이름 있는 내보내기를 사용하는 기준을 다룹니다. 단일 모듈의 테스트는 해당 모듈 옆에 두고, 여러 모듈이나 실제 인프라를 다루는 테스트는 __tests__/에 두는 등 테스트 종류별 위치도 안내합니다. 1,200줄이 넘는 파일은 상태나 기능 등의 실제 경계를 기준으로 나누되 공개 가져오기 경로와 동작을 유지하는 방법을 설명합니다.

이럴 때 유용합니다

새 파일을 추가하거나 테스트를 어디에 둘지 결정할 때, 또는 큰 파일을 나눌 구조를 계획할 때 참고할 수 있습니다. 기존 파일을 일괄적으로 이름 변경하지 않고, 새 파일과 분할된 모듈이 코드베이스의 관례를 따르도록 돕습니다.

사용 예시

  • “이 기능의 훅과 테스트를 어디에 두면 좋을지 정리해 주세요.”
  • “이 큰 파일을 나눌 디렉터리 구성을 제안해 주세요.”

주의 사항

최상위 디렉터리별 담당 범위는 AGENTS.md와 project-overview가 정합니다. 이 가이드는 그 하위의 배치와 명명을 다룹니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
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 / 1,000자

이 양식은 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

무료요약 있음

서버 환경 변수로 사용자 설정의 기본값을 지정하도록 구현하는 절차를 안내합니다. 변수 검증, 서버 설정 구성, 사용자 저장소 반영부터 예시 환경 파일과 셀프 호스팅 문서 갱신까지 다룹니다.

  • 환경 변수로 사용자 설정 기본값 지정
  • 설정을 서버 구성과 사용자 저장소에 연결
  • 환경 변수 예시와 문서 갱신
lobehub/lobehub8.4만2026년 10월 26일 업데이트

agent-runtime-hooks

무료요약 있음

에이전트 실행 단계, 도구 호출, 사람의 승인, 컨텍스트 압축, 하위 에이전트 호출에 훅을 등록하는 방법을 안내합니다. 이벤트를 관찰하고 로컬 도구 결과를 모의하거나 설정에 따라 웹훅으로 도구 호출을 허용 또는 거부할 수 있습니다.

  • 에이전트 단계와 오류 기록
  • 테스트 중 도구 결과 모의
  • 웹훅으로 도구 호출 허용 또는 거부
lobehub/lobehub8.4만2026년 10월 26일 업데이트

agent-signal

무료요약 있음

에이전트의 이벤트 기반 백그라운드 작업을 설계하고 구현하도록 돕습니다. 소스, 시그널, 액션, 정책의 역할을 나누고 비동기 처리, 중복 실행 방지, 완료 기록과 관측 기능을 다룹니다.

  • 이벤트로 시작되는 백그라운드 작업 추가
  • 대화 요청과 작업을 분리
  • 액션의 중복 실행 방지
lobehub/lobehub8.4만2026년 10월 26일 업데이트

agent-testing-bot

무료요약 있음

실제 데스크톱 채팅 앱에서 봇 채널의 인수 테스트를 진행합니다. Discord, Slack, Telegram, WeChat, Lark, QQ에서 메시지를 보내고 응답을 기다린 뒤 결과 화면을 캡처합니다. iMessage는 BlueBubbles 브리지를 사용합니다.

  • 실제 Discord 채널에서 봇 응답 확인하기
  • Slack이나 Telegram 대화 경로 테스트하기
  • macOS 앱의 작업 결과 화면으로 기록하기
lobehub/lobehub8.4만2026년 10월 26일 업데이트

lobehub의 스킬 모두 보기

이 스킬의 문제 신고