diff --git a/CLAUDE.md b/CLAUDE.md
index e8692c686..4df0e8f8d 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -2,117 +2,95 @@
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
-## Important: Continuous Knowledge Updates
+# Repomix Project Structure and Overview
 
-**ALWAYS update this CLAUDE.md file during development tasks when you learn:**
-- New project-specific patterns or conventions
-- Solutions to common problems or edge cases
-- Debugging techniques specific to this codebase
-- Tool usage patterns that improve efficiency
-- Review feedback patterns that could help future development
-- Architecture decisions and their rationale
+This document provides a structural overview of the Repomix project, designed to aid AI code assistants (like Copilot) in understanding the codebase.
 
-**When to update:** Don't wait until task completion - update immediately when you discover useful knowledge that would benefit future development sessions. This ensures knowledge continuity across different coding sessions.
+Please refer to `README.md` for a complete and up-to-date project overview, and `CONTRIBUTING.md` for implementation guidelines and contribution procedures.
 
-# Repomix Development Guide
+## Project Overview
 
-Repomix is a tool that packs repository contents into single files optimized for AI consumption. It converts codebases into structured formats (XML, Markdown, Plain Text) with intelligent compression, security scanning, and token counting for LLM integration.
+Repomix is a tool that packs the contents of a software repository into a single file, making it easier for AI systems to analyze and process the codebase. It supports various output formats (XML, Markdown, or plain text), ignores files based on configurable patterns, and performs security checks to exclude potentially sensitive information.
 
-## Project Structure Overview
+## Directory Structure
 
