type-project-organization

Enforce unified export syntax and centralized index.ts entry points in TypeScript projects.

2|Updated Jun 28, 2025
One-click install
npx skills add https://github.com/ruan-cat/11comm --skill type-project-organization
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: type-project-organization
Source: https://github.com/ruan-cat/11comm/tree/main/.claude/skills/type-project-organization
Command: npx skills add https://github.com/ruan-cat/11comm --skill type-project-organization

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a comprehensive convention for organizing and exporting types in TypeScript-based projects (e.g., apps/type), addressing issues like export conflicts, duplicated exports, and inconsistent export entry points. It guides how to structure directories, when to export all versus individual members, and how to consolidate common types within a predictable export surface.

Core Features & Use Cases

  • Full export syntax: Always use export * from "./module" to re-export all members, avoiding scattered named exports.
  • Unified export entry points: Create index.ts files at root and per-module levels to provide a single export surface.
  • Avoid duplicate exports: Centralize shared types and options to prevent conflicts and streamline maintenance.
  • Use-case: In a large type project, consolidating all types under apps/type with a consistent export path simplifies imports and reduces refactoring risk.

Quick Start

Tell the AI to apply the type project organization rules to the repository: replace scattered type exports with a unified export approach, create index.ts exports at each level, and move shared types to a common common/ area.

Frequently Asked Questions about type-project-organization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I organize and export types consistently across TypeScript modules?

Type organization uses unified export syntax with export * from statements at both root and module levels, creating single index.ts entry points per layer. This standardizes how types flow through your project and eliminates scattered named exports that cause conflicts.

What's the best way to structure a large TypeScript type project to avoid duplicate exports?

Centralize shared types and options in a common directory, then re-export them through module-level index.ts files using full export syntax. This prevents duplication, simplifies maintenance, and gives consumers one predictable import path.

Why should I use export * from instead of selective named exports in TypeScript?

Full export syntax using export * from avoids naming conflicts, reduces refactoring risk when types change, and enforces a consistent export surface across all modules. It makes the dependency graph clearer and easier to maintain at scale.

Can I apply type export conventions to an existing TypeScript project with scattered exports?

Yes. Replace scattered type exports with unified index.ts entry points at root and module levels, move shared types to a common directory, and enforce full re-export syntax. This refactoring reduces import paths and consolidates your export surface.

When do I need a common directory for shared types in TypeScript projects?

Use a common directory when types or options are referenced across multiple modules to prevent duplication and circular dependencies. Centralizing these in one location creates a single source of truth that all modules can safely import from.

How do I verify that my TypeScript type exports follow a unified structure?

Run typecheck and export-structure checks to validate that all modules follow full export syntax, use centralized index.ts entry points, and avoid duplicate or selective exports. These checks enforce the unified convention across your project.