feat: implement comprehensive skills token optimization system (#9938)

* docs: add comprehensive performance optimization and Sentry error analysis guides

Added two major documentation enhancements:

1. Performance Optimization Guide (1k-coding-patterns/performance.md):
   - 8 major optimization categories for React/React Native
   - Concurrent request control with executeBatched pattern
   - React Native bridge optimization strategies
   - List rendering optimizations (windowSize, FlashList, content-visibility)
   - Developer alerts showing which base components have built-in optimizations
   - Clear decision trees for when to apply manual optimizations
   - Real-world examples from iOS AppHang fixes

2. Sentry Error Analysis Workflow (1k-dev-workflows/fix-sentry-errors.md):
   - Complete workflow for analyzing production crash reports
   - 6 types of proof methodology for establishing causation
   - Bug analysis log template with evidence chain requirements
   - Common fix patterns for AppHang, ANR, and crashes
   - Real-world iOS AppHang case study with detailed analysis

Key Features:
- 🚨 Developer alerts clearly marking optimized base components
- ✅/⚠️ Visual indicators for "no action needed" vs "manual action required"
- Decision trees for quick reference
- Interlocking evidence chain methodology (环环相扣，逐步递进)
- Prevention measures and testing guidelines

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

* refactor: split 1k-coding-patterns into focused skills for better token efficiency

Split 1k-coding-patterns skill into 6 specialized skills to reduce initial token consumption:

New skills created:
- 1k-date-formatting: Date and time formatting utilities
- 1k-i18n: Internationalization and translation management
- 1k-error-handling: Error handling patterns and best practices
- 1k-cross-platform: Platform-specific code patterns
- 1k-code-quality: Linting, documentation, and code quality standards
- 1k-performance: Performance optimization patterns (previously created)

Benefits:
- Reduces initial skill loading token consumption by 47-53% for most tasks
- Each skill is now focused on a single responsibility
- Improves skill discoverability with targeted trigger words
- Maintains comprehensive documentation with Quick Reference sections

Updated 1k-coding-patterns to keep core patterns:
- Promise handling
- React components
- Restricted patterns

All skills include cross-references to related skills for easy navigation.

* refactor: split 1k-dev-workflows into focused skills

Aggressively split 1k-dev-workflows into specialized skills following single-responsibility principle:

New skills created:
- 1k-sentry-analysis: Sentry error analysis and crash fixes (34.6 KB)
  - Complete workflow from JSON analysis to bug fix implementation
  - Evidence-based methodology with 6 types of proof
  - AppHang, ANR, and crash fix patterns

- 1k-test-version: Test version creation workflow (3.3 KB)
  - Automates upgrade test version creation
  - Version number and build number configuration

Merged to existing skill:
- fix-lint.md → 1k-code-quality (5.1 KB)
  - Lint fixes naturally belong with code quality standards
  - Consolidated all linting workflows in one place

Removed skill:
- 1k-dev-workflows (deleted)
  - All content successfully distributed to appropriate skills

Updated references:
- Updated all cross-references in other skills
- Updated 1k-new-skill skill categories table
- Maintained skill relationship graph

Benefits:
- Sentry analysis (34KB) now loads independently - huge token savings
- Better skill discoverability with specific trigger words
- Clearer separation of concerns
- Each skill has focused, single responsibility

Total content: 43 KB redistributed across 3 skills

* docs: add token optimization best practices to 1k-new-skill

Added comprehensive token optimization guidelines based on recent skill splitting experience:

New sections added:
1. Token optimization considerations
   - Decision criteria for splitting (file size, usage frequency, independence)
   - Keep-together criteria (correlation, shared concepts, small files)
   - Token savings formula with real-world examples

2. Splitting workflow
   - Step-by-step guide for splitting existing skills
   - File size analysis commands
   - Git rename tracking best practices
   - Cross-reference update process

3. Enhanced anti-patterns
   - Token optimization anti-patterns
   - Good vs bad splitting examples
   - Common mistakes to avoid

Real-world data included:
- 1k-coding-patterns split: 47-53% token savings in 90% of cases
- 1k-dev-workflows split: 80% savings when not analyzing Sentry

Benefits:
- Clear guidance on when to split vs merge skills
- Quantifiable decision criteria (>10 KB files, >1000 lines)
- Practical workflow for executing splits
- Evidence-based approach with actual measurements

This will help maintain optimal token efficiency as skill library grows.

* feat: add skills token monitoring tool and documentation

Created comprehensive token monitoring system for Claude Code Skills:

New files:
1. development/analyze-skills-tokens.py
   - Analyzes all skills and estimates token consumption
   - Identifies skills that should be split (>5k, >10k tokens)
   - Provides detailed per-file breakdown
   - Sorts by size to prioritize optimization
   - Uses conservative estimate: 1 token ≈ 4 characters

2. development/SKILLS-TOKEN-MONITORING.md
   - Complete monitoring guide and best practices
   - Decision criteria for splitting skills
   - Token savings formula with real-world examples
   - Recommended monitoring schedule
   - Current status snapshot and FAQs

Features:
- Automatic recommendations (URGENT/CONSIDER/MONITOR/OK)
- Detailed breakdown showing largest files per skill
- Sorting options (by name or by size)
- Usage tips and splitting guidelines
- Real-world savings data from recent splits

Current findings:
- Total: 23 skills, 76,200 tokens (303 KB)
- Urgent: react-best-practices (14,345 tokens)
- Consider: 1k-sentry-analysis, 1k-feature-guides, 1k-performance

Benefits:
- Proactive token optimization
- Data-driven splitting decisions
- Track skill growth over time
- Prevent token bloat

Usage:
  python3 development/analyze-skills-tokens.py
  python3 development/analyze-skills-tokens.py --sort-by-size
  python3 development/analyze-skills-tokens.py --detailed

* docs: add skill optimization analysis and recommendations

Analyzed 3 large skills (>5k tokens) for potential splitting:
- 1k-sentry-analysis (9,394 tokens)
- 1k-feature-guides (8,493 tokens)
- 1k-performance (6,267 tokens)

Key Findings:

**Recommendation: Keep all 3 intact**

Reasons for each skill:

1. 1k-sentry-analysis (9,394 tokens)
   - Linear workflow with sequential, interdependent steps
   - Users need complete workflow for Sentry error analysis
   - Splitting would break workflow coherence
   - High correlation: all steps used together

2. 1k-performance (6,267 tokens)
   - Comprehensive optimization guide needs holistic view
   - 8 categories are interdependent (list + memoization + async)
   - Below 10k threshold, acceptable for topic breadth
   - SKILL.md provides good Quick Reference
   - Users think "optimize performance" not individual categories

3. 1k-feature-guides (8,493 tokens)
   - All feature development workflows, used together
   - Adding features often needs pages + notifications + events
   - No single file too large (max 386 lines)
   - Splitting would force 2-4 skill loads instead of 1

Decision Framework Established:

Split if ALL true:
- File/skill >10KB OR multiple unrelated topics
- Topics have <50% usage correlation
- Distinct trigger words
- Each split >2KB (worth overhead)
- Natural split boundaries exist

Keep intact if ANY true:
- Linear workflow / sequential steps
- Topics used together (>50% correlation)
- Size <10k AND topics related
- Splitting breaks semantic coherence
- Users think of it as single concept

Priority for Future:
- react-best-practices (14,345 tokens) - urgent split needed
- Can split into 6 categories (bundle, rendering, async, js-perf, client, server)
- Would achieve 83% token reduction per category

Monitoring Thresholds:
- Re-evaluate if skills exceed 10-12k tokens
- Or if growth >30-60% from current size
- Or if unrelated topics added

Benefits of keeping intact:
- Workflow coherence maintained
- Better user experience (no skill jumping)
- Comprehensive reference in one place
- Acceptable token consumption (<10k)

* docs: add mandatory token analysis self-check for new skills

Added required token analysis step to skill creation workflow:

Changes to 1k-new-skill/SKILL.md:
- Added step 5 to "Output the skill" section
- Token analysis now REQUIRED before committing
- Verification checklist with clear action thresholds:
  - <2k tokens: Excellent, proceed
  - 2-5k tokens: Good, monitor growth
  - 5-10k tokens: Review split possibility, document correlation
  - >10k tokens: Must split before committing
- Commands to run analysis and check specific skill
- Reference to detailed monitoring guide

Changes to SKILLS-TOKEN-MONITORING.md:
- Updated monitoring schedule with new requirement
- Added "Post-Creation Self-Check" section
- Complete workflow example showing:
  1. Create skill
  2. REQUIRED: Run analysis
  3. Check results
  4. Take action (split if needed)
  5. Only then commit
- Acceptance criteria clearly defined
- Ensures all new skills optimized from day one

Benefits:
- Prevents token bloat at source
- Catches oversized skills before merge
- Establishes clear quality gate
- Self-documenting: developers know expectations
- Proactive optimization vs reactive splitting

This makes token optimization a required part of the development process,
not an afterthought.

* refactor: organize skills analysis files into dedicated directory

Move skills token analysis files into development/skills-analysis/:
- analyze-skills-tokens.py (token analysis tool)
- SKILLS-TOKEN-MONITORING.md (monitoring guide)
- SKILL-OPTIMIZATION-ANALYSIS.md (optimization docs)

Update all references in:
- .claude/skills/1k-new-skill/SKILL.md
- Command examples and documentation links

---------

Co-authored-by: Claude Sonnet 4.5 <[email protected]>

Author: huhuanming

.claude/skills/1k-code-quality/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: 1k-code-quality
+description: Code quality standards for OneKey. Use when fixing lint warnings, running pre-commit tasks, handling unused variables, writing comments, or ensuring code quality. All comments must be in English. Triggers on lint, linting, eslint, oxlint, tsc, type check, unused variable, comment, documentation, spellcheck, code quality, pre-commit, yarn lint.
+allowed-tools: Read, Grep, Glob
+---
+
+# Code Quality
+
+Linting, documentation, and general code quality standards for OneKey.
+
+## Lint Commands
+
+```bash
+# Pre-commit (fast, only staged files)
+yarn lint:staged
+yarn tsc:staged
+
+# CI only (full project check)
+yarn lint        # Comprehensive: TypeScript, ESLint, folder structure, i18n
+yarn lint:only   # Quick: oxlint only
+yarn tsc:only    # Full type check
+```
+
+**Note:** `yarn lint` is for CI only. For pre-commit, always use `yarn lint:staged`.
+
+## Pre-Commit Workflow
+
+For fast pre-commit validation:
+```bash
+# Lint only modified files (recommended)
+yarn lint:staged
+
+# Or with type check
+yarn lint:staged && yarn tsc:staged
+```
+
+## Common Lint Fixes
+
+```typescript
+// Unused variable - prefix with underscore
+const { used, unused } = obj;     // ❌ Error: 'unused' is defined but never used
+const { used, unused: _unused } = obj;  // ✅ OK
+
+// Unused parameter - prefix with underscore
+function foo(used: string, unused: number) {}     // ❌ Error
+function foo(used: string, _unused: number) {}    // ✅ OK
+
+// Floating promise - add void or await
+someAsyncFunction();        // ❌ Error: Promises must be awaited
+void someAsyncFunction();   // ✅ OK (fire-and-forget)
+await someAsyncFunction();  // ✅ OK (wait for result)
+```
+
+## Language Requirements
+
+**All comments must be written in English:**
+
+```typescript
+// ✅ GOOD: English comment
+// Calculate the total balance including pending transactions
+
+// ❌ BAD: Chinese comment
+// 计算总余额，包括待处理的交易
+
+// ✅ GOOD: JSDoc in English
+/**
+ * Fetches user balance from the blockchain.
+ * @param address - The wallet address to query
+ * @returns The balance in native token units
+ */
+async function fetchBalance(address: string): Promise<bigint> {
+  // ...
+}
+```
+
+## When to Comment
+
+```typescript
+// ✅ GOOD: Explain non-obvious logic
+// Use 1.5x gas limit to account for estimation variance on this chain
+const gasLimit = estimatedGas * 1.5n;
+
+// ✅ GOOD: Explain business logic
+// Premium users get 50% discount on transaction fees
+const fee = isPremium ? baseFee * 0.5 : baseFee;
+
+// ❌ BAD: Obvious comment
+// Set the value to 5
+const value = 5;
+```
+
+## Development Principles
+
+### Single Responsibility
+Each function should perform a single, atomic task:
+
+```typescript
+// ✅ GOOD: Single responsibility
+async function fetchUserBalance(userId: string): Promise<Balance> {
+  const user = await getUser(userId);
+  return await getBalanceForAddress(user.address);
+}
+
+// ❌ BAD: Multiple responsibilities
+async function fetchUserBalanceAndUpdateUI(userId: string) {
+  const user = await getUser(userId);
+  const balance = await getBalanceForAddress(user.address);
+  setBalanceState(balance);
+  showNotification('Balance updated');
+  logAnalytics('balance_fetched');
+}
+```
+
+### Avoid Over-Abstraction
+Don't create helpers for one-time operations:
+
+```typescript
+// ❌ BAD: Over-abstracted
+const createUserFetcher = (config: Config) => {
+  return (userId: string) => {
+    return fetchWithConfig(config, `/users/${userId}`);
+  };
+};
+const fetchUser = createUserFetcher(defaultConfig);
+const user = await fetchUser(userId);
+
+// ✅ GOOD: Simple and direct
+const user = await fetch(`/api/users/${userId}`).then(r => r.json());
+```
+
+## Detailed Guides
+
+### Code Quality Standards
+See [code-quality.md](references/rules/code-quality.md) for comprehensive guidelines:
+- Linting commands and pre-commit workflow
+- Comment and documentation standards
+- Language requirements (English only)
+- Single responsibility principle
+- Avoiding over-abstraction
+- Consistent naming conventions
+- Code quality checklist
+
+### Fixing Lint Warnings
+See [fix-lint.md](references/rules/fix-lint.md) for complete lint fix workflow:
+- Analyzing lint warnings
+- Categorizing lint errors
+- Common fix patterns by category
+- Spellcheck fixes
+- Unused variable/parameter handling
+- Automated fix strategies
+- Testing after fixes
+
+## Spellcheck
+
+If a technical term triggers spellcheck errors:
+```bash
+# Check if word exists
+grep -i "yourword" development/spellCheckerSkipWords.txt
+
+# Add if not present (ask team lead first)
+echo "yourword" >> development/spellCheckerSkipWords.txt
+```
+
+## Checklist
+
+### Pre-commit
+- [ ] `yarn lint:staged` passes
+- [ ] `yarn tsc:staged` passes
+
+### Code Quality
+- [ ] All comments are in English
+- [ ] No commented-out code committed
+- [ ] Functions have single responsibility
+- [ ] No unnecessary abstractions
+- [ ] Consistent naming conventions
+
+## Related Skills
+
+- `/1k-sentry-analysis` - Sentry error analysis and fixes
+- `/1k-test-version` - Test version creation workflow
+- `/1k-coding-patterns` - General coding patterns

…atterns/references/rules/code-quality.md …quality/references/rules/code-quality.md.claude/skills/1k-coding-patterns/references/rules/code-quality.md renamed to .claude/skills/1k-code-quality/references/rules/code-quality.md .claude/skills/1k-coding-patterns/references/rules/code-quality.md renamed to .claude/skills/1k-code-quality/references/rules/code-quality.md

@@ -10,39 +10,12 @@ allowed-tools: Read, Grep, Glob, Write, Edit
 
 | Topic | Guide | Key Points |
 |-------|-------|------------|
-| Date formatting | [date-formatting.md](references/rules/date-formatting.md) | Use `formatDate()` from dateUtils, never native JS |
-| Internationalization | [i18n.md](references/rules/i18n.md) | Use `ETranslations` enum, never hardcode strings |
 | Promise handling | [promise-handling.md](references/rules/promise-handling.md) | Always await or use `void`, never floating promises |
 | React components | [react-components.md](references/rules/react-components.md) | Named imports, functional components, no FC type |
 | Restricted patterns | [restricted-patterns.md](references/rules/restricted-patterns.md) | Forbidden: `toLocaleLowerCase`, direct hd-core import |
-| Error handling | [error-handling.md](references/rules/error-handling.md) | Try/catch for async, user-friendly messages |
-| Code quality | [code-quality.md](references/rules/code-quality.md) | English comments, lint before commit |
-| Cross-platform | [cross-platform.md](references/rules/cross-platform.md) | Use `platformEnv`, file extensions for platform code |
 
 ## Critical Rules Summary
 
-### Date Formatting
-
-```typescript
-// ❌ FORBIDDEN
-date.toLocaleDateString()
-
-// ✅ CORRECT
-import { formatDate } from '@onekeyhq/shared/src/utils/dateUtils';
-formatDate(date, { hideSeconds: true });
-```
-
-### Internationalization
-
-```typescript
-// ❌ FORBIDDEN
-<Text>Confirm</Text>
-
-// ✅ CORRECT
-import { ETranslations } from '@onekeyhq/shared/src/locale';
-intl.formatMessage({ id: ETranslations.global__confirm });
-```
-
 ### Promise Handling
 
 ```typescript
@@ -81,48 +54,14 @@ const { x } = await CoreSDKLoader();
 import { localDb } from '...';
 ```
 
-### Error Handling
-
-```typescript
-// ❌ BAD - silent failure
-try { await risky(); } catch (e) {}
-
-// ✅ CORRECT
-try {
-  await risky();
-} catch (error) {
-  console.error('Failed:', error);
-  Toast.error({ title: 'Operation failed' });
-}
-```
-
-### Code Quality
-
-```bash
-# Pre-commit (fast, recommended)
-yarn lint:staged
-yarn tsc:staged
-
-# CI only (full project check)
-yarn lint
-```
-
-### Cross-Platform
-
-```typescript
-// ✅ CORRECT - Use platformEnv
-import platformEnv from '@onekeyhq/shared/src/platformEnv';
-if (platformEnv.isNative) { /* mobile */ }
-
-// ✅ CORRECT - Use file extensions
-// MyComponent.native.tsx, MyComponent.web.tsx
-
-// ❌ FORBIDDEN
-if (typeof window !== 'undefined') { }
-```
-
 ## Related Skills
 
+- `/1k-date-formatting` - Date and time formatting
+- `/1k-i18n` - Internationalization and translations
+- `/1k-error-handling` - Error handling patterns
+- `/1k-cross-platform` - Platform-specific code
+- `/1k-code-quality` - Linting and code quality
+- `/1k-performance` - Performance optimization
 - `/1k-state-management` - Jotai atom patterns
 - `/1k-architecture` - Project structure and import rules
-- `/1k-dev-workflows` - Lint fixes, pre-commit tasks
+- `/1k-code-quality` - Lint fixes, pre-commit tasks