-### **src/ Directory - Core Library**
-The main Repomix library that powers both CLI tool and web service:
-- **cli/**: Command-line interface with Commander.js
-- **config/**: Zod-based configuration loading and validation  
-- **core/**: Business logic organized by functionality (file, git, metrics, output, security, treeSitter)
-- **mcp/**: Model Context Protocol server for AI assistant integration
-- **shared/**: Common utilities and types
+The project is organized into the following directories:
 
-### **website/ Directory - Web Application** 
-Full-stack web application for repomix.com:
-- **client/**: VitePress documentation site with Vue.js components for "Try It" feature
-- **server/**: Hono-based API server for online repository processing
-- **Multi-language support**: 12 languages for documentation
-- **Docker deployment**: Containerized client and server components
-
-#### **Supported Languages (12 total)**
-English, Japanese, Chinese (Simplified/Traditional), Korean, German, French, Spanish, Portuguese (Brazilian), Indonesian, Vietnamese, Hindi
-
-#### **Website Development Guidelines**
-- **Translation workflow**: Update English first, then translate to other languages
-- **Navigation sync**: All language configurations in `website/client/.vitepress/config/` must be synchronized
-- **New language addition**: Complete one language fully before starting another
-- **VitePress architecture**: Uses shared configuration in `configShard.ts` for search and common settings
-- **Content structure**: Each language has dedicated directory (e.g., `website/client/src/ja/`)
-- **Quality assurance**: Test navigation and search functionality for each language
-
-### **browser/ Directory - Browser Extension**
-Cross-browser extension (Chrome/Firefox/Edge) that adds Repomix integration to GitHub:
-- **Manifest V3**: Latest browser extension specification
-- **Content script**: Adds "Repomix" button to GitHub repository pages  
-- **Multi-language**: 11 language support with internationalization
-- **One-click workflow**: Direct integration from GitHub to repomix.com
-
-## Build & Development Commands
-- `npm run build` - Build the project
-- `npm run lint` - Run all linters (Biome, TypeScript, secretlint)
-- `npm run lint-biome` - Run Biome linter with auto-fix
-- `npm run lint-ts` - Run TypeScript type checking
-- `npm test` - Run all tests
-- `npm test -- /path/to/file.test.ts` - Run a specific test file
-- `npm test -- -t "test name"` - Run tests matching description
-- `npm run test-coverage` - Run tests with coverage report
-- `npm run repomix` - Build and run the CLI tool
-- `npm run repomix-src` - Pack only src and tests directories
-- `npm run repomix-website` - Pack only website directory
-- `npm run website` - Start local website development environment
-- `npm run website-generate-schema` - Generate JSON schema for configuration
+```
+repomix/
+├── browser/ # Browser extension source code
+├── src/ # Main source code
+│   ├── cli/ # Command-line interface logic (argument parsing, command handling, output)
+│   ├── config/ # Configuration loading, schema, and defaults
+│   ├── core/ # Core logic of Repomix
+│   │   ├── file/ # File handling (reading, processing, searching, tree structure generation, git commands)
+│   │   ├── metrics/ # Calculating code metrics (character count, token count)
+│   │   ├── output/ # Output generation (different styles, headers, etc.)
+│   │   ├── packager/ # Orchestrates file collection, processing, output, and clipboard operations.
+│   │   ├── security/ # Security checks to exclude sensitive files
+│   │   ├── mcp/ # MCP server integration (packaging codebases for AI analysis)
+│   │   ├── tokenCount/ # Token counting using Tiktoken
+│   │   └── treeSitter/ # Code parsing using Tree-sitter and language-specific queries
+│   └── shared/ # Shared utilities and types (error handling, logging, helper functions)
+├── tests/ # Unit and integration tests (organized mirroring src/)
+│   ├── cli/
+│   ├── config/
+│   ├── core/
+│   ├── integration-tests/
+│   ├── shared/
+│   └── testing/
+└── website/ # Documentation website (VitePress)
+```
 
-## Core Architecture
 
-### File Processing Pipeline (`src/core/file/`)
-- **fileCollect.ts**: Parallel file reading with worker threads for performance
-- **fileProcess.ts**: Content transformation including comment removal and formatting
-- **fileSearch.ts**: Glob pattern-based file discovery with gitignore integration
-- **filePathSort.ts**: Git-aware file ordering by change frequency for optimal AI context
 
-### Security & Validation (`src/core/security/`)
-- **securityCheck.ts**: Multi-threaded Secretlint integration for sensitive data detection
-- **validateFileSafety.ts**: Pre-processing file safety validation
-- Uses worker threads for concurrent security scanning to prevent blocking
+# Coding Guidelines
+- Follow the Airbnb JavaScript Style Guide.
+- Split files into smaller, focused units when appropriate:
+  - Aim to keep code files under 250 lines. If a file exceeds 250 lines, split it into multiple files based on functionality.
+- Add comments to clarify non-obvious logic. **Ensure all comments are written in English.**
+- Provide corresponding unit tests for all new features.
+- After implementation, verify changes by running:
+  ```bash
+  npm run lint  # Ensure code style compliance
+  npm run test  # Verify all tests pass
+  ```
 
-### Output Generation (`src/core/output/`)
-- **outputGenerate.ts**: Multi-format support (XML default, Markdown, Plain Text)
-- **outputStyles/**: Format-specific templates with Handlebars templating
-- **outputStyleDecorate.ts**: Content decoration with line numbers and headers
+## Commit Messages
+- Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for all commit messages
+- Always include a scope in your commit messages
+- Format: `type(scope): Description`
+  ```
+  # Examples:
+  feat(cli): Add new --no-progress flag
+  fix(security): Handle special characters in file paths
+  docs(website): Update installation guide
+  style(website): Update GitHub sponsor button color
+  refactor(core): Split packager into smaller modules
+  test(cli): Add tests for new CLI options
+  ```
+- Types: feat, fix, docs, style, refactor, test, chore, etc.
+- Scope should indicate the affected part of the codebase (cli, core, website, security, etc.)
+- Description should be clear and concise in present tense
+- Description must start with a capital letter
 
-### Tree-Sitter Integration (`src/core/treeSitter/`)
-- **languageParser.ts**: 15+ language support for intelligent code parsing
-- **parseStrategies/**: Language-specific parsing strategies for optimal compression
-- Achieves ~70% token reduction while preserving semantic meaning
+## Pull Request Guidelines
+- All pull requests must follow the template:
+  ```md
+  <!-- Please include a summary of the changes -->
 
-### CLI Architecture (`src/cli/`)
-- **cliRun.ts**: Main CLI orchestrator using Commander.js
-- **actions/**: Modular command handlers (default, remote, init, mcp, version)
-- **defaultAction.ts**: Standard local repository processing workflow
-- **remoteAction.ts**: GitHub URL/shorthand processing with branch/commit resolution
+  ## Checklist
 
-### MCP Server (`src/mcp/`)
-- **mcpServer.ts**: Model Context Protocol server for AI assistant integration
-- **tools/**: File system access, repository packing, and content search capabilities
-- Provides sandboxed AI-to-codebase interaction layer
+  - [ ] Run `npm run test`
+  - [ ] Run `npm run lint`
+  ```
+- Include a clear summary of the changes at the top of the pull request description
+- Reference any related issues using the format `#issue-number` 
 
-## Code Style Guidelines
-- **Formatting**: 2 spaces indentation, 120 char line width, single quotes, trailing commas
-- **Imports**: Use `node:` prefix for built-ins, `.js` extension for relative imports, `import type` for types
-- **TypeScript**: Strict type checking, explicit return types, prefer interfaces for object types
-- **Error Handling**: Custom errors extend `RepomixError`, descriptive messages, proper try/catch
-- **File Structure**: Keep files under 250 lines, organize by feature, use workers for concurrent operations
-- **Comments**: All comments must be written in English, clarify non-obvious logic
-- **Testing**: Use Vitest, provide unit tests for all new features, descriptive test names, arrange/act/assert pattern
 
-### **Dependencies and Testing Best Practices**
-- **Dependency Injection**: Inject dependencies through `deps` object parameter for testability
+## Dependencies and Testing
+- Inject dependencies through a deps object parameter for testability
+- Example:
   ```typescript
   export const functionName = async (
     param1: Type1,
@@ -125,213 +103,9 @@ Cross-browser extension (Chrome/Firefox/Edge) that adds Repomix integration to G
     // Use deps.defaultFunction1() instead of direct call
   };
   ```
-- **Mocking Strategy**: Mock dependencies by passing test doubles through deps object
-- **vi.mock() Usage**: Use `vi.mock()` only when dependency injection is not feasible
-- **Test Organization**: Tests mirror src/ directory structure in tests/ folder
-
-## Naming Conventions
-- PascalCase: Classes, interfaces, types
-- camelCase: Variables, functions, methods, file names
-- Test files: `[filename].test.ts`
-
-## Key Design Patterns
-
-### Worker Thread Architecture
-- CPU-intensive operations (file processing, security checks, metrics) use Piscina worker pools
-- **Workers**: `src/core/file/workers/`, `src/core/security/workers/`, `src/core/metrics/workers/`
-- Enables concurrent processing while keeping main thread responsive
-
-### Dependency Injection
-- Functions accept `deps` object parameter containing dependencies for testability
-- Example: `fileCollect(paths, options, deps = { readFile, processFile })`
-- Enables easy mocking in tests and flexible runtime configuration
-
-### Configuration System
-- **configSchema.ts**: Zod-based type-safe configuration with runtime validation
-- **configLoad.ts**: Hierarchical config merging (global → project → CLI options)
-- Supports JSON5 format for comments in configuration files
-
-### Error Handling
-- All custom errors extend `RepomixError` base class in `src/shared/errorHandle.ts`
-- Structured error types with context information for debugging
-- Proper error propagation through async/worker boundaries
-
-## Git Workflow
-
-### Pre-Commit Requirements (MANDATORY)
-**ALWAYS run these commands before every commit:**
-```bash
-npm run lint
-npm run test
-```
-
-- **npm run lint**: Runs Biome formatter, TypeScript type checking, and Secretlint security scan
-- **npm run test**: Executes full test suite to ensure no regressions
-- **Never commit failing code**: Fix all lint errors and test failures before committing
-- **Use `--write` flag**: Biome will auto-fix formatting issues when possible
-
-### Commit Message Format
-- Follow [Conventional Commits](https://www.conventionalcommits.org/) with scope: `type(scope): Description`
-- **Write all commit messages in English** - both title and body must be in English for consistency
-- **Format**: `type(scope): Description` - Description must start with capital letter
-- **Types**: feat, fix, docs, style, refactor, test, chore, etc.
-- **Scope**: Indicate affected part (cli, core, website, security, etc.)
-- Write detailed commit messages focusing on the "why" rather than the "what"
-- **Include user dialogue context**: Reference the specific conversation or request that led to the change in the commit body
-- Format: Use title for technical change, body with clear dialogue section marker and summary
-- Start with dialogue type summary, then provide bullet points of the conversation flow
-- If user spoke in another language, translate their quotes to English in the commit message
-- Examples: 
-  ```
-  feat(cli): Add new --no-progress flag
-  
-  User requested a feature enhancement for CI automation:
-  - User asked: "Can we disable progress output for CI environments?"
-  - User explained: "Progress output creates noise in build logs"
-  - Assistant implemented --no-progress flag for automation compatibility
-  
-  🤖 Generated with [Claude Code](https://claude.ai/code)
-  
-  Co-Authored-By: Claude <noreply@anthropic.com>
-  ```
-
-## Pull Request Review Process
-
-### Viewing PR Comments
-There are different types of comments in GitHub PRs that require different approaches to view:
-
-**1. General PR Comments (in main conversation):**
-```bash
-gh pr view {PR_NUMBER} --comments
-```
-
-**2. Specific Code Line Comments (Files changed tab):**
-```bash
-gh api repos/yamadashy/repomix/pulls/{PR_NUMBER}/comments --jq '.[] | {path: .path, line: .line, body: .body}'
-```
-
-**3. Review Comments with Status:**
-```bash
-gh api repos/yamadashy/repomix/pulls/{PR_NUMBER}/reviews --jq '.[] | select(.state == "COMMENTED" or .state == "CHANGES_REQUESTED") | .body'
-```
-
-### Automated Review Bots
-This repository uses several automated review tools:
-
-- **CodeRabbit**: AI-powered code review with actionable suggestions
-- **Gemini Code Assist**: Google's AI code reviewer with severity ratings (High/Medium/Low)
-- **Copilot Pull Request Reviewer**: GitHub's automated review suggestions
-- **Codecov**: Test coverage analysis and reporting
-
-### Requesting Additional Reviews
-You can request additional AI reviews manually:
-
-**CodeRabbit Review Request:**
-```
-@coderabbitai review
-```
-
-**Gemini Review Request:**
-```
-/gemini review
-```
-
-**Important**: Post each review request in separate comments for proper processing.
-
-### Responding to Review Feedback
-
-**1. Address Technical Issues First:**
-- Fix high-priority issues (security, functionality, memory leaks)
-- Address medium-priority issues (UX, maintainability)
-- Consider low-priority suggestions for future improvements
-
-**2. Commit Changes with Clear Messages:**
-```bash
-git commit -m "fix(scope): Address PR review feedback
-
-- Fix specific issue 1 (reference commit/line if applicable)
-- Improve specific aspect 2
-- Address reviewer concern about X
-
-🤖 Generated with [Claude Code](https://claude.ai/code)
-
-Co-Authored-By: Claude <noreply@anthropic.com>"
-```
-
-**3. Respond to Reviewers:**
-- Use `gh pr comment {PR_NUMBER} --body "message"` for general responses
-- Reference specific commits that address issues: `Fixed in commit \`abc1234\``
-- Explain rationale for decisions when not implementing suggestions
-- Thank reviewers for their feedback
-
-**4. Self-Review (When Requested):**
-- Perform self-review only when explicitly requested by the user
-- Add comprehensive review comments covering: directory structure, content quality, impact assessment
-- Use `gh pr comment {PR_NUMBER} --body "..."` to add detailed self-review comments
-- Structure self-review with clear sections: code quality, testing, documentation, risk assessment
-- **Be thorough**: Cover all significant changes and their rationale
-
-**5. Resolve Conversations (IMPORTANT!):**
-- **Always resolve addressed feedback** - this helps track progress and shows respect for reviewers
-- CodeRabbit: Use `@coderabbitai resolve` command in PR comments
-- Others: Respond with explanation, then let reviewers mark as resolved
-- GitHub Web UI: Use "Resolve conversation" button on Files changed tab
-- **Don't forget this step** - unresolved conversations can delay PR approval
-
-### Common Review Issues and Solutions
-
-**Vue.js/Frontend:**
-- Event listener cleanup: Use `onUnmounted()` instead of return functions in `onMounted()`
-- Disabled element events: Move event handlers to parent containers
-- CSS positioning: Consider `position: fixed` for tooltips to avoid parent overflow issues
-- Accessibility: Maintain ARIA labels and proper focus management
-
-**Performance:**
-- Use `{ passive: true }` for scroll listeners
-- Implement proper cleanup for all event listeners
-- Consider debouncing/throttling for frequent events
-
-**Code Quality:**
-- Remove duplicate CSS definitions
-- Use existing color schemes for consistency
-- Follow established patterns in the codebase
-- Maintain proper TypeScript typing
-
-### Review Process Checklist
-
-Before marking PR as ready for merge:
-
-1. ✅ **Address all feedback** - Fix high/medium priority issues
-2. ✅ **Run linting and tests (MANDATORY)** - `npm run lint && npm test` - Must pass before committing
-3. ✅ **Commit with clear messages** - Reference what was fixed
-4. ✅ **Respond to reviewers** - Explain changes and decisions
-5. ✅ **Resolve conversations** - Mark addressed feedback as resolved
-6. ✅ **Update documentation** - If architectural changes were made
-7. ✅ **Perform self-review if requested** - Add comprehensive comments using `gh pr comment`
-
-**Remember**: Resolving conversations shows that feedback has been addressed and helps maintainers track review progress. Self-review should only be performed when explicitly requested by the user.
-
-## Knowledge Management & Continuous Improvement
-
-### Document Learning During Development
-
-**Key principle:** Update CLAUDE.md immediately when discovering useful patterns, not at the end of tasks.
-
-**Examples of knowledge worth documenting:**
-- **Project quirks**: "Website uses `position: fixed` for tooltips due to parent `overflow: hidden`"
-- **Tool discoveries**: "Use `gh api` for line-specific PR comments, `gh pr view --comments` for general ones"
-- **Debug techniques**: "Check `canShareFiles()` implementation when Web Share API behaves unexpectedly"
-- **Performance patterns**: "Always use `{ passive: true }` for scroll listeners in Vue components"
-- **Architecture insights**: "tooltip-container pattern prevents disabled button event issues"
-- **Documentation workflows**: "Historical release notes archived in `.github/releases/` by semantic versioning structure"
-- **PR management**: "Self-review PRs only when explicitly requested using `gh pr comment` for comprehensive analysis"
-
-### Maintaining This File
-
-- **Be specific**: Instead of "fix tooltip issues", write "move mouseenter to container for disabled buttons"
-- **Include context**: Explain *why* a solution works, not just *what* to do
-- **Reference locations**: Include file paths and line numbers when relevant
-- **Update immediately**: Don't batch updates - add knowledge as you learn it
-- **Cross-reference**: Link related sections (e.g., PR review patterns ↔ Vue.js best practices)
+- Mock dependencies by passing test doubles through deps object
+- Use vi.mock() only when dependency injection is not feasible
 
-This file is a living document that should grow with every development session, ensuring no valuable knowledge is lost between tasks.
+## Generate Comprehensive Output
+- Include all content without abbreviation, unless specified otherwise
+- Optimize for handling large codebases while maintaining output quality
diff --git a/browser/CLAUDE.md b/browser/CLAUDE.md
new file mode 100644
index 000000000..c9b3bbeaa
--- /dev/null
+++ b/browser/CLAUDE.md
@@ -0,0 +1,46 @@
+# Browser Extension Guidelines
+
+This file provides guidance for working with the Repomix browser extension.
+
+## Project Overview
+
+Cross-browser extension (Chrome/Firefox/Edge) that adds Repomix integration to GitHub repository pages. Uses Manifest V3 with content scripts to inject a "Repomix" button directly into GitHub's UI.
+
+## Directory Structure
+
+```
+browser/
+├── app/                    # Extension source code
+│   ├── _locales/          # Internationalization files (11 languages)
+│   ├── images/            # Extension icons (16px to 128px)
+│   ├── manifest.json      # Extension manifest (Manifest V3)
+│   ├── scripts/           # TypeScript source files
+│   │   ├── background.ts  # Service worker (background script)
+│   │   └── content.ts     # Content script for GitHub integration
+│   └── styles/            # CSS styles for injected elements
+├── dist/                  # Built extension files (generated)
+├── promo/                 # Store promotional materials
+└── tests/                 # Test files
+```
+
+## Development Commands
+
+```bash
+npm run dev chrome     # Development mode for Chrome
+npm run build-all      # Build for all browsers
+npm run lint          # TypeScript type checking
+npm run test          # Run tests
+npm run generate-icons # Generate icon set from SVG
+```
+
+## Internationalization
+
+### Supported Languages (11 total)
+English, Japanese, German, French, Spanish, Portuguese (Brazilian), Indonesian, Vietnamese, Korean, Chinese (Simplified/Traditional), Hindi.
+
+### Adding New Languages
+1. Create directory in `app/_locales/[language_code]/`
+2. Add `messages.json` with required keys:
+   - `appName`, `appDescription`, `buttonText`
+3. Add `detailed-description.txt` for store descriptions
+4. Test extension loads correctly with new locale
diff --git a/website/CLAUDE.md b/website/CLAUDE.md
new file mode 100644
index 000000000..be53fe8dd
--- /dev/null
+++ b/website/CLAUDE.md
@@ -0,0 +1,34 @@
+# Website Documentation
+
+## Project Overview
+
+Full-stack web application consisting of VitePress documentation site (client) and Hono API server for online repository processing, with 12-language support.
+
+## Supported Languages (12 total)
+English (en), Japanese (ja), Chinese Simplified (zh-cn), Chinese Traditional (zh-tw), Korean (ko), German (de), French (fr), Spanish (es), Portuguese Brazilian (pt-br), Indonesian (id), Vietnamese (vi), Hindi (hi).
+
+All translations should be accurate and maintain consistent terminology across languages. When adding new features or documentation, please ensure that the English version is updated first, followed by translations in other languages.
+
+## Navigation Configuration
+When modifying website navigation or adding new pages:
+1. Update the configuration files in `website/client/.vitepress/config/`
+2. Each language has its own config file (e.g., `configEnUs.ts`, `configJa.ts`)
+3. Shared configurations are in `configShard.ts`
+
+Ensure all language configurations are synchronized to maintain consistency across the documentation.
+
+## Adding New Languages
+When adding support for a new language, follow these steps:
+
+1. Create a configuration file (e.g., `configXx.ts`) in `website/client/.vitepress/config/` based on existing language configurations
+2. Include proper sidebar navigation, labels, and search translations
+3. Update the imports and locale entries in the main VitePress configuration (`config.ts`)
+4. Add search configurations to `configShard.ts`
+5. Update the supported languages list in this file
+6. Create directory structure for content (e.g., `website/client/src/xx/`)
+7. Create content files starting with main index page and guide index
+8. Progressively translate remaining documentation pages
+9. Test navigation and search functionality in the new language
+
+When working on multiple languages simultaneously, approach one language at a time completely before moving to the next language to maintain quality and consistency.
